bug-bash
[Top][All Lists]
Advanced

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

Re: return exit code in EXIT trap


From: Chet Ramey
Subject: Re: return exit code in EXIT trap
Date: Mon, 8 Aug 2022 17:12:58 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

On 8/8/22 4:22 PM, Robert Elz wrote:
     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.

Shoot your shot, then.


   | (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.

If you're writing a trap command that includes a `return' outside of any
function it calls, your primary goal is to affect code that happens to be
running, unsuspecting or not.


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.

The apparent rationale for preserving $?.

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.

As above, it's possible to have the majority of trap actions be transparent
unless you explicitly put something in to alter the control flow. No
argument there.


   | 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.

That's the original chicken-and-egg problem. Without any idea about what
the original goal was, we're all just speculating about the intent of the
current language. Without the original goal, there's no reason to doubt any
proposal would simply be rejected out of hand as being "inconsistent with
the original intent of the standard" (not that we're supposed to magically
divine what that is). I'm personally tired of hearing how obvious the
original intent is when you combine several paragraphs from different parts
of the standard (e.g., the recent job list discussion).

The current language is a disaster. It would be conformant if you executed
`action' immediately after running the `trap' command, since the
description reads

"Each time trap is invoked, the action argument shall be processed in a manner equivalent to:

eval action
"

which is not the same thing as "whenever one of the corresponding
conditions arises."

But we all know the intent, so everyone pretty much blows right past that.

Look, I would be ok with wording specifying that the `real' intent of
using return in a trap action is to return from any enclosing function
that was executing when the trap action is executed, and the language in
the `return' description doesn't apply to functions invoked while executing
a trap action. The current wording doesn't say anything that specific.

I'd also be ok with clarifying the trap action, since the description of
`trap' says the "action shall be read and executed by the shell" and the
description of `return' says "When return is executed in a trap action,"
without specifying anything about function scope. Since the trap action can
include arbitrary shell commands, and invoke arbitrary utilities, let's be
precise about what we mean.

I don't have a big dog in this fight -- it's really a minor point -- but if
I'm going to change the behavior again, even if I'm told my interpretation
was wrong, it had better be on the strength of some sort of affirmative
statement from the austin group about what the desired behavior should be.

I'm not interested in an `I'm not going to change my shell for *this*'
contest, either, but I'd like to see some convergence around desired
behavior. And to get that, someone has to take a step. (Well, someone
besides Koichi. He already took one.)

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/



reply via email to

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