From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15300 invoked by alias); 3 Feb 2017 09:30:34 -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: 40490 Received: (qmail 11053 invoked from network); 3 Feb 2017 09:30:34 -0000 X-Qmail-Scanner-Diagnostics: from mailout3.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.13):SA:0(-5.0/5.0):. Processed in 3.141142 secs); 03 Feb 2017 09:30:34 -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-73-58944b538d0f Date: Fri, 03 Feb 2017 09:20:17 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Bug in regexp operator when warn_create_global is in effect Message-id: <20170203092017.3e646cc8@pwslap01u.europe.root.pri> In-reply-to: <170202145527.ZM20908@torch.brasslantern.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+NgFnrJIsWRmVeSWpSXmKPExsWy7djPc7rB3lMiDJ7Ok7E42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGXv/Kha85qs4eeYYWwPjI+4uRg4OCQETic8Ta7oYOYFMMYkL 99azdTFycQgJLGWUOPH2NguE08skMefBRHaIKhOJ1k3/mSESyxglvs5vZwNJCAlMY5K49tkE InGaUeLklx3sEIkzjBIfJmWC2CwCqhJTb38Gi7MJGEpM3TSbEcQWERCXOLv2PAuILSzgIfHl 0SpmEJtXwF7i/9ZlYDWcAlYSbY9nMIHY/AL6Elf/fmKCuMheYuaVM4wQ9YISPybfA5vDLKAj sW3bY3YIW15i85q3YFdLCPxnk1j0/xorxP+yEpsOMEPMcZE48/AM1ExhiVfHt0B9LCPR2XEQ Kt7PKPGk2xdizgxGidNndrBBJKwl+m5fZIRYxicxadt0Zoj5vBIdbUIQJtBfKwQgqh0lznU9 ZZ7AqDgLydWzkFw9C8nVCxiZVzGKpJYW56anFpvqFSfmFpfmpesl5+duYgQmgNP/jn/dwbj0 mNUhRgEORiUe3hPekyOEWBPLiitzDzFKcDArifBGek6JEOJNSaysSi3Kjy8qzUktPsQozcGi JM67Z8GVcCGB9MSS1OzU1ILUIpgsEwenVAPjlbyDf/xvRLuwfZD7y8R4ZJNXqdi9AuvFp5OM zswICUv3eTLhbkT3hImG24/GGLCZzOhobHeel2McHbDqxLPHArujtr9Tjl4a8+79+uwrkyPe 2JZYhP5p4ZYJVlY1ZVq9lc+o5lWrBZtxpmuMu2m52S0fpRTupfzWuxPF1ja8DmpbO8tCnFGJ pTgj0VCLuag4EQDDu2sY/AIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsVy+t/xq7ozvadEGPRtEbE42PyQyYHRY9XB D0wBjFFuNhmpiSmpRQqpecn5KZl56bZKoSFuuhZKCnmJuam2ShG6viFBSgpliTmlQJ6RARpw cA5wD1bSt0twy9j7V7HgNV/FyTPH2BoYH3F3MXJySAiYSLRu+s8MYYtJXLi3nq2LkYtDSGAJ o8SLV3tYIJwZTBL3L96Dck4zSlz/uJURpEVI4AyjxLqjdiA2i4CqxNTbn9lBbDYBQ4mpm2aD 1YgIiEucXXueBcQWFvCQ+PJoFdg6XgF7if9bl4HVcApYSbQ9nsEEsaCbSWL+gblsIAl+AX2J q38/MUHcZy8x88oZRohmQYkfk++BDWUW0JLYvK2JFcKWl9i85i0zxHHqEjfu7mafwCg8C0nL LCQts5C0LGBkXsUoklpanJueW2yoV5yYW1yal66XnJ+7iREYRduO/dy8g/HSxuBDjAIcjEo8 vAWekyOEWBPLiitzDzFKcDArifBGek6JEOJNSaysSi3Kjy8qzUktPsRoCgyZicxSosn5wAjP K4k3NDE0tzQ0MrawMDcyUhLnLflwJVxIID2xJDU7NbUgtQimj4mDU6qBUX9K6bkKqWevP1mt Nd18qCN3WvJcA70tT+pP3F+/bemquUdr/tUzqGwpbxfj5phvUqDa3BGRcYPHr/669y27dUrn gtsyW0VfC7WXb7MO27Bt4gqjY8Kh+dHFc4rnv1jzZc+zciEjQd9Nv+tOrpF0CvvXc7Kk7OOT XrbY6b/O9xzTiDVmbFVyVmIpzkg01GIuKk4EAAiu+je4AgAA X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170203092018eucas1p12f18879c4db6d5286f8752d9fdebf32d 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> <170202145527.ZM20908@torch.brasslantern.com> On Thu, 2 Feb 2017 14:55:27 -0800 Bart Schaefer wrote: > On Feb 2, 9:43am, Peter Stephenson wrote: > } > } > While it is correct, that regexp matching sets, as side effect, the > } > variables mentioned here, it doesn't, IMHO, make much sense that a zsh > } > user, who not even *uses* these variables, receives these error > } > messages. > } > } Yes, you're right, the user doesn't even necessarily want them > } [...]. So probably best to turn the warnings off. > > Didn't we discuss this once beforeand decide exactly the opposite? > > Yes, here: > http://www.zsh.org/mla/workers//2015/msg03106.html > > That seems to directly contradict what you just said/patched. That's a fair point to bring up, and I remember the discussion now you point it out, but that appears to have been more general --- in particular, I believe I was mostly thinking about cases where the user would have done something explicitly causing the variable to be set as a key part of what they were doing rather than as a side effect. For example, anything setting REPLY has been called to get a reply, and in native zsh, match / MATCH etc. are triggered by globbing flags. I refer the honourable gentleman to the closing remark I made to the list on that occasion: > If we need to make exceptions, I think they're more likely to be connected > to specific instances of setting variables internally. I think this can be considered one such case --- the user is doing a basic regular expression where the result they want is the result of the test, and they may not even be aware that variables are created. As a second possibly significant point, this is not zsh-specific syntax, it's allowed in other recent shells where you wouldn't expect to have to declare the variables. I'm sure you can argue this the other way, though. pws