[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: Mon, 23 Jan 89 14:59:40 -0500
Posted-Date: Fri, 20 Jan 89 19:43:16 -0500
Date: Fri, 20 Jan 89 19:43:16 -0500
We have had some problems with file-name translations and have
had to make some changes in the way logical and physical
pathnames are parsed. Specifically, we've had to change
logical names so that all case information is retained (instead
of upcasing by default). Also, the flavor LOWER-CASE-PREFERRED-MIX
which is mixed into unix pathnames is broken.
(try (send #p"<unix-host>:/foo/foo.lisp" :new-name "bar")
(send #p"<unix-host>:/foo/foo.lisp" :new-name "BAR")
(notice the case inversion)
We've fixed this to work properly along with allowing things
like README to be accessed (names with all caps).
This case-inversion behavior is fully documented, not a bug. It is
described in the "Streams, Files, and I/O" manual; look for
"interchange case". The purpose is to make things like
(copy-file "<VMS-host>:[DIR]FOO.LISP" "<unix-host>:/dir/")
work as expected (i.e., the result file should be named "foo.lisp",
not "FOO.LISP"). The :NEW-RAW-NAME message is intended for your
I don't think that you caught the whole point. The flavor in which
the above inversion occurs in called LOWERCASE-PREFERRED-MIXIN,
implying that things in uppercase will translate to lower. The
bug is that when this flavor is handed things in lowercase,
they are translated to upper. This behavior is not at all desirable,
and is something I call a bug.
I caught the whole point; I've explained this confusing feature to many
people over the years. I also understand the problems it causes; we've
got a "portable" file manipulation package whose biggest problems have
been caused by the different ways in which Common Lisp implementations
perform pathname operations, and case is one of themost insidious
differences. Yet I still maintain that Symbolics has done things in the
best way for an implementation that supports a heterogeneous file
Please read pages 71-73 of "Streams, Files, and I/O". When using
non-:RAW operations, uppercase components represent the file server's
preferred case, lowercase components represent the opposite case, and
mixed case components are left alone. In the case of file systems on
which lowercase is preferred (such as Unix), this means that the
non-:RAW operations (which include the Common Lisp pathname functions)
toggle the case of monocase components.
Note, by the way, that everything is still kept consistent in this
(pathname-name "<unix>:/foo/bar.lisp") => "BAR"
:new-name (pathname-name "<unix>:/foo/quux.bin"))
You only run into problems when you try to cons pathnames from strings
that didn't originate in the pathname software, e.g.
(let ((new-name (accept 'string :prompt "New name")))
(send pathname :new-name new-name))
In this case, it would probably be more appropriate to use
:NEW-RAW-NAME, since users don't generally type in interchange case.
Ok, I see your point but the scheme doesn't work. Suppose I have
a defsystem form and I have a short-name attribute "foo". If this
system is stored on a unix host with a physical default pathname,
the system will try to look for files of the form
FOO.system-dir, etc.., instead of foo.system-dir. Thats not at
all what I expect, nor what is stored on the unix machine.
This problem manifests itself in many different forms, in
places where none of my code is responsible for sending parsing messages
to the pathname. Why shouldn't LOWER-CASE-PREFERRED-MIXIN do exactly
what it says?