From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21798 invoked by alias); 6 Mar 2015 17:44:18 -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: 19979 Received: (qmail 12273 invoked from network); 6 Mar 2015 17:44:07 -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=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:in-reply-to:comments:to:subject:mime-version :content-type; bh=ika3JMFbbohDVowu3U5JR7oAnvSKcV51/u38nQ9diw8=; b=aWjhwkyAXp4v1HxTLNnwXppQe74Ryi/1knF11IYEYc6fG4F6cgVS6pNxqDlRzSpAwG xrxnbJtkBg9OCNbfqZsL30TJzlTIkOK2bDKc7V2ckt+0oAGc2SDGr2c3WyrfJpyXsc/i 1LNUqizqKHJmwndHPY58yPMWc3xgbBcqIw9CKZlfh5wUqvX24rPNwI+FtoXbtQ5ndky1 iyJiGy06YtaS/rpbvlFDkK6U8mxXSCh+PqUaqHpwi1pxI0J1D4fGc/WChtVV45RNTo1k JBn+to9mr56QV9OlTmrsQq1hr7KcuqnTY8kfFpOjHBmQMvMJ+ri8cA3XNWDdrLuzuGqG mpHQ== X-Gm-Message-State: ALoCoQk6sFIxU0U5yzsiAvCiFekBYCkou/e632lfkkpz1Kz3pOSyOUSLZIZBEtvuwVMcD/ErbplB X-Received: by 10.182.121.162 with SMTP id ll2mr11726697obb.71.1425663843409; Fri, 06 Mar 2015 09:44:03 -0800 (PST) From: Bart Schaefer Message-Id: <150306094359.ZM9698@torch.brasslantern.com> Date: Fri, 6 Mar 2015 09:43:59 -0800 In-Reply-To: <54F9D180.4020900@eastlink.ca> Comments: In reply to Ray Andrews "Re: grammar triviality with '&&'" (Mar 6, 8:10am) References: <54F33934.2070607@eastlink.ca> <13666281425228233@web7o.yandex.ru> <54F345D3.9010204@eastlink.ca> <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> In-Reply-To: <20150306163201.GD10507@ypig.lip.ens-lyon.fr> Comments: In reply to Vincent Lefevre "Re: grammar triviality with '&&'" (Mar 6, 5:32pm) X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: grammar triviality with '&&' MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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.