From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21996 invoked by alias); 6 Feb 2017 16:14:19 -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: 40503 Received: (qmail 19189 invoked from network); 6 Feb 2017 16:14:19 -0000 X-Qmail-Scanner-Diagnostics: from mailout1.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.11):SA:0(-5.0/5.0):. Processed in 1.375498 secs); 06 Feb 2017 16:14:19 -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: cbfec7ef-f79d26d00000420c-f0-58989e7aad14 Date: Mon, 06 Feb 2017 16:04:04 +0000 From: Peter Stephenson To: Ronald Fischer Cc: zsh-workers@zsh.org Subject: Re: Bug in regexp operator when warn_create_global is in effect Message-id: <20170206160404.5612527c@pwslap01u.europe.root.pri> In-reply-to: <1486396090.3153023.871899752.700E33C7@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+NgFvrIIsWRmVeSWpSXmKPExsWy7djP87pV82ZEGFxdq26x+ZydxcHmh0wO TB7vHn1k9lh18ANTAFMUl01Kak5mWWqRvl0CV8b2K+2MBUfFK57+u87SwHhXqIuRk0NCwETi 7ed97BC2mMSFe+vZuhi5OIQEljFKPJ7zEsr5zCjxbP45dpiOpzP2g9lgVRcPiUAU/WOUuPz2 DStE4jSjxP0zMhD2GUaJ37ckQWwWAVWJxl/NLCA2m4ChxNRNsxlBbBEBBYntS54CDeXgYBYQ l5g9JRAkLCzgIfHl0SpmEJtXwF5i/u/vTCA2p0CAxPlVK8Bu4BfQl7j69xMTxG32EjOvnGGE qBeU+DH5HtgqZgEdiW3bHrND2PISm9e8ZQa5WUJgHrvEjRs3WED2SgjISmw6wAxhukhc+WAL MVJY4tXxLVCvy0h0dhyEWtXPKPGk2xdizAxGidNndrBBJKwl+m5fZITYxScxadt0qJm8Eh1t QhAm0FsrBCYwKs1CcugsJIfOQnLoAkbmVYwiqaXFuempxYZ6xYm5xaV56XrJ+bmbGIEJ4fS/ 4+93MD5tDjnEKMDBqMTDm9ExI0KINbGsuDL3EKMEB7OSCK/QHKAQb0piZVVqUX58UWlOavEh RmkOFiVx3r0LroQLCaQnlqRmp6YWpBbBZJk4OKUaGFsLtb/L7Yz7H7qF/eQT+35OyX+xTPuV PC9EKL5fG7xsZvGqidM/HCu7ujks5WvCNHPGn6f+hauEH5/ofqnz08PXopNtr6RpPn6k7zlJ /eSPg3MFwlsWTBMT/lO0prq5MF5m8hu9N8vv7Li74edtNZeC+PnBs+J6lbdJXzW5wOh1quYR d6Jac4USS3FGoqEWc1FxIgCGPl8nBAMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsVy+t/xa7oH5s2IMLg5Udli8zk7i4PND5kc mDzePfrI7LHq4AemAKYoN5uM1MSU1CKF1Lzk/JTMvHRbpdAQN10LJYW8xNxUW6UIXd+QICWF ssScUiDPyAANODgHuAcr6dsluGVsv9LOWHBUvOLpv+ssDYx3hboYOTkkBEwkns7Yzw5hi0lc uLeerYuRi0NIYAmjxOG9/5lBEkICDUwSq14LQSROM0q0/7rCBOGcYZRomHCSBaSKRUBVovFX M5jNJmAoMXXTbEYQW0RAQWL7kqdAKzg4mAXEJWZPCQQJCwt4SHx5tApsAa+AvcT839+ZQGxO gQCJ86tWsEPMn8ki8WPLarCZ/AL6Elf/fmKCONVeYuaVM4wQzYISPybfA6thFtCS2LytiRXC lpfYvOYt1AfqEjfu7mafwCgyC0nLLCQts5C0LGBkXsUoklpanJueW2yoV5yYW1yal66XnJ+7 iREYb9uO/dy8g/HSxuBDjAIcjEo8vAe6ZkQIsSaWFVfmHmKU4GBWEuEVmgMU4k1JrKxKLcqP LyrNSS0+xGgKDKSJzFKiyfnAVJBXEm9oYmhuaWhkbGFhbmSkJM5b8uFKuJBAemJJanZqakFq EUwfEwenVANj9brk+dJ7f8Yw2hQ+DP28gfkjJ29YEePu4woWJ7btqf7W79XAN/PA4eNVkxkX 39p8bauQ1u03b7a8/Hcsey/ndaaPx3JP/tGV0JP1Szb9rPAxbSVPQaa50Bmz1x8f186Tk/Y2 FMy0qVy41GtB4Gvd341PTacKr/gwmeHmn6Rt+84k1K59aF2wXomlOCPRUIu5qDgRAOonkI/N AgAA X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170206160407eucas1p26518be9c771cc42a50057a5e171bfed2 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> <20170206120215.1942a506@pwslap01u.europe.root.pri> <1486396090.3153023.871899752.700E33C7@webmail.messagingengine.com> On Mon, 06 Feb 2017 16:48:10 +0100 Ronald Fischer 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