Re: Bug in regexp operator when warn_create_global is in effect

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Mon, 06 Feb 2017 12:26:37 +0100
Ronald Fischer <ynnor@xxxxx> wrote:
> 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.

You might want to look at the discussion Bart referred to in his
previous post,

http://www.zsh.org/mla/workers//2015/msg03106.html

but here's the summary.

The main point is to handle cases something like the following, where
although the variable creation is hidden it's explicitly requested by the
user:

fn() {
   [[ $1 = (#m)${~2} ]]
}

That (#m) in the pattern and the fact the pattern is in a function are
the only relevant facts here.  The (#m) is a request to cause MATCH,
MBEGIN and MEND to be set by the shell.  Because that's the purpose of
(#m), you want the warning so as to be able to decide whether those
variables are to be global or not and resolve between the two with a
local or typeset -g.

Your case is different because the use of the variables isn't requested
by special syntax, it's buried under standard regex syntax, so I've
fixed it for that one case.  I'm certainly interested in any more like
this you come up with.

> > 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.

That's fixed by my patch, as far as I can tell with no collateral
damage.  Please do report any further problems of this type so we can
discuss explicitly what's going on, which always makes things much
easier.

> 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

Unless you're implying something further I haven't grapsed, that MATCH
variable is always and only cruft that's never actually providing a
useful value, and in some (as above) cases you might even want to guard
against it being global if it is created.  Also, it's not useful for any
purpose for anyone who isn't using WANRCREATEGLOBAL.  Tests to see if
the variable MATCH is set would become useless, as it always is set,
potentially breaking scripts.

(You won't know this, because it's new syntax, but we've just introduced
a new option WARN_NESTED_VAR that warns if you set a variable in an
enclosing scope, which you can turn on for specific functions if
needed.  Your trick doesn't fix that case, fixing the individual warning
does.  That option may not interest you anyway, as it's a bit more
invasive than WARN_CREATE_GLOBAL, but the problem is still there.)

I would hope there are better ways of fixing the problems related to the
warning itself, as I've done in this particular case, which is why I'd
like to see any further explicit examples in case there are any that
don't obviously fit one way or the other.

pws