From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 781 invoked by alias); 6 Feb 2017 11:26:41 -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: 40498 Received: (qmail 6107 invoked from network); 6 Feb 2017 11:26:41 -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 0.692017 secs); 06 Feb 2017 11:26:41 -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=cc :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=nWe9X+MM0rXX0KPbpEhoyGnRzR E=; b=NsPTYz9aG0TxP+4z62YV03aD+YzEDjBoelFDZWRMWfklEztUaUy/oKitBf csEyT4y4kVAgcWueoVq7AT7O15EiEZlU4MOi6erW4Ppv19zq6nm5gi62O/8rtGcS t0h5QENi1mv0/57+crJ2QMW9FR2BHWV9GB6q7f78COPoIsGgY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=nW e9X+MM0rXX0KPbpEhoyGnRzRE=; b=owZEGkiw+jrIiuxSqKe1ejjID/Iv/sdqF1 8FY/Zqu0y2Dx8IJuuW21seNImEbCdCA1irTQQX7KnSF8XOcXS7LZ4cSTP6B2j5it MQAXCGD6sEDL9mYZkDpfbHIm8ze47eTv+9AnBv5zjRalUhuTs5DJZR4okX9ZCm1Z KhMpa/v6k= X-ME-Sender: Message-Id: <1486380397.3096055.871643504.62927FCE@webmail.messagingengine.com> From: Ronald Fischer To: Peter Stephenson Cc: 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 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> In-Reply-To: <20170206111152.7ed7ba11@pwslap01u.europe.root.pri> Subject: Re: Bug in regexp operator when warn_create_global is in effect Date: Mon, 06 Feb 2017 12:26:37 +0100 On Mon, Feb 6, 2017, at 12:11, Peter Stephenson wrote: > On Mon, 06 Feb 2017 11:44:09 +0100 > Ronald Fischer 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