truename, merge-pathnames, etc.

[Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>]

    Date: Thu, 6 Aug 87 14:11:14 MDT
    From: sandra%orion@cs.utah.edu (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
    something like

	(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?

    -Sandra
    -------

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.