From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9066 invoked by alias); 27 Mar 2012 14:34:43 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 16925 Received: (qmail 4211 invoked from network); 27 Mar 2012 14:34:41 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <120327073414.ZM6783@torch.brasslantern.com> Date: Tue, 27 Mar 2012 07:34:14 -0700 In-reply-to: Comments: In reply to Richard Hartmann "`cd .` in non-existent directory leads into weird corner case" (Mar 27, 2:56am) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: `cd .` in non-existent directory leads into weird corner case MIME-version: 1.0 Content-type: text/plain; charset=us-ascii 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%