[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: return exit code in EXIT trap

From: Robert E. Griffith
Subject: Re: return exit code in EXIT trap
Date: Mon, 8 Aug 2022 15:16:41 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

Understanding now that traps are more literally like inserting an eval, what makes return in the top level trap string special is that there are two script paths behind it so its reasonable the the coder of the trap to ask from which last statement do I want to preserve the exit code. The shell needs to give the coder the option of choosing either.

I think a better solution to that would have been to leave return alone and instead allow the trap to access the $? value of the last command before the interruption in the first command of the trap string similar to how the ERROR trap works. (or in a new special var if that is problematic for some reason).

As it is, the problem is that 'return' and 'return $?' doing different things is unintuitive in itself.

Would that work? Is it too late to suggest that?


On 8/8/22 14:45, Chet Ramey wrote:
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]