[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
truename, merge-pathnames, etc.
- To: Sandra J Loosemore <firstname.lastname@example.org>
- Subject: truename, merge-pathnames, etc.
- From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
- Date: Thu, 6 Aug 87 19:07 EDT
- Cc: email@example.com
- In-reply-to: <8708062011.AA16097@orion.utah.edu>
Date: Thu, 6 Aug 87 14:11:14 MDT
From: firstname.lastname@example.org (Sandra J Loosemore)
I'm having a problem with incorrect expansion of pathnames under VMS, when
logical names are used. The problem happens when I, or the Lisp runtime, does
(merge-pathnames "LIBRARY:" *default-pathname-defaults*)
My logical name "LIBRARY:" is likely to translate to a string that supplies
both a device and directory. However, the Lisp doesn't do the translation and
is instead pulling the directory from *default-pathname-defaults*, with the
end result that it builds up a pathname pointing to the wrong place. I can't
use TRUENAME to force translation of the logical name first, because it
complains about not being able to find a file that matches the incomplete
specification. And, I can't build up a complete file specification to give
to TRUENAME because of the other problem. Perhaps we need another function
like TRUENAME that just does the name translation without checking to see
that the file exists?
This is what :UNSPECIFIC as a pathname component is good for.
(Not that we implement it in this particular case, either).
The people who borrowed the Symbolics pathname system for
Common Lisp emasculated it without understanding it.
The idea is that if a pathname *isn't supposed to have* certain
components, then you use :UNSPECIFIC. If they're just not supplied
yet, use NIL. Then MERGE-PATHNAMES can figure out the right thing
to do for itself.
Of course, this moves the burden onto the shoulders of PARSE-PATHNAME.
For UNIX pathnames (distinguishing between "foo", and "foo.", and
"foo" with no type specified yet), this is apparent from the syntax.
Since the designers of VMS didn't choose to make their pathname syntax
independent of run-time context (boo, hiss!), PARSE-PATHNAME has to
be able to ask the operating system what logical pathname translations
are in effect at the time.
The pathname section of CLtL is full of gotcha's like this. It is
in need of some serious cleanup.