Re: Bug in regexp operator when warn_create_global is in effect

[Peter Stephenson <p.stephenson@samsung.com>]

On Thu, 2 Feb 2017 14:55:27 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:

> On Feb 2,  9:43am, Peter Stephenson wrote:
> }
> } > While it is correct, that regexp matching sets, as side effect, the
> } > variables mentioned here, it doesn't, IMHO, make much sense that a zsh
> } > user, who not even *uses* these variables, receives these error
> } > messages.
> } 
> } Yes, you're right, the user doesn't even necessarily want them
> } [...].  So probably best to turn the warnings off.
> 
> Didn't we discuss this once beforeand decide exactly the opposite?
> 
> Yes, here:
>     http://www.zsh.org/mla/workers//2015/msg03106.html
> 
> That seems to directly contradict what you just said/patched.

That's a fair point to bring up, and I remember the discussion now you
point it out, but that appears to have been more general --- in
particular, I believe I was mostly thinking about cases where the user
would have done something explicitly causing the variable to be set as
a key part of what they were doing rather than as a side effect.  For
example, anything setting REPLY has been called to get a reply, and in
native zsh, match / MATCH etc. are triggered by globbing flags.

I refer the honourable gentleman to the closing remark I made to the
list on that occasion:

> If we need to make exceptions, I think they're more likely to be connected
> to specific instances of setting variables internally.

I think this can be considered one such case --- the user is doing a
basic regular expression where the result they want is the result of the
test, and they may not even be aware that variables are created.  As a
second possibly significant point, this is not zsh-specific syntax, it's
allowed in other recent shells where you wouldn't expect to have to
declare the variables.

I'm sure you can argue this the other way, though.

pws