From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23876 invoked by alias); 24 Oct 2013 09:07:26 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 31880 Received: (qmail 20168 invoked from network); 24 Oct 2013 09:07:21 -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=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 X-AuditID: cbfec7f4-b7f0a6d000007b1b-ed-5268e0ea788f Date: Thu, 24 Oct 2013 09:57:13 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Strange function/pipestatus behavior, maybe a scope bug? Message-id: <20131024095713.44d2982e@pwslap01u.europe.root.pri> In-reply-to: <131023221548.ZM2352@torch.brasslantern.com> References: <20131023092155.5ba8a54b@pwslap01u.europe.root.pri> <20131023221412.5cdecd76@pws-pc.ntlworld.com> <131023221548.ZM2352@torch.brasslantern.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42I5/e/4Vd1XDzKCDNZ+ULY42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGadWr2YrmC5QMfHIJ7YGxhM8XYycHBICJhLrF15kgrDFJC7c W8/WxcjFISSwlFHi0urj7BDOciaJ1gtnGUGqWARUJVra97GC2GwChhJTN80Gi4sIiEucXXue BcQWFnCVOHtnJlCcg4NXwF5i88EykDCngKXE5QtnoBasY5KY97eTDSTBL6AvcfXvJ6gr7CVm XjkDNpNXQFDix+R7YDOZBbQkNm9rYoWw5SU2r3nLPIFRYBaSsllIymYhKVvAyLyKUTS1NLmg OCk911CvODG3uDQvXS85P3cTIyQIv+xgXHzM6hCjAAejEg+vxof0ICHWxLLiytxDjBIczEoi vJ4VGUFCvCmJlVWpRfnxRaU5qcWHGJk4OKUaGNNXnHdbtcbFcNat3pj/krLCNWc4w92eSczp 2PzqKmfguyvuVaE7v9+zcdSNXKe+aQbvkiknPk5qdmBUKQ++/PJRm0rExcz2CU+CLh598SHY smCL14p302X9FY467D/5WzT6aZaNckFuakjW2lWieuGlq+4YbfoRyluV/26W9fXHE18y7d43 30uJpTgj0VCLuag4EQAOR2iwIAIAAA== On Wed, 23 Oct 2013 22:15:48 -0700 Bart Schaefer wrote: > It therefore suffices to lift the pipestatus-updating code out of the > update_job() routine and call it from printjob() just before the Job > object is deleted. > > There's a minor redundancy still here in that update_job() sometimes > calls printjob() which will result in storepipestats() being called > twice; but update_job() needs the return status, sometimes has a > different idea of whether the job is in the foreground, and doesn't > always call printjob(), so I don't see any obvious way around this. This doesn't seem serious. > One remaining bug which is neither new to this nor fixed by it: The > very first time one runs a pipeline ending in a shell function, > something goes wrong and the whole thing is treated as if it is in > the background. Here's zsh-5.0.2-248-ge05261f without my patch: > > % true | false | true | false | (){ true }; echo $pipestatus > [1] + done true | > exit 1 false | > done true | > running false > 1 > % Sounds like a race setting up the job, maybe related to the fact that "thisjob" isn't initialised in a particularly obvious place when the code is executing within the shell. Are you seeing this with any shell function, or just anonymous functions? > Oh, one other bug which I don't believe is new: the PIPEFAIL option > doesn't work right if the last command is a builtin. Maybe that > test should be moved into storepipestats() as well, in which case > the redundancy I mentioned above might also be eliminated. Are you saying that $pipestatus is correct but the overall status is wrong if you have something like "true | true | true" or "true | true | false"? It certainly sounds like they ought to run at the same point. The last command ought to be the easy one --- that's where the status has always come from, so if those two pipelines are giving different answers with and without PIPEFAIL something is definitely odd. pws