On 8/8/22 1:53 PM, Robert Elz wrote:
Date: Mon, 8 Aug 2022 10:34:50 -0400
From: Chet Ramey <chet.ramey@case.edu>
Message-ID: <6ea53781-b6a8-8be1-2314-a25904727f17@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.
That's true enough. The related but not identical propostition is also
true: if the shell is executing a function when the trap action runs, and
the trap action contains a `return' that's not inside a function it
calls,
the original function returns and alters the exection flow.
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.
(A return that's in a trap which isn't inside a function called from
the trap is where it might be appropriate).
That's where part of the varying behavior is.
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 ...
I think you mean that the trap action has not called a function itself,
since you gave an example in a previous message where the "in the string"
meaning doesn't make any sense.
| "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).
I think the motive is to make trap action execution `transparent', but
the
current wording doesn't cover all the edge cases necessary to do that
(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).
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.
So propose that, and let's have a wider discussion.