Date: Mon, 8 Aug 2022 10:34:50 -0400
From: Chet Ramey <chet.ra...@case.edu>
Message-ID: <6ea53781-b6a8-8be1-2314-a25904727...@case.edu>
| It's a logical conclusion from the requirement that the trap action be
| executed as if you had dropped an `eval action' into the function, or
| wherever the shell is executing when the trap is processed.
OK, that's reasonable - I think I was getting a bit too abstract in
my thinking.
That's about "eval" working, not so much about the language for return
being the same as that for exit ... if a trap action invokes a function,
which runs exit, the shell exits, but if it calls a function which runs
return all that happens is that function returns, and the rest of the
trap action continues running. Having "exit" mean "exit $?-as-it-was"
in those circumstances makes some sense, having return do that is absurd.
(A return that's in a trap which isn't inside a function called from
the trap is where it might be appropriate).
I'm personally not sure any of this is all that important (other than the
way hash has interpreted it - and apparently this time, changing without
caring about backward compat with older versions - having the "in a trap
action" mean "any time a trap action is being run" rather than just
"in the string in the trap action") as ...
| "The value of "$?" after the trap action completes shall be the value it
| had before trap was invoked."
is important if a trap action runs, does whatever, then just returns
execution to whatever had been happening - but if we're going to arbitrarily
alter the flow of execution directly from the trap handler (rather than
say setting a variable which can be tested to change things) then retaining
the value of $? is much less significant - having it be a defined value
is useful, having it related to where the trap happened to be invoked is
much less so (as that might have been just about anywhere where the trap
remains set - and $? could be just about anything at that point).
| > Clearly this needs a posix defect report filed, if no-one else does that
| > today, I probably will.
|
| Please do. The behavior is all over the place,
It didn't happen that day, and isn't going to today, but I will do it
soon (unless someone else does).
Unfortunately "all over the place" just bodes "unspecified" as the result,
which helps no-one. It would be better if we could agree that preserving
the old value of $? in return/exit is only appropriate for those return/exit
commands which will cause the trap action to terminate - so not anything
running in any sub-shell environment inside the trap, and not a return
from any function called from within the trap action.
kre
