Re: ".." and :UP

[Sam S. <sd...@gn...>]

> * Bruno Haible <oe...@py...t> [2004-01-12 13:13:29 +0100]:
>
> In the docs of 19.1.1. Directory canonicalization I read:
>
>> 2. "..", "*", and "**" are converted to :UP, :WILD and :WILD-INFERIORS,
>>    respectively
>> 3. patterns foo/../ are collapsed
>
> But this is inconsistent on Unix! CLHS section 19.2.2.4.3 explains
> what :UP means:
>
>   :up              Go upward in directory structure (semantic)         
>   :back            Go upward in directory structure (syntactic)        
>
> The meaning of ".." on Unix is "parent directory", i.e. :UP. (But
> newbie users are confused by the behaviour of "cd .." in some shells.)

CLISP _is_ a shell - not just because of
<http://clisp.cons.org/clash.html>, but because of the fundamental
interactive nature of CL.

> So (2) is correct, but collapsing "foo/../" is not the right thing to
> do.  "foo" may be a symlink. And you aren't allowed to access the
> filesystem during parsing of filenames. Therefore collapsing of ".."
> is an operation that must be delayed until TRUENAME or OPEN or similar
> functions are called.

TRUENAME & OPEN convert pathnames to absolute, so, when they are called,
it is pointless to collapse "foo/../".

> clisp-2.27 and earlier did it right:
>
> (pathname-directory (parse-namestring "foo/../bar/baz/bla"))
> (:RELATIVE "foo" ".." "bar" "baz")
>
> clisp-2.28 and the more recent ones do it wrong:
>
> (pathname-directory (parse-namestring "foo/../bar/baz/bla"))
> (:RELATIVE "bar" "baz")

You might be right from the "language lawyer" POV if you view the
language as defined by the ANSI spec (which is a perfectly reasonable
and consistent POV).
Note however that CL, as opposed to, say, Scheme, was not a "designed"
language, but a "standardized" one, i.e., a "common functionality" spec.
(observe frequent references to "existing practice" in CLHS issues).
Therefore it makes sense to conform to the behavior of other
CL implementations when it is consistent, even when it violates the
letter of the spec.
LispWorks does the same thing as CLISP.
What about Allegro, CMUCL, MCL?

Note also the current behavior did not originate with my whim.
It was explicitly requested by the users who clamored that this is TRT.
Observe that this is not just an issue of aesthetics: if "foo" does not
exist but "bar/zot" does, then 2.27 (truename "foo/../bar/zot") will
signal an error - even though the OS or libc calls would work just fine,
e.g., open("foo/../bar/zot","r") would return a valid FILE* -
while 2.28 will happily return #p"/home/me/bar/zot".
This was an issue for someone, and there were bugs on SF and
discussions on clisp-list.

If all the other CL implementations do the same thing, I suggest
leaving this as it is now.

If there is a discrepancy, i.e., some lisps behave as CLISP 2.27, then
we can make this canonicalization optional, and enable it only with
--ansi.

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
If a train station is a place where a train stops, what's a workstation?