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
|
