Re: 3.1.6-test-1: strange cd behaviour

[Peter Stephenson <pws@ibmth.df.unipi.it>]

"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 <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy