Re: grammar triviality with '&&'

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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.

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, then until it encounters an explicit
";" or "&" (or some other lookahead token that can't appar at that
position in the pipeline production) the interpreter doesn't "know"
whether it has actually reached the end of the "and_or" production.

Therefore it would either violate (2) to speculatively execute what has
been seen so far, or it would violate (3) to wait for the next token to
complete the lookahead.  Sure, we could either discard goal (1) to
make this an interactively-only feature [there's at least precedent for
that with setopts], or we can discard goal (2); we can do whatever
we want.  I assume you'd find it way too annoying to discard (3).

But this is in a sense analogous to suggesting that

    one | two | three

could wait to see what happens to "one" before deciding whether to send
the output along to "two".  The grammar would work just fine with

    one
    | two
    | three

but you'd never suggest that the shell should implicitly do

    one | tee temp1
    cat temp1 | two | tee temp2
    cat temp2 | three | tee temp3

just so that you can decide later whether you're interested in adding
yet another stage to the pipeline.  Or at least I hope you would not
suggest that, though if you look through the list archives people have
in fact asked how to capture output so they can re-use it later.  See
Functions/Misc/keeper for an example.

In any case, I'm done trying to explain this.  We've already put the lie
to the word "triviality" in the subject of this thread.