From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28925 invoked by alias); 25 Oct 2014 23:04:54 -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: 33535 Received: (qmail 27067 invoked from network); 25 Oct 2014 23:04:51 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-Originating-IP: [80.3.229.105] X-Spam: 0 X-Authority: v=2.1 cv=AoZg3YNP c=1 sm=1 tr=0 a=uz1KDxDNIq33yePw376BBA==:117 a=uz1KDxDNIq33yePw376BBA==:17 a=NLZqzBF-AAAA:8 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=0zwQDXPwTY92ReiDL_4A:9 a=CjuIK1q_8ugA:10 Date: Sun, 26 Oct 2014 00:04:48 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: bug in zsh wait builtin - rhbz#1150541 Message-ID: <20141026000448.12fa03fd@pws-pc.ntlworld.com> In-Reply-To: <141025153231.ZM19285@torch.brasslantern.com> References: <20141021210234.199eee3d@pws-pc.ntlworld.com> <141021235542.ZM14840@torch.brasslantern.com> <20141023093232.1f4201e2@pwslap01u.europe.root.pri> <141023215041.ZM19768@torch.brasslantern.com> <20141025200847.782316a4@pws-pc.ntlworld.com> <141025152827.ZM7060@torch.brasslantern.com> <141025153231.ZM19285@torch.brasslantern.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.7; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sat, 25 Oct 2014 15:32:31 -0700 Bart Schaefer wrote: > On Oct 25, 3:28pm, Bart Schaefer wrote: > } > } #0 0x080b7085 in wait_for_processes () at ../../zsh-5.0/Src/signals.c:537 > } 537 if (!(jn->stat & (STAT_CURSH|STAT_BUILTIN)) && jn - jobtab != > } thisjob) > } (gdb) p jn > } $1 = 0x0 > > Add "jn != NULL &&" to the front of that condition and all tests pass. Yes, I was dozily wondering about that when I sent the patch but didn't get around to checking. I'm now wondering whether we need if (!jn || (!(jn->stat & (STAT_CURSH|STAT_BUILTIN)) && jn - jobtab != thisjob)) addbgstatus(pid, (int)lastval2); i.e. if there's *no* job we should remember the PID because we don't have enough information to say we don't need to remember it. That's probably safe --- we've already had a succesful return value from wait or one of its relatives so it's a child of the shell --- but there might be cases where it's inefficient. I suppose I ought to check what happens when job control is off. > Incidentally, when you ^Z the foreground job, the value of $! is not > updated, so the only way to use wait is by job identifier (which is > equivalent to using fg). $! finally does get updated when the job is > continued with bg. (This describes the pre-33531-patch state, but I > don't think the patch alters it.) Yes, this isn't going to interact particularly usefully with the patch, but I'm not really expecting it to be particularly useful when you're in an interactive shell with job control anyway. pws