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