Re: return exit code in EXIT trap

[Koichi Murase]

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:
https://www.mail-archive.com/austin-group-l@opengroup.org/msg06011.html

A summary of the current situation is found in this reply. I haven't
received any further replies to this reply.
https://www.mail-archive.com/austin-group-l@opengroup.org/msg06030.html

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

--
Koichi