Re: portability of pathnames

[shebs%utah-orion@utah-cs.arpa (Stanley Shebs)]

>From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
>I came across your complaint about portability of pathnames and the
>problems with make-pathname.  I was just wondering if
>you had anything specific to propose.

I submit there are NO portable things to be done with pathnames.
Even something as innocuous as (load "foo-bar-baz") isn't going to
be portable to machines with only short filenames, or ones that don't
allow hyphens in filenames.  Proposals that the implementation can
map names around are bogus, since in the simplest case (changing chars
in the name) things like

	(with-open-file (s1 "foo-bar-baz" :direction :output)
		(with-open-file (s2 "foo_bar_baz" :direction :output)
			...))

will get pretty strange, and in the most complex case, the implementation must
have its own mini-filesystem to conform to the standard.  As things
stand now, you can't have a Common Lisp on a machine without a filesystem!
More plausibly, you can't have one where random objects like floating-point
numbers designate files (a la the EZ programming environment).

In the practice of porting programs, I've had to put all explicit filenames
and pathname operations into machine-specific files.  Even something like

	(merge-pathnames :type "lisp" :defaults "/usr/games/doctor")

is not guaranteed to work on a Unix implementation that decides (correctly)
that Unix files don't really have types.

My proposal: flush all pathname stuff entirely.  Pathnames are abstract
objects with no user-visible components.  The PATHNAME function still exists
to coerce other kinds of objects (probably strings) into pathnames; OPEN
and other operations need not look any different.  TRUENAME is probably
still worthwhile, but none of the others are truly portable, so there's
little point in standardizing on them.  Implementations can provide whatever
ones are appropriate.

There's a certain analogy with character bits and fonts, the main difference
being that more people feel compelled to do *something* with pathnames.
The standard is so full of loopholes that once one gets outside the realm
of vanilla Unix/VMS/Tops-20 filenames, any pathname manipulation is just
not going to work right.  So let's shrink the standard and not exercise
ourselves trying to design a filesystem interface that will accommodate
every strangeness invented by the OS people.

							stan