Re: Bug in regexp operator when warn_create_global is in effect

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

On Mon, 06 Feb 2017 16:48:10 +0100
Ronald Fischer <ynnor@mm.st> wrote:
> Now I get it! Thanks for the explanation!
> 
> This (#m) example makes me think to the following problem (looks like an
> opened can of worms): 
> 
> Clearly, a user who is aware to the global-vs-local topic will
> conciously decide, whether he wants the M* variables local or global,
> but no matter how he decides, it would be an insane decision if he
> doesn't decide for the same scope on all three variables. For example,
> it doesn't make sense to define MBEGIN as global and MATCH and MEND as
> local. From the programmer's viewpoint, it would be more natural to
> either decide on these three variables "as a group". Either all global
> or all local. Currently, there is nothing which would enforce this
> decision.

Yes, indeed.  We're right at the limit of what you can get from a single
option.  You could argue even the various cases of MATCH, REPLY,
etc. could have been a different option from the original
WARN_CREATE_GLOBAL --- it isn't basically because it still fits in with
what I originally thought the option was for, but I think your use is a
little different. Too late now.

The case of leaving one of the variables as a global and then having it
overridden in a function is what the new WARN_NESTED_VAR / functions -W
is about.  But that's arguably something of a sledgehammer:  that's why
we made it settable for only one function at a time as well as
glboally.  (That will also appear in 5.4 if you ever want to
investigate.)

> From a programmer's viewpoint, a good concept (IMHO) would be that these
> automatically created variables are always local, so if a function wants
> to make a match globally visible, it would have to create its own global
> variable for this. In the same way, it would perhaps make sense that
> loop variables (in for-loop) are by default local, because this is the
> usual way to use them. However, in both cases this might break existing
> code, so it is perhaps not a real alternative. Seems that we have to
> live with a compromise.

Yes, it's all rather a compromise.  Shell language is a bit of an
outlier in terms of modern scripting languages in many ways.

We actually recently rejected the notion of automatically making things
local as making scoping that bit too complicated, introducing too many
incompatibilities or possible hard to find glitches, etc., and I think
it's quite unlikely we'd go down that route as things stand.  (We
invented WARN_NESTED_VAR as a proxy.)  But that certainly doesn't mean
what we've got is perfect.

> > That's fixed by my patch, as far as I can tell with no collateral
> > damage. 
> 
> Thanks a lot, really. From which zsh version will this be available?

Will be in 5.4 --- but that's not currently imminent.  I'd like to
have quicker releases than we did last year, if possible, but it seems
the shell doesn't currently compile on at least one not-very-obscure
system.

pws