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

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

[Richard Hartmann]

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

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

[Daniel Shahaf]

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

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

[Bart Schaefer]

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% 

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

[Richard Hartmann]

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

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

[Richard Hartmann]

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

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

[Peter Stephenson]

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

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

[Mikael Magnusson]

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

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

[Peter Stephenson]

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

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

[Mikael Magnusson]

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

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

[Mikael Magnusson]

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

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

[Peter Stephenson]

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

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

[Vincent Lefevre]

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)

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

[Mikael Magnusson]

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}%

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

[Peter Stephenson]

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

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

[Richard Hartmann]

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

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

[Jun T.]

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

.% 

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

[Richard Hartmann]

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

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

[Peter Stephenson]

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

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

[Mikael Magnusson]

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

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

[Richard Hartmann]

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

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

[Bart Schaefer]

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.

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

[Vincent Lefevre]

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)

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

[Jun T.]

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.

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

[Vincent Lefevre]

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)

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

[Jun T.]

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.

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

[Vincent Lefevre]

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)

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

[Bart Schaefer]

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.