a bug of zsh

a bug of zsh

[ZiHan Zheng]

[-- Attachment #1: Type: text/plain, Size: 162 bytes --]

to reproduce this bug:

cd ~
mkdir aaa
cd aaa
rm ~/aaa -r
cd .

then current working directory is just "." and you can do nothing until cd
into an absolute path.

Re: a bug of zsh

[Peter Stephenson]

On Wed, 28 Sep 2016 22:06:25 +0800
ZiHan Zheng <zhengzihan1996@gmail.com> wrote:
> to reproduce this bug:
> 
> cd ~
> mkdir aaa
> cd aaa
> rm ~/aaa -r
> cd .
> 
> then current working directory is just "." and you can do nothing until cd
> into an absolute path.

Hmmm... I can see you're point, I think --- before you do "cd .", the
shell will happily use the logical directory structure to e.g. "cd ..",
whereas after you do "cd ." you're stuck without something like cd
$PWD/..

It would certainly be good if there's some way of aborting the "cd ."
consistently so we both don't actually change directory and don't lose
state.  I think the problem may be once we find we can't cd any more we
throw up our hands in horror and decide we don't know where we are,
which is certainly a bit feeble, particularly since there's no
outward indication of a problem until you find you're trapped.

Is there some reason we can't just stat the directory first and bail
out early? I know it's prohibitively expensive testing glob results
with stat, but this is a rather different case.

However, the cd logic is already more complicated than you would
probably believe, and changing to a directory that no longer exists
isn't going to have good effects, so I'm not sure how much sleep we're
(well, I'm) actually going to lose over this, to be brutally honest.

pws

Re: a bug of zsh

[Mikael Magnusson]

On Wed, Sep 28, 2016 at 5:04 PM, Peter Stephenson
<p.stephenson@samsung.com> wrote:
> On Wed, 28 Sep 2016 22:06:25 +0800
> ZiHan Zheng <zhengzihan1996@gmail.com> wrote:
>> to reproduce this bug:
>>
>> cd ~
>> mkdir aaa
>> cd aaa
>> rm ~/aaa -r
>> cd .
>>
>> then current working directory is just "." and you can do nothing until cd
>> into an absolute path.
>
> Hmmm... I can see you're point, I think --- before you do "cd .", the
> shell will happily use the logical directory structure to e.g. "cd ..",
> whereas after you do "cd ." you're stuck without something like cd
> $PWD/..
>
> It would certainly be good if there's some way of aborting the "cd ."
> consistently so we both don't actually change directory and don't lose
> state.  I think the problem may be once we find we can't cd any more we
> throw up our hands in horror and decide we don't know where we are,
> which is certainly a bit feeble, particularly since there's no
> outward indication of a problem until you find you're trapped.
>
> Is there some reason we can't just stat the directory first and bail
> out early? I know it's prohibitively expensive testing glob results
> with stat, but this is a rather different case.
>
> However, the cd logic is already more complicated than you would
> probably believe, and changing to a directory that no longer exists
> isn't going to have good effects, so I'm not sure how much sleep we're
> (well, I'm) actually going to lose over this, to be brutally honest.

FWIW this is only a problem if you use nochasedots/nochaselinks, which
while it is the default, is overall a very confusing option to have
set and hopefully most people disable it. In either case you can
always do cd -P .. to get out as well. I feel like it should be
possible to get the -L branch to detect this state and fall back to a
-P .. but honestly I'm not sure if the current state is unintended for
-L or not.

-- 
Mikael Magnusson

Re: a bug of zsh

[Peter Stephenson]

On Wed, 28 Sep 2016 17:28:08 +0200
Mikael Magnusson <mikachu@gmail.com> wrote:
> FWIW this is only a problem if you use nochasedots/nochaselinks, which
> while it is the default, is overall a very confusing option to have
> set and hopefully most people disable it.

Hmm, this would render symbolic links at best semi-workable for me, so
while it's worth considering your own situation and there are arguments
bothw ways I definitely won't suggest people just rush out and do it
regardless...

pws

Re: a bug of zsh

[Bart Schaefer]

[Sorry, lots of context to set up a really short question at the end.]

On Sep 28,  4:04pm, Peter Stephenson wrote:
}
} It would certainly be good if there's some way of aborting the "cd ."
} consistently so we both don't actually change directory and don't lose
} state.  I think the problem may be once we find we can't cd any more we
} throw up our hands in horror and decide we don't know where we are,
} which is certainly a bit feeble, particularly since there's no
} outward indication of a problem until you find you're trapped.

On Sep 28,  5:07pm, Peter Stephenson wrote:
} Subject: Re: a bug of zsh
}
} On Wed, 28 Sep 2016 17:28:08 +0200
} Mikael Magnusson <mikachu@gmail.com> wrote:
} > FWIW this is only a problem if you use nochasedots/nochaselinks, which
} > while it is the default, is overall a very confusing option to have
} > set and hopefully most people disable it.
} 
} Hmm, this would render symbolic links at best semi-workable for me, so
} while it's worth considering


What if "cd" simply behaves as if chase_dots is set any time the value of
$PWD is "." ?

Re: a bug of zsh

[Peter Stephenson]

On Wed, 28 Sep 2016 12:10:10 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> What if "cd" simply behaves as if chase_dots is set any time the value of
> $PWD is "." ?

Ah, you mean (with the default options)

% ./foo
% pwd
/export/home/pws/tmp/foo
% rmdir ../foo
% pwd
/export/home/pws/tmp/foo      # cd .. still works here
% cd .
% pwd
.                             # but now "cd .." would require chase_dots
%

That seems a reasonable minimal fix.  I haven't looked at the code.

pws

Re: a bug of zsh

[Bart Schaefer]

On Sep 29,  9:23am, Peter Stephenson wrote:
} Subject: Re: a bug of zsh
}
} % ./foo
} % pwd
} /export/home/pws/tmp/foo
} % rmdir ../foo
} % pwd
} /export/home/pws/tmp/foo      # cd .. still works here
} % cd .
} % pwd
} .                             # but now "cd .." would require chase_dots
} %
} 
} That seems a reasonable minimal fix.  I haven't looked at the code.

Try it this way?


diff --git a/Src/builtin.c b/Src/builtin.c
index c78fd9b..60dc07f 100644
--- a/Src/builtin.c
+++ b/Src/builtin.c
@@ -1273,7 +1273,23 @@ fixdir(char *src)
 #ifdef __CYGWIN__
     char *s0 = src;
 #endif
-    int ret = 0;
+    /* This function is always called with n path containing at
+     * least one slash, either because one was input by the user or
+     * because the caller has prepended either pwd or a cdpath dir.
+     * If asked to make a relative change and pwd is set to ".",
+     * the current directory has been removed out from under us,
+     * so force links to be chased.
+     *
+     * Ordinarily we can't get here with "../" as the first component
+     * but handle the silly special case of ".." in cdpath.
+     *
+     * Order of comparisons here looks funny, but it short-circuits
+     * most rapidly in the event of a false condition.  Set to 2
+     * here so we still obey the (lack of) CHASEDOTS option after
+     * the first "../" is preserved (test chasedots > 1 below).
+     */
+    int chasedots = (src[0] == '.' && pwd[0] == '.' && pwd[1] == '\0' &&
+		     (src[1] == '/' || (src[1] == '.' && src[2] == '/'))) * 2;
 
 /*** if have RFS superroot directory ***/
 #ifdef HAVE_SUPERROOT
@@ -1305,12 +1321,12 @@ fixdir(char *src)
 	    while (dest > d0 + 1 && dest[-1] == '/')
 		dest--;
 	    *dest = '\0';
-	    return ret;
+	    return chasedots;
 	}
 	if (src[0] == '.' && src[1] == '.' &&
 	    (src[2] == '\0' || src[2] == '/')) {
-	    if (isset(CHASEDOTS)) {
-		ret = 1;
+	    if (isset(CHASEDOTS) || chasedots > 1) {
+		chasedots = 1;
 		/* and treat as normal path segment */
 	    } else {
 		if (dest > d0 + 1) {
@@ -1348,6 +1364,7 @@ fixdir(char *src)
 		    dest[-1] = *src++ ^ 32;
 	}
     }
+    /* unreached */
 }
 
 /**/