Re: PATCH: 3.1.6-test-1: strange cd behaviour

[Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>]

"Andrej Borsenkow" wrote:
> Yes. Completely remove this. If current dir no more exists, the error message
> here is more of a feature - it indicates, that somethig went wrong. User alwa
> ys
> has ``cd'' or even ``cd /'' fallback. I'm afraid, in this case zsh oversmarts
> itself.  And after all, with all symlinks around, you cannot even be sure, th
> at
> $PWD is prefix of current dir :-( (Our /bin/sh resolves links while /bin/ksh
> does not).

Actually, that's not completely removing it, that's including about half
the code, just not the stuff that allows the PWD to be backtracked
automatically.  (Unless you are suggesting going back to not testing for a
non-existent directory at all?  But then you don't get the error message
with `cd ..'.)

Furthermore, whether PWD is a prefix of the *physical* current directory is
a different issue entirely, depending on the option CHASELINKS.  Without
that set, zsh will always try to turn $PWD/.. into ${PWD:h}, wherever that
lands you up.  The issue here is whether to check for the existence of
$PWD/.. in the former case, as soon as it sees the .. .

Which opens another kettle of fish: if the .. is not at the end, then
/foo/bar/../rod might not be the same physical path as /foo/rod.  So if you
are in /foo/bar, and that is a symbolic link to somewhere not under foo,
and you try to change to /foo/rod by `cd ../rod', then without the bit of
laxity I added allowing backing up $PWD regardless of existence, cd ../rod
will fail, which I don't think is on, since if CHASELINKS is not set this
is just the sort of behaviour you expect to work --- note that this works
in ksh, too.  (Although with AUTOCD `../rod' on its own already fails,
because it tests for a physical directory, since cancd() doesn't call
fixdir() --- anyone want that fixed?)

It's now true that if you do `cd bar/../rod' and bar is a symlink, then
this won't work because of the test I added --- it stat's bar/../rod which
looks for rod in the physical parent of the directory to which bar points.
Maybe this is already going too far when CHASELINKS is unset.  (I could
change it to stat every occurrence of <dir>/.. , which was my first thought,
and which should get round this.)

So the options seem to be: as it was or as it is now, the halfway house
breaks too much when the current directory is a link.  Zsh has been
oversmart with directories all its life.

Any more suggestions?  I could maybe make it more stringent when CHASELINKS
is not set --- but that's increasing the complexity still further.  I would
be perfectly happy to back off the patch altogether, too.

-- 
Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy