2017-06-13 07:22:10 +0100, Stephane Chazelas:
> 2017-06-13 00:02:34 +0200, Jilles Tjoelker:
> [...]
> > I think this is supposed to be handled by rule 1 in the first (non-yacc)
> > part of 2.10.2 Shell Grammar Rules, but the text is not clear to me. For
> > example, rule 7b for non-initial words in a simple command says rule 1
> > should be applied, but reserved words clearly should not be recognized
> > in that context.
>
> It's quite obscure to me as well. I have to admit I don't get
> the point of 7a. AFAICT 7b already says that if the TOKEN
> doesn't contain "=", then rule 1 applies.
[...]
It was broken by SUSv4 TC2. Earlier (TC1), it had:
7. [Assignment preceding command name]
a. [When the first word]
If the TOKEN does not contain the character '=',
rule 1 is applied. Otherwise, 7b shall be applied.
b. [Not the first word]
If the TOKEN contains the <equals-sign> character:
* If it begins with '=', the token WORD shall be
returned.
* If all the characters preceding '=' form a
valid name (see XBD Name), the token
ASSIGNMENT_WORD shall be returned. (Quoted
characters cannot participate in forming a valid
name.)
* Otherwise, it is unspecified whether it is
ASSIGNMENT_WORD or WORD that is returned.
Assignment to the NAME shall occur as specified in Simple
Commands.
And when 7b was modified to encompass what 7a had, the
fact that 7a was now superflous was overlooked. But also, that
modification broke the whole point about those 7a and 7b being
referenced in cmd_name and cmd_word and is the point raised by
Jilles here (that when not the first word, keywords can't be
yielded).
That's the fix for http://austingroupbugs.net/view.php?id=839
(which apparently aimed to allow shells to have keywords with
"=") that broke it.
--
Stephane
