2022年8月3日(水) 21:19 Robert E. Griffith <b...@junga.com>: > 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.
Could you explain your thinking in a little more detail? The concept of the above statement was originally explained by kre as a reply to my inquiry about the rationale of possible interpretations (B) or (C), but it's not stated to support behavior (B) but to explain that asking the rationale of the specification is not meaningful in general. In fact, kre who explained the above statement thought in his first reading that interpretation (A) is intended. Anyway, for the present case, the intended behavior of POSIX is ambiguous, and the actual implementations diverge. So, each implementation including Bash is not required to follow a specific interpretation of POSIX. This means that each implementation can choose its reasonable behavior. [ Note: kre is not saying that we should ignore correctness and rationale in implementing a feature not specified in POSIX. ] If we care the backward compatibility, Bash has implemented behavior (B) only very recently (Bash 4.4) in its long history, and in fact broke the scripts that use `return' in trap handlers. Before 4.4, Bash has not been implementing this special treatment of `return' in trap handlers. If we want to make existing Bash scripts remain unbroken but still follow the (somewhat ambiguous) POSIX specification, I still think the affected range is smaller with behavior (A).
