exit in traps

[Christoph Anton Mitterer <calestyo@xxxxxxxxxxxx>]

Hey.

Not sure whether this is a bug:
   #!/bin/sh
   
   #trap -- "echo EXIT" EXIT
   trap -- 'echo $?; echo INT; exit' INT
   
   foo=$(exit 44)
   read -r tmp

Running that and <Ctrl-C>ing at the read prompt:
$ dash x.sh ; echo $?
^C1
INT
1
$ 

$ bash x.sh ; echo $?
^C44
INT
0
$ 


First, shouldn’t dash’s echo $? give 44, like bash’s does? The most
recent pipeline is foo=$(exit 44), as the read hasn't completed yet, so
$? should be 44.


Second, for the final exit state:
POSIX says[0] for `exit`:
> If n is not specified, the result shall be as if n were specified
> with the current value of the special parameter '?' (see 2.5.2
> Special Parameters ), except that if the exit command would cause the
> end of execution of a trap action, the value for the special
> parameter '?' that is considered "current" shall be the value it had
> immediately preceding the trap action.

I'd read that as if a blank `exit` in a trap action (but only one that
actually causes the trap to end (i.e. not something like $(exit) ),
should cause an overall exit status of 44 here, too.

Both, dash and bash would do that wrong.


If one uncomments the trap on EXIT:
$ dash x.sh ; echo $?
^C1
INT
EXIT
1

Which I don't understand either.
IMO the INT trap should need to end with 44 here (but only because of
the literal exit - I think it should rather end with 0 if there were
not exit in it).
But then, dash executes the EXIT action, and in that the original $?
should be 44, too, (from the INT action’s exit, not directly from
outside the trap actions) but why does the shell end with 1? Shouldn't
it be 0 because of echo EXIT?


Thanks,
Chris.


[0] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_22