Hey.
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_26
specifies that set -e is ignored as follows:
> 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.
That is AFAIU not only the non-0 outcome of a command is ignored, but
also anything that is called from there and where normally set -e would
kick in, simply keeps running, like with:
set -e
foo() { echo a; false; echo b; }
$ foo || :
a
b
whereas:
$ foo
a
<exit>
So far so good.
Does POSIX mandate how that should work when a TRAP action is executed
while the shell is in a context where set -e would be ignored?
I've made a test case for that:
#!/bin/sh
set -e
foo() { echo a; false; echo b; }
trap -- "echo INT; foo" INT
sleep 100 || :
And at least bash and dash, both DON'T ignore set -e in the trap
action, e.g.:
$ bash t.sh
^CINT
a
$ dash t.sh
^CINT
a
$
Is that a mere (but of course sane) coincidence or does it actually
somehow follow from POSIX.
I couldn't find anything that would IMO directly imply it.
Instead,
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_29
says:
> The environment in which the shell executes a trap action on EXIT
> shall be identical to the environment immediately after the last
> command executed before the trap action on EXIT was executed.
And
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_13
says:
> A shell execution environment consists of the following:
> ...
> Options turned on at invocation or by set
Now one can be nitpicking any argue that the "ignoring of set -e"
wasn't actually "turned on" by calling set,... and thus the "ignoring
of set -e" isn't an actually set part of the environment, but that's
IMO rather a bit much fortune telling.
If not properly specified, and it's deemed helpful I could open a
ticket if that helps.
Thanks,
Chris.
