From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9437 invoked by alias); 25 Sep 2016 15:16:26 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 39435 Received: (qmail 25264 invoked from network); 25 Sep 2016 15:16:26 -0000 X-Qmail-Scanner-Diagnostics: from know-smtprelay-omc-3.server.virginmedia.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(80.0.253.67):SA:0(-0.0/5.0):. Processed in 0.511275 secs); 25 Sep 2016 15:16:26 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: p.w.stephenson@ntlworld.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _smtprelay.virginmedia.com designates 80.0.253.67 as permitted sender) X-Originating-IP: [86.21.219.59] X-Spam: 0 X-Authority: v=2.1 cv=W9TFLkik c=1 sm=1 tr=0 a=utowdAHh8RITBM/6U1BPxA==:117 a=utowdAHh8RITBM/6U1BPxA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=glWgSL0mk1_NlhvH-X4A:9 a=CjuIK1q_8ugA:10 Date: Sun, 25 Sep 2016 16:16:20 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Bug related to stdin/always/jobcontrol Message-ID: <20160925161620.035dac1c@ntlworld.com> In-Reply-To: <20160922115921.GA3613@fujitsu.shahaf.local2> References: <87r392jgd0.fsf@juno.home.vuxu.org> <20160905164207.4630643b@pwslap01u.europe.root.pri> <20160914183105.69862fa9@pwslap01u.europe.root.pri> <20160914223553.3173c8ca@ntlworld.com> <20160922115921.GA3613@fujitsu.shahaf.local2> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 22 Sep 2016 11:59:21 +0000 Daniel Shahaf wrote: > This (39331) broke fg'ing a function for me: > > % print $ZSH_PATCHLEVEL > zsh-5.2-dev-1-401-g4e51079 > % f() { $EDITOR } > % f > > zsh: suspended f > % fg > [1] + continued f > zsh: suspended (tty output) f > > After the 'fg' I get another prompt immediately, instead of being > returend to $EDITOR. I think this is a fairly straightforward additional race fix, luckily, at least to get us to the point where known problems are fixed. In the cases I was looking at before, the processes associated with the SUPERJOB already existed, and there was no further opportunity of fixing up the pgrp for the SUBJOB. The fact those processes already existed also determined the pgrp for the SUBJOB, which is what's being set here that caused the case above to be mishandled. In this case, there's no process associated with the SUPERJOB yet, but that's OK: everything gets handled properly when there is one. I think the gleader of the SUBJOB doesn't need any further special handling here (everything seems to work, anyway). Process handling and SUPERJOB creation are murkily separate, so I don't think this is (necessarily) buggy. There could well be more aspects as I certainly haven't got my mind round everything --- in particular, I don't know for sure that the fact the shell has registered processes associated with the superjob is actually tied to the subjob's pgrp, which is what this test assumes, just that that appears to be so in the cases I've tried. pws diff --git a/Src/exec.c b/Src/exec.c index d924148..a5086c3 100644 --- a/Src/exec.c +++ b/Src/exec.c @@ -1703,7 +1703,8 @@ execpline(Estate state, wordcode slcode, int how, int last1) jobtab[list_pipe_job].stat |= STAT_SUPERJOB; jn->stat |= STAT_SUBJOB | STAT_NOPRINT; jn->other = pid; - jn->gleader = jobtab[list_pipe_job].gleader; + if (hasprocs(list_pipe_job)) + jn->gleader = jobtab[list_pipe_job].gleader; } if ((list_pipe || last1) && hasprocs(list_pipe_job)) killpg(jobtab[list_pipe_job].gleader, SIGSTOP);