Re: syntax error while parsing a case command within `$(...)'

[Koichi Murase]

2021年2月16日(火) 19:29 Chris Elvidge <celvidge001@gmail.com>:
> > I think that section just describes the necessary condition that the
> > word is recognized as the reserved keyword: "This recognition shall
> > *only* occur...". It doesn't explain whether the reserved keyword can
> > be really used to construct the AST following the shell grammar. 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.
>
> It seems to me that you're missing a semicolon between 'fi' and 'if' to
> delineate the two constructs.

Yes, that's an example of a syntax error that I made by intentionally
removing the semicolon. If we just look at POSIX XCU 2.4 which Andreas
pointed to justify "fi fi", a similar combination "fi if" without
semicolon in between appears to be also justified, but that's false.
Thus there should be also other essential rules. That's what I wanted
to say.

By the way, in the case of nested compounds such as `case x in (x) if
:; then echo; fi esac' or `{ { echo; } }', the fact was actually
somewhat opposite. According to the formal grammar by BNF (without
caring XCU 2.4), actually, semicolonless commands like

$ case x in (x) if : then echo fi esac

or

$ { { echo } }

are valid. However, it is ambiguous and confusing, so this kind of
construct is afterward disallowed by the grammatical "Constraints"
specified in XCU 2.4.

--
Koichi