From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15265 invoked by alias); 10 Nov 2012 01:39:49 -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: 30790 Received: (qmail 27170 invoked from network); 10 Nov 2012 01:39:48 -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: <121109171319.ZM4069@torch.brasslantern.com> Date: Fri, 09 Nov 2012 17:13:19 -0800 In-reply-to: <20121109225255.7139bb47@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: Function code breaking out of if then ...fi" (Nov 9, 10:52pm) References: <121102143911.ZM14168@torch.brasslantern.com> <20121105142942.41d73d31@pwslap01u.europe.root.pri> <20121105145501.50c674f1@pwslap01u.europe.root.pri> <20121109225255.7139bb47@pws-pc.ntlworld.com> 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 9, 10:52pm, Peter Stephenson wrote: } } On the behaviour that when the shell encounters a "fatal" error in a } script it resumes at the next "top level" command: here's a proposal. } This makes that behaviour optional, for compatibility, but turns it off } by default. I don't think the old, undocumented, behaviour is intuitive } enough for us to go on leaving it as the default. The shell essentially } skips a chunk of code and resumes later on at a point where there's not } the slightest reason to suppose it's appropriate to do so; you might be } relying on the structure that was previously executing to set things up } for the next chunk of code. I believe I know the reason for this behavior, and perhaps it points to a bug: When reading a startup file such as .zshrc, there is an intent to avoid skipping the entire configuration just because of one erroneous command somewhere in the middle. My possibly flawed recollection was that this was only supposed to happen in startup scripts, not in scripts run as standalone programs or loaded by "source" or ".". If this patch modifies the behavior of startup files, perhaps one further step would be to turn on CONTINUE_ON_ERROR before startup files are read, then turn it off before entering the main loop iff the starup files themselves have not frobbed it. I believe something similar is done with MONITOR and also HASHDIRS.