From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22768 invoked by alias); 20 Feb 2018 19:54:50 -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: List-Unsubscribe: X-Seq: 23154 Received: (qmail 17880 invoked by uid 1010); 20 Feb 2018 19:54:50 -0000 X-Qmail-Scanner-Diagnostics: from mta04.eastlink.ca by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(24.224.136.10):SA:0(-2.6/5.0):. Processed in 4.397537 secs); 20 Feb 2018 19:54:50 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) 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, SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: rayandrews@eastlink.ca X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=utf-8; format=flowed X-Authority-Analysis: v=2.3 cv=dfKuI0fe c=1 sm=1 tr=0 a=RnRVsdTsRxS/hkU0yKjOWA==:117 a=RnRVsdTsRxS/hkU0yKjOWA==:17 a=IkcTkHD0fZMA:10 a=vUKU3sqJLHSv-b7pAzAA:9 a=QEXdDO2ut3YA:10 X-EL-IP-NOAUTH: 24.207.101.9 Subject: Re: &&|| To: zsh-users@zsh.org References: <64c5472a-b174-00b6-7ab0-b65d664be675@eastlink.ca> <20180219215726.4c25cc7d@ntlworld.com> <20180220092659.2233e6ef@pwslap01u.europe.root.pri> <20180220170734.7f428bd6@pwslap01u.europe.root.pri> From: Ray Andrews Message-id: Date: Tue, 20 Feb 2018 11:24:41 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 In-reply-to: <20180220170734.7f428bd6@pwslap01u.europe.root.pri> Content-language: en-CA On 20/02/18 09:07 AM, Peter Stephenson wrote: > You've now extended your demand so that it works with an else clause as Not 'extended' that is the entire point of my question. I'm expecting the '||' to be identical to a logical 'else', there is no other issue. Demand? I seek clarification, mind, if it were agreed that my sense of the logic were correct I'd be happy to see it change, but issues of logic and code flow are rigorous and not subject to opinion. > You could do this, I suppose. > > first-statement && { > any-old-stuff > true << right, I see how that protects. > } || {something-else-entirely} Ok, I'm at least on guard for that sort of thing from now on.  I've more and more been using &&|| constructions in place of if/else simply because the former is more compact, but I'll be more vigilant from now on.  Braces are ignored as far as truth tests on the left of any && or ||.  I can't say I like it tho, not that that matters, a thing like this is entirely at your discretion.