From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16484 invoked by alias); 24 Oct 2013 16:46:20 -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: 31888 Received: (qmail 10363 invoked from network); 24 Oct 2013 16:46:14 -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-b6-52694ed31fe7 Date: Thu, 24 Oct 2013 17:46:10 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Strange function/pipestatus behavior, maybe a scope bug? Message-id: <20131024174610.0da2aaaf@pwslap01u.europe.root.pri> In-reply-to: <131024092633.ZM27623@torch.brasslantern.com> References: <20131023092155.5ba8a54b@pwslap01u.europe.root.pri> <20131023221412.5cdecd76@pws-pc.ntlworld.com> <131023221548.ZM2352@torch.brasslantern.com> <20131024095713.44d2982e@pwslap01u.europe.root.pri> <131024092633.ZM27623@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/4Zd3LfplBBp2fZSwONj9kcmD0WHXw A1MAYxSXTUpqTmZZapG+XQJXxqRd/YwFE/kqZk65xtrAuJq7i5GDQ0LAROLPbdMuRk4gU0zi wr31bF2MXBxCAksZJc5Muc4M4Sxnkjjy6SYLSBWLgKrEo5ndYDabgKHE1E2zGUFsEQFxibNr z4PFhQVcJc7emQkW5xWwl/jdvJcJxOYUsJJ49ecvI8TQKcwSWzd9BSviF9CXuPr3ExPEGfYS M6+cgWoWlPgx+R7YUGYBLYnN25pYIWx5ic1r3jJPYBSYhaRsFpKyWUjKFjAyr2IUTS1NLihO Ss811CtOzC0uzUvXS87P3cQICcIvOxgXH7M6xCjAwajEw6vxIT1IiDWxrLgy9xCjBAezkgjv NL3MICHelMTKqtSi/Pii0pzU4kOMTBycUg2MkrdkzRVX+205s2jaraX8dhxhE4I/3PPvn/GM V9W1O/NjsoCd7+UYFQu+lXFn+ZYdKDgZ1Nu21bxAL6T98vf2krYSY9n46ucsi+W7Puw3tPmj 8fO/1PXXQZZ/c4WCAu8xxUdlJTncvHq5K6g7cv0kATmbl2cmGwoqdoQoqqrcX+EjxSQp/VmJ pTgj0VCLuag4EQA+q+ytIAIAAA== On Thu, 24 Oct 2013 09:26:33 -0700 Bart Schaefer wrote: > Not exactly. PIPEFAIL means that if any command anywhere in the pipeline > fails, then the entire pipeline fails. *Without* PIPEFAIL, the command > > true | (return 3) | true > > shoule have pipefail=(0 3 0) and exit status 0. *With* PIPEFAIL, it > should have pipefail=(0 3 0) and exit status 3. But it does not, > becuase "true" is a builtin. Replace with /bin/true and the PIPEFAIL > exit status is correct. With your patch (removing mine, which isn't so careful about thisjob), this seems to work here. The following adds Ian's test that consistently failed before and no longer does; any external command probably ought todo the trick, but I suppose there might still be a small race; maybe the function should even have a sleep in it. I've kept awk in case the timing hits a sweet (or rather sour) spot, but sanitised it so awk can't flail around doing different things. Amusingly (or otherwise), running this from the command line was for a time consistently giving me the "no job control in this shell message", then it stopped, so this definitely looks like a race. diff --git a/Test/A05execution.ztst b/Test/A05execution.ztst index fd13e91..8578016 100644 --- a/Test/A05execution.ztst +++ b/Test/A05execution.ztst @@ -189,3 +189,10 @@ >2048 0 0 0 F:This test checks for a bug in `$pipestatus[]' handling. If it breaks then F:the bug is still there or it reappeared. See workers-29973 for details. + + externFunc() { awk >/dev/null 2>&1; true; } + false | true | false | true | externFunc + echo $pipestatus +0:Check $pipestatus with a known difficult case +>1 0 1 0 0 +F:This similar test was triggering a reproducible failure with pipestatus. pws