Re: return exit code in EXIT trap

[Robert Elz]

    Date:        Mon, 8 Aug 2022 14:45:06 -0400
    From:        Chet Ramey <chet.ramey@case.edu>
    Message-ID:  <253ddd1c-2d2d-1ac1-f4bb-a611896ceb38@case.edu>


  | >   Having "exit" mean "exit $?-as-it-was"
  | > in those circumstances makes some sense, having return do that is absurd.
  |
  | You are going to have to convince people.

I don't actually think that will be very hard.

  | I think you mean that the trap action has not called a function itself,

Yes, probably.

  | I think the motive is to make trap action execution `transparent',

In a sense.

  | but the current wording doesn't cover all the edge cases necessary
  | to do that

the current wording is at least unclear

  | (and
  | it's a fool's game, anyway, since the trap action is executed in the
  | current shell execution environment with all the obvious side effects).

But that's not really an issue.   The objective isn't, or shouldn't be,
to guarantee that a trap action is transparent (if that were required
there'd be no point running it at all - there must be some side effect
at least) but to make it possible to write a trap action that does not
affect unsuspecting code that happens to be running.

That is, just like a processor interrupt, or a C signal handler.   When
written correctly those things can return to previously executing code,
which will never notice that the interrupt/signal/trap happened, unless
they specifically check for one of the side effects.

But if one wants, it is possible to have the interrupt terminate the
process (even panic the system), or for a signal handler to longjmp()
out of whatever is happening, abruptly terminating a whole execution
sequence.  Preventing any of that is not the objective.   Nor is it
to prevent a trap action from altering the execution environment, if
that is what it needs to do.

  | So propose that, and let's have a wider discussion.

The point is to try to avoid a series of "but that's not what my shell
does, and I don't want to change it" responses.   If that happens we're
lost - it would be much nicer to get some agreement on how things ought
to behave before proposing POSIX wording to specify it behave that way.

kre