Re: Bug in regexp operator when warn_create_global is in effect

[Ronald Fischer <ynnor@xxxxx>]

On Mon, Feb 6, 2017, at 12:11, Peter Stephenson wrote:
> On Mon, 06 Feb 2017 11:44:09 +0100
> Ronald Fischer <ynnor@xxxxx> wrote:
> > > Yes, you're right, the user doesn't even necessarily want them, which is
> > > different from the case of the globbing flags in native zsh
> > > expressions.  So probably best to turn the warnings off.
> > 
> > I wouldn't consider this an optimal solution. This type of warning
> > proved to be extremely useful, and was catching already several spelling
> > errors in our own program.
> 
> I'm not sure what you're referring to, but the change only turns off the
> warnings for the case in question, i.e. regular expression matches,
> where the use of the variables is hidden, the one you were complaining
> about.  

I think I misunderstood your comment here. I thought that you did not
want to change anything in zsh, but recommend that I simply turn off
warning about creating globals inside functions. This indeed would not
have been a good idea.

Basically, I want to be warned about globals which I explicitly create
by myself, but I don't want to be warned about globals which are created
implicitly by zsh (since I don't have any control about them.

> If you're talking about other cases, if you could show exactly what's
> triggering a warning, or failing to trigger it, I'll have a look.

The case is exactly the example program I've supplied: We get a warning
about a global variable being created, while this variable is not even
mentioned anywhere in the code.

About the suggestion in my original posting: What speaks against the
idea of creating all "implicit variables" as globals implicitly, when
the shell starts execution? That is, a program

    #!/bin/zsh
    source something
    foo bar

would be equivalent (that is, internally replaced) by

    #!/bin/zsh
    MATCH=
    source something
    foo bar

If you worry that MATCH could be an exported variable in the parent
shell (and hence must not be modified), it is trivial to include this
case as well.

Ronald