Re: request for clarification on Open Group Base Specifications Issue 7: Canc...

2017-06-13 Thread Dimitri Staessens
Hi Geoff,

Awesome service, thanks!

Dimitri

On 06/13/17 13:35, Geoff Clare wrote:
> Dimitri Staessens  wrote, on 12 Jun 2017:
>> Is there a way for me to track down the people that are responsible for
>> this adjustment in the specification so that they can comment on their
>> intentions and motivations for making it?
> https://collaboration.opengroup.org/austin/interps/documents/14359/AI-136.txt
>



Re: request for clarification on Open Group Base Specifications Issue 7: Canc...

2017-06-13 Thread Geoff Clare
Dimitri Staessens  wrote, on 12 Jun 2017:
>
> Is there a way for me to track down the people that are responsible for
> this adjustment in the specification so that they can comment on their
> intentions and motivations for making it?

https://collaboration.opengroup.org/austin/interps/documents/14359/AI-136.txt

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England



Re: compound-list

2017-06-13 Thread Stephane Chazelas
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  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



Re: compound-list

2017-06-13 Thread 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.

Note that SUSv2 was more wordy on "rule 1", clearing some of the
confusion:
http://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html#tag_001_010

There are some related bugs:

http://austingroupbugs.net/view.php?id=839
http://austingroupbugs.net/view.php?id=643


> The "lex" of "do" in "until a do b; done" is then WORD, making the
> script impossible to parse.
> 
> > AFAICT, it should be:
> 
> > Until linebreak term sequential_sep Do
> 
> > And there are similar problems with if_clause, else_part,
> > while_clause, until_clause, case_clause, brace_group, do_group
> > at least.
> 
> The sequential_sep is not required by shells in situations like
> 
> until { false; } do echo hi; break; done
> 
> until(false)do echo hi; break; done
> 
> if :; then if :; then echo hi; fi fi
> 
> { { echo hi; } }
> 
> This is handled by the part of rule 1 about contexts where WORD is not
> valid but at least one reserved word is.
[...]

You're right, I didn't think of that.