Re: x[ as first word in sh
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 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
Re: x[ as first word in sh
> On Jul 29, 2019, at 3:30 PM, Stephane Chazelas > 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 Hi Stephane, No. The reasons why bugid:1100 was rejected are clearly detailed in bugnote:4038. None of those issues have been addressed in the more than 14 months since that bug report was rejected. There is no reason to believe that if we reopened all of the bugs that Mark said were replaced by bugid:1100 that we would not just be wasting our time and rejecting each one of them with a duplicate of bugnote:4038 as the reason for rejection. Please do not tell us to go back and redo a lot of work we did over a year ago. If you think you understand the problem(s) better than Mark did, please file a new bug (or a few new bugs) that clearly states the problem that each is addressing, gives examples of shell productions that are incorrectly handled by the current grammar, explains how your changes fix the problem (without creating new problems), and defines all new terms used by your changes. All of this is detailed in bugnote:4038. Sincerely, Don
Re: x[ as first word in sh
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
Re: x[ as first word in sh
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 -- Stephane
Re: x[ as first word in sh
2019-07-29 13:30:56 -0500, Eric Blake: > On 7/29/19 1:08 PM, Stephane Chazelas wrote: [...] > > I had the vague recollection that there was but I can't find it > > now. If there's not, that would be a bug in the spec as several > > shells including ksh, bash, zsh, yash treat it as the start of > > an array element assignment (like in: [...] Sorry, I was wrong about yash. Array element assignment in yash is done with the "array" builtin. > > x[ foo > > + 1]=value > > Ouch. I think you've identified a real problem. Not that big a problem as I don't expect anyone would use "x[" in the first word of a command. Thanks for double-checking. I thought there was text that explicitely allowed that ksh behaviour, maybe I was confusing with [[...]] or ((...)). 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. -- Stephane
Re: x[ as first word in sh
On 7/29/19 1:08 PM, Stephane Chazelas wrote: > That's a follow-up on > https://www.mail-archive.com/bug-bash@gnu.org/msg23451.html > > Is there anything in the POSIX spec that allows: > > x[ foo > > To be interpreted as anything other than invoking the "x[" > command with "foo" as argument? > > I had the vague recollection that there was but I can't find it > now. If there's not, that would be a bug in the spec as several > shells including ksh, bash, zsh, yash treat it as the start of > an array element assignment (like in: > > x[ foo > + 1]=value Ouch. I think you've identified a real problem. In XSH 2.13.3, we explicitly added wording to allow unmatched unquoted '[' in a word to be used in its role similar to 'test' (the difference being whether a later ']' argument is necessary): If the pattern contains an open bracket ( '[' ) that does not introduce a bracket expression as in XBD RE Bracket Expression, ... If the pattern does not match any existing filenames or pathnames, the pattern string shall be left unchanged. So by that argument, if the shell parses 'x[' as a word, then because it does not form a valid glob, it must be used unchanged as the command name. But that explicit wording does not cover whether 'x[' has to be delimited as a word. XSH 2.3 states in rule 7 that an unquoted blank ends the delimiting of any prior word, but the behavior you are showing for shells that parse a[b]= as an array assignment are trying to find the matching ] before delimiting the first word (so the shell extension of array assignment is somehow acting as a quoting context that prevents the whitespace thus parsed from being the unquoted blank that ends the delimiting of the word). The shell grammar, at XSH 2.10.1, allows for array assignments in rule 7b: If the TOKEN contains an unquoted (as determined while applying rule 4 from Token Recognition) character that is not part of an embedded parameter expansion, command substitution, or arithmetic expansion construct (as determined while applying rule 5 from Token Recognition): If the TOKEN begins with '=', then rule 1 shall be applied. If all the characters in the TOKEN preceding the first such form a valid name (see XBD Name), the token ASSIGNMENT_WORD shall be returned. Otherwise, it is unspecified whether rule 1 is applied or ASSIGNMENT_WORD is returned. with the intent that a[b]= can be an ASSIGNMENT_WORD in shells with array extensions, but can also be WORD for shells that treat it as glob to determine a command name. But without any explicit specification of permitting whitespace in the array arguments, it looks like there is a discrepancy between POSIX requirements and existing shell behavior. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
x[ as first word in sh
That's a follow-up on https://www.mail-archive.com/bug-bash@gnu.org/msg23451.html Is there anything in the POSIX spec that allows: x[ foo To be interpreted as anything other than invoking the "x[" command with "foo" as argument? I had the vague recollection that there was but I can't find it now. If there's not, that would be a bug in the spec as several shells including ksh, bash, zsh, yash treat it as the start of an array element assignment (like in: x[ foo + 1]=value -- Stephane
