Re: inconsistent pathnames

Walter C. Pelissero wrote:
> 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."?

No, "foo." should have name "foo" and type "".  As I said your 
interpretation of "..." as name ".." and type "." is ok.
> 
>  > 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.
> 
>  >     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.

In any case, thanks for the patch.  I'll apply it and run some tests to 
see how things go.  (It's easy to break pathname stuff by accident.)

Ray