From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29712 invoked from network); 14 Jul 1999 09:47:06 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 14 Jul 1999 09:47:06 -0000 Received: (qmail 23185 invoked by alias); 14 Jul 1999 09:46:55 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7130 Received: (qmail 23174 invoked from network); 14 Jul 1999 09:46:49 -0000 Message-Id: <9907140915.AA13464@ibmth.df.unipi.it> To: "ZSH workers mailing list" Subject: Re: 3.1.6-test-1: strange cd behaviour In-Reply-To: ""Bart Schaefer""'s message of "Wed, 14 Jul 1999 08:47:26 DFT." <990714084726.ZM30209@candle.brasslantern.com> Date: Wed, 14 Jul 1999 11:15:49 +0200 From: Peter Stephenson "Bart Schaefer" wrote: > } Currently that works fine: since tmp exists, it changes directory there. > } However, if you insist on the initial directory being valid, then > } (for example) statting ~/tmp/d1/.. will fail, and the cd won't work. > } Furthermore, you can't even stat the relative path "..", since that's gone > } too. So I don't see a way of reconciling the two things. > > It worked (and still works) in 3.0. What changed? This is a story of horror. In both versions the directory path code (c.f. xsymlinks()) is as clear as mud mixed with more mud in mud sauce (in fact, I remember Zefram saying something similar). What changed is that in 3.0 relative paths are handled differently from absolute ones, while in 3.1 the existing pwd is tacked on the front and all are handled together. In 3.0, to make this work, ..'s behave differently if they are going up further than the start of the current pwd. In the case of `cd dummy/..', it didn't and instead performed a chdir() on the whole thing, so that was tested properly. On the other hand, cd .. works by examining and modifiying the current pwd, so you could cd from a non-existent directory. However, if you have .. in your cdpath, then `cd dummy/..' will try the path `../dummy/..', realises it's going up beyond pwd and hence allow the dummy/.. to be rationalized away, and this works perfectly, taking you, somewhat unexpectedly, to the parent of your current directory. 3.1 is more integrated: it takes a complete path and operates on that. This has the effects previously reported. Without restoring the 3.0 behaviour, the fix would be to do something clever when pwd is a prefix of the path --- i.e., $PWD/.. is automatically turned into $PWD:h, whether the directory exists or not, but $PWD/../dummy/.. becomes ${PWD:h}/dummy/.. which is weighed in the balance and found wanting. This would get all the advantages and none of the disadvantages of the 3.0 method (I hope). The rule would be something like - If $PWD is a prefix, rationalize away any immediately following ..'s (and .'s, to be on the safe side) before doing any testing. - At that point, even if $PWD is a prefix, look at the path and see if it contains any /../ or finishes with /.. . If so, stat() it and check that it exists. If not, return and let the chdir code handle errors. - If everything's OK so far (i.e. no ..'s, or the directory exists) rationalize the rest of the path. I may or may not get round to this myself. -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy