From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26664 invoked by alias); 5 Nov 2012 14:40:07 -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: 30778 Received: (qmail 12956 invoked from network); 5 Nov 2012 14:39:54 -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=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at samsung.com does not designate permitted sender hosts) Date: Mon, 05 Nov 2012 14:29:42 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Function code breaking out of if then ...fi Message-id: <20121105142942.41d73d31@pwslap01u.europe.root.pri> In-reply-to: <121102143911.ZM14168@torch.brasslantern.com> References: <121102143911.ZM14168@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=UTF-8 Content-transfer-encoding: quoted-printable X-TM-AS-MML: No n Fri, 02 Nov 2012 14:39:11 -0700 Bart Schaefer wrote: > On Nov 2, 10:09am, Michal Maruska wrote: > } > } I wonder if the following behaviour is a bug, or > } simply my wrong expectation: > }=20 > } 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". >=20 > 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. >=20 > However, what *is* happening is that a glob failure in a complex > command acts in the manner of a "break" statement. It's not really like a break, it's like (well, is) a global error flag --- but the error status gets reset at the top level command loop, which we reach in a script after the end of a set of complex commands --- but only right at the end, when we're reading a new (possibly complex, arbitrarily nested) command from the script. I think actually what's going on could be considered a bug which is an oversight for the case of scripts. If the code was running a function, the failure would cause it to skip right to the end of the function, indeed any arbitrarily nested hierarchy of functions. If we took the rough equivalence between functions and scripts seriously, any hard error (zerr() or zerrnam()) would cause a script to exit in the same way. Interactively, the error flag would still get reset but non-interactively it wouldn't. I don't see anything in the documentation to suggest that the top-level command loop should be special non-interactively in the way it currently is. Indeed, when documenting try- and always-blocks, I wrote: An `error' in this context is a condition such as a syntax error which causes the shell to abort execution of the current func=E2=80=90 tion, script, or list. ^^^^^^ which is clearly not true. If there's a more fundamental description of what happens on an error, I don't know where it is. Indeed, it looks to me that without this the shell is violating the "shall exit" terms of POSIX, section 2.8.1 of the shell command language. To use the example they give, this script echo "${x!y}" echo Got here shouldn't print anything apart from the error message, but does. pws