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

[Koichi Murase]

> XCU 2.10.2/(1) Shell Grammar Rules [Command Name]
> > When the TOKEN is exactly a reserved word, the token identifier for
> > that reserved word shall result. Otherwise, the token WORD shall be
> > returned. Also, if the parser is in any state where only a reserved
> > word could be the next correct token, proceed as above.
>
> [...]
>
> The above special rule means that
>
>   $ if [[ str ]] then [[ str ]] fi
>   $ if ((expr)) then ((expr)) fi
>
> should also be acceped as valid constructs.  Other shells parses them,
> but Bash fails:
>
> [...]
>
> Maybe Bash could insist that [[ ... ]] and ((...)) are not part of the
> standard so that it can behave inconsistently.  But it seems to me
> that there is really no reason to behave inconsistently here.

This is actually an easy fix as attached. I guess this change can be
safely applied because originally these constructs were a syntax
error, so no shell scripts rely on the current behavior.

0001-accept-reserved-words-after-arithmetic-condtional-co.patch
Description: Binary data