On Wed, 3 Aug 2022 at 08:06, Koichi Murase <myoga.mur...@gmail.com> wrote:
> 2022年8月3日(水) 5:57 Chet Ramey <chet.ra...@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
