Re: EXIT trap is not executed after an exec failure in a non-interactive shell

[Robert Elz]

    Date:        Fri, 1 Oct 2021 09:59:44 -0400
    From:        Chet Ramey <chet.ramey@case.edu>
    Message-ID:  <ab8e0b1f-f116-ca47-590e-ee8fa9ec50a7@case.edu>

  | Yes. When the shell runs `exec', it assumes the execed program will overlay
  | the shell process. To make that happen transparently, it has to undo things
  | it has done: it ends job control and restores the original process groups,
  | it restores the signal dispositions that it got from its parent,

All that is reasonable, but

  | and it clears other shell state like the EXIT trap.

this looks like a bug to me, and pointless anyway.   If the exec succeeds
there is no more shell, so its state no longer exists, cleared or not,
so in that case, clearing it was just wasting time.

If the exec fails, all the rest can easily be undone, but unless it was
saved elsewhere (which would be bizarre indeed) shell state that's been
cleared cannot be recovered.

That is, signals should be restored, traps should be left alone - and then
if the shell is not simply going to exit when the exec fails, the traps
indicate how the signals should be restored.

Is the jobs table part of the shell state that is cleared?   If so, and
the shell isn't exiting, that sounds like a real problem.   If it isn't,
what's the distinction (apart from needing an internal routine to restore
signals ignoring the trap settings, which is just code).   How about
shell variables, are all of those "cleared" too?

kre