Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT

[Masinter.pa@Xerox.COM]

Sandra sent me a list of possible options of what your working group
might do on the issue of pathnames.

I had imagined a bottom-up approach, going from current practice in
various systems (especially the networked systems)  that try to deal
simultaneously with multiple operating systems, into something that
could be generally adopted. 

Of the options that Sandra sent me, these are my preferences:

(1) Try to establish and document what constitutes portable usage,
independent of additional restrictions or new functionality. 

(2) Try to specify a portable extension for dealing with hierarchical
file systems (such as provided by Unix, VMS,  Tops-20, Symbolics,
MS-DOS, Macintosh, Xerox), and pathnames that specify directories
instead of files

(3) For various common operating systems, specify exactly what can go
into each pathname component.  Clarify things like whether the square
brackets that surround a directory specification in VMS filename syntax
are actually part of the string stored in the directory field or not,
whether the "." that usually separates the name and type fields is part
of one or the other or neither, etc.

(4) Specify what MAKE-PATHNAME should do if it can't build a valid
pathname from the arguments it gets.  (PARSE-NAMESTRING either signals
an error or returns NIL, depending on the value of the :JUNK-ALLOWED
argument.)

(5) Clear up what should happen if the operating system just doesn't
support the notion of one or another of the pathname components, such as
versions on Unix or directories on CTSS.  Also come up with some way of
dealing with case (in)sensitivity, maximum lengths on the various
fields, and what characters are valid in filenames.  (Versions are
particularly important in the context of OPEN.)

I don't like this one, but only because no-one has convinced me of its
usefulness and
I don't like adding useless features:

(6) Add an optional argument to TRUENAME to indicate that you want
translation only, without checking to see if the file really exists or
not.

Sandra sent a suggestion about removing requirements on (PATHNAME
<sybmol>), but I think the sentiment is to remove the automatic coercion
of symbols into pathnames entirely, so that (PATHNAME <symbol>) is an
error (see issue PATHNAME-SYMBOL).