On 6/27/18 10:33 AM, Piotr Grzybowski wrote:
>
> On 27 Jun 2018, at 14:57, Chet Ramey wrote:
>
>> On 6/27/18 6:59 AM, Piotr Grzybowski wrote:
>>
>>> +function_newline_list: '(' ')' | function_newline_list '\n'
>>> + ;
>>> +
>>
>> This would appear to allow constructs like
>>
>> foo()
>> () ()
>> {
>> function body
>> }
>
> only by the look of things ;-) (thats what I meant in P.S.) actually those
> tokens are not allowed:
>
> bash-5.0$ cat /tmp/m.sh
> foo()
> () ()
> {
> function body
> }
>
> bash-5.0$ . /tmp/m.sh
> bash: /tmp/m.sh: line 2: syntax error near unexpected token `)'
> bash: /tmp/m.sh: line 2: `() ()'
>
> I am sure function_newline_list can be rewritten in a better way though.
I don't really see the value. It doesn't solve any problems; it just lets
you feel better about the grammar. The shift-reduce behavior (shifting) is
what we want, anyway.
The problem is that the left paren is ambiguous given the syntax bash
supports (mostly for backwards compatibility). If you've already read
`function name', and you read a left paren, you're stuck: you can shift
to `function name (' or reduce to `function name' and look to read a
subshell command. The only way to differentiate between the two requires
that you look ahead more than bison allows you.
That's why this gives a syntax error, and still does even after your
change:
function name ( echo subshell )
Technically we should support that, since we try to support the same
function body syntax for Posix and non-Posix function definitions, but the
grammar can't quite do it in its current form. The vast majority of the
time you're going to read a function definition `function name () compound-
command' anyway, and bison shifting gives you that.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
