From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21858 invoked by alias); 27 Aug 2017 22:26:28 -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: 41609 Received: (qmail 22247 invoked by uid 1010); 27 Aug 2017 22:26:28 -0000 X-Qmail-Scanner-Diagnostics: from ioooi.vinc17.net 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(92.243.22.117):SA:0(-1.9/5.0):. Processed in 2.410106 secs); 27 Aug 2017 22:26:28 -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=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: vincent@vinc17.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Date: Mon, 28 Aug 2017 00:26:18 +0200 From: Vincent Lefevre To: zsh-workers@zsh.org Subject: Re: "set -e" handling is broken with zsh 5.3.1 and 5.4.1 Message-ID: <20170827222618.GA3398@zira.vinc17.org> Mail-Followup-To: zsh-workers@zsh.org References: <20170827005040.GA12622@zira.vinc17.org> <20170827195648.6f078249@ntlworld.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170827195648.6f078249@ntlworld.com> X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/1.8.3-7137-vl-r99863 (2017-08-22) On 2017-08-27 19:56:48 +0100, Peter Stephenson wrote: > This appears to have been deliberate, in that after "if" we usually > restore noerrexit beahaviour on the first thing we execute, but if it's > a function we don't. However, I can't for the life of me work out why I > made that exeception --- certainly nothing goes wrong in the tests if I > apply the following, and I would expect to be testing whatever it was > made me think we needed the qualification. It might have been to do > with empty functions, but making f empty, so it runs but doesn't change > the status, doesn't seem to do anything unexpected (we shouldn't > and don't exit). Perhaps it was needed in the past, and no longer makes sense now. Have you looked at the diff that introduced it, the corresponding commit log and the discussions that occurred at that time? BTW, if it was added for some purpose, a test should have been added at the same time to make it fail if this condition was not there. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)