Remind me why ${name+word} is the way it is?

Remind me why ${name+word} is the way it is?

[Bart Schaefer]

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.

Re: Remind me why ${name+word} is the way it is?

[Peter Stephenson]

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

Re: Remind me why ${name+word} is the way it is?

[Han Pingtian]

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.

Re: Remind me why ${name+word} is the way it is?

[Bart Schaefer]

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.

Re: Remind me why ${name+word} is the way it is?

[Han Pingtian]

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.

Spurious "no match" (Re: Remind me why ${name+word} is the way it is?)

[Bart Schaefer]

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");
 }
 

Re: Spurious "no match" (Re: Remind me why ${name+word} is the way it is?)

[Peter Stephenson]

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

Re: Spurious "no match" (Re: Remind me why ${name+word} is the way it is?)

[Peter Stephenson]

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

Re: Remind me why ${name+word} is the way it is?

[Han Pingtian]

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.