Re: return exit code in EXIT trap

[Robert E. Griffith]

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.

--BobG

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