inconsistent pathnames

At least on 19d this doesn't work:

* (namestring "...")

This is due to the fact that PARSE-NAMESTRING returns
something that
LISP::UNPARSE-UNIX-FILE doesn't like:

* (describe (parse-namestring "..."))

#P(:NAME "...") is a structure of type PATHNAME.
HOST: #<LISP::UNIX-HOST>.
DEVICE: NIL.
DIRECTORY: NIL.
NAME: "...".
TYPE: NIL.
VERSION: NIL.

To mend the error I'd propose something like this:

diff -c -r1.103 filesys.lisp
*** filesys.lisp	4 Aug 2007 23:54:37 -0000	1.103
--- filesys.lisp	5 Sep 2007 15:30:04 -0000
***************
*** 336,346 ****
  		     ;; nil.
  		     (setf pieces (append pieces (list (cons tail-start
tail-end))))
  		     (values nil nil nil))
  		    ((not (find-if-not #'(lambda (c)
  					   (char= c #.))
  				       namestr :start tail-start :end tail-end))
! 		     ;; Got a bunch of dots.  Make it a file of the same
name, and type nil.
! 		     (values (subseq namestr tail-start tail-end) nil
nil))
  		    (t
  		     (extract-name-type-and-version namestr tail-start
tail-end)))))
  	;; PVE: Make sure there are no illegal characters in the
name
--- 336,350 ----
  		     ;; nil.
  		     (setf pieces (append pieces (list (cons tail-start
tail-end))))
  		     (values nil nil nil))
+ 		    ((string= namestr "." :start1 tail-start
:end1 tail-end)
+ 		     ;; "." is a directory as well.
+ 		     (setf pieces (append pieces (list (cons tail-start
tail-end))))
+ 		     (values nil nil nil))
  		    ((not (find-if-not #'(lambda (c)
  					   (char= c #.))
  				       namestr :start tail-start :end tail-end))
! 		     ;; Got a bunch of dots.  Make it a file of the same
name, and type the empty string.
! 		     (values (subseq namestr tail-start (1- tail-end))
"" nil))
  		    (t
  		     (extract-name-type-and-version namestr tail-start
tail-end)))))
  	;; PVE: Make sure there are no illegal characters in the
