From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20377 invoked by alias); 2 Nov 2012 21:40:04 -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: 30775 Received: (qmail 10524 invoked from network); 2 Nov 2012 21:40:01 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <121102143911.ZM14168@torch.brasslantern.com> Date: Fri, 02 Nov 2012 14:39:11 -0700 In-reply-to: Comments: In reply to Michal Maruska "Function code breaking out of if then ...fi" (Nov 2, 10:09am) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Function code breaking out of if then ...fi MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Nov 2, 10:09am, Michal Maruska wrote: } } I wonder if the following behaviour is a bug, or } simply my wrong expectation: } } This script, assuming the globbing fails, and I'm not using NULL_GLOB, } does not bother finishing the commands in the "then ....fi" block, } instead continues after "fi". This doesn't really have anything to do with the function. The same thing happens with if true; then echo non-existing* exit 0 fi What slightly surprises me is that a glob failure isn't considered an error for purposes of ERR_EXIT (the -e option in your #! line). I would have expected the whole script to quit at that point, but I guess glob errors are not treated as command failures because the command never executes in the first place. However, what *is* happening is that a glob failure in a complex command acts in the manner of a "break" statement. This is to prevent runaway loops spewing the same globbing error ad infitinum; I remember that this change was made a long while ago, but I don't recall exactly when, and it appears it would take a major excavation to find it in the ChangeLog. The trouble of course is that a "break" statement isn't supposed to have any effect in the body of an "if", but although actually using "break" in that context is not allowed, the same logic isn't applied when the internal error-flag gets set by a glob failure, and zsh bails out of the if-body the same way it would from a loop-body. Whether this is a bug could be argued either way. NOMATCH occupies a sort of grey area between parser-detectable syntax error and run-time command failure. } I was advised (on IRC) to use } } { fn } always { TRY_BLOCK_ERROR=0 } This is a workaround, because it introduces a new complex command (the braced expression to the left of "always") and gives you a hook for clearing the error before it affects any surrounding complex command. But that would be the wrong place to document this behavior of NOMATCH.