From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6494 invoked by alias); 6 Feb 2017 12:02:26 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 40499 Received: (qmail 4985 invoked from network); 6 Feb 2017 12:02:26 -0000 X-Qmail-Scanner-Diagnostics: from mailout4.w1.samsung.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(210.118.77.14):SA:0(-5.0/5.0):. Processed in 1.30579 secs); 06 Feb 2017 12:02:26 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: p.stephenson@samsung.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at samsung.com does not designate permitted sender hosts) X-AuditID: cbfec7f5-f79d06d000004445-fc-589865cad8a1 Date: Mon, 06 Feb 2017 12:02:15 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Bug in regexp operator when warn_create_global is in effect Message-id: <20170206120215.1942a506@pwslap01u.europe.root.pri> In-reply-to: <1486380397.3096055.871643504.62927FCE@webmail.messagingengine.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsWy7djPc7qnUmdEGGz/rmJxsPkhkwOjx6qD H5gCGKO4bFJSczLLUov07RK4Mrr2z2cvWChVsXXzZOYGxpsiXYwcHBICJhJPl6Z1MXICmWIS F+6tZ+ti5OIQEljKKNE98xo7hNPLJPHs+y52mIbpK9wg4ssYJa7efQBVNI1J4u+W5ywQzmlG iW1LnkBlzgA51zYwgixhEVCVuDBvLZjNJmAoMXXTbDBbREBc4uza8ywgtrCAh8SXR6uYQWxe AXuJT/2HwWo4BQIknn08DRbnF9CXuPr3ExPE4fYSM6+cYYSoF5T4Mfke2BxmAR2Jbdses0PY 8hKb17xlBjlIQqCZXaJtZzsbxD+yEpsOMEPMcZF4+2Aj1ExhiVfHt7BD2DISnR0HoeL9jBJP un0h5sxglDh9ZgcbRMJaou/2RUaIZXwSk7ZNZ4aYzyvR0SYEYQL9tUIAotpR4lzXU+YJjIqz kFw9C8nVs5BcvYCReRWjSGppcW56arGpXnFibnFpXrpecn7uJkZgEjj97/jXHYxLj1kdYhTg YFTi4X2gPz1CiDWxrLgy9xCjBAezkgjvm7gZEUK8KYmVValF+fFFpTmpxYcYpTlYlMR59yy4 Ei4kkJ5YkpqdmlqQWgSTZeLglGpgXCkdWnE2Ql85oNuu7Xxu1YuggOKZ3mzXHvb94bvc7NL7 dvrbv/HfT1f+XruTOXvTTbfb4duyK943fSzk1PWR81QMjdKXaO5NakifLWDI8FB1l5LijuId a46v1Z289E2xlMX03psPrzKaNfrP/fZwwVrVZkvX1sxswbyK3kOPDh5ILdAyDXmpxFKckWio xVxUnAgAzbXCMP4CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsVy+t/xK7pCaTMiDM6dtrY42PyQyYHRY9XB D0wBjFFuNhmpiSmpRQqpecn5KZl56bZKoSFuuhZKCnmJuam2ShG6viFBSgpliTmlQJ6RARpw cA5wD1bSt0twy+jaP5+9YKFUxdbNk5kbGG+KdDFycEgImEhMX+HWxcgJZIpJXLi3nq2LkYtD SGAJo8SPeXeZQRJCAjOYJPYczoNInGaUuN35khEicYZR4tP5QhCbRUBV4sK8tWBxNgFDiamb ZoPZIgLiEmfXnmcBsYUFPCS+PFoFNpRXwF7iU/9hsBpOgQCJZx9PM0MsmMsscejmfVaQBL+A vsTVv5+YIM6zl5h55QwjRLOgxI/J98CGMgtoSWze1sQKYctLbF7zFupqdYkbd3ezT2AUnoWk ZRaSlllIWhYwMq9iFEktLc5Nzy021CtOzC0uzUvXS87P3cQIjKFtx35u3sF4aWPwIUYBDkYl Ht4H+tMjhFgTy4orcw8xSnAwK4nwvombESHEm5JYWZValB9fVJqTWnyI0RQYMhOZpUST84Hx nVcSb2hiaG5paGRsYWFuZKQkzlvy4Uq4kEB6YklqdmpqQWoRTB8TB6dUA6P+3PPn2B+smjqj cW6XzB2TQzw/tjL9qFRP5F76dT3f+2MnfKZZXZsl3bAoJV4nTWXrkmRxzf+fQx9ebs/yM/5v f8dMwdB+27KvzFlPl0x3mbPUZ+GLbW981XzDpgrb+Cw78LK/9+GCzRPMuANM13DtNTdrzT/w Z3/Bmi7XSRs4bXTflV+ZNS1IiaU4I9FQi7moOBEAsU/TX7cCAAA= X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170206120218eucas1p174ece0b5982a66d6516b59c8f2a6b647 X-Msg-Generator: CA X-Sender-IP: 182.198.249.179 X-Local-Sender: =?UTF-8?B?UGV0ZXIgU3RlcGhlbnNvbhtTQ1NDLURhdGEgUGxhbmUb?= =?UTF-8?B?7IK87ISx7KCE7J6QG1ByaW5jaXBhbCBFbmdpbmVlciwgU29mdHdhcmU=?= X-Global-Sender: =?UTF-8?B?UGV0ZXIgU3RlcGhlbnNvbhtTQ1NDLURhdGEgUGxhbmUbU2Ft?= =?UTF-8?B?c3VuZyBFbGVjdHJvbmljcxtQcmluY2lwYWwgRW5naW5lZXIsIFNvZnR3YXJl?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDA1Q0QwNTAwNTg=?= CMS-TYPE: 201P X-HopCount: 7 X-CMS-RootMailID: 20170202073801epcas4p3fa77b3bbe2794d2f574ac0319f13ab3f X-RootMTR: 20170202073801epcas4p3fa77b3bbe2794d2f574ac0319f13ab3f References: <1486021036.1782934.867696784.0FCB3E9A@webmail.messagingengine.com> <20170202094340.64946066@pwslap01u.europe.root.pri> <1486377849.3086499.871611224.31A19FC9@webmail.messagingengine.com> <20170206111152.7ed7ba11@pwslap01u.europe.root.pri> <1486380397.3096055.871643504.62927FCE@webmail.messagingengine.com> On Mon, 06 Feb 2017 12:26:37 +0100 Ronald Fischer 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