Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: grammar triviality with '&&'
On 2015-03-06 09:43:59 -0800, Bart Schaefer wrote:
> On Mar 6, 8:10am, Ray Andrews wrote:
> }
> } The deeper question is why shells were designed this way.
>
> On Mar 6, 5:32pm, Vincent Lefevre wrote:
> }
> } I don't think that the grammar would become more complex.
>
> What you're both missing or at least glossing over is the interaction
> between the grammar and the interactive interpreter.
I don't think I've introduced a difference.
> There goals are: (1) the grammar for scripts is identical to the grammer
> for interactive use, (2) the execution order is identical both in scripts
> and in interactive use, and (3) when used interactively, the input can be
> interpreted [commands executed] as soon as a complete syntactic structure
> has been recognized.
>
> Under the current grammar, the interpreter always "knows," at the point
> where a line break occurs, whether or not it has a complete syntactic
> element that it can execute. If you allow the and_or producion to put
> a linebreak before AND_IF / OR_IF,
[...]
No, I did *not* allow that. Ray wanted that in his original post, but
my proposition is just a modification of the grammar that doesn't need
such a thing about the linebreak handling. There are some drawbacks
compared to what Ray wanted initially (e.g., don't do this with
"set -e"), but this is a compromise.
Note that since && and || can be used inside [[ ... ]], this change
is probably not needed in scripts. It could be useful interactively
without needing an alias.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Messages sorted by:
Reverse Date,
Date,
Thread,
Author