zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh-workers@zsh.org
Subject: Re: Strange function/pipestatus behavior, maybe a scope bug?
Date: Thu, 24 Oct 2013 17:46:10 +0100	[thread overview]
Message-ID: <20131024174610.0da2aaaf@pwslap01u.europe.root.pri> (raw)
In-Reply-To: <131024092633.ZM27623@torch.brasslantern.com>

On Thu, 24 Oct 2013 09:26:33 -0700
Bart Schaefer <schaefer@brasslantern.com> 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


  reply	other threads:[~2013-10-24 16:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-22 18:03 Ian F
2013-10-23  8:21 ` Peter Stephenson
2013-10-23 19:49   ` Ian F
2013-10-23 21:14     ` Peter Stephenson
2013-10-24  5:15       ` Bart Schaefer
2013-10-24  8:57         ` Peter Stephenson
2013-10-24 15:48           ` Peter Stephenson
2013-10-24 16:03             ` Peter Stephenson
2013-10-24 16:44               ` Bart Schaefer
2013-10-24 16:39             ` Bart Schaefer
2013-10-24 16:26           ` Bart Schaefer
2013-10-24 16:46             ` Peter Stephenson [this message]
2013-10-25  0:38               ` Bart Schaefer
2013-10-24 15:17         ` Jun T.
2013-10-24 16:25           ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131024174610.0da2aaaf@pwslap01u.europe.root.pri \
    --to=p.stephenson@samsung.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).