* `cd .` in non-existent directory leads into weird corner case @ 2012-03-27 0:56 Richard Hartmann 2012-03-27 5:13 ` Daniel Shahaf 2012-03-27 14:34 ` Bart Schaefer 0 siblings, 2 replies; 27+ messages in thread From: Richard Hartmann @ 2012-03-27 0:56 UTC (permalink / raw) To: zsh-users Hi all, maybe I am misunderstanding zsh's intentions here, but this behaviour seems to be quite useless/counter-intuitive and potentially harmful: richih@adamantium ~ % zsh -f adamantium% PS1="%~ %# " ~ % mkdir testdir ~ % cd testdir ~/testdir % rmdir ~/testdir ~/testdir % cd . . % ls . % pwd . . % cd .. . % pwd . . % Wouldn't it be better if zsh threw an error as soon as the user tries to `cd .`? Thanks, Richard ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-03-27 0:56 `cd .` in non-existent directory leads into weird corner case Richard Hartmann @ 2012-03-27 5:13 ` Daniel Shahaf 2012-03-27 14:34 ` Bart Schaefer 1 sibling, 0 replies; 27+ messages in thread From: Daniel Shahaf @ 2012-03-27 5:13 UTC (permalink / raw) To: Richard Hartmann; +Cc: zsh-users Richard Hartmann wrote on Tue, Mar 27, 2012 at 02:56:23 +0200: > Hi all, > > maybe I am misunderstanding zsh's intentions here, but this behaviour > seems to be quite useless/counter-intuitive and potentially harmful: > > richih@adamantium ~ % zsh -f > adamantium% PS1="%~ %# " > ~ % mkdir testdir > ~ % cd testdir > ~/testdir % rmdir ~/testdir > ~/testdir % cd . > . % ls > . % pwd > . > . % cd .. > . % pwd > . > . % > > Wouldn't it be better if zsh threw an error as soon as the user tries to `cd .`? > FWIW: stat64(".", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 chdir("/tmp/d") = -1 ENOENT (No such file or directory) stat64(".", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 chdir(".") = 0 stat64("/tmp/d", 0xbf9b00ec) = -1 ENOENT (No such file or directory) stat64(".", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0 rt_sigprocmask(SIG_BLOCK, [INT], [CHLD], 8) = 0 stat64("..", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0 open("..", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 which tells me two things: that there is an initial chdir() call which fails (re your suggestion to propagate that), and that the behaviour might be even weirder if you remove the parent directory as well. ('cd /tmp/d/e && rm -rf /tmp/d') > > Thanks, > Richard ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-03-27 0:56 `cd .` in non-existent directory leads into weird corner case Richard Hartmann 2012-03-27 5:13 ` Daniel Shahaf @ 2012-03-27 14:34 ` Bart Schaefer 2012-03-27 15:25 ` Richard Hartmann 2012-04-02 9:52 ` Richard Hartmann 1 sibling, 2 replies; 27+ messages in thread From: Bart Schaefer @ 2012-03-27 14:34 UTC (permalink / raw) To: zsh-users 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% ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-03-27 14:34 ` Bart Schaefer @ 2012-03-27 15:25 ` Richard Hartmann 2012-04-02 9:52 ` Richard Hartmann 1 sibling, 0 replies; 27+ messages in thread From: Richard Hartmann @ 2012-03-27 15:25 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-users On Tue, Mar 27, 2012 at 16:34, Bart Schaefer <schaefer@brasslantern.com> 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-03-27 14:34 ` Bart Schaefer 2012-03-27 15:25 ` Richard Hartmann @ 2012-04-02 9:52 ` Richard Hartmann 2012-04-02 10:12 ` Peter Stephenson 2012-04-02 10:15 ` Mikael Magnusson 1 sibling, 2 replies; 27+ messages in thread From: Richard Hartmann @ 2012-04-02 9:52 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-users On Tue, Mar 27, 2012 at 16:34, Bart Schaefer <schaefer@brasslantern.com> wrote: > However, I've always been a little puzzled about the decision to set > $PWD to "." in this case. Bash remembers the relative location: Just to make sure this does not get lost, do we agree that not changing $PWD to a literal dot would make sense? Escalating the ENOENT to the user is probably the best approach. Richard ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-02 9:52 ` Richard Hartmann @ 2012-04-02 10:12 ` Peter Stephenson 2012-04-02 10:56 ` Mikael Magnusson 2012-04-02 10:15 ` Mikael Magnusson 1 sibling, 1 reply; 27+ messages in thread From: Peter Stephenson @ 2012-04-02 10:12 UTC (permalink / raw) To: zsh-users On Mon, 2 Apr 2012 11:52:02 +0200 Richard Hartmann <richih.mailinglist@gmail.com> wrote: > On Tue, Mar 27, 2012 at 16:34, Bart Schaefer <schaefer@brasslantern.com> wrote: > > > However, I've always been a little puzzled about the decision to set > > $PWD to "." in this case. Bash remembers the relative location: > > Just to make sure this does not get lost, do we agree that not > changing $PWD to a literal dot would make sense? Escalating the ENOENT > to the user is probably the best approach. Sounds OK. Silently failing and changing the directory reported doesn't really do a lot of good to anyone. -- Peter Stephenson <pws@csr.com> Software Engineer Tel: +44 (0)1223 692070 Cambridge Silicon Radio Limited Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-02 10:12 ` Peter Stephenson @ 2012-04-02 10:56 ` Mikael Magnusson 2012-04-02 11:00 ` Peter Stephenson 0 siblings, 1 reply; 27+ messages in thread From: Mikael Magnusson @ 2012-04-02 10:56 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh-users On 2 April 2012 12:12, Peter Stephenson <Peter.Stephenson@csr.com> wrote: > On Mon, 2 Apr 2012 11:52:02 +0200 > Richard Hartmann <richih.mailinglist@gmail.com> wrote: >> On Tue, Mar 27, 2012 at 16:34, Bart Schaefer <schaefer@brasslantern.com> wrote: >> >> > However, I've always been a little puzzled about the decision to set >> > $PWD to "." in this case. Bash remembers the relative location: >> >> Just to make sure this does not get lost, do we agree that not >> changing $PWD to a literal dot would make sense? Escalating the ENOENT >> to the user is probably the best approach. > > Sounds OK. Silently failing and changing the directory reported doesn't > really do a lot of good to anyone. Can we keep the current behaviour for cd -P? Sometimes I mv directories and like to end up in the correct place when I cd .. in a shell that was 'moved'. Maybe this case wouldn't be affected, but it still feels more consistent to me if I keep following the physical links even if it was deleted. -- Mikael Magnusson ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-02 10:56 ` Mikael Magnusson @ 2012-04-02 11:00 ` Peter Stephenson 2012-04-02 11:10 ` Mikael Magnusson 0 siblings, 1 reply; 27+ messages in thread From: Peter Stephenson @ 2012-04-02 11:00 UTC (permalink / raw) To: zsh-users On Mon, 2 Apr 2012 12:56:55 +0200 Mikael Magnusson <mikachu@gmail.com> wrote: > >> Just to make sure this does not get lost, do we agree that not > >> changing $PWD to a literal dot would make sense? Escalating the ENOENT > >> to the user is probably the best approach. > > > > Sounds OK. Silently failing and changing the directory reported doesn't > > really do a lot of good to anyone. > > Can we keep the current behaviour for cd -P? I think that only those cases that currently give up and silently revert to "." as the current directory would be affected, so anything that already did something sensible would still do that. Certainly that's what we should be aiming for. -- Peter Stephenson <pws@csr.com> Software Engineer Tel: +44 (0)1223 692070 Cambridge Silicon Radio Limited Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-02 11:00 ` Peter Stephenson @ 2012-04-02 11:10 ` Mikael Magnusson 2012-04-02 11:39 ` Peter Stephenson ` (2 more replies) 0 siblings, 3 replies; 27+ messages in thread From: Mikael Magnusson @ 2012-04-02 11:10 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh-users On 2 April 2012 13:00, Peter Stephenson <Peter.Stephenson@csr.com> wrote: > On Mon, 2 Apr 2012 12:56:55 +0200 > Mikael Magnusson <mikachu@gmail.com> wrote: >> >> Just to make sure this does not get lost, do we agree that not >> >> changing $PWD to a literal dot would make sense? Escalating the ENOENT >> >> to the user is probably the best approach. >> > >> > Sounds OK. Silently failing and changing the directory reported doesn't >> > really do a lot of good to anyone. >> >> Can we keep the current behaviour for cd -P? > > I think that only those cases that currently give up and silently revert > to "." as the current directory would be affected, so anything that > already did something sensible would still do that. Certainly that's > what we should be aiming for. 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). -- Mikael Magnusson [1] {13:08:58|~}% mkcd foo {13:09:04|~/foo}% mv ~/foo ~/tmp # ~/tmp already exists {13:09:07|~/foo}% rmdir ~/tmp/foo {13:09:09|~/foo}% cd .. {13:09:09|~/tmp}% ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-02 11:10 ` Mikael Magnusson @ 2012-04-02 11:39 ` Peter Stephenson 2012-04-03 9:51 ` Richard Hartmann 2012-04-03 9:57 ` Peter Stephenson 2 siblings, 0 replies; 27+ messages in thread From: Peter Stephenson @ 2012-04-02 11:39 UTC (permalink / raw) To: zsh-users On Mon, 2 Apr 2012 13:10:17 +0200 Mikael Magnusson <mikachu@gmail.com> 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). That last bit's going to depend on what error handling happens when "cd ." fails, both internally and in the shell code. Internally, the right thing to do, presumably, is if we don't do the bogus PWD=. just leave PWD as it was before, which seems natural enough. Otherwise, as far as I can it's the same basic case as before --- if it used to do some sensible it still should. -- Peter Stephenson <pws@csr.com> Software Engineer Tel: +44 (0)1223 692070 Cambridge Silicon Radio Limited Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-02 11:10 ` Mikael Magnusson 2012-04-02 11:39 ` Peter Stephenson @ 2012-04-03 9:51 ` Richard Hartmann 2012-04-03 9:57 ` Peter Stephenson 2 siblings, 0 replies; 27+ messages in thread From: Richard Hartmann @ 2012-04-03 9:51 UTC (permalink / raw) To: Mikael Magnusson; +Cc: Peter Stephenson, zsh-users On Mon, Apr 2, 2012 at 13:10, Mikael Magnusson <mikachu@gmail.com> 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). If feasible, I agree that this would be nice. Richard ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-02 11:10 ` Mikael Magnusson 2012-04-02 11:39 ` Peter Stephenson 2012-04-03 9:51 ` Richard Hartmann @ 2012-04-03 9:57 ` Peter Stephenson 2012-04-03 10:16 ` Mikael Magnusson 2 siblings, 1 reply; 27+ messages in thread From: Peter Stephenson @ 2012-04-03 9:57 UTC (permalink / raw) To: zsh-users On Mon, 2 Apr 2012 13:10:17 +0200 Mikael Magnusson <mikachu@gmail.com> 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. -- Peter Stephenson <pws@csr.com> Software Engineer Tel: +44 (0)1223 692070 Cambridge Silicon Radio Limited Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-03 9:57 ` Peter Stephenson @ 2012-04-03 10:16 ` Mikael Magnusson 2012-04-03 11:11 ` Richard Hartmann 2012-04-03 14:06 ` Bart Schaefer 0 siblings, 2 replies; 27+ messages in thread From: Mikael Magnusson @ 2012-04-03 10:16 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh-users On 3 April 2012 11:57, Peter Stephenson <Peter.Stephenson@csr.com> wrote: > On Mon, 2 Apr 2012 13:10:17 +0200 > Mikael Magnusson <mikachu@gmail.com> 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-03 10:16 ` Mikael Magnusson @ 2012-04-03 11:11 ` Richard Hartmann 2012-04-03 14:06 ` Bart Schaefer 1 sibling, 0 replies; 27+ messages in thread From: Richard Hartmann @ 2012-04-03 11:11 UTC (permalink / raw) To: Mikael Magnusson; +Cc: Peter Stephenson, zsh-users On Tue, Apr 3, 2012 at 12:16, Mikael Magnusson <mikachu@gmail.com> wrote: > 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). As we are talking error scenarios, consider forced removal of media, etc. Richard ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-03 10:16 ` Mikael Magnusson 2012-04-03 11:11 ` Richard Hartmann @ 2012-04-03 14:06 ` Bart Schaefer 1 sibling, 0 replies; 27+ messages in thread From: Bart Schaefer @ 2012-04-03 14:06 UTC (permalink / raw) To: zsh-users On Apr 3, 12:16pm, Mikael Magnusson wrote: } } 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 In order to do this even remotely portably, though, zsh would have to open ".." with readdir() as soon as it cd's into a directory, and then hold open that descriptor until it cd's out again; plus the system would have to support fchdir() -- I don't know how portable that is compared to /proc/*/cwd but I'm pretty sure neither of them is going to be available on every platform where zsh can be compiled. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-02 9:52 ` Richard Hartmann 2012-04-02 10:12 ` Peter Stephenson @ 2012-04-02 10:15 ` Mikael Magnusson 2012-04-02 10:33 ` Peter Stephenson ` (2 more replies) 1 sibling, 3 replies; 27+ messages in thread From: Mikael Magnusson @ 2012-04-02 10:15 UTC (permalink / raw) To: Richard Hartmann; +Cc: Bart Schaefer, zsh-users On 2 April 2012 11:52, Richard Hartmann <richih.mailinglist@gmail.com> wrote: > On Tue, Mar 27, 2012 at 16:34, Bart Schaefer <schaefer@brasslantern.com> wrote: > >> However, I've always been a little puzzled about the decision to set >> $PWD to "." in this case. Bash remembers the relative location: > > Just to make sure this does not get lost, do we agree that not > changing $PWD to a literal dot would make sense? Escalating the ENOENT > to the user is probably the best approach. Weird, when I try making a directory and remove it, I can still cd .. to the parent... I can even cd into the dir with another shell (via /proc/$$/cwd), and cd .. to the correct parent dir from that other shell. > 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 succeed silently because the directory exists and is empty. % ls % pwd . % stat . File: '.' Size: 6 Blocks: 0 IO Block: 4096 directory Device: 811h/2065d Inode: 299438815 Links: 0 Access: (0755/drwxr-xr-x) Uid: ( 1000/ mikachu) Gid: ( 100/ users) Access: 2012-04-02 12:12:26.696856559 +0200 Modify: 2012-04-02 12:12:26.696856559 +0200 Change: 2012-04-02 12:12:31.260107270 +0200 When I try bart's double-directory trick, I can still cd .. twice and get back to the correct grandparent directory. -- Mikael Magnusson ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-02 10:15 ` Mikael Magnusson @ 2012-04-02 10:33 ` Peter Stephenson 2012-04-02 10:46 ` Mikael Magnusson 2012-04-02 11:07 ` Vincent Lefevre 2012-04-02 12:59 ` Richard Hartmann 2 siblings, 1 reply; 27+ messages in thread From: Peter Stephenson @ 2012-04-02 10:33 UTC (permalink / raw) To: zsh-users On Mon, 2 Apr 2012 12:15:59 +0200 Mikael Magnusson <mikachu@gmail.com> wrote: > Weird, when I try making a directory and remove it, I can still cd .. > to the parent... That's not weird; the shell remembers PWD because by default it changes directory logically rather than physically, i.e. retaining symbolic links in the path, so it changes to the parent directory by what amounts to 'cd $PWD:h'. What you get with CHASE_LINKS or cd -P is another matter, since the ability to take account of symbolic links means the whole logic is rather baroque, but I'd vaguely expect it either to fail or fail to resolve the physical directory and default to trimming PWD. (What it does and what it should do are again not necessarily identical.) -- Peter Stephenson <pws@csr.com> Software Engineer Tel: +44 (0)1223 692070 Cambridge Silicon Radio Limited Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-02 10:33 ` Peter Stephenson @ 2012-04-02 10:46 ` Mikael Magnusson 0 siblings, 0 replies; 27+ messages in thread From: Mikael Magnusson @ 2012-04-02 10:46 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh-users On 2 April 2012 12:33, Peter Stephenson <Peter.Stephenson@csr.com> wrote: > On Mon, 2 Apr 2012 12:15:59 +0200 > Mikael Magnusson <mikachu@gmail.com> wrote: >> Weird, when I try making a directory and remove it, I can still cd .. >> to the parent... > > That's not weird; the shell remembers PWD because by default it changes > directory logically rather than physically, i.e. retaining symbolic > links in the path, so it changes to the parent directory by what > amounts to 'cd $PWD:h'. How does this explain that it works from the other shell that never knew what $PWD was? I'm sticking with my theory that the directory exists until we leave it :). I called it weird because obviously it doesn't work for richih, as one can see in his transcript. > What you get with CHASE_LINKS or cd -P is another matter, since the > ability to take account of symbolic links means the whole logic is > rather baroque, but I'd vaguely expect it either to fail or fail to > resolve the physical directory and default to trimming PWD. (What it > does and what it should do are again not necessarily identical.) Ah, and I do have both CHASE_LINKS and CHASE_DOTS set, which explains it. When I unset them, zsh indeed stays in mysterious '.' land forever. With them set, it properly follows the physical .. entries back to the parent directory. [so the first part has chase_* set] ~% mkcd foo ~/foo% rmdir ~+ ~/foo% cd . .% cd .. ~% mkcd foo/bar ~/foo/bar% rmdir ~+ ~+(:h) ~/foo/bar% zsh -f .% pwd . .% cd .. .% pwd . .% cd .. .% pwd . .% cd .. .% pwd . .% cd -P .. .% cd -P .. ~% -- Mikael Magnusson ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-02 10:15 ` Mikael Magnusson 2012-04-02 10:33 ` Peter Stephenson @ 2012-04-02 11:07 ` Vincent Lefevre 2012-04-02 12:59 ` Richard Hartmann 2 siblings, 0 replies; 27+ messages in thread From: Vincent Lefevre @ 2012-04-02 11:07 UTC (permalink / raw) To: Mikael Magnusson; +Cc: Richard Hartmann, Bart Schaefer, zsh-users On 2012-04-02 12:15:59 +0200, Mikael Magnusson wrote: > On 2 April 2012 11:52, Richard Hartmann <richih.mailinglist@gmail.com> wrote: > > On Tue, Mar 27, 2012 at 16:34, Bart Schaefer <schaefer@brasslantern.com> wrote: > > > >> However, I've always been a little puzzled about the decision to set > >> $PWD to "." in this case. Bash remembers the relative location: > > > > Just to make sure this does not get lost, do we agree that not > > changing $PWD to a literal dot would make sense? Escalating the ENOENT > > to the user is probably the best approach. > > Weird, when I try making a directory and remove it, I can still cd .. > to the parent... I can even cd into the dir with another shell (via > /proc/$$/cwd), and cd .. to the correct parent dir from that other > shell. This seems to depend on the file system. The following script tst() { base=`pwd` echo "Test 1" mkdir dir cd dir rmdir ../dir pwd cd . pwd cd .. pwd cd "$base" echo "Test 2" mkdir dir cd dir rmdir ../dir pwd cd .. pwd } tst under NFS sometimes gives with zsh 4.3.12: Test 1 /home/vlefevre/dir tst:cd:9: no such file or directory: . /home/vlefevre/dir tst:cd:11: no such file or directory: .. /home/vlefevre/dir Test 2 /home/vlefevre/dir tst:cd:21: no such file or directory: .. /home/vlefevre/dir and sometimes: Test 1 /home/vlefevre/dir tst:cd:9: no such file or directory: . /home/vlefevre/dir tst:cd:11: no such file or directory: .. /home/vlefevre/dir Test 2 /home/vlefevre/dir /home/vlefevre and sometimes: Test 1 /home/vlefevre/dir . /home/vlefevre Test 2 /home/vlefevre/dir tst:cd:21: no such file or directory: .. /home/vlefevre/dir >From /tmp, I always get: Test 1 /tmp/dir . /tmp Test 2 /tmp/dir /tmp With sh (dash): Test 1 /home/vlefevre/dir cd: 26: can't cd to . /home/vlefevre/dir /home/vlefevre Test 2 /home/vlefevre/dir /home/vlefevre and Test 1 /tmp/dir cd: 26: can't cd to . /tmp/dir /tmp Test 2 /tmp/dir /tmp respectively. With zsh in ksh emulation: Test 1 /home/vlefevre/dir tst:cd:9: no such file or directory: . /home/vlefevre/dir tst:cd:11: no such file or directory: .. /home/vlefevre/dir Test 2 /home/vlefevre/dir tst:cd:21: no such file or directory: .. /home/vlefevre/dir or Test 1 /home/vlefevre/dir . . Test 2 /home/vlefevre/dir /home/vlefevre -- Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-02 10:15 ` Mikael Magnusson 2012-04-02 10:33 ` Peter Stephenson 2012-04-02 11:07 ` Vincent Lefevre @ 2012-04-02 12:59 ` Richard Hartmann 2012-04-03 4:04 ` Jun T. 2 siblings, 1 reply; 27+ messages in thread From: Richard Hartmann @ 2012-04-02 12:59 UTC (permalink / raw) To: Mikael Magnusson; +Cc: Bart Schaefer, zsh-users On Mon, Apr 2, 2012 at 12:15, Mikael Magnusson <mikachu@gmail.com> wrote: > Weird, when I try making a directory and remove it, I can still cd .. > to the parent... I can even cd into the dir with another shell (via > /proc/$$/cwd), and cd .. to the correct parent dir from that other > shell. We must be trying to do different things... % zsh -f adamantium% mkdir blubb adamantium% cd blubb adamantium% pwd /home/richih/blubb adamantium% rmdir /home/richih/blubb adamantium% cd . adamantium% pwd . adamantium% stat . File: `.' Size: 6 Blocks: 0 IO Block: 4096 directory Device: 802h/2050d Inode: 134300028 Links: 0 Access: (0755/drwxr-xr-x) Uid: ( 1000/ richih) Gid: ( 1000/ richih) Access: 2012-04-02 14:56:15.416702007 +0200 Modify: 2012-04-02 14:56:15.416702007 +0200 Change: 2012-04-02 14:56:30.056251660 +0200 Birth: - adamantium% mkdir test mkdir: cannot create directory `test': No such file or directory adamantium% touch test touch: cannot touch `test': No such file or directory adamantium% Richard ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-02 12:59 ` Richard Hartmann @ 2012-04-03 4:04 ` Jun T. 2012-04-03 14:43 ` Vincent Lefevre 0 siblings, 1 reply; 27+ messages in thread From: Jun T. @ 2012-04-03 4:04 UTC (permalink / raw) To: zsh-users Once pwd is set to '.', $PWD has different value than pwd. Is this intensional? /tmp% mkdir x && cd x /tmp/x% rmdir ../x /tmp/x% cd . .% pwd . .% echo $PWD /tmp/x .% cd . .% pwd . .% echo $PWD .% ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-03 4:04 ` Jun T. @ 2012-04-03 14:43 ` Vincent Lefevre 2012-04-04 17:03 ` Jun T. 0 siblings, 1 reply; 27+ messages in thread From: Vincent Lefevre @ 2012-04-03 14:43 UTC (permalink / raw) To: zsh-users On 2012-04-03 13:04:52 +0900, Jun T. wrote: > Once pwd is set to '.', $PWD has different value than pwd. > Is this intensional? Not only in this case. mkdir -p tmpdir1/tmpdir2 cd tmpdir1/tmpdir2 pwd echo "$PWD" mv ../../tmpdir1 ../../tmpdir3 pwd echo "$PWD" cd ../.. rm -r tmpdir3 gives: /tmp/tmpdir1/tmpdir2 /tmp/tmpdir1/tmpdir2 /tmp/tmpdir3/tmpdir2 /tmp/tmpdir1/tmpdir2 pdksh, mksh and posh behave like zsh, but dash, bash and ksh93 output /tmp/tmpdir1/tmpdir2 every time. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-03 14:43 ` Vincent Lefevre @ 2012-04-04 17:03 ` Jun T. 2012-04-05 14:20 ` Vincent Lefevre 0 siblings, 1 reply; 27+ messages in thread From: Jun T. @ 2012-04-04 17:03 UTC (permalink / raw) To: zsh-users On 2012/04/03, at 23:43, Vincent Lefevre wrote: > mv ../../tmpdir1 ../../tmpdir3 > pwd > > /tmp/tmpdir3/tmpdir2 In my case this happens only by 'pwd -P'. I guess you have CHASE_LINKS set. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-04 17:03 ` Jun T. @ 2012-04-05 14:20 ` Vincent Lefevre 2012-04-05 16:17 ` Jun T. 0 siblings, 1 reply; 27+ messages in thread From: Vincent Lefevre @ 2012-04-05 14:20 UTC (permalink / raw) To: zsh-users On 2012-04-05 02:03:11 +0900, Jun T. wrote: > On 2012/04/03, at 23:43, Vincent Lefevre wrote: > > mv ../../tmpdir1 ../../tmpdir3 > > pwd > > > > /tmp/tmpdir3/tmpdir2 > > In my case this happens only by 'pwd -P'. > I guess you have CHASE_LINKS set. I usually do such tests with the default configuration, e.g. after "zsh -f" or by putting the commands in a file <script>, run with <shell> <script> so that I can test them with several shells (zsh, dash, bash, ksh93...). -- Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-05 14:20 ` Vincent Lefevre @ 2012-04-05 16:17 ` Jun T. 2012-04-15 1:17 ` Vincent Lefevre 0 siblings, 1 reply; 27+ messages in thread From: Jun T. @ 2012-04-05 16:17 UTC (permalink / raw) To: zsh-users On 2012/04/05, at 23:20, Vincent Lefevre wrote: > putting the commands in a file <script>, run with > > <shell> <script> Could you please try 'zsh -f <script>' ? Or try adding 'unsetopt chase_links' at the top of the script. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-05 16:17 ` Jun T. @ 2012-04-15 1:17 ` Vincent Lefevre 2012-04-15 18:07 ` Bart Schaefer 0 siblings, 1 reply; 27+ messages in thread From: Vincent Lefevre @ 2012-04-15 1:17 UTC (permalink / raw) To: zsh-users On 2012-04-06 01:17:23 +0900, Jun T. wrote: > On 2012/04/05, at 23:20, Vincent Lefevre wrote: > > putting the commands in a file <script>, run with > > > > <shell> <script> > > Could you please try 'zsh -f <script>' ? Ah, I didn't know that the .zshenv file was sourced (I was a bit confused because it was disabled from /etc/zshenv on some other machine). xvii% zsh -f ~/wd/src/testcases/dir-test2.sh /tmp/tmpdir1/tmpdir2 /tmp/tmpdir1/tmpdir2 /tmp/tmpdir1/tmpdir2 /tmp/tmpdir1/tmpdir2 xvii% zsh ~/wd/src/testcases/dir-test2.sh /tmp/tmpdir1/tmpdir2 /tmp/tmpdir1/tmpdir2 /tmp/tmpdir3/tmpdir2 /tmp/tmpdir1/tmpdir2 xvii% zsh -c ~/wd/src/testcases/dir-test2.sh /tmp/tmpdir1/tmpdir2 /tmp/tmpdir1/tmpdir2 /tmp/tmpdir1/tmpdir2 /tmp/tmpdir1/tmpdir2 I don't understand why the -c option has any effect (I couldn't see anything in the man pages). -- Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: `cd .` in non-existent directory leads into weird corner case 2012-04-15 1:17 ` Vincent Lefevre @ 2012-04-15 18:07 ` Bart Schaefer 0 siblings, 0 replies; 27+ messages in thread From: Bart Schaefer @ 2012-04-15 18:07 UTC (permalink / raw) To: zsh-users On Apr 15, 3:17am, Vincent Lefevre wrote: } } I don't understand why the -c option has any effect (I couldn't } see anything in the man pages). With -f or no option at all, dir-test2.sh is being run approximately as if read by "source". With -c, it's being run as an external command, so it might not even be zsh that's executing it. ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2012-04-15 18:08 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-03-27 0:56 `cd .` in non-existent directory leads into weird corner case Richard Hartmann 2012-03-27 5:13 ` Daniel Shahaf 2012-03-27 14:34 ` Bart Schaefer 2012-03-27 15:25 ` Richard Hartmann 2012-04-02 9:52 ` Richard Hartmann 2012-04-02 10:12 ` Peter Stephenson 2012-04-02 10:56 ` Mikael Magnusson 2012-04-02 11:00 ` Peter Stephenson 2012-04-02 11:10 ` Mikael Magnusson 2012-04-02 11:39 ` Peter Stephenson 2012-04-03 9:51 ` Richard Hartmann 2012-04-03 9:57 ` Peter Stephenson 2012-04-03 10:16 ` Mikael Magnusson 2012-04-03 11:11 ` Richard Hartmann 2012-04-03 14:06 ` Bart Schaefer 2012-04-02 10:15 ` Mikael Magnusson 2012-04-02 10:33 ` Peter Stephenson 2012-04-02 10:46 ` Mikael Magnusson 2012-04-02 11:07 ` Vincent Lefevre 2012-04-02 12:59 ` Richard Hartmann 2012-04-03 4:04 ` Jun T. 2012-04-03 14:43 ` Vincent Lefevre 2012-04-04 17:03 ` Jun T. 2012-04-05 14:20 ` Vincent Lefevre 2012-04-05 16:17 ` Jun T. 2012-04-15 1:17 ` Vincent Lefevre 2012-04-15 18:07 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).