Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Strange function/pipestatus behavior, maybe a scope bug?



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



Messages sorted by: Reverse Date, Date, Thread, Author