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