2021年2月16日(火) 19:24 Oğuz <oguzismailuy...@gmail.com>: > XRAT Shell Grammar ( > https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap02.html#tag_23_02_10 > ) explains that giving almost the same examples as we posted in this thread.
Thank you, interesting! So, if I understand correctly, the following construct which Bash allows is finally disallowed by POSIX? $ if (false) then (echo x) else (echo y) fi To summarize, the following cases are required by the POSIX standard to be correctly parsed? $ bash -c ': $(case x in esac)' $ bash -c ': $(case x in (x) if :; then echo a; fi esac)' $ bash -c ': $(case x in (x) a() { echo a; } esac)' $ bash -c ': $(case x in (x) { echo a; } esac)' $ bash -c ': $(case x in (x) while false; do echo a; done esac)' $ bash -c ': $(case x in (x) case y in (y) echo a;; esac esac)' and this case $ bash -c ': $(case x in (x) (echo a) esac)' could be a Bash extension. But actually, it totally depends on what is "the matching closing parenthesis" in the description of the command substitution by the POSIX: XCU 2.6.3 Command Substitution > With the $(command) form, all characters following the open > parenthesis to the matching closing parenthesis constitute the > command. I guess the rationale of the current Bash behavior is that "the matching closing parenthesis" in the context of the command substitution is actually not strictly defined in the standard. -- Koichi