Rule 7 is also referenced by Rule 8, as the token may represent a function name to be defined, and determining whether the token is an IO_NUMBER or a reference to a file on the path also comes into play, depending on the following tokens to disambiguate command's productions. For that 7a establishes quickly the token does not qualify for being an ASSIGNMENT_WORD that might be a best match for completing simple_command using the cmd_prefix by itself variant. The split into 7a and 7b may be a hangover from some older shells considering a variable assignment by itself as a separate type of cmd_name, and didn't permit cmd_prefix type usages. On Monday, July 29, 2019 Stephane Chazelas <stephane.chaze...@gmail.com> wrote: 2019-07-29 22:25:29 +0100, Stephane Chazelas: > 2019-07-29 21:33:50 +0100, Stephane Chazelas: > [...] > > BTW, what's the point of 2.10.2 7a? It seems 7b already says > > what 7a says (if the TOKEN doesn't contain a =, then rule 1 > > applies). The distinction seems to be caused by the distinction > > between cmd_name vs cmd_word grammar rules which seems to be > > about keywords not being recognised after redirections or > > assignments, but I can't see how 7a/7b help there. > [...] > > It seems it was broken in the 2016 edition by the resolution of > http://austingroupbugs.net/view.php?id=839 [...]
I see it (and several other issues) was already raised in http://austingroupbugs.net/view.php?id=1100 which was rejected. The grammar in the suggested resolution there makes a lot more sense to me than the current one but that may be down to me missing some background on yacc parsing and misunderstanding how it works. Since 1100 was rejected, shouldn't the other issues it was meant to factorize (which doesn't include this one though) and were closed as duplicate reopened? -- Stephane
