Re: 3.1.6-test-1: strange cd behaviour

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

"Andrej Borsenkow" wrote:
> (/tools/src  is in cdpath)
> 
> bor@itsrm2:/tools/src/zsh-3.1.6-test-1%> builtin cd zsh-3.1.6-test-1/..
> bor@itsrm2:/tools/src/zsh-3.1.6-test-1%> echo $?
> 0
> 
> That is, cd does not change directory and returns success.

I take it what you're really complaining about is that there is no
subdirectory zsh-3.1.6-test-1 at that point, i.e. 
  cd anyolddirectorynameatallatall/..
always succeeds and leaves you in `.'?

It certainly looks like a bug to me, because the unspoken assumption is
that cd will fail unless the path you've given it is valid as it stands ---
and it isn't, chdir() would fail if given the raw path.  However, I ought
to point out that bash and some versions of ksh (but not sh, which is too
dumb to massage paths, and not csh or tcsh either, and not some other
versions of ksh) silently accept this.

I wrote a patch for this, but unfortunately there's a real problem.
Consider:

% mkdir ~/tmp/d1
% cd ~/tmp/d1
% rm -rf ~/tmp/d1
% cd ..

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.

-- 
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