From: Peter Seibel
Subject: (pathname "/tmp/foo/bar/") vs (pathname "/tmp/foo/bar")
Date: 
Message-ID: <m31xoyy4ff.fsf@javamonkey.com>
Among all the various wrinkles in interpretation and implementation
choices around pathnames, all the Unix-based Common Lisp's I've tested
seem to agree that:

  (pathname-directory "/tmp/foo/bar") ==> (:ABSOLUTE "tmp" "foo")

while:

  (pathname-directory "/tmp/foo/bar/") ==> (:ABSOLUTE "tmp" "foo" "bar")

I.e. the trailing '/' on the namestring controls whether the last
element goes into the directory component of the pathname.

However I have not tested every implementation. Does anyone know of a
Unix-based implementation where that is *not* true?

-Peter

-- 
Peter Seibel                                      ·····@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp

From: Rob Warnock
Subject: Re: (pathname "/tmp/foo/bar/") vs (pathname "/tmp/foo/bar")
Date: 
Message-ID: <6mSdnYSYH5FrubPdXTWc-g@speakeasy.net>
Peter Seibel  <·····@javamonkey.com> wrote:
+---------------
| Among all the various wrinkles in interpretation and implementation
| choices around pathnames, all the Unix-based Common Lisp's I've tested
| seem to agree that:
|   (pathname-directory "/tmp/foo/bar") ==> (:ABSOLUTE "tmp" "foo")
| while:
|   (pathname-directory "/tmp/foo/bar/") ==> (:ABSOLUTE "tmp" "foo" "bar")
| 
| I.e. the trailing '/' on the namestring controls whether the last
| element goes into the directory component of the pathname.
+---------------

It would seem logical that this is pretty much required if one wants
pathname/namestring invariance, that is, if we want:

    (namestring (pathname xxx)) => xxx

and:

    (pathname (namestring yyy)) => yyy

Perhaps some NAMESTRING examples may be helpful (albeit non-normative):

    > (namestring (make-pathname :name "bar"))
    "bar"
    > (namestring (make-pathname :directory '(:ABSOLUTE "tmp" "foo")))
    "/tmp/foo/"
    > (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,
otherwise you couldn't get the same pathname back [second invariant above].


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Christophe Rhodes
Subject: Re: (pathname "/tmp/foo/bar/") vs (pathname "/tmp/foo/bar")
Date: 
Message-ID: <sqr7wx1bw6.fsf@lambda.dyndns.org>
····@rpw3.org (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.

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: Rob Warnock
Subject: Re: (pathname "/tmp/foo/bar/") vs (pathname "/tmp/foo/bar")
Date: 
Message-ID: <TtycnbmxULLO7rLdXTWc-g@speakeasy.net>
Christophe Rhodes  <·····@cam.ac.uk> wrote:
+---------------
| ····@rpw3.org (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

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Rahul Jain
Subject: Re: (pathname "/tmp/foo/bar/") vs (pathname "/tmp/foo/bar")
Date: 
Message-ID: <87u11s1c8x.fsf@nyct.net>
····@rpw3.org (Rob Warnock) writes:

> (e.g., Unix shells with filename completion tend to stick a "/" on
> when the completed file name is a directory, etc.).

Actually, zsh strips the trailing slash if you don't add anything after
it (by hitting return or space or some movement key).

-- 
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: (pathname "/tmp/foo/bar/") vs (pathname "/tmp/foo/bar")
Date: 
Message-ID: <pan.2004.02.15.18.15.23.792958@knm.org.pl>
On Sun, 15 Feb 2004 07:25:39 -0600, Rob Warnock wrote:

> 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.).

I believe Unix standards like the Single Unix Specification tend to make
sure that "path/" is equivalent to "path" when it names a directory, e.g.
"rmdir foo/" is equivalent to "rmdir foo", and "chmod a+w foo/" is valid
if and only if "foo" is a directory. A potential directory counts too -
"mkdir foo/" works. So a trailing slash on a directory never hurts, but
is never mandatory (except the root "/" of course, where it is mandatory).

This is not so on Windows, where a trailing "/" or "\" is often not
allowed.

Output of Unix system commands, like getting the current dir or
enumerating names in a directory, doesn't append the "/", except for
the root "/" itself. If some UI wants to present to the user directories
with slashes, it's its responsibility to add them.

-- 
   __("<         Marcin Kowalczyk
   \__/       ······@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/
From: Harald Hanche-Olsen
Subject: Re: (pathname "/tmp/foo/bar/") vs (pathname "/tmp/foo/bar")
Date: 
Message-ID: <pcooes01q1o.fsf@thoth.math.ntnu.no>
+ Christophe Rhodes <·····@cam.ac.uk>:

| ····@rpw3.org (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.

In a strict logical sense you are right of course, but I would
certainly expect every CL implementation to bend over backwards to
support the file naming conventions of its host operating system, so
long as this is possible without actually violating the CL standard.

We all have reasonable expectations of our Lisp systems beyond them
being standards compliant, and this is one of those areas.  We really
don't want our Lisp systems to delete our files or cause the end of
the universe as we know it either, just because we invoked some
undefined behaviour.

-- 
* Harald Hanche-Olsen     <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
  than thinking does: but it deprives us of whatever chance there is
  of getting closer to the truth.  -- C.P. Snow
From: Christophe Rhodes
Subject: Re: (pathname "/tmp/foo/bar/") vs (pathname "/tmp/foo/bar")
Date: 
Message-ID: <sq3c9cmbr3.fsf@lambda.dyndns.org>
Harald Hanche-Olsen <······@math.ntnu.no> writes:

> In a strict logical sense you are right of course, but I would
> certainly expect every CL implementation to bend over backwards to
> support the file naming conventions of its host operating system, so
> long as this is possible without actually violating the CL standard.

Sure.  But what bit of the operating system?  For instance, even
without invoking anything terribly advanced, it's rather hard to
support filenames with colons in them with any particular regularity;
the problem gets worse if an implementation decides to support
shell-like wildcard names, because then a given file at the Unix
level looks different from the same file at the libc level.  And so
on, and so on.

> We all have reasonable expectations of our Lisp systems beyond them
> being standards compliant, and this is one of those areas.  We really
> don't want our Lisp systems to delete our files or cause the end of
> the universe as we know it either, just because we invoked some
> undefined behaviour.

Don't tempt me.  But these "reasonable expectations" are things that
don't have any particular justification; in fact, there's a very
strong argument that no (Lisp) namestring should look like a (Unix)
filename at all -- that, to disambiguate the host issue, all (Lisp)
namestrings should start with a colon.  Is that reasonable?  Not by
your argument, but I wager I could make a convincing case that it's
objectively better than the expected status quo.

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: Harald Hanche-Olsen
Subject: Re: (pathname "/tmp/foo/bar/") vs (pathname "/tmp/foo/bar")
Date: 
Message-ID: <pco8yj21wzg.fsf@thoth.math.ntnu.no>
+ Christophe Rhodes <·····@cam.ac.uk>:

| Harald Hanche-Olsen <······@math.ntnu.no> writes:
| 
| > In a strict logical sense you are right of course, but I would
| > certainly expect every CL implementation to bend over backwards to
| > support the file naming conventions of its host operating system, so
| > long as this is possible without actually violating the CL standard.
| 
| Sure.  But what bit of the operating system?  For instance, even
| without invoking anything terribly advanced, it's rather hard to
| support filenames with colons in them with any particular regularity;

Ah, but that is /already/ difficult.  Try feeding a filename with a
colon in it to scp and see what happens.  But if the default host is
named unix you might just insist that any filename with a colon in it
must be prefix with unix:.  Unix users are used to this sort of
arbitrary special rules anyway.

| the problem gets worse if an implementation decides to support
| shell-like wildcard names,

Yeah, it would probably be a mistake to try that.

| > We all have reasonable expectations [...]  We really don't want
| > our Lisp systems to [...] cause the end of the universe [...]
| 
| Don't tempt me.

Why not?  I have learned a lot from discussions arising from someone
getting tempted.  Oh, never mind.

| But these "reasonable expectations" are things that don't have any
| particular justification; in fact, there's a very strong argument
| that no (Lisp) namestring should look like a (Unix) filename at all
| -- that, to disambiguate the host issue, all (Lisp) namestrings
| should start with a colon.  Is that reasonable?  Not by your
| argument, but I wager I could make a convincing case that it's
| objectively better than the expected status quo.

No, I could live with the colon, so long as what follows looks and
behaves like a unix filename (as long as we're on unix, that is).  I
think what is at issue here is: Who and what are namestrings really
for?  Portable programs can't use them anyway (except for logical
pathnames), so I tend to think of them as being more useful for (a)
convenience in interactive use, and (b) to allow users (who may be
nonprogrammers) to specify a file to the application.  For (b), in
particular, you need namestrings as close to what is expected on the
host OS as is practicable (or you need a GUI file picker).

-- 
* Harald Hanche-Olsen     <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
  than thinking does: but it deprives us of whatever chance there is
  of getting closer to the truth.  -- C.P. Snow