If the shell finds itself in an orphaned directory like that, no answer is correct. PWD will be set to something bogus (or unset) -- behavior varies between shells.

A straight pwd is basically equivalent to `echo "$PWD"'; `pwd -P' will attempt to use getcwd() to walk the file hierarchy and will produce an error.

I like the current behavior better than unsetting PWD, and certainly more than leaving it set to something really wrong.

How does this help things? If you're in a removed directory, where `..' doesn't exist, trying to cd into another removed directory (so pathname canonicalization doesn't help you), PWD
is going to be wrong no matter what. getcwd(3) won't help.

Having `.' or `..' in PWD is at least a hint that something is wrong with the current directory.

Without this patch it is possible to create a path with lots of "." or ".." in CWD.

For example:

   $ mkdir -p /tmp/test/test/test && cd /tmp/test/test/test
   $ rm -r /tmp/test && cd . ; pwd
   cd: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
   /tmp/test/test/test/.
   $ cd ..
   cd: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
   $ cd .
   cd: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
   $ cd ..
   cd: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
   $ pwd
   /tmp/test/test/test/./.././..

This patch fixes it while making sure that when possible a regular "cd .." should still work, e.g:

   $ mkdir /tmp/test && cd /tmp/test && rm -r /tmp/test
   & cd .. && pwd
   /tmp