set -e not ignored in AND-OR list

[Christoph Anton Mitterer <calestyo@xxxxxxxxxxxx>]

Hey.

(With 0.5.12-9 on Debian.)


https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_26
says for the exceptions of set -e:



>  with the following exceptions:
> 
> 1. The failure of any individual command in a multi-command pipeline,
> or of any subshell environments in which command substitution was
> performed during word expansion, shall not cause the shell to exit.
> Only the failure of the pipeline itself shall be considered.
> 2. The -e setting shall be ignored when executing the compound list
> following the while, until, if, or elif reserved word, a pipeline
> beginning with the ! reserved word, or any command of an AND-OR list
> other than the last.
> 3. If the exit status of a compound command other than a subshell
> command was the result of a failure while -e was being ignored, then
> -e shall not apply to this command.

Looking at (2):

$ dash; echo shell left
$ set -e; foo() { echo a >&2; false; echo b >&2; }
$ foo | true
a
=> expected, no ! before the pipline, so -e is NOT ignored and the
   false in foo() kicks in

$ ! foo | true
a
b
=> expected, ! before the pipline, so -e IS ignored and the
   false in foo() kicks NOT in


$ $(foo) | true
a
=> expected, no ! before the pipline, so -e is NOT ignored and the
   false in foo() kicks in

$ $(foo) || true
a
$ $(foo) && true
a

=> these I don't understand
   it's and AND-OR list, not the last element, so -e should be ignored,
   yet it kicks in at the false


In fact, bash seems to do it right:
$ bash; echo shell left
$ shopt -s inherit_errexit
$ set -e; foo() { echo a >&2; false; echo b >&2; }
$ # (its behaviour is the same for the upper examples)

$ $(foo) || true
a
b
$ $(foo) && true
a
b
$

Neither of the shells exited (no "shell left" printed), which is IMO
also expected

I don't think POSIX' (1) can explain dash's behaviour, as one is only
about not causing the shell to exit (i.e. "after" the pipeline has
finished) - not about ignoring the effects of set -e (like within
foo() )

A bug?


Thanks,
Chris.