Re: bug in zsh wait builtin - rhbz#1150541

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

On Sat, 25 Oct 2014 15:32:31 -0700
Bart Schaefer <schaefer@brasslantern.com> 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