From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28293 invoked by alias); 2 Mar 2015 05:22:13 -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: 19947 Received: (qmail 9364 invoked from network); 2 Mar 2015 05:22:10 -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,HTML_MESSAGE, 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:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fxKworqq4UUyp73TXv/YLTONVmhru/wnOwKPdR7FYds=; b=H5wOjw3yZY+fOE8zwYUI+yU3uVJvRlqN54w+uTK4YMV74/gipKCfRcSFcHVBeS4/Sh MtwMc0KcSnvC1LPtGqIQNvNq8qQtCsf0MLK7d+SkxBacmNzh/fF5o1xWCQeC7MixX7sk 7pjJ2PzoSWb7PC5WH8mj2c8uk2C//CGvOuTHth8TJkZ2b7cf+frWHtiF46vqbxARvEXz ilNfZqmuc03F3rehnUT+HFslXbZ9MJu25/7R3m9YtZzifoVCDPeqdr07agKgMfSv5dAE S8Yn6riWMDtAW75iuQ0ozgFvmV1ouBudGgg/1AwF96I4D8GJ72mibDLI+rbCf1clqawd PkSA== X-Gm-Message-State: ALoCoQlmmc0+FWVesqdNnVypViJFoYf8QgFAANGHclPeQ3p6fROwfz/oSybzkTd/HYIhgsUGyyLz MIME-Version: 1.0 X-Received: by 10.152.182.196 with SMTP id eg4mr22559486lac.70.1425273724794; Sun, 01 Mar 2015 21:22:04 -0800 (PST) In-Reply-To: <54F3E489.5050603@eastlink.ca> References: <54F33934.2070607@eastlink.ca> <13666281425228233@web7o.yandex.ru> <54F345D3.9010204@eastlink.ca> <20150302022754.GA7449@xvii.vinc17.org> <54F3E489.5050603@eastlink.ca> Date: Sun, 1 Mar 2015 21:22:04 -0800 Message-ID: Subject: Re: grammar triviality with '&&' From: Kurtis Rader To: Ray Andrews Cc: Zsh Users Content-Type: multipart/alternative; boundary=001a11349e36130fd40510476659 --001a11349e36130fd40510476659 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 1, 2015 at 8:18 PM, Ray Andrews wrote: > Well, what would the costs be? It looks to me that the error is an > arbitrary restriction and if it didn't break something I'd remove it even > if for no other reason that that it is arbitrary. Of course if there were > any complications, then it shouldn't be touched. Oh, and of course no one > has to use it if they think it would ruffle anyone's feathers as far as > tradition, but I'd use it for sure. Things should only be limited where it > is necessary that they be limited. I'd not be surprised if the code was > actually simpler, '&&' would just grab the errorlevel of the previous > command as always and there'd just be one less error to handle. > One obvious cost is that anyone reading a script that uses the feature will naturally assume the author made a mistake and the script is invalid. The reason this restriction exists is not arbitrary. It is a an obvious and natural consequence of how the grammar was interpreted by the person(s) who wrote the code for the Bourne-shell, Bash, Zsh, etcetera. Why is it simpler for the code to "just grab the errorlevel of the previous command" when it sees a leading "&&" or "||"? Also, it is not just a matter of changing the zsh implementation. Unit tests need to be added and existing tests likely updated. Documentation needs to be changed. Whether the change might break existing uses has to be carefully considered. You say "I'd use it for sure". Please provide a non-contrived example, preferably two or three, where this would be useful. How hard is it to be explicit and include the "[[ $? -eq 0 ]]" in a script? If this feature were truly useful for interactive use I might agree with you. But I see no evidence and my 30+ years experience that it has no use outside of making a tiny percentage of scripts a few characters shorter. -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank --001a11349e36130fd40510476659--