Re: 3.0.6-pre-5 problem

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Jun 25,  4:29pm, Bart Schaefer wrote:
} Subject: Re: 3.0.6-pre-5 problem
}
} zsh(28198)-+-pstree(5173)
}            `-xterm(5161)---zsh(5162)---mutt(5164)
} 
} The top-level xterm case is now producing process trees exactly like
} the case where there's an intermediate zsh, but the parent zsh is still
} not ignoring the TSTP.
 
More information:  Fooling around with "gdbterm" (I posted it to zsh-users
a while back) I managed to get zsh to stop and resume again (though the
mutt process got orphaned).  When zsh came back and I typed "fg" to try to
resume mutt, I got "no job control in this shell" which is pretty strange
as there had been job control a moment before.

That indicates to me that, in this bit of code from execpline() we're going
through the third branch:

		    if ((pid = fork()) == -1) {
			/* ... */
		    }
		    else if (pid) {
			/* ... */
		    else {
			close(synch[0]);
			entersubsh(Z_ASYNC, 0, 0);
			if (jobtab[list_pipe_job].procs)
			    setpgrp(0L, mypgrp = jobtab[list_pipe_job].gleader);
			close(synch[1]);
			kill(getpid(), SIGSTOP);
			list_pipe = 0;
			list_pipe_child = 1;
			opts[INTERACTIVE] = 0;
			break;
		    }

Which of course is the one thing Sven hasn't tried patching yet ... but I'm
not sure WHY zsh is going through the third branch.  All of Sven's patches
have been to the second branch.

What's odd is that over in the 6860 "Re: PATCH: loop killing" thread, zsh
DOESN'T get the signal when it's supposed to.  Maybe Sven's got the cases
in which zsh takes the second and third branches, reversed?

Or maybe I'm just completely confused, which is entirely likely by now.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com