From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3577 invoked by alias); 3 Apr 2012 10:16:44 -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: 16968 Received: (qmail 8142 invoked from network); 3 Apr 2012 10:16:42 -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.6 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_LOW, T_DKIM_INVALID autolearn=no version=3.3.2 Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.google.com designates 209.85.160.43 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I1lABssKSYl3u4aHj2Uk/otsDZKe4kDkfwNLjvhoO4Q=; b=MedZ/Gk/7FKDFRoxuzcUGHPw9P10oq1kOpzHEwCj6s+Nrz2p6RENJBJIqaL5+wn/PI uB4JS0TOw/r+pNEYJs4aiBlwx1PEMytDrsmeBpOrcq+qVhDfjymbniGnI2i1s3ibRa9q ydnZethPSpAAIfL9ay3IK/0QOAXI+vmmQEgCNsGkuY9mNndS5LHHarV6LNUseK0Hth7R Q/8Wr7mJBq0lpGi8EHTG9QKR/fEb5XpL00hvQgrI34Zo2kx8JxS9Bri0pjOtVyZFf3Ye oyBLaRrJDNpb8tadGISchHO8ebkFAz2BD0czC7eSq72RV+T7EBwB18gYE6xJ218Ujino dMgg== MIME-Version: 1.0 In-Reply-To: <20120403105748.6b16c3aa@pwslap01u.europe.root.pri> References: <120327073414.ZM6783@torch.brasslantern.com> <20120402111219.62cbd0c7@pwslap01u.europe.root.pri> <20120402120008.0ed7e583@pwslap01u.europe.root.pri> <20120403105748.6b16c3aa@pwslap01u.europe.root.pri> Date: Tue, 3 Apr 2012 12:16:37 +0200 Message-ID: Subject: Re: `cd .` in non-existent directory leads into weird corner case From: Mikael Magnusson To: Peter Stephenson Cc: zsh-users@zsh.org Content-Type: text/plain; charset=UTF-8 On 3 April 2012 11:57, Peter Stephenson wrote: > On Mon, 2 Apr 2012 13:10:17 +0200 > Mikael Magnusson wrote: >> One (semi-)realistic case I came up with, one shell sits in a >> directory, someone else first moves the directory, then deletes it, >> then the shell tries to 'cd ..'. In this case I would like it to end >> up in the new parent directory as it does now [1], not the old >> "$PWD:h". (with chasedots/-P) (and even if I did 'cd .' first for some >> weird reason). > > Hmmm... when I read this before I concentrated on "as it does now" and > skipped the "not the old $PWD:h". I don't see how that can work. > You're saying we should use the physical directory to find its parent > even though it doesn't exist any more. > > Are you saying you think the shell currently has some magic to do > this? It seems to violate the laws of physics, unless we recorded > the physical directory as a second PWD just on the off chance someone > deletes the current one, which seems silly. I don't know if this is something that works on all systems, but on linux at least, it seems that the directory inode sticks around while a process still has it, or any subdirectory of it, as its current directory (or otherwise open i suppose). This means that it is still possible to access the . and .. entries in it, and follow them via chdir(), see the transcripts in my other mail where it even works from a second shell going into the dir via 'cd /proc/$firstshell/cwd' and then doing 'cd -P ..'. If the system doesn't keep the '..' entry around, I'm not demanding that cd -P .. should work as I described :). -- Mikael Magnusson