Re: return exit code in EXIT trap

[Martin D Kealey]

On Wed, 3 Aug 2022 at 08:06, Koichi Murase <myoga.murase@gmail.com> wrote:

> 2022年8月3日(水) 5:57 Chet Ramey <chet.ramey@case.edu>:
>
>> 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).
>>
>
As there are at least two "obvious" interpretations, I would say that the
"plain language of the standard" is anything but.

So in the absence of a clear singular interpretation, I would look at "what
is the point" of the rule in POSIX? What utility does it provide?

There is evident utility in allowing "return" to terminate a trap handler
while avoiding alteration of $?, but I see no feasible utility in changing
how return works inside functions when it's called from a trap handler.

So I would say the latter interpretation (B) is the "more strange" option
to choose to implement.

Another consideration is that POSIX exists to codify existing behaviour,
and only to impose new requirements where there is conflict among existing
behaviours. Again, Prior to this change to Bash, there was *no* precedent
for interpretation B.

Even if one believes that the standard is unambiguous, the two points above
mean that interpretation B is clearly an error on the part of the standards
committee.

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

I concur with this assessment.

-Martin