Re: grammar triviality with '&&'

[ZyX <kp-pav@yandex.ru>]

01.03.2015, 19:09, "Ray Andrews" <rayandrews@eastlink.ca>:
> I notice that zsh is quite tolerant as far as most
> line wrap situations go, except for this:
>
>      [ -e file1 ] &&
>      [ -e file2 ] &&
>      echo 'both files exist'
>
> ... good
>
>      [ -e file1 ]
>      && [ -e file2 ]
>      && echo 'both files exist'
>
> ... syntax error, but we can fix it like this:
>
>      [ -e file1 ]\
>      && [ -e file2 ]\
>      && echo 'both files exist'
>
> I'm wondering why the line continuation is strictly necessary.
> IOW, why doesn't the parser permit the '&&' on a new line?
> I've been trying to come up with something that would
> cause an ambiguity if it were permitted, but can't find anything,
> but I doubt the rule would be there otherwise.

Each of the lines is a sequence of `zle self-insert` followed by `zle accept-line`. In first and third cases it is possible to, based on parser state, determine that more input is required. In the second it is a complete command on the first line.

Note that zsh is a shell. Its main purpose is parsing user input, *not* scripts. What you ask will require special-casing script parsing (note: things like aliases or BANGHIST are processed prior to the time string is feed to the parser).

Note 2:

    ( echo "echo foo" ; sleep 5 ; echo "echo bar" ; sleep 5 ; echo "echo baz" ) | zsh -

outputs foo, bar, baz with 5 second intervals in between. Waiting for EOF or next line would not be very logical here, especially since shells may be and sometimes are used in non-interactive mode by the user and not by the script piping to stdin, and this is what special-casing is against (user input is already very special due to zle).