>>>>> "WP" == Walter C Pelissero <[EMAIL PROTECTED]> 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
