From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2175 invoked by alias); 19 Feb 2018 22:07:57 -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: 23149 Received: (qmail 3623 invoked by uid 1010); 19 Feb 2018 22:07:57 -0000 X-Qmail-Scanner-Diagnostics: from know-smtprelay-omc-9.server.virginmedia.net 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(80.0.253.73):SA:0(-1.9/5.0):. Processed in 9.69582 secs); 19 Feb 2018 22:07:57 -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=-1.9 required=5.0 tests=BAYES_00,SPF_PASS, T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: p.w.stephenson@ntlworld.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | X-Originating-IP: [86.21.219.59] X-Authenticated-User: p.w.stephenson@ntlworld.com X-Spam: 0 X-Authority: v=2.3 cv=NJ77BXyg c=1 sm=1 tr=0 a=utowdAHh8RITBM/6U1BPxA==:117 a=utowdAHh8RITBM/6U1BPxA==:17 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=gir0-LH0AAAA:8 a=ZUy6X01_kBHcmezY8DUA:9 a=QEXdDO2ut3YA:10 a=aLewGyoHDmJ4ULJHWpSz:22 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1519077447; bh=ct/N4Kk5Ft+SiFYCz2HhwFFGhL2xZt0GSf8lSEqMKPo=; h=Date:From:To:Subject:In-Reply-To:References; b=T+un5hKhHB+RpCLflW9q+nGDbN4/TPeSqohWNo2arnZvziN1u8fxdQK1Ap/Urw53X IEojKUG44RqIG1KFgQ/rGO1TwSJaJxHQqVejf191aOvlhPZSM/CG5fLUuBBdy8DL+I a5m4EcLCjKOJZGwicdhE3oHVsZtpjP71Rnkc2OIFraEKEHZ4bL9ClKESQKZtH6F6bg HDOQfaJB31EQPhYJ8PuosBNpl5W6xktSE8e9n6mrtCJs3n7S6dE464I9TgcxCw82kq fotRddzZQGiKSK3h4oHHSONg44A3/H30PoPnlkvGQMNayTeCpIzU5uB6z+kiF7aRFq 8IXWifQRdXsJw== Date: Mon, 19 Feb 2018 21:57:26 +0000 From: Peter Stephenson To: Zsh Users Subject: Re: &&|| Message-ID: <20180219215726.4c25cc7d@ntlworld.com> In-Reply-To: <64c5472a-b174-00b6-7ab0-b65d664be675@eastlink.ca> References: <64c5472a-b174-00b6-7ab0-b65d664be675@eastlink.ca> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4wfL+2ccGYbHpCZximHeDVnkJ4COTBPkYA1ksQZGjhv/Z5/5N/zzWIDBvus3Q/6Qmbhw4ja6flnGnNnnKO8Nxkic+cpElvU6AEmbw/x4qhoEMkSORwMFwk X4e2y8Vi+I3dR4f4Hj4Y6kNpG2B8wo9uND8P8I3AMO+yavc11UJuAm/aiwFMgfCJe9FeHjfJ7ir4ug== On Mon, 19 Feb 2018 13:12:20 -0800 Ray Andrews wrote: > function test () > { > =C2=A0=C2=A0=C2=A0 _aaray=3D`ls` You never need to use output from ls in a shell unless you need long output like ls -l (and there are ways round that, too). This should be _aarray=3D(*) and you get the full power of globbing if you wanted to vary the contents in some way. Strictly, I suppose it should be _aarray=3D(*(N)) to give you an empty array rather than an error if there are no files that don't begin with a dot. > =C2=A0=C2=A0=C2=A0 [ true ] && { print -l "${ _aaray[@]}" | GREP_COLOR= =3D'01;33' egrep=20 Do you mean just "true"? Not sure what putting this in square brackets is supposed to achieve. It does work, but purely by virtue of the fact that the string "true" has non-zero length --- as does the string "false", which is one of several reasons I'd avoid this. > --color=3Dalways "$1"\ > > | GREP_COLOR=3D'01;31' egrep --color=3Dalways "$2" }\ >=20 > || echo bust! If you read the documentation about && and || (OK, OK, I'm joking, I'm joking) you'll find the statement: Both operators have equal precedence and are left associative.=20 That's written for geeks, but what it means is the shell simply looks through from left to right, taking the &&s and ||s as they come: - If it finds "&&" at any point, it executes the following chunk if the previous returned status true. Otherwise, it skips it and looks for any further "&&" or "||". - If it finds "||" at any point, it executes the following chunk if the previous returned status false. Otherwise, it skips it and looks for any further "&&" or "||". I've skipped over the fact that actually it may not have executed the chunk before the "&&" or "||" it's looking at. So where I said "the previous status returned" you should really think of "the last status of anything it did execute was...". So false && true || true - runs false to get status (surprise!) false. - looks at the "&&" and decides "nah, skip the next bit". - looks at the "||" and still has status false, so executes the true. That should give you enough of a hint to follow any combination. Note this is not how && and || work in C, or even in zsh's own arithmetic context which is much more like C than the standard shell syntax is. You can affect the precedence with braces, but they need to surround the "&&" or "||" expression you want to protect. In your case you've simply surrounded a pipeline which would be run in one go anyway: % echo one && echo one | sed -e s/o/a/ one ane is just the same as % echo one && { echo one | sed -e s/o/a/ } one ane and sticking more of the poor suffering &&s and ||s after doesn't change it, either. > } pws