2020-04-19 15:21 Oğuz <oguzismailuy...@gmail.com>: > The same document you linked says: > > > If the shell is not currently executing a function or dot script, the > > results are unspecified. > > in DESCRIPTION section; it's unspecified what those returns do.
Thank you for the comment, but I am confused. In both two examples that I provided, it actually running a function when `kill' is called, i.e. `kill' is called when `invoke' is executed. Then the trap handler is invoked while executing the function. If that is not the correct interpretation [i.e., the function is not considered currently executed while the trap handler is processed, and the description on `return' applies only to `return's appearing in the function calls inside the trap action], then it is the third interpretation: (C) The `return's in the function-call tree in trap processing are affected, but the behavior of `return' directly called from the trap argument is unspecified. However, in this case, the same question for the interpretation (B) also applies to the interpretation (C): 2020-04-19 13:32 Koichi Murase <myoga.mur...@gmail.com>: > > - If the literal interpretation (B) is correct, what is the use case > > of this behavior, or what is the rationale for this behavior? Currently, I do not see any rationale for the behavior (B) or (C). Does anyone know something which explains the necessity of the behavior (B) or (C)? 2020-04-19 15:21 Oğuz <oguzismailuy...@gmail.com>: > However some shells (dash for instance) print 42. I think it's a > misreading of the standard. It seems to me that (A) is the natural behavior because it is more consistent with the following description in `trap' section. I can imagine that the special case for the `return' exit status is added to make it more consistent with this section: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_28_03 > [XCU 2.14 Special Built-In Utilities - trap - DESCRIPTION/paragraph 2] > > [...] The value of "$?" after the trap action completes shall be the value > it had before trap was invoked. Maybe I am wrong, but I cannot stop suspecting that this is a wording problem that the original intension is (A), but it just reads like (B) or (C) due to not enough description in the standard. -- Koichi
