[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: Wed, 3 Aug 2022 08:19:47 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

That was an interesting read. The illuminating point for me was the statement to the effect of "the POSIX specification is not meant to describe what it correct or rational, but what historically has been implemented so that existing scripts will remain unbroken". This makes me appreciate Chet's position more.

I suppose I could imagine a script that is working correctly at its macro level because of this behavior, but its kind of hard to do so.

In any case, I guess I will just start using return $? instead of relying on the default behavior which is deliberately unpredictable. Its a bit harder for you since your users will attribute these problems to you.


On 8/2/22 18:06, Koichi Murase wrote:
2022年8月3日(水) 5:57 Chet Ramey <chet.ramey@case.edu>:
On 8/2/22 4:18 PM, Robert E. Griffith wrote:
Is there a reason why POSIX would want the return behavior to of function
down the stack to behave differently when in a trap? Seems strange to me.
I don't remember if Koichi ever opened up a bug with the Austin Group.
This is the thread in the Austin Group list:

A summary of the current situation is found in this reply. I haven't
received any further replies to this reply.

The specification of POSIX is clearly ambiguous, and no one seems to
know which one is the correct interpretation. The behavior [(A), (B),
or whatever] seems to be effectively *unspecified* in POSIX because
POSIX seems just to summarize the common feature set of "existing
implementations" but there is no convergence among them.

Until then, I'm going by the plain language of the standard. It seems more
strange that POSIX would have intended this to mean only a `return' in the
actual action string (A) instead of while the trap action is executing (B).
 From POSIX's perspective, the current behavior of bash-4.4+ [i.e.,
behavior (B)] is nothing wrong as it is effectively unspecified, but
behavior (A) seems still more reasonable to me. Behavior (B) is a
source of problems for me because `return' without arguments cannot be
used inside functions, or we need to remember which function contains
`return' without arguments to write trap strings. Currently, I am
avoiding writing `return' but instead always writing `return "$?"' as
a workaround, but I don't think every user knows this. Also, I am
wondering if there is any actual use case of behavior (B). On the
other hand, the top-level `return' in trap strings can be used to
change the control path in signaled functions. I think behavior A can
be useful in such a case when one wants to exit the function without
affecting $?.


reply via email to

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