Zsh Mailing List Archive
Messages sorted by:
Re: Another bug when suspending pipelines
- X-seq: zsh-workers 39368
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: "Zsh Hackers' List" <zsh-workers@xxxxxxx>
- Subject: Re: Another bug when suspending pipelines
- Date: Fri, 16 Sep 2016 15:25:07 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=XxdVW8gRzqhZmLx0sQifYxOpuomFmvGu8KWx5qmvIdA=; b=ItmC2PASj0Cv79GsIo7EOBtHJaK6YMPnw6/I78O92CfUIvf2+sMGe6B/+9eCVNLbQX jPBypvcawCex7TDXkL8R3T+cv5NqmZMt4KOexpvbZQP0nprDSL747uD8USa2hGw8si/n wsQeEDBUQFDwPjPSWgvCjADpmHjTqeP4XCpTcpKURsCNwsyQ0qPdcpOtjkjaKxrlMFfO Grgo+2XRARoZZMfH9fCNJVHYxlxWBLXDlmpAlZLp07olOfIdIYjlWwLhaoji6y2u4/DK uMehK97DvTtdTioUvxrz9e5IX0T7vQQittjNYoN7WhhNChwIqSx3csjp99mwjKTUIJKd eN4A==
- In-reply-to: <firstname.lastname@example.org>
- List-help: <mailto:email@example.com>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <CGME20160916123306eucas1p1f4349b727ebdfb64b4947c9d210457e1@eucas1p1.samsung.com> <email@example.com> <160916113801.ZM11473@torch.brasslantern.com> <firstname.lastname@example.org>
On Sep 16, 9:52pm, Peter Stephenson wrote:
} Subject: Re: Another bug when suspending pipelines
} On Fri, 16 Sep 2016 11:38:01 -0700
} Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
} > The parent has to manage all three of these jobs, because it can't
} > hand off the already-forked "sleep 7" to the newly-forked brace job.
} > It has to arrange that the brace job can be sent a SIGCONT on "fg"
} > but not actually do anything until the "sleep 7" has finished; I
} > believe that's handled by the "synch" pipes and hidden reads; in any
} > case, it works.
} The parent shell "simply" waits for the non-shell processes that were
} forked directly from the parent shell on the right of the pipeline and
} restarts the forked shell to run the rest (which may, of course, include
} other external processes) when those have finished.
Hm. That means that if you *backgound* the "sleep" and bother looking
with "ps", you will see a process that is in T state while the shell
claims it is running.
I suppose that's worked fine for the last lo these many years, but does
it not mean that an external "kill -CONT" can cause the expected order
of events to be violated?
} > * makes the tail of the brace expression into a process group which
} > becomes the tty leader, and
} > * writes a byte on the synch pipe to wake it up.
} This all happened in one go when the shell was forked.
Maybe it shouldn't. Ugh.
Messages sorted by: