Re: `cd .` in non-existent directory leads into weird corner case

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mar 27,  2:56am, Richard Hartmann wrote:
}
} maybe I am misunderstanding zsh's intentions here, but this behaviour
} seems to be quite useless/counter-intuitive and potentially harmful:

I believe the thinking was that the harm has already been done once the
current directory has been removed out from under the shell.
 
} Wouldn't it be better if zsh threw an error as soon as the user tries
} to `cd .`?

Possibly; I seem to recall a (very long ago) discussion in which it was
concluded that the situation arose so rarely as to not be of concern.
How often does one "cd ." ?

Various external commands such as "ls" silently exit with success on a
non-existent current working directory, I think that may have been the
model for the original behavior.

However, I've always been a little puzzled about the decision to set
$PWD to "." in this case.  Bash remembers the relative location:

bash-3.2$ cd /tmp
bash-3.2$ mkdir -p x/y
bash-3.2$ cd x/y
bash-3.2$ rm -r /tmp/x
bash-3.2$ cd .
cd: error retrieving current directory: getcwd: cannot access parent
directories: No such file or directory
bash-3.2$ pwd
/tmp/x/y/.
bash-3.2$ cd ..
cd: error retrieving current directory: getcwd: cannot access parent
directories: No such file or directory
bash-3.2$ pwd
/tmp/x/y/./..

Thus in bash if you do another "cd .." in this example you get back to
"/tmp", whereas in zsh all relative "cd" stop working.  It'd probably
be more in line with other zsh behavior to collapse out the "./.." and
set $PWD to /tmp/x but that introduces interesting effects if a new
directory was also created having the same path as the removed one.

Of course zsh already does magic in that case:

torch% cd /tmp
torch% mkdir -p x/y
torch% cd x/y
torch% rm -r /tmp/x
torch% mkdir -p /tmp/x/y
torch% touch FIRST
torch% ls
FIRST
torch% rm -r /tmp/x
torch% mkdir -p /tmp/x/y
torch% touch /tmp/x/y/SECOND
torch% ls
torch% cd .
torch% ls
SECOND
torch%