Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Bug in regexp operator when warn_create_global is in effect

On Thu, 2 Feb 2017 14:55:27 -0800
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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.


Messages sorted by: Reverse Date, Date, Thread, Author