From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18271 invoked by alias); 6 Feb 2017 15:48:16 -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: 40502 Received: (qmail 6746 invoked from network); 6 Feb 2017 15:48:16 -0000 X-Qmail-Scanner-Diagnostics: from out1-smtp.messagingengine.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(66.111.4.25):SA:0(-0.7/5.0):. Processed in 1.062623 secs); 06 Feb 2017 15:48:16 -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=-0.7 required=5.0 tests=FREEMAIL_FROM, RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: ynnor@mm.st X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at spf.messagingengine.com designates 66.111.4.25 as permitted sender) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=mm.st; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=4BUSYo9xgNJQyByV6xYWlVk4if g=; b=MWP+bCKE1gUd6rjM1wccLQMj+Mghw7GXW/EXGet18bxD+uD9I3VS86ukCz nD834YhRBzU5TbMkbmSIzy+SCChd8iJ7ElFDG7tkzvoYwXw1yjslqAK2ucxPgbvc +GSf5fi4dKIsvBBnnGgbHX2v2r8zkLjZtPu1i4Cjje6SMoBu4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=4B USYo9xgNJQyByV6xYWlVk4ifg=; b=sawqQ8QzWh29rnzdqUpiCGE/iXB6dnsVBt byn8WPe2/kYZhWRTThTrLrtvaNA15kgI3AMK5KlEOVIaBf/YhiwvF3HIWtZKdr2h Eqw+BsypJ0DoyA/rBLWoFmcVPNE5n1rWswjdz4niRAvgIbP5mmmFNl5glZOQidJj 93XqBWLdU= X-ME-Sender: Message-Id: <1486396090.3153023.871899752.700E33C7@webmail.messagingengine.com> From: Ronald Fischer To: Peter Stephenson , zsh-workers@zsh.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - html Date: Mon, 06 Feb 2017 16:48:10 +0100 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> Subject: Re: Bug in regexp operator when warn_create_global is in effect In-Reply-To: <20170206120215.1942a506@pwslap01u.europe.root.pri> > 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. 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. This now looks like a special case for (#m), but I wonder whether the same wouldn't be true too for zsh modules, which also might create sets of variables which belong together. >>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. > 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? Ronald