2021年2月17日(水) 21:56 Robert Elz <[email protected]>: > | For example, this alone doesn't explain why > | > | $ if :; then echo A; fi if :; then echo A; fi > | > | (i.e., the combination "fi if") is a syntax error. > > That one is quite a different issue,
Yes, that's what I wanted to claim by the above example, that is, XCU 2.4 isn't the (most) essential point for the reason that `fi esac' or `fi fi` is a valid construct. The above example is just a counter-example against explaining `fi esac` by solely XCU 2.4. I used `fi if' as an example because I did know that `fi if' isn't allowed by the grammar, so I have referred to the grammar in the next paragraph in my previous reply. Instead, as you have explained in your next paragraph, the essential reason why `fi esac' can appear in a valid command is that the grammatical structure allows the combination of `fi esac' as a result of some embedded compound command in another. > ps: many of these strange rules all originate in the original Bourne > shell's recursive descent parser, I was also thinking these apparent rules are strange before carefully reading the BNF (in yacc style) specified in XCU 2.10, but now I somehow feel these rules are understandable (but still not so natural of course). I admit that it is confusing to most users, but at least, I wouldn't say it's ``insane'' now. > [...] and consequently, POSIX, which documents > what actually exists, specifies it as well. Thank you for the explanation of the historical backgrounds. That's actually exactly what I guessed when I looked at the BNF. Anyway, even if the POSIX specifies some inconsistent grammar, I feel that cannot be the reason that Bash behaves in a way even more inconsistent than what POSIX specifies. -- Koichi