name
***************
*** 507,513 ****
  		     (find #. name :start 1))
  	    ;; A single leading dot is ok.
  	    (error "Cannot specify a dot in a pathname name
without a pathname type: ~S" name))
! 	  (when (or (string= ".." name)
  		    (string= "." name))
  	    (error "Invalid value for a pathname name:
~S" name)))
  	(strings (unparse-unix-piece name)))
--- 511,518 ----
  		     (find #. name :start 1))
  	    ;; A single leading dot is ok.
  	    (error "Cannot specify a dot in a pathname name
without a pathname type: ~S" name))
! 	  (when (or (and (string= ".." name)
! 			 (not type-supplied))
  		    (string= "." name))
  	    (error "Invalid value for a pathname name:
~S" name)))
  	(strings (unparse-unix-piece name)))
*** pathname.lisp	08 Nov 2005 18:12:29 +0100	1.84
--- pathname.lisp	05 Sep 2007 17:53:58 +0200	
***************
*** 784,790 ****
  		(check-component-validity d :directory))
  	    (cdr dir))
        (when (and (stringp name)
! 		 (or (string= name "..") (string= name
".")))
  	(warn "Silly argument for a unix PATHNAME-NAME:
~S" name)))
  
      ;; More sanity checking
--- 784,792 ----
  		(check-component-validity d :directory))
  	    (cdr dir))
        (when (and (stringp name)
! 		 (or (and (string= name "..")
! 			  (not type))
! 		     (string= name ".")))
  	(warn "Silly argument for a unix PATHNAME-NAME:
~S" name)))
  
      ;; More sanity checking


The patch does two things:
 - it parses "..." into a name=".." and
type="" as it already did for
   namestrings like "foo."
 - it accepts (make-pathname :name ".." :type
"") as consequence of #1


Side note.
SBCL doesn't seem to suffer from this problem, but it looks
like that
code might be quite different as it doesn't even try to
handle "."
and ".." specially, unless they are followed by a
"/".  Considering
that Unix allows things like "cat .", maybe SBCL's
approach is the
one closer to the Unix philosophy.

-- 
walter pelissero
http://www.pelissero.de

>>>>> "WP" == Walter C Pelissero
<walterpelissero.de> writes:

    WP> At least on 19d this doesn't work:
    WP> * (namestring "...")

    WP> This is due to the fact that PARSE-NAMESTRING
returns something that
    WP> LISP::UNPARSE-UNIX-FILE doesn't like:

    WP> * (describe (parse-namestring "..."))

    WP> #P(:NAME "...") is a structure of type
PATHNAME.
    WP> HOST: #<LISP::UNIX-HOST>.
    WP> DEVICE: NIL.
    WP> DIRECTORY: NIL.
    WP> NAME: "...".
    WP> TYPE: NIL.
    WP> VERSION: NIL.

[patch snipped]

    WP> The patch does two things:
    WP>  - it parses "..." into a
name=".." and type="" as it already did
for
    WP>    namestrings like "foo."
    WP>  - it accepts (make-pathname :name ".."
:type "") as consequence of #1

Shouldn't namestring (unparse-unix-file?) be changed to
accept name
"..." and type nil?  This makes more sense to me
since "abc" is parsed
as name "abc" and type nil.  But I guess name
".." and type "" is
acceptable too.

I also now see there are a whole bunch of issues, like how
should
"..a" be parsed?  Is it name = "..a",
type = nil, or name = ".", type
"a", or something else?  My head hurts.

    WP> Side note.
    WP> SBCL doesn't seem to suffer from this problem,
but it looks like that
    WP> code might be quite different as it doesn't even
try to handle "."
    WP> and ".." specially, unless they are
followed by a "/".  Considering

I think these things were changed to get more print/read
consistency
with pathnames.

    WP> that Unix allows things like "cat .",
maybe SBCL's approach is the

On Solaris, Mac OS X, and Linux:

$ /bin/cat .
cat: input error on .: Is a directory

Ray

Raymond Toy (RT/EUS) writes:
 >     WP> The patch does two things:
 >     WP>  - it parses "..." into a
name=".." and type="" as it already did
for
 >     WP>    namestrings like "foo."
 >     WP>  - it accepts (make-pathname :name
".." :type "") as consequence of #1
 > 
 > Shouldn't namestring (unparse-unix-file?) be changed
to accept name
 > "..." and type nil?  This makes more sense
to me since "abc" is
 > parsed as name "abc" and type nil.  But I
guess name ".." and type
 > "" is acceptable too.

So you mean to change the interpretation of
"foo."?

 > I also now see there are a whole bunch of issues, like
how should
 > "..a" be parsed?  Is it name =
"..a", type = nil, or name = ".", type
 > "a", or something else?  My head hurts.

I suppose anything goes as long as you are consistent. 
After all the
concept of file type in the pathname is alien to the Unix
filesystem.
Though, I can immagine, different behaviours from different
Lisp
implementations may cause portability issues.

 >     WP> that Unix allows things like "cat
.", maybe SBCL's approach is the
 > 
 > On Solaris, Mac OS X, and Linux:
 > 
 > $ /bin/cat .
 > cat: input error on .: Is a directory

Are you working on a NFS filesystem?  That's not the
behaviour of a
Posix open().

-- 
walter pelissero
http://www.pelissero.de

Raymond Toy (RT/EUS) writes:
 > >  > I also now see there are a whole bunch of
issues, like how should
 > >  > "..a" be parsed?  Is it name =
"..a", type = nil, or name = ".", type
 > >  > "a", or something else?  My head
hurts.
 > > 
 > > I suppose anything goes as long as you are
consistent.  After all the
 > > concept of file type in the pathname is alien to
the Unix filesystem.
 > > Though, I can immagine, different behaviours from
different Lisp
 > > implementations may cause portability issues.
 > 
 > Converting strings to pathnames has never been
portable.  If you want 
 > portability, you need to use make-pathname directly.

Well, there are situation where you can't use MAKE-PATHNAME
yourself.
DIRECTORY, for instance, will use it for you.  That BTW was
the source
of my problems.  Knowing in advance what goes in type and
what goes in
name, I believe, does simplify writing portable code.

 > >  >     WP> that Unix allows things like
"cat .", maybe SBCL's approach is the
 > >  > 
 > >  > On Solaris, Mac OS X, and Linux:
 > >  > 
 > >  > $ /bin/cat .
 > >  > cat: input error on .: Is a directory
 > > 
 > > Are you working on a NFS filesystem?  That's not
the behaviour of a
 > > Posix open().
 > 
 > Actually, on Solaris it was an NFS system.  But for
Mac OS X, and Linux, 
 > it was not.  But on Solaris cat /bin dumps out the
directory.

A friend confirmed that although Linux cat complains when
fed with a
directory, the behaviour of its open(2) is in line with
Posix.  That
is, it will happily open a directory.

Funny enough, I'm running FreeBSD from which Mac OS X should
descend.

-- 
walter pelissero
http://www.pelissero.de

Raymond Toy (RT/EUS) writes:
 > Walter C. Pelissero wrote:
 > > Raymond Toy (RT/EUS) writes:
 > >  > >  > I also now see there are a whole
bunch of issues, like how should
 > >  > >  > "..a" be parsed?  Is
it name = "..a", type = nil, or name =
".", type
 > >  > >  > "a", or something
else?  My head hurts.
 > >  > > 
 > >  > > I suppose anything goes as long as you
are consistent.  After all the
 > >  > > concept of file type in the pathname
is alien to the Unix filesystem.
 > >  > > Though, I can immagine, different
behaviours from different Lisp
 > >  > > implementations may cause portability
issues.
 > >  > 
 > >  > Converting strings to pathnames has never
been portable.  If you want 
 > >  > portability, you need to use make-pathname
directly.
 > > 
 > > Well, there are situation where you can't use
MAKE-PATHNAME yourself.
 > > DIRECTORY, for instance, will use it for you. 
That BTW was the source
 > > of my problems.  Knowing in advance what goes in
type and what goes in
 > > name, I believe, does simplify writing portable
code.
 > 
 > Where can't you use make-pathname yourself?  What do
you mean directory 
 > will use it for you?  (directory (make-pathname
:directory '(:absolute) 
 > :name :wild)) works for me.
 > 
 > I would like to know how directory was the source of
your problem.  Was 
 > it because directory returned a list of pathnames for
which no 
 > namestring could be printed, like "..."?

Yes.

~ $ cd ~/tmp
~/tmp $ mkdir foobar
~/tmp $ cd foobar
~/tmp/foobar $ touch ...
~/tmp/foobar $ lisp -init /dev/null
; Loading #P"/dev/null".
CMU Common Lisp 19d Release (19D), running on
zaphod.home.loc
With core:
/usr/home/local/cmucl-19d/lib/cmucl/lib/lisp.core
Dumped on: Thu, 2006-11-23 01:30:40+01:00 on
bsdcpu.csl.sri.com
See <http://www.cons.org/cm
ucl/> for support information.
Loaded subsystems:
    Python 1.1, target Intel x86
    CLOS based on Gerd's PCL 2004/04/14 03:32:47
* (namestring (car (directory (make-pathname :directory
'(:relative)))))


Error in function LISP::UNPARSE-UNIX-FILE:
   Cannot specify a dot in a pathname name without a
pathname type: "..."
   [Condition of type SIMPLE-ERROR]

Restarts:
  0: [ABORT] Return to Top-Level.

Debug  (type H for help)

(LISP::UNPARSE-UNIX-FILE
 #P(IRECTORY
(:ABSOLUTE "usr" "home" "wcp"
"tmp" ...) :NAME "..."))
Source: Error finding source: 
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source
file no longer exists:
  target:code/filesys.lisp.
0] 

 > BTW, I've applied your patch.  It looks good, and
actually fixes the 
 > issue I raised about "..a".  It is now :name
".", :type "a".

This was actually my main concern, with my patch
".foo" and "..foo"
are treated differently.  Which one is the right one is
matter of
philosophical debate.  On the other hand

  (pathname "..foo")

used to produced an invalid pathname.

-- 
walter pelissero
http://www.pelissero.de

http:/
/common-lisp.net/project/names-and-paths anyone?  (The
hosting  
machine is currently down due to a move to a different
location in  
Milan. it will be up next week)

Cheers

Marco




On Sep 6, 2007, at 10:09 AM, Walter C. Pelissero wrote:

> Raymond Toy (RT/EUS) writes:
>>>> I also now see there are a whole bunch of
issues, like how should
>>>> "..a" be parsed?  Is it name =
"..a", type = nil, or name = ".",  
>>>> type
>>>> "a", or something else?  My head
hurts.
>>>
>>> I suppose anything goes as long as you are
consistent.  After all  
>>> the
>>> concept of file type in the pathname is alien
to the Unix  
>>> filesystem.
>>> Though, I can immagine, different behaviours
from different Lisp
>>> implementations may cause portability issues.
>>
>> Converting strings to pathnames has never been
portable.  If you want
>> portability, you need to use make-pathname
directly.
>
> Well, there are situation where you can't use
MAKE-PATHNAME yourself.
> DIRECTORY, for instance, will use it for you.  That BTW
was the source
> of my problems.  Knowing in advance what goes in type
and what goes in
> name, I believe, does simplify writing portable code.
>
>>>>     WP> that Unix allows things like
"cat .", maybe SBCL's  
>>>> approach is the
>>>>
>>>> On Solaris, Mac OS X, and Linux:
>>>>
>>>> $ /bin/cat .
>>>> cat: input error on .: Is a directory
>>>
>>> Are you working on a NFS filesystem?  That's
not the behaviour of a
>>> Posix open().
>>
>> Actually, on Solaris it was an NFS system.  But for
Mac OS X, and  
>> Linux,
>> it was not.  But on Solaris cat /bin dumps out the
directory.
>
> A friend confirmed that although Linux cat complains
when fed with a
> directory, the behaviour of its open(2) is in line with
Posix.  That
> is, it will happily open a directory.
>
> Funny enough, I'm running FreeBSD from which Mac OS X
should descend.
>
> -- 
> walter pelissero
> http://www.pelissero.de
>

--
Marco Antoniotti, Associate Professor
DISCo, Università Milano Bicocca
Via Bicocca degli Arcimboldi 8, U7, 4 piano
I-20126 Milan (MI) ITALY

Please note that I am not checking my Spam-box anymore.