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 09:57:13 +0100 [thread overview]
Message-ID: <20131024095713.44d2982e@pwslap01u.europe.root.pri> (raw)
In-Reply-To: <131023221548.ZM2352@torch.brasslantern.com>
On Wed, 23 Oct 2013 22:15:48 -0700
Bart Schaefer <schaefer@brasslantern.com> 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
next prev parent reply other threads:[~2013-10-24 9:07 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 [this message]
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
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=20131024095713.44d2982e@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).