From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26809 invoked by alias); 20 Dec 2010 14:44:49 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 15658 Received: (qmail 23187 invoked from network); 20 Dec 2010 14:44:45 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_PASS autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at csr.com does not designate permitted sender hosts) Date: Mon, 20 Dec 2010 14:44:34 +0000 From: Peter Stephenson To: Subject: Re: Absolute path of a path Message-ID: <20101220144434.0f7d4922@pwslap01u.europe.root.pri> In-Reply-To: <20101220102645.GA15278@prunille.vinc17.org> References: <20101027164454.GA19471@prunille.vinc17.org> <20101028104451.GB19471@prunille.vinc17.org> <20101028105250.GB7283@prunille.vinc17.org> <20101220102645.GA15278@prunille.vinc17.org> Organization: Cambridge Silicon Radio X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 20 Dec 2010 14:44:34.0791 (UTC) FILETIME=[6B4A2770:01CBA054] X-Scanned-By: MailControl A_10_80_00 (www.mailcontrol.com) on 10.71.0.141 On Mon, 20 Dec 2010 11:26:45 +0100 Vincent Lefevre wrote: > On 2010-10-28 12:52:50 +0200, Vincent Lefevre wrote: > > On 2010-10-28 12:44:51 +0200, Vincent Lefevre wrote: > > > FYI: > > >=20 > > > ypig:~> realpath symlink/../vlefevre/symlink > > > /home/vlefevre > > >=20 > > > ypig:~> echo symlink/../vlefevre/symlink(:A) > > > /home/vlefevre/vlefevre/symlink > > >=20 > > > where symlink is a symbolic link to ".". > >=20 > > I think that this is even a bug in zsh, as > >=20 > > ypig:~> echo symlink/../vlefevre/symlink2(:A) > > zsh: no match > >=20 > > So, it seems that resolution as been done correctly (it is > > detected that symlink/../vlefevre/symlink exists but not > > symlink/../vlefevre/symlink2), however the output for the > > former one /home/vlefevre/vlefevre/symlink doesn't exist > > (there's no vlefevre file or directory in /home/vlefevre). >=20 > I've reported the following bug on the Debian BTS about this: >=20 > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D607615 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 =E2=80=98..=E2=80=99 occurs before resolution of = symbolic links 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. Now we try and do the following: Resolve use of symbolic links where possible ^^^^^^^^^^^^^^ Well, it's not possible. /home/pws/tmp/tmp doesn't exist, so we're stuck at that point. Note also the rule inherited from :a Note that the transformation takes place even if the file or any intervening directories do not exist. So it's not an error that we can't do anything more, it just stops trying to do anything with it at that point and returns what it's got. If you don't want it to check for an entry in the file system, i.e. you don't want globbing rules on the file before the :A modifier is applied, you need to use parameter substitution, e.g. ${${:-symlink/../tmp/symlink}:A}, and this gives the same answer in both cases (and in both cases the filename is useless). But this is the right thing to do if you know you're about to create a path which initially (during globbing) might do something different from what happens after you've applied the :A rules. The moral is "don't expect globbing to follow rules applicable to directory string transformation". The problem underlying this is the vain attempt to make symbolic links work logically with respect to ".." when the rule applied to entries in the filesystem is different. You can disguise a certain amount of the illogic from the user, but you can't disguise it from the OS. --=20 Peter Stephenson Software Engineer Tel: +44 (0)1223 692070 Cambridge Silicon Radio Limited Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, = UK Member of the CSR plc group of companies. CSR plc registered in England and= Wales, registered number 4187346, registered office Churchill House, Cambr= idge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom