[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Koichi Murase
Subject: Re: syntax error while parsing a case command within `$(...)'
Date: Tue, 16 Feb 2021 22:54:02 +0800

> 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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]