* a bug of zsh @ 2016-09-28 14:06 ` ZiHan Zheng 2016-09-28 15:04 ` Peter Stephenson 0 siblings, 1 reply; 7+ messages in thread From: ZiHan Zheng @ 2016-09-28 14:06 UTC (permalink / raw) To: zsh-workers [-- 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: a bug of zsh 2016-09-28 14:06 ` a bug of zsh ZiHan Zheng @ 2016-09-28 15:04 ` Peter Stephenson 2016-09-28 15:28 ` Mikael Magnusson 0 siblings, 1 reply; 7+ messages in thread From: Peter Stephenson @ 2016-09-28 15:04 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: a bug of zsh 2016-09-28 15:04 ` Peter Stephenson @ 2016-09-28 15:28 ` Mikael Magnusson 2016-09-28 16:07 ` Peter Stephenson 0 siblings, 1 reply; 7+ messages in thread From: Mikael Magnusson @ 2016-09-28 15:28 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh workers 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: a bug of zsh 2016-09-28 15:28 ` Mikael Magnusson @ 2016-09-28 16:07 ` Peter Stephenson 2016-09-28 19:10 ` Bart Schaefer 0 siblings, 1 reply; 7+ messages in thread From: Peter Stephenson @ 2016-09-28 16:07 UTC (permalink / raw) To: zsh workers 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: a bug of zsh 2016-09-28 16:07 ` Peter Stephenson @ 2016-09-28 19:10 ` Bart Schaefer 2016-09-29 8:23 ` Peter Stephenson 0 siblings, 1 reply; 7+ messages in thread From: Bart Schaefer @ 2016-09-28 19:10 UTC (permalink / raw) To: zsh-workers [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 "." ? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: a bug of zsh 2016-09-28 19:10 ` Bart Schaefer @ 2016-09-29 8:23 ` Peter Stephenson 2016-09-30 4:29 ` Bart Schaefer 0 siblings, 1 reply; 7+ messages in thread From: Peter Stephenson @ 2016-09-29 8:23 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: a bug of zsh 2016-09-29 8:23 ` Peter Stephenson @ 2016-09-30 4:29 ` Bart Schaefer 0 siblings, 0 replies; 7+ messages in thread From: Bart Schaefer @ 2016-09-30 4:29 UTC (permalink / raw) To: zsh-workers 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 */ } /**/ ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-09-30 4:29 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CGME20160928140702eucas1p295fe6131e7ec88107a118fa9bbcbec7e@eucas1p2.samsung.com> 2016-09-28 14:06 ` a bug of zsh ZiHan Zheng 2016-09-28 15:04 ` Peter Stephenson 2016-09-28 15:28 ` Mikael Magnusson 2016-09-28 16:07 ` Peter Stephenson 2016-09-28 19:10 ` Bart Schaefer 2016-09-29 8:23 ` Peter Stephenson 2016-09-30 4:29 ` 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).