Subject: Re: (pathname "/tmp/foo/bar/") vs (pathname "/tmp/foo/bar")
From: (Rob Warnock)
Date: Sun, 15 Feb 2004 07:25:39 -0600
Newsgroups: comp.lang.lisp
Message-ID: <>
Christophe Rhodes  <> wrote:
| (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			<>
627 26th Avenue			<URL:>
San Mateo, CA 94403		(650)572-2607