Re: portability of pathnames

[SANDRA <LOOSEMORE@UTAH-20.ARPA>]

I'm afraid I don't have a real good proposal to offer on this issue, other
than to describe how we have tackled the issue in PCLS, which currently
handles VMS and Unix file systems and has hooks for a few others.  Basically,
we view the pathname as consisting of a "place" (the host, device, and
directory), a name, and a type, and don't do too much with versions.  There
are consistent conventions for the name and type on all machines; ie, you
can pass lowercase strings with no delimiters to make-pathname and get
something reasonable.  (If there are characters in the strings which are
invalid for that particular file system, some appropriate kind of
translation usually occurs automagically.)  The specification of the
"place" parts of the pathname, on the other hand, are machine dependent.
Although the hooks are there to support it, we never pass "place"
components to make-pathname in portable code.  Instead, we use
merge-pathnames.  (We generally only worry about this when we are trying to
find a library file, and in that case the namestring for the "place" is
stored in a global variable; "places" are usually installation-specific
anyway.)

There really seem to be only three situations that probably cover about 95%
of the cases where you want to muck with pathnames:

(1) The user has supplied a complete file name as a string and you want to
find that file.

(2) You are looking for a file with a given name and type in one of several
possible places -- often the default place.

(3) You have somehow acquired a complete pathname and you want to find a
file in the same place with the same name, but with a different extension.
(Like creating a FOO.BIN file in the same place that you found the
corresponding FOO.LISP.)

I would be very happy to see the standard firmed up just enough so that you
can do these three operations in a portable manner.  At the very least, the
manual should make clear what operations are guaranteed to work on all
implementations and which are implementation-specific extensions.

-Sandra
-------