[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
truename, merge-pathnames, etc.
- To: firstname.lastname@example.org (Sandra J Loosemore)
- Subject: truename, merge-pathnames, etc.
- From: Ram@C.CS.CMU.EDU
- Date: Sat, 08 Aug 1987 20:46:00 -0000
- Cc: common-lisp@SAIL.STANFORD.EDU
- In-reply-to: Msg of 6 Aug 1987 16:11-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore)
- Sender: RAM@
In CMU Common Lisp, we have hacked around these problems by playing
with the rules for filename parsing. Although the result may be
somewhat nonintuitive, it is legal common Lisp, since the
namestring => pathname translation is not specified. Parse-Namestring
contrives to translate pathnames so that Merge-Pathnames "works
right". This is mostly done by by sticking special values in the
pathname, and is probably similar to the notion of :Unspecified.
For example, we get around to problem you mention by having:
(pathname-device "foo:") => #()
That is, a namestring that specifies only a device is translated so as
to make explcit that a directory is being specified as well. The
directory has no components, so NAMESTRING translates back to the
original namestring, but merging of other directories in inhibited.
We are currently running on a Unix filesystem. Since Unix has no
notion of devices or logical names, we use the pathname device field
for a "search list" mechanism that is implemented by Lisp. If we were
on a filesystem where devices meant anything, then this hack probably
wound't work so well.
There are also some other cases in which merging is inhibited by the
appropriate namestring translation:
(pathname-device "/foo/") => :ABSOLUTE
(pathname-device "foo/") => "Default"
(pathname-type "foo.") => ""
I agree that Common Lisp should address this, and think that a general
solution would be appropriate, but it is possible in many cases to do
the right thing within the constraints of the current MERGE-PATHNAMES
definition by tweaking the namestring translation.