2019-08-21 11:29:09 +0000, Austin Group Bug Tracker: [...] > I don't like the suggestion of making it completely unspecified how > non-name=... is parsed. All of the examples you give are things that I > would naturally expect to be parsed as some kind of assignment if they are > not treated as a cmd_word. If they then can't be processed as a valid > assignment, this would produce an assignment error (rather than a syntax > error). > > So the way I would prefer to handle this is to change the text in 7b from: > <blockquote>Assignment to the name within a returned ASSIGNMENT_WORD token > shall occur as specified in [xref to 2.9.1].</blockquote>to something > like:<blockquote>If a returned ASSIGNMENT_WORD token begins with a valid > name, assignment of the value after the first <equals-sign> to the name > shall occur as specified in [xref to 2.9.1]. If a returned ASSIGNMENT_WORD > token does not begin with a valid name, either an unspecified form of > assignment shall be performed (for example, assignment to an array element > in shells that support array variables as an extension) or a variable > assignment error shall occur; see [xref to 2.8.1] for the consequences of > these errors.</blockquote> [...]
I don't see the point in that. IMO, it's of no help to portable application writers and unnecessarily constrains implementations. If I can't use [=] extended behaviour $a[foo=bar] in a portable sh script, I don't see the point in requiring that if I were to do it, it would have to either be performing "some form of assignment" (whatever that means) or reporting an "assignment error" (whatever that means) with the exclusion of any other behaviour. -- Stephane
