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 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


  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).