From: Ronald Fischer <ynnor@mm.st>
To: Peter Stephenson <p.stephenson@samsung.com>
Cc: zsh-workers@zsh.org
Subject: Re: Bug in regexp operator when warn_create_global is in effect
Date: Mon, 06 Feb 2017 12:26:37 +0100 [thread overview]
Message-ID: <1486380397.3096055.871643504.62927FCE@webmail.messagingengine.com> (raw)
In-Reply-To: <20170206111152.7ed7ba11@pwslap01u.europe.root.pri>
On Mon, Feb 6, 2017, at 12:11, Peter Stephenson wrote:
> On Mon, 06 Feb 2017 11:44:09 +0100
> Ronald Fischer <ynnor@mm.st> 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
next prev parent reply other threads:[~2017-02-06 11:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20170202073801epcas4p3fa77b3bbe2794d2f574ac0319f13ab3f@epcas4p3.samsung.com>
2017-02-02 7:37 ` Ronald Fischer
2017-02-02 9:43 ` Peter Stephenson
2017-02-02 22:55 ` Bart Schaefer
2017-02-03 9:20 ` Peter Stephenson
2017-02-06 10:44 ` Ronald Fischer
2017-02-06 11:11 ` Peter Stephenson
2017-02-06 11:26 ` Ronald Fischer [this message]
2017-02-06 12:02 ` Peter Stephenson
2017-02-06 15:48 ` Ronald Fischer
2017-02-06 16:04 ` Peter Stephenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1486380397.3096055.871643504.62927FCE@webmail.messagingengine.com \
--to=ynnor@mm.st \
--cc=p.stephenson@samsung.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).