From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13633 invoked by alias); 5 Dec 2016 12:23:47 -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: 40099 Received: (qmail 6171 invoked from network); 5 Dec 2016 12:23:47 -0000 X-Qmail-Scanner-Diagnostics: from cventin.lip.ens-lyon.fr 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(140.77.13.17):SA:0(0.0/5.0):. Processed in 1.076436 secs); 05 Dec 2016 12:23:47 -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.0 required=5.0 tests=none autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: vincent@vinc17.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at vinc17.net does not designate permitted sender hosts) Date: Mon, 5 Dec 2016 13:23:41 +0100 From: Vincent Lefevre To: zsh-workers@zsh.org Subject: Re: ERR__EXIT failure (was Re: zsh 5.2-test-1) Message-ID: <20161205122341.GA7827@cventin.lip.ens-lyon.fr> Mail-Followup-To: zsh-workers@zsh.org References: <20161202203009.2eee2e4b@ntlworld.com> <20161205092802.GA20311@zira.vinc17.org> <20161205104228.013ee411@pwslap01u.europe.root.pri> <20161205111140.4c79b09b@pwslap01u.europe.root.pri> <20161205113029.15b4cbd4@pwslap01u.europe.root.pri> <20161205121130.GA8832@cventin.lip.ens-lyon.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20161205121130.GA8832@cventin.lip.ens-lyon.fr> X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/1.7.1-6878-vl-r94147 (2016-11-29) On 2016-12-05 13:11:30 +0100, Vincent Lefevre wrote: > On 2016-12-05 11:30:29 +0000, Peter Stephenson wrote: > > And plus also free bonus with same fix on { ... } --- see tests. But it > > occurs to me perhaps it's not that simple... > > > > What about ( ... )? We can't check what's going on inside, so > > presumably exiting on any non-zero status from that must be right? > > If you mean: > > set -e; ( false && true; ); echo OK > > then yes. A good idea is to compare with what the other shells do. > dash, bash, ksh93 and mksh all exit in this case. And this is really what the user should expect, IMHO. I mean that from the current shell, the ( ... ) construct should be seen as a black box, just like when running an external command. Hence this behavior. > > If so, is it really right to suppress exit on the status at the end > > of { ... } or should the two work the same way? > > Concerning > > set -e; { false && true; }; echo OK > > dash, bash, ksh93 and mksh all print OK. And on the opposite, { ... } is mainly used for grouping, but should have as little effect as possible. More precisely, on set -e; { false && true; }; echo $? the above shells output 1 as expected. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)