> 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
