From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25362 invoked by alias); 21 Aug 2017 06:27:23 -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: 41576 Received: (qmail 25553 invoked by uid 1010); 21 Aug 2017 06:27:22 -0000 X-Qmail-Scanner-Diagnostics: from out1-smtp.messagingengine.com 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(66.111.4.25):SA:0(-2.6/5.0):. Processed in 2.578791 secs); 21 Aug 2017 06:27:22 -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=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=n0Nugp mHhlXqMA+OKc8Ktd4D2jN0AjB7CD2/yzqMFXw=; b=julP8LNwicanMYIA8qeOp/ fjg/WTnhtj1/dkoT21jmbIZkyLTwn2rOTJmiJCW/IIb7HEYg/tjNbOTfHbcXcReL j4gFU4ATX4dvrymzL9dMWVlI75PVIMReBXUFmGV4146K2wtkAmL17bIoqVNa9Poe ojF56uEyga9D/m+2zTHm0VrMWgJdszeE9BKTHaff2RzvlhjDPh/mbjeVg0MOvCcH 8c4yAaFoIf1MgGYJI5ydklyBGlMG9/jE4aFPP3J8peicF9NOL0LsEr9bcbByke8Y xxv6RN7pEQsiLqU7gSuREEuzpGSmh5/uPbLbOEu/2eGMAqedw8Ij7535CTaMIbKg == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=n0Nugp mHhlXqMA+OKc8Ktd4D2jN0AjB7CD2/yzqMFXw=; b=kRGUrbE3D5JlTwonidnl6K 1Rnn8cF5twDb/NckqQGjXqki4tulsaPWftAf++toKtFN1FmswySazZeZUcowlAEs osnsO3RkMwiooNJocQvu/XirTc00iy+APFPAnx9b3g+JF5bbNCd2S8I852D1qLCr gGJLZEMOQcJyFTG3Aqu2Tk2Wsd6BUYkFF8ANpQLXzr1VmxIn9s4zcp0TUsfjDUfq DF6mtmhhhTcs1O2LTY1erG8o1tKnsdTjEP6i8y8zMI12lRMz5bvaiizoSIIcjXmy 2KgwOw6SAUWavqPzmYolC2ZJ0yXiRsv2OX4XsLsi4+KbUG2sPyNakQ2kAMXlu5dA == X-ME-Sender: Message-Id: <1503296832.2707476.1079657368.3BDF7CBD@webmail.messagingengine.com> From: Daniel Shahaf To: Radon Rosborough , zsh-workers@zsh.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044 References: Subject: Re: Question about err_return Date: Mon, 21 Aug 2017 06:27:12 +0000 In-Reply-To: Radon Rosborough wrote on Sun, 20 Aug 2017 22:28 -0700: > why does the following: >=20 > function { setopt err_return; false; echo 'oh no' } >=20 > print nothing, while >=20 > function { setopt err_return; false; echo 'oh no' } && true >=20 > prints 'oh no'? This seems very inconsistent to me, as I would expect > the result of 'x && true' to be the same as 'x' in all circumstances. >=20 > Now I found an old thread [1] about this, and the resolution was that > this behavior was unsurprising since err_return emulates err_exit. The > idea is that err_exit is automatically disabled for all child code > whenever a function is invoked as part of a conditional expression, > and so err_return does the same. I'm having trouble seeing how this is not simply a bug. Consider: . % f() { setopt err_return; false; echo 'this runs' } % f && : this runs The command "false" had a non-zero exit status, and the enclosing function continued to execute. That's exactly what the documentation promises would not happen: . ERR_RETURN If a command has a non-zero exit status, return immediately f= rom the enclosing function. I don't see how the fact that f's callsite is the left-hand side of a '&&' is relevant here. It would be relevant to deciding whether f's non-zero return value should cause the _caller_ to return/exit immediately as well, but that has to do with the ERR_EXIT / ERR_RETURN settings in the caller scope, and shouldn't change f's behaviour. (The invariant you proposed=C2= =A0=E2=80=94 =C2=ABfoo=C2=BB =E2=89=A1 =C2=ABfoo && true=C2=BB=C2=A0=E2=80=94 is a good = one.) The analogy with ERR_EXIT's treatment of '&&'/'||' should kick in when those oprators are used _inside_ the function: . % f() { setopt err_return; false || true; echo 'this should be printed'= } The callee function behaves the same way if err_return is set in the caller= , as Bart suggested in the original thread. > But we have an err_return in Zsh. Is it worth breaking backward > compatibility to improve the usability of err_return? Well, I'm certainly not suggesting to change this before 5.4.2 (which is expected soon). But we could change this after 5.4.2 and let it soak in ma= ster until 5.5. Thoughts? > If not, I would like to know how I can otherwise implement error > checking in my scripts. I need for any unexpected error to cause an > immediate return from the enclosing function, which is how err_return > is advertised in the Zsh manual [3], but not how it actually works at > present. Yes, the documentation doesn't match the implementation, so we need to fix = one or the other. Thanks for the report, and for digging up those old threads. Cheers, Daniel