2022年8月3日(水) 5:57 Chet Ramey <chet.ra...@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
