Re: Inconsistent behavior of ERR_EXIT with conditionals

[Philippe Altherr <philippe.altherr@xxxxxxxxx>]

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

My ultimate point with that example was to demonstrate that ERR_EXIT doesn't achieve my goal.

My goal is to be able to run a Zsh script with the guarantee that if anything goes wrong the script stops immediately where by "anything goes wrong" I mean any command whose result is not otherwise checked returns a non-zero exit status. If you don't agree that this would be a useful feature, then we can stop the discussion.

If you think that ERR_EXIT achieves my goal, then it would be useful if you could give me an example of a legitimate use of/reliance on ERR_EXIT. I could then try to build a better example to demonstrate that ERR_EXIT is not achieving my goal. If I fail to convince you that ERR_EXIT does not achieve my goal, then too we can stop the discussion.

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.

Indeed, that remains an open question to me and I agree that the new option shouldn't be added if it requires too much additional complexity.

Philippe

On Wed, Nov 9, 2022 at 7:00 AM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:

On Tue, Nov 8, 2022 at 8:11 PM Philippe Altherr
<philippe.altherr@xxxxxxxxx> 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.