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

[Richard Hartmann <richih.mailinglist@xxxxxxxxx>]

On Tue, Mar 27, 2012 at 16:34, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:

> I believe the thinking was that the harm has already been done once the
> current directory has been removed out from under the shell.

Yes-ish; zsh is arguably making it worse by locking itself into a
relative path prison.


> 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 ." ?

With git branches, the deletion of directories you were just in is
relatively common, sometimes git will delete the underlying directory
and create a new one with the same name, instead. This confuses
vcs_info. `cd .` is my default way of making vcs_info read in its info
again.


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

They fail silently, they don't lock themselves in.


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

And that's pretty much the beef. Would it be acceptable to change this
behavior if `cd .` does not start throwing errors?


> Of course zsh already does magic in that case:

Interesting; while maybe handy, I think I would prefer it to fail
instead of DWIM.


Richard