zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Philippe Altherr <philippe.altherr@gmail.com>
Cc: zsh-workers@zsh.org
Subject: Re: Inconsistent behavior of ERR_EXIT with conditionals
Date: Tue, 8 Nov 2022 22:00:30 -0800	[thread overview]
Message-ID: <CAH+w=7a_yhcrGD3b5LvZ4HiUKJgaCWh5uyRiCfxbQRMz9Jpdbw@mail.gmail.com> (raw)
In-Reply-To: <CAGdYchtyqMTAWn6yVJpJypOZ-Gyj1Fm6+kmsztm8hKXki5FSLg@mail.gmail.com>

On Tue, Nov 8, 2022 at 8:11 PM Philippe Altherr
<philippe.altherr@gmail.com> wrote:
>>
>> The first developer is wrong.  That's not what -e is for.  A script
>> should be correct WITHOUT the use of -e ... the purpose of -e is to
>> uncover cases where the developer made a mistake, not to be an
>> integral part of the script function.
>
> I can agree with that but consider that the developer's mistake was to use a ";" instead of an "&&" in the "backup" function.

No, that wasn't his mistake.  His mistake was to not explicitly call
"exit" on failure of scp and instead rely on errexit to bail out of
the backup function.

The second developer's mistake was changing ; to && following the call
to the backup function without actually understanding how the backup
function (didn't) work.  *If* errexit worked the way you want, the &&
test would be spurious anyway, because either the function would have
returned the status of "echo" (always success) or would have died
without getting that far.

Neither of these is a situation where the developer should have been
relying on errexit to save them.

> My broader point was that the same error (or developer mistake) in a function "foo" triggers an exit if "foo" is called from a plain statement but not if it's called from within a condition. Wouldn't you agree that it's unfortunate that the same error/mistake may or may not trigger an exit depending on whether it's executed outside or inside a condition?

I wouldn't necessarily agree that it's the same mistake.  What's
unfortunate is that you're relying on a Deus ex machina to save your
script from disaster.

> Would you agree to add a new shell option if it allows to run Zsh scripts such that if any command unexpectedly fails the script immediately stops (and its implementation doesn't require too complex changes)?

I would abstain from the decision and leave it to others, but I don't
believe it can be done without some rather invasive changes.


  reply	other threads:[~2022-11-09  6:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-04 16:37 Philippe Altherr
2022-11-06 20:45 ` Bart Schaefer
2022-11-07  3:50   ` Bart Schaefer
2022-11-07  5:35     ` [PATCH] " Bart Schaefer
2022-11-07  9:44       ` Peter Stephenson
2022-11-08  1:20         ` Bart Schaefer
2022-11-08  4:58     ` Philippe Altherr
2022-11-08  5:36       ` Bart Schaefer
2022-11-08  8:04         ` Lawrence Velázquez
2022-11-08 18:51           ` Philippe Altherr
2022-11-08 19:20             ` Lawrence Velázquez
2022-11-08 23:28             ` Bart Schaefer
2022-11-09  4:11               ` Philippe Altherr
2022-11-09  6:00                 ` Bart Schaefer [this message]
2022-11-09 14:22                   ` Philippe Altherr
2022-11-10  1:00                     ` Bart Schaefer
2022-11-10  5:09                       ` Bart Schaefer
2022-11-11  3:04                         ` Philippe Altherr
2022-11-11  4:06                           ` Lawrence Velázquez
2022-11-11  4:09                           ` Eric Cook
2022-11-08 23:11           ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH+w=7a_yhcrGD3b5LvZ4HiUKJgaCWh5uyRiCfxbQRMz9Jpdbw@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=philippe.altherr@gmail.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).