Re: inconsistent pathnames

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