From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5774 invoked by alias); 9 Mar 2015 11:36:44 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 19986 Received: (qmail 7261 invoked from network); 9 Mar 2015 11:36:40 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_PCNT autolearn=no version=3.3.2 Date: Mon, 9 Mar 2015 12:26:20 +0100 From: Vincent Lefevre To: zsh-users@zsh.org Subject: Re: grammar triviality with '&&' Message-ID: <20150309112620.GE26461@xvii.vinc17.org> Mail-Followup-To: zsh-users@zsh.org References: <20150302022754.GA7449@xvii.vinc17.org> <150302005440.ZM16546@torch.brasslantern.com> <20150302103156.GB6869@xvii.vinc17.org> <150302084958.ZM17306@torch.brasslantern.com> <20150304085512.GA3609@ypig.lip.ens-lyon.fr> <54F73D18.8070801@eastlink.ca> <150305205951.ZM8811@torch.brasslantern.com> <54F9D180.4020900@eastlink.ca> <20150306163201.GD10507@ypig.lip.ens-lyon.fr> <150306094359.ZM9698@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <150306094359.ZM9698@torch.brasslantern.com> X-Mailer-Info: http://www.vinc17.net/mutt/ User-Agent: Mutt/1.5.23-6425-vl-r76280 (2015-03-04) 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 - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)