19 Nisan 2020 Pazar tarihinde Koichi Murase <myoga.mur...@gmail.com> yazdı:
> 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. > > So was I, obviously overlooked that part. > 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/V > 3_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. Apparently in trap actions return without an operand is reserved for retaining exit status of the last command preceding the trap action. Thus (B) sounds like the correct interpretation. However this way functions invoked from trap actions have to use return $? to deliver exit status of the last command they executed. I agree that the standard should elaborate on this. 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 > -- Oğuz
