Christophe Rhodes <firstname.lastname@example.org> wrote:
| email@example.com (Rob Warnock) writes:
| > > (namestring (make-pathname :directory '(:ABSOLUTE "tmp" "foo")
| > :name "bar"))
| > "/tmp/foo/bar"
| > > (namestring (make-pathname :directory '(:ABSOLUTE "tmp" "foo" "bar")))
| > "/tmp/foo/bar/"
| > So namestrings need *some* convention to distinguish the 3rd & 4th
| > cases [1st and 2nd as edited - CSR] otherwise you couldn't get the
| > same pathname back [second invariant above].
| What makes you assume that either or both of these pathnames must have
| a namestring? Your argument assumes this property, but it's certainly
| not the case that all pathnames have namestrings.
Good point. I was specifically addressing Peter's particular question,
but you're absolutely right that in general:
19.1.2 Pathnames as Filenames
In addition, pathnames can also represent certain partially
composed filenames for which an underlying file system might
not have a specific namestring representation.
A pathname need not correspond to any file that actually exists...
There exist conceivable pathnames for which there is no mapping
to a syntactically valid filename in a particular implementation.
And so on.
But for Unix/Linux-based platforms [and maybe even Windows?], I would
opine that the trailing slash convention is a "reasonable" choice for
an implementation-defined mapping of directories to namestrings, as it
matches users' expectations given what other system utilities tend to
do (e.g., Unix shells with filename completion tend to stick a "/" on
when the completed file name is a directory, etc.).
IMHO, pathname/namestring conversion invariance is a "nice" property,
if/when you can get it.
Rob Warnock <firstname.lastname@example.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607