* Remind me why ${name+word} is the way it is? @ 2016-11-12 4:34 ` Bart Schaefer 2016-11-14 9:46 ` Peter Stephenson 2016-11-17 2:33 ` Han Pingtian 0 siblings, 2 replies; 9+ messages in thread From: Bart Schaefer @ 2016-11-12 4:34 UTC (permalink / raw) To: zsh-workers Noodling with something else and ... torch% name='foo[bar]' torch% echo ${name} foo[bar] torch% echo ${name+foo[bar]} zsh: no matches found: foo[bar] torch% print -l ${name+foo bar} foo bar So the "word" in ${name+word} and variants is not subject to splitting, but is subject to globbing, even though (w/o GLOB_SUBST SH_WORDSPLIT) ${name} is not subject to either of those. I know it's always been that way and I'm sure I knew why at some point. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Remind me why ${name+word} is the way it is? 2016-11-12 4:34 ` Remind me why ${name+word} is the way it is? Bart Schaefer @ 2016-11-14 9:46 ` Peter Stephenson 2016-11-17 2:33 ` Han Pingtian 1 sibling, 0 replies; 9+ messages in thread From: Peter Stephenson @ 2016-11-14 9:46 UTC (permalink / raw) To: zsh-workers On Fri, 11 Nov 2016 20:34:00 -0800 Bart Schaefer <schaefer@brasslantern.com> wrote: > Noodling with something else and ... > > torch% name='foo[bar]' > torch% echo ${name} > foo[bar] > torch% echo ${name+foo[bar]} > zsh: no matches found: foo[bar] > torch% print -l ${name+foo bar} > foo bar > > So the "word" in ${name+word} and variants is not subject to splitting, > but is subject to globbing, even though (w/o GLOB_SUBST SH_WORDSPLIT) > ${name} is not subject to either of those. It's obviously needed for the parameter operators with pattern matching that things don't get quoted. (Except when they already are double-quoted and need unquoting.) I don't know of a good reason why the operators that just substitute a value are like that. It may just be no special case was ever added. pws ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Remind me why ${name+word} is the way it is? 2016-11-12 4:34 ` Remind me why ${name+word} is the way it is? Bart Schaefer 2016-11-14 9:46 ` Peter Stephenson @ 2016-11-17 2:33 ` Han Pingtian 2016-11-17 5:34 ` Bart Schaefer 2016-11-18 1:30 ` Remind me why ${name+word} is the way it is? Han Pingtian 1 sibling, 2 replies; 9+ messages in thread From: Han Pingtian @ 2016-11-17 2:33 UTC (permalink / raw) To: zsh-workers On Fri, Nov 11, 2016 at 08:34:00PM -0800, Bart Schaefer wrote: > Noodling with something else and ... > > torch% name='foo[bar]' > torch% echo ${name} > foo[bar] > torch% echo ${name+foo[bar]} When I was trying this I got this strange result of 'url-quote-magic': % name=a;echo ${name:+foo[bar]} zsh: no match % url-quote-magic:10: no match % url-quote-magic:10: no match % url-quote-magic:10: no match % url-quote-magic:10: no match % = url-quote-magic:10: no match % == url-quote-magic:10: no match % === url-quote-magic:10: no match % ==== url-quote-magic:10: no match % ===== space and = cause the warning "url-quote-magic:10: no match". This only can be triggered by running "name=a;echo ${name:+foo[bar]}" first. > zsh: no matches found: foo[bar] > torch% print -l ${name+foo bar} > foo bar > > So the "word" in ${name+word} and variants is not subject to splitting, > but is subject to globbing, even though (w/o GLOB_SUBST SH_WORDSPLIT) > ${name} is not subject to either of those. > > I know it's always been that way and I'm sure I knew why at some point. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Remind me why ${name+word} is the way it is? 2016-11-17 2:33 ` Han Pingtian @ 2016-11-17 5:34 ` Bart Schaefer 2016-11-23 1:26 ` Han Pingtian 2016-11-18 1:30 ` Remind me why ${name+word} is the way it is? Han Pingtian 1 sibling, 1 reply; 9+ messages in thread From: Bart Schaefer @ 2016-11-17 5:34 UTC (permalink / raw) To: Zsh hackers list On Wed, Nov 16, 2016 at 6:33 PM, Han Pingtian <hanpt@linux.vnet.ibm.com> wrote: > > % name=a;echo ${name:+foo[bar]} > zsh: no match > % > url-quote-magic:10: no match What zsh version are you using? I can't reproduce this (tried 5.2 and git HEAD). Line 10 is words=("${(@Q)${(z)lbuf}}") To get the "no match" message you have to have cshnullglob set, and obviously you also have self-insert remapped to url-quote-magic. I suspect you have another setting that is influencing this. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Remind me why ${name+word} is the way it is? 2016-11-17 5:34 ` Bart Schaefer @ 2016-11-23 1:26 ` Han Pingtian 2016-11-29 6:44 ` Spurious "no match" (Re: Remind me why ${name+word} is the way it is?) Bart Schaefer 0 siblings, 1 reply; 9+ messages in thread From: Han Pingtian @ 2016-11-23 1:26 UTC (permalink / raw) To: zsh-workers On Wed, Nov 16, 2016 at 09:34:32PM -0800, Bart Schaefer wrote: > On Wed, Nov 16, 2016 at 6:33 PM, Han Pingtian <hanpt@linux.vnet.ibm.com> wrote: > > > > % name=a;echo ${name:+foo[bar]} > > zsh: no match > > % > > url-quote-magic:10: no match > Oh, I can still reproduce this problem by running name=a;echo ${name:+foo[bar]} two times. > What zsh version are you using? I can't reproduce this (tried 5.2 and > git HEAD). > I am using git HEAD, this problem can be reprodced. > Line 10 is > > words=("${(@Q)${(z)lbuf}}") > > To get the "no match" message you have to have cshnullglob set, and > obviously you also have self-insert remapped to url-quote-magic. I > suspect you have another setting that is influencing this. Yes, I have cshnullglob set and self-insert remapped. If I unset cshnullglob, then this problem cannot be reproduced any more. Those are all the options: % setopt autocd autopushd nobgnice braceccl completeinword cshnullglob extendedglob extendedhistory noglobalrcs globcomplete histexpiredupsfirst histfindnodups histignorespace histlexwords histsavenodups histverify incappendhistorytime interactive interactivecomments kshtypeset nolistambiguous magicequalsubst monitor pushdignoredups rcexpandparam rcquotes rmstarwait shinstdin zle Thanks. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Spurious "no match" (Re: Remind me why ${name+word} is the way it is?) 2016-11-23 1:26 ` Han Pingtian @ 2016-11-29 6:44 ` Bart Schaefer 2016-11-29 9:38 ` Peter Stephenson 0 siblings, 1 reply; 9+ messages in thread From: Bart Schaefer @ 2016-11-29 6:44 UTC (permalink / raw) To: zsh-workers On Nov 23, 9:26am, Han Pingtian wrote: } Subject: Re: Remind me why ${name+word} is the way it is? } } On Wed, Nov 16, 2016 at 09:34:32PM -0800, Bart Schaefer wrote: } > On Wed, Nov 16, 2016 at 6:33 PM, Han Pingtian <hanpt@linux.vnet.ibm.com> wrote: } > > } > > % name=a;echo ${name:+foo[bar]} } > > zsh: no match } > > % } > > url-quote-magic:10: no match } > } Oh, I can still reproduce this problem by running } } name=a;echo ${name:+foo[bar]} } } two times. So, this isn't url-quote-magic's fault -- the value of the internal C variable badcshglob is never getting cleared after the error has been ignored, so it trips the next time any command passes through a test for whether a glob has failed. Any user-defined widget that assigns to an array ought to generate the same error. This seems to do the right thing, but someone please review: diff --git a/Src/subst.c b/Src/subst.c index c7c5522..42e741a 100644 --- a/Src/subst.c +++ b/Src/subst.c @@ -411,7 +411,9 @@ globlist(LinkList list, int nountok) next = nextnode(node); zglob(list, node, nountok); } - if (badcshglob == 1) + if (noerrs) + badcshglob = 0; + else if (badcshglob == 1) zerr("no match"); } ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Spurious "no match" (Re: Remind me why ${name+word} is the way it is?) 2016-11-29 6:44 ` Spurious "no match" (Re: Remind me why ${name+word} is the way it is?) Bart Schaefer @ 2016-11-29 9:38 ` Peter Stephenson 2016-11-29 10:06 ` Peter Stephenson 0 siblings, 1 reply; 9+ messages in thread From: Peter Stephenson @ 2016-11-29 9:38 UTC (permalink / raw) To: zsh-workers On Mon, 28 Nov 2016 22:44:50 -0800 Bart Schaefer <schaefer@brasslantern.com> wrote: > So, this isn't url-quote-magic's fault -- the value of the internal C > variable badcshglob is never getting cleared after the error has been > ignored, so it trips the next time any command passes through a test > for whether a glob has failed. Any user-defined widget that assigns > to an array ought to generate the same error. > > This seems to do the right thing, but someone please review: The code structure for this badcshglob great; it's hard to see how it could have been right to allow that error to propagate back to who knows where. I think the change could only cause problems by unexpected side effects. pws ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Spurious "no match" (Re: Remind me why ${name+word} is the way it is?) 2016-11-29 9:38 ` Peter Stephenson @ 2016-11-29 10:06 ` Peter Stephenson 0 siblings, 0 replies; 9+ messages in thread From: Peter Stephenson @ 2016-11-29 10:06 UTC (permalink / raw) To: zsh-workers On Tue, 29 Nov 2016 09:38:08 +0000 Peter Stephenson <p.stephenson@samsung.com> wrote: > The code structure for this badcshglob great should say "The code structure for badcshglob isn't great". pws ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Remind me why ${name+word} is the way it is? 2016-11-17 2:33 ` Han Pingtian 2016-11-17 5:34 ` Bart Schaefer @ 2016-11-18 1:30 ` Han Pingtian 1 sibling, 0 replies; 9+ messages in thread From: Han Pingtian @ 2016-11-18 1:30 UTC (permalink / raw) To: zsh-workers On Thu, Nov 17, 2016 at 10:33:25AM +0800, Han Pingtian wrote: > On Fri, Nov 11, 2016 at 08:34:00PM -0800, Bart Schaefer wrote: > > Noodling with something else and ... > > > > torch% name='foo[bar]' > > torch% echo ${name} > > foo[bar] > > torch% echo ${name+foo[bar]} > When I was trying this I got this strange result of 'url-quote-magic': > > % name=a;echo ${name:+foo[bar]} > zsh: no match > % > url-quote-magic:10: no match > % > url-quote-magic:10: no match > % > url-quote-magic:10: no match > % > url-quote-magic:10: no match > % = > url-quote-magic:10: no match > % == > url-quote-magic:10: no match > % === > url-quote-magic:10: no match > % ==== > url-quote-magic:10: no match > % ===== > > space and = cause the warning "url-quote-magic:10: no match". This only > can be triggered by running "name=a;echo ${name:+foo[bar]}" first. Never mind. This problem gone away after a recompilation. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2016-11-29 10:16 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CGME20161112043435epcas1p1414be9386b843c435a1f1bc6cb242af1@epcas1p1.samsung.com> 2016-11-12 4:34 ` Remind me why ${name+word} is the way it is? Bart Schaefer 2016-11-14 9:46 ` Peter Stephenson 2016-11-17 2:33 ` Han Pingtian 2016-11-17 5:34 ` Bart Schaefer 2016-11-23 1:26 ` Han Pingtian 2016-11-29 6:44 ` Spurious "no match" (Re: Remind me why ${name+word} is the way it is?) Bart Schaefer 2016-11-29 9:38 ` Peter Stephenson 2016-11-29 10:06 ` Peter Stephenson 2016-11-18 1:30 ` Remind me why ${name+word} is the way it is? Han Pingtian
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).