From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11218 invoked by alias); 11 Apr 2011 16:48:46 -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: 15956 Received: (qmail 27178 invoked from network); 11 Apr 2011 16:48:32 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) 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_HELO_PASS autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at csr.com does not designate permitted sender hosts) Date: Mon, 11 Apr 2011 17:48:25 +0100 From: Peter Stephenson To: Zsh Users Subject: Re: $pipestatus and shell functions Message-ID: <20110411174825.3bd3e84b@pwslap01u.europe.root.pri> In-Reply-To: <20110411173835.385fba1f@pwslap01u.europe.root.pri> References: <20110411173835.385fba1f@pwslap01u.europe.root.pri> Organization: Cambridge Silicon Radio X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.103.11.49] X-Scanned-By: MailControl A_10_80_00 (www.mailcontrol.com) on 10.68.0.112 On Mon, 11 Apr 2011 17:38:35 +0100 Peter Stephenson wrote: > J=C3=A9r=C3=A9mie Roquet wrote: > > $ foo() { false | true } > > $ true | foo ; echo $pipestatus > > 1 0 >=20 > You're falling > foul of (i) a shell function looks like a job to the shell (ii) it > appears that function is being made the current job, so generates the > pipe status when it exits (the same happens if you use a { ... } > expression there, so that's not a workaround). However, there's some > truly horrible handling for job control in complicated cases like > this (what is supposed to get signals and what do you return to if > you get one?) so it's quite possible that those two contributing > factors are themselves deliberate. I'm not entirely convinced, > though; it surprises me that that the notion of the current job > changes like that. A little digging suggests it is deliberate. If you ever have a week to spare, look at the comment relating to the declaration of list_pipe in exec.c. Within the description of the example: cat foo | while read a; do grep $a bar; done you find If the user hits ^Z at this point (and jobbing is used), the shell is notified that the grep was suspended. The list_pipe flag is used to tell the execpline where it was waiting that it was in a pipeline with a shell construct at the end (which may also be a shell function or several other things). When zsh sees the suspended grep, it forks to let the sub-shell execute the rest of the while loop. So the shell is deliberately treating constructs in the right hand side of the pipeline as jobs in their own right, and in particular as the current foreground job, since that's the one where you can do job control. This overrides the natural expectation that the pipeline is the current job and so the one for which $pipestatus would be reported. --=20 Peter Stephenson Software Engineer Tel: +44 (0)1223 692070 Cambridge Silicon Radio Limited Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, = UK Member of the CSR plc group of companies. CSR plc registered in England and= Wales, registered number 4187346, registered office Churchill House, Cambr= idge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom