2021年2月17日(水) 21:56 Robert Elz <k...@munnari.oz.au>:
>   | 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

Reply via email to