Re: Absolute path of a path

[Vincent Lefevre <vincent@xxxxxxxxxx>]

On 2010-12-20 14:44:34 +0000, Peter Stephenson wrote:
> I'm not convinced this is a bug.  It may be strange, but as it's an
> example manufactured to show strangeness, that's probably not
> too surprising.
> 
> Let's leave (:A) out of this to begin with.  We only need one fact about
> it: it's in a set of globbing flags, so that means it forces the
> expression to be treated as a glob, with 'no match' (or equivalent)
> behaviour:
> 
> % cd ~/tmp
> % ln -s . symlink
> % echo symlink/../tmp/symlink(N)
> symlink/../tmp/symlink
> % echo symlink/../tmp/symlink2(N)
> # empty
> 
> This behaviour I've shown so far is correct: symlink/../tmp/symlink is
> an entry in the file system (it's a symbolic link to nothing, but that's
> not a 'no match' condition), whereas symlink/../tmp/symlink2 isn't.
> Until *after* you applied :A, zsh just passes it as a string to the OS,
> which blindly follows it: down into symlink (doesn't change the physical
> directory), then up (does), then back down into tmp... oh look, there's
> a symlink entry here, so it exists.
> 
> It's only at this stage that the flags in globbing are applied.  So zsh
> follows the entirely different rules in this case:
> 
>   Note that resolution of â..â occurs before resolution of symbolic links

This is confusing because the OS resolved symbolic links (during the
filename generation) before the :A rule was applied, thus before the
"resolution" of '..'. Moreover what zsh does with '..' is *not* the
standard resolution (which is to go to the parent directory). IMHO,
the documentation should say exactly what is done with '..' (this is
also true for :a) and there should be a note to say that this may not
be consistent to what has been done by the OS for filename generation
(if the result is applied of the result of filename generation).

> So we get (in my case, which is exactly parallel to yours)
> 
>   /home/pws/tmp/symlink/../tmp/symlink
> 
> becomes
> 
>   /home/pws/tmp/tmp/symlink
> 
> This is the key point.  This is a different rule from how the OS tracks
> a file name during globbing.  We do not want to mess about with the
> globbing rules just because the file name is going to be modified in
> some way after use; in particular, we don't know in general that a
> modifier is going to produce a real file name, consider :t.

OK, but then I think that the documentation is very unclear and is even
lying by using the word "resolve". It isn't a resolution because what
is done by zsh doesn't correspond to what is done by the OS. It's just
a string transformation, just like :t.

Regards,

-- 
Vincent LefÃvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / ArÃnaire project (LIP, ENS-Lyon)