From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-users-return-22419-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 6470 invoked by alias); 24 Jan 2017 21:25:25 -0000
Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Users List <zsh-users.zsh.org>
List-Post: <mailto:zsh-users@zsh.org>
List-Help: <mailto:zsh-users-help@zsh.org>
X-Seq: 22419
Received: (qmail 6105 invoked from network); 24 Jan 2017 21:25:25 -0000
X-Qmail-Scanner-Diagnostics: from mercury.zanshin.com by f.primenet.com.au (envelope-from <schaefer@brasslantern.com>, uid 7791) with qmail-scanner-2.11 
 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1.  
 Clear:RC:0(64.84.47.142):SA:0(-0.0/5.0):. 
 Processed in 1.594242 secs); 24 Jan 2017 21:25:25 -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=-0.0 required=5.0 tests=SPF_PASS
	autolearn=unavailable autolearn_force=no version=3.4.1
X-Envelope-From: schaefer@brasslantern.com
X-Qmail-Scanner-Mime-Attachments: |
X-Qmail-Scanner-Zip-Files: |
Received-SPF: pass (ns1.primenet.com.au: SPF record at ipost.com designates 64.84.47.142 as permitted sender)
Date: Tue, 24 Jan 2017 13:24:42 -0800 (PST)
From: Bart Schaefer <schaefer@brasslantern.com>
Reply-To: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-users@zsh.org
Subject: Re: Avoiding the zshells intelligence...in one case
In-Reply-To: <slrno8fb8e.3dr.martin@lounge.imp.fu-berlin.de>
Message-ID: <alpine.LRH.2.00.1701241320080.4560@toltec.zanshin.com>
References: <20170122080153.GA5042@solfire> <alpine.LRH.2.00.1701220936420.4560@toltec.zanshin.com> <slrno8aadl.dbe.martin@lounge.imp.fu-berlin.de> <alpine.LRH.2.00.1701221437530.4560@toltec.zanshin.com> <slrno8chmt.58s.martin@lounge.imp.fu-berlin.de>
 <alpine.LRH.2.00.1701231438190.4560@toltec.zanshin.com> <slrno8fb8e.3dr.martin@lounge.imp.fu-berlin.de>
User-Agent: Alpine 2.00 (LRH 1167 2008-08-23)
X-Face: "f/X=UCVgd*^c>+x(gMq0at?e:woX+;'snkkRzc3SX<0AZ (/PS4.M2hzGS9X:Qj]at_H/%a9K}:-eS<"v_7vX84PG9Bf Zpb`wI!I4geY=or+nWq`3CX`oq&TJR;g^ps|7(MH?jh;bs %vHJfCh5>a*6Re5m|Bidja\\o]>n\A)ib1:yX*T`zR(*h~ %tOw<~!D9{e6h!8M2:d8G2@K>y^1I_Vdy\d\MYe]z7c
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 24 Jan 2017, Martin Vaeth wrote:

> Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> > re_nomatch() { { ${~@} } always { setopt nomatch } }
> > alias t='setopt nonomatch && noglob re_nomatch echo'
>
> Why is this risky? Because it can leave nomatch in the wrong state?

Because if you accidentally use it in a pipeline it'll throw away its
standard input, and if you use it in a complex && || series it may not
produce the expected result.

Both of which are even worse if instead of "&&" you use a ";" as you did
in your more complicated formulation.