Re: PATCH: that execution stuff

Re: PATCH: that execution stuff

[Sven Wischnowsky]

Bart Schaefer wrote:

> Thanks, Sven; this finally seems to have nailed the critical bits.

Ha. One thing I knew already about yesterday:

  % f() { while read a; do :; done; mutt }
  % cat foo | f

The important bit is that mutt is started when the cat has finished.
In this case it is put in the group of the parent shell. Bing! Something
similar happens when we ^Z such a thing when the beginning of the
pipeline has already exited (the sub-shell is left in the group of the 
parent shell).

While trying to fix this I also found another one:

  % f() { cat builtin.c }
  % f | while read a; do :; done

Then ^Z it and try to fg it -- nothing happens. The sub-shell for the
function is not continued correctly.

There were some other things (like the sub-shell not continuing the
cat in the second example) I found and which should be fixed now, but
I don't really remember them. Some were probably caused by me trying
to get these two to work.

If someone feels adventurous and has spare time (ha!), he could
probably try more of these combinations (^Z'ing, fg'ing, ^C'ing loops, 
function, pipes, combinations of all of them) and tell us if he finds
something that still doesn't work.
  

Bye
 Sven

P.S.:   If you have the impression that the execution code is getting
        more and more complicated, you are right.
P.P.S.: Execution code is really hard to bug. Sigh.

diff -u os/exec.c Src/exec.c
--- os/exec.c	Tue Jun 29 17:25:48 1999
+++ Src/exec.c	Wed Jun 30 11:51:09 1999
@@ -903,7 +903,7 @@
 
 		    /* If the super-job contains only the sub-shell, the
 		       sub-shell is the group leader. */
-		    if (!jn->procs->next)
+		    if (!jn->procs->next || lpforked == 2)
 			jn->gleader = list_pipe_pid;
 
 		    for (pn = jobtab[jn->other].procs; pn; pn = pn->next)
@@ -961,7 +961,8 @@
 		    else if (pid) {
 			char dummy;
 
-			lpforked = 1;
+			lpforked = 
+			    (killpg(jobtab[list_pipe_job].gleader, 0) == -1 ? 2 : 1);
 			list_pipe_pid = pid;
 			nowait = errflag = 1;
 			breaks = loops;
@@ -983,9 +984,12 @@
 		    else {
 			close(synch[0]);
 			entersubsh(Z_ASYNC, 0, 0);
-			if (jobtab[list_pipe_job].procs)
-			    setpgrp(0L, mypgrp = jobtab[list_pipe_job].gleader);
-			else
+			if (jobtab[list_pipe_job].procs) {
+			    if (setpgrp(0L, mypgrp = jobtab[list_pipe_job].gleader)
+				== -1) {
+				setpgrp(0L, mypgrp = getpid());
+			    }
+			} else
 			    setpgrp(0L, mypgrp = getpid());
 			close(synch[1]);
 			kill(getpid(), SIGSTOP);
@@ -2206,9 +2210,8 @@
 	    if (kill(jobtab[list_pipe_job].gleader, 0) == -1 ||
 		setpgrp(0L, jobtab[list_pipe_job].gleader) == -1) {
 		jobtab[list_pipe_job].gleader =
-		    jobtab[thisjob].gleader = mypgrp;
-		setpgrp(0L, mypgrp);
-
+		    jobtab[thisjob].gleader = (list_pipe_child ? mypgrp : getpid());
+		setpgrp(0L, jobtab[list_pipe_job].gleader);
 		if (how & Z_SYNC)
 		    attachtty(jobtab[thisjob].gleader);
 	    }
diff -u os/jobs.c Src/jobs.c
--- os/jobs.c	Tue Jun 29 12:51:16 1999
+++ Src/jobs.c	Wed Jun 30 11:51:48 1999
@@ -787,9 +787,13 @@
 	       what this might be.  --oberon
 
 	    errflag = 0; */
+	    if (subsh) {
+		killjb(jn, SIGCONT);
+		jn->stat &= ~STAT_STOPPED;
+	    }
 	    if (jn->stat & STAT_SUPERJOB) {
 		Job sj = jobtab + jn->other;
-		if (sj->stat & STAT_DONE) {
+		if ((sj->stat & STAT_DONE) || !sj->procs) {
 		    struct process *p;
 		    
 		    for (p = sj->procs; p; p = p->next)
@@ -803,11 +807,18 @@
 			    break;
 			}
 		    if (!p) {
+			int cp;
+
 			jn->stat &= ~STAT_SUPERJOB;
 			jn->stat |= STAT_WASSUPER;
-			if (WIFEXITED(jn->procs->status) &&
-			    killpg(jn->gleader, 0) == -1)
-			    jn->gleader = mypgrp;
+
+			if ((cp = ((WIFEXITED(jn->procs->status) ||
+				    WIFSIGNALED(jn->procs->status)) &&
+				   killpg(jn->gleader, 0) == -1))) {
+			    Process p;
+			    for (p = jn->procs; p->next; p = p->next);
+			    jn->gleader = p->pid;
+			}
 			/* This deleted the job too early if the parent
 			   shell waited for a command in a list that will
 			   be executed by the sub-shell (e.g.: if we have
@@ -819,7 +830,7 @@
 			/* If this super-job contains only the sub-shell,
 			   we have to attach the tty to our process group
 			   (which is shared by the sub-shell) now. */
-			if (!jn->procs->next)
+			if (!jn->procs->next || cp || jn->procs->pid != jn->gleader)
 			    attachtty(jn->gleader);
 			kill(sj->other, SIGCONT);
 		    }
@@ -830,7 +841,9 @@
 
 		    jn->stat |= STAT_STOPPED;
 		    for (p = jn->procs; p; p = p->next)
-			p->status = sj->procs->status;
+			if (p->status == SP_RUNNING ||
+			    (!WIFEXITED(p->status) && !WIFSIGNALED(p->status)))
+			    p->status = sj->procs->status;
 		    curjob = jn - jobtab;
 		    printjob(jn, !!isset(LONGLISTJOBS), 1);
 		    break;
@@ -1250,7 +1263,10 @@
 		if (func != BIN_WAIT) {		/* fg */
 		    thisjob = job;
 		    if ((jobtab[job].stat & STAT_SUPERJOB) &&
-			!jobtab[job].procs->next)
+			((!jobtab[job].procs->next ||
+			  WIFEXITED(jobtab[job].procs->status) ||
+			  WIFSIGNALED(jobtab[job].procs->status))) &&
+			jobtab[jobtab[job].other].gleader)
 			attachtty(jobtab[jobtab[job].other].gleader);
 		    else
 			attachtty(jobtab[job].gleader);
diff -u os/signals.c Src/signals.c
--- os/signals.c	Tue Jun 29 12:51:17 1999
+++ Src/signals.c	Wed Jun 30 11:43:50 1999
@@ -586,7 +586,10 @@
  
                 for (pn = jn->procs; pn->next; pn = pn->next)
                     err = kill(pn->pid, sig);
- 
+
+		if (!jobtab[jn->other].procs && pn)
+		    err = kill(pn->pid, sig);
+
                 return err;
             }
  

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: that execution stuff

[Sven Wischnowsky]

I wrote:

> P.P.S.: Execution code is really hard to bug. Sigh.

*De*bug, I wanted to say. Ouch. ;-)

Bye
 Sven

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: that execution stuff

[Bart Schaefer]

On Jun 29, 12:51pm, Sven Wischnowsky wrote:
} Subject: Re: PATCH: that execution stuff
}
} However, there is still a problem (and this one isn't new, it was
} always like this): the sub-shell created on ^Z has the same pgrp as
} the parent shell and commands started by it use it, too. So if we
} have:
} 
}   % f() { less /etc/termcap; mutt }
}   % f
} 
} and then ^Z the less, fg it, and exit from it, the sub-shell takes
} over and starts mutt *in the pgrp of the parent shell*!

Oy.

} As I said, I
} don't have mutt, but this should then have the effect of stopping the
} parent shell again, right?

Yes.

} The solution would of course be to make the sub-shell use its own
} group

Specifically, the PID of the current job ...

} and have the parent shell correctly handle the
} attachtty()s. The patch tries to do that.

Here's "ps j" output (from another terminal while mutt is in foreground):

 PPID   PID  PGID   SID TTY TPGID  STAT  UID   TIME COMMAND
18625 18626 18626 18626  p3 18631  S     674   0:00 Src/zsh -f 
18626 18631 18631 18626  p3 18631  S     674   0:00 Src/zsh -f 
18631 18632 18631 18626  p3 18631  S     674   0:00 mutt 

Note, mutt is in its own pgrp, exactly as it wants to be.  This is with
3.0.6-pre-5 after patches up to this one, but I don't know why it'd be
different in pws-24.

Thanks, Sven; this finally seems to have nailed the critical bits.

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

RE: PATCH: that execution stuff

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> > Andrej Borsenkow wrote:
> >
> > > > I don't need to point out that `while true; do gzip ...; done' is not
> > > > expected to be ^C'able again, do I? Maybe we should document this?
> > > > (Together with the ^Z/fg/^C-trick?)
> > >
> > > It does not work. I can suspend *and* kill 'while true; do gzcat
> > -f; done'. But
> > > after I suspend and resume it, I can neither kill nor suspend it again.
> >
> > Hm, it worked for me with `zcat ... >/dev/null'. But this patch might
> > also have an effect on this (because of this sub-shell-pgrp thing).
> 
> Yes, now it works as described. No way to kill loop with gzcat before ^Z; ant
> two ^C's after that (I forgot, are two ^C's expected? Or was it supposed to be
> only one?).

Uff. That feels good ;-) And, yes, the two ^C's are expected -- one
for the gzcat which doesn't give us any information and the second one 
to kill the sub-shell. If the first gzcat in the loop has finished you 
need only one -- the second one ;-)

> In any case, as long as it is documented, it is far better as csh or ksh here.
> And thinking more about it - the only clean way to implement job control that
> works in any case is to start "guard zsh" for every pipeline (and run every
> pipeline in seperate process group). This is probably too much. It could be
> optimised if we are sure pipeline never executes external commands ... no idea
> how hard it is.

Extremly hard. To be exact: almost impossible because we might have a
list that first defines a function and then calls a command that once
looked like an external command but after that definition calls the
function. And other nasty things like that.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

RE: PATCH: that execution stuff

[Andrej Borsenkow]

> Andrej Borsenkow wrote:
>
> > > I don't need to point out that `while true; do gzip ...; done' is not
> > > expected to be ^C'able again, do I? Maybe we should document this?
> > > (Together with the ^Z/fg/^C-trick?)
> >
> > It does not work. I can suspend *and* kill 'while true; do gzcat
> -f; done'. But
> > after I suspend and resume it, I can neither kill nor suspend it again.
>
> Hm, it worked for me with `zcat ... >/dev/null'. But this patch might
> also have an effect on this (because of this sub-shell-pgrp thing).
>

Yes, now it works as described. No way to kill loop with gzcat before ^Z; ant
two ^C's after that (I forgot, are two ^C's expected? Or was it supposed to be
only one?).

In any case, as long as it is documented, it is far better as csh or ksh here.
And thinking more about it - the only clean way to implement job control that
works in any case is to start "guard zsh" for every pipeline (and run every
pipeline in seperate process group). This is probably too much. It could be
optimised if we are sure pipeline never executes external commands ... no idea
how hard it is.

/andrej

Re: PATCH: that execution stuff

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Jun 29,  8:56am, Sven Wischnowsky wrote:
> } Subject: PATCH: that execution stuff
> }
> } This tries to get the always-pgrp-behavior back without losing the
> } other things that were fixed in the meanwhile. Now please test your
> } favorite execution bugs everyone and tell me what does not work.
> 
> This gets exactly to where I got, and no farther.  The test case is the
> same as for the original problem reported by Jos Backus; the failure is
> as I described in 6883:  Suspend the function, then bring it back into
> the foreground, and bin_fg() passes zsh's PID to attachtty() as the
> process group, which means mutt gets a SIGTTIN as soon as you type.  And
> then when you try to bring it back into the foreground yet again, the
> wrong thing gets SIGCONT'd and zsh ends up waiting in sigsuspend() for a
> job that's never going to signal it.

(Btw. I couldn't test Jos' problem because I don't have mutt.)

But I could reproduce it with less, I had forgotten to test it with
something that needs the terminal, sorry.

The patch below is probably larger than necessary, mainly because I
made the gleader of the super-job be set to -1 if the super-job
contains only the sub-shell created on ^Z.
After the problem Bart mentioned worked again I tried:

  % f() { less /etc/termcap; echo done }
  % x=4; while (( x-- )); do f; done

Which works now, too.

However, there is still a problem (and this one isn't new, it was
always like this): the sub-shell created on ^Z has the same pgrp as
the parent shell and commands started by it use it, too. So if we
have:

  % f() { less /etc/termcap; mutt }
  % f

and then ^Z the less, fg it, and exit from it, the sub-shell takes
over and starts mutt *in the pgrp of the parent shell*! As I said, I
don't have mutt, but this should then have the effect of stopping the
parent shell again, right?

The solution would of course be to make the sub-shell use its own
group, and have the parent shell correctly handle the
attachtty()s. The patch tries to do that.

I had to add a STAT_*-flag (WASSUPER) that is set when a super-job is
turned into a normal one. It's used to delete the sub-job when the
super-job finishes (under certain circumstances it is possible to
delete it before the super-job, but I can't find a good place where to 
put that deletejob() without breaking one case or another).


Andrej Borsenkow wrote:

> > I don't need to point out that `while true; do gzip ...; done' is not
> > expected to be ^C'able again, do I? Maybe we should document this?
> > (Together with the ^Z/fg/^C-trick?)
> 
> It does not work. I can suspend *and* kill 'while true; do gzcat -f; done'. But
> after I suspend and resume it, I can neither kill nor suspend it again.

Hm, it worked for me with `zcat ... >/dev/null'. But this patch might
also have an effect on this (because of this sub-shell-pgrp thing).

So, the next round...

Bye
 Sven

P.S.: Bart, thanks, I had just had a look at the other new uses of
      pline_level, too. The problem is to find out which are needed 
      to be able to stop functions/functions-in-loops (which was
      broken before) and which had to go.

diff -u os/exec.c Src/exec.c
--- os/exec.c	Tue Jun 29 12:49:36 1999
+++ Src/exec.c	Tue Jun 29 11:59:32 1999
@@ -302,7 +302,7 @@
 static int
 execcursh(Cmd cmd, LinkList args, int flags)
 {
-    if (!list_pipe)
+    if (!list_pipe && thisjob != list_pipe_job)
 	deletejob(jobtab + thisjob);
     cmdpush(CS_CURSH);
     execlist(cmd->u.list, 1, flags & CFLAG_EXEC);
@@ -890,7 +890,7 @@
 
 	    lastwj = thisjob = newjob;
 
-	    if (list_pipe)
+	    if (list_pipe || pline_level)
 		jn->stat |= STAT_NOPRINT;
 
 	    if (nowait) {
@@ -901,8 +901,10 @@
 		    DPUTS(!list_pipe_pid, "invalid list_pipe_pid");
 		    addproc(list_pipe_pid, list_pipe_text);
 
+		    /* If the super-job contains only the sub-shell, the
+		       sub-shell is the group leader. */
 		    if (!jn->procs->next)
-			jn->gleader = mypgrp;
+			jn->gleader = list_pipe_pid;
 
 		    for (pn = jobtab[jn->other].procs; pn; pn = pn->next)
 			if (WIFSTOPPED(pn->status))
@@ -924,7 +926,7 @@
 	    }
 
 	    for (; !nowait;) {
-		if (list_pipe_child || pline_level) {
+		if (list_pipe_child) {
 		    jn->stat |= STAT_NOPRINT;
 		    makerunning(jn);
 		}
@@ -983,6 +985,8 @@
 			entersubsh(Z_ASYNC, 0, 0);
 			if (jobtab[list_pipe_job].procs)
 			    setpgrp(0L, mypgrp = jobtab[list_pipe_job].gleader);
+			else
+			    setpgrp(0L, getpid());
 			close(synch[1]);
 			kill(getpid(), SIGSTOP);
 			list_pipe = 0;
@@ -1004,8 +1008,7 @@
 		jn = jobtab + pj;
 		killjb(jn, lastval & ~0200);
 	    }
-	    if (list_pipe_child || ((list_pipe || pline_level) &&
-				    (jn->stat & STAT_DONE)))
+	    if (list_pipe_child || (list_pipe && (jn->stat & STAT_DONE)))
 		deletejob(jn);
 	    thisjob = pj;
 
diff -u os/jobs.c Src/jobs.c
--- os/jobs.c	Tue Jun 29 12:49:41 1999
+++ Src/jobs.c	Tue Jun 29 12:50:20 1999
@@ -180,7 +180,7 @@
 		/* If we have `cat foo|while read a; grep $a bar;done'
 		 * and have hit ^Z, the sub-job is stopped, but the
 		 * super-job may still be running, waiting to be stopped
-		 * or to exit. So we have to send it a SIGSTOP. */
+		 * or to exit. So we have to send it a SIGTSTP. */
 		int i;
 
 		for (i = 1; i < MAXJOB; i++)
@@ -672,6 +672,8 @@
     if (jn->ty)
 	zfree(jn->ty, sizeof(struct ttyinfo));
 
+    if (jn->stat & STAT_WASSUPER)
+	deletejob(jobtab + jn->other);
     jn->gleader = jn->other = 0;
     jn->stat = jn->stty_in_env = 0;
     jn->procs = NULL;
@@ -792,13 +794,17 @@
 		    
 		    for (p = sj->procs; p; p = p->next)
 			if (WIFSIGNALED(p->status)) {
-			    killpg(jn->gleader, WTERMSIG(p->status));
+			    if (jn->gleader != mypgrp && jn->procs->next)
+				killpg(jn->gleader, WTERMSIG(p->status));
+			    else
+				kill(jn->procs->pid, WTERMSIG(p->status));
 			    kill(sj->other, SIGCONT);
 			    kill(sj->other, WTERMSIG(p->status));
 			    break;
 			}
 		    if (!p) {
 			jn->stat &= ~STAT_SUPERJOB;
+			jn->stat |= STAT_WASSUPER;
 			if (WIFEXITED(jn->procs->status) &&
 			    killpg(jn->gleader, 0) == -1)
 			    jn->gleader = mypgrp;
@@ -810,6 +816,11 @@
 			   but the parent shell gets notified for the
 			   sleep.
 			   deletejob(sj); */
+			/* If this super-job contains only the sub-shell,
+			   we have to attach the tty to our process group
+			   (which is shared by the sub-shell) now. */
+			if (!jn->procs->next)
+			    attachtty(jn->gleader);
 			kill(sj->other, SIGCONT);
 		    }
 		    curjob = jn - jobtab;
@@ -1238,7 +1249,11 @@
 		fflush(shout);
 		if (func != BIN_WAIT) {		/* fg */
 		    thisjob = job;
-		    attachtty(jobtab[job].gleader);
+		    if ((jobtab[job].stat & STAT_SUPERJOB) &&
+			!jobtab[job].procs->next)
+			attachtty(jobtab[jobtab[job].other].gleader);
+		    else
+			attachtty(jobtab[job].gleader);
 		}
 	    }
 	    if (stopped) {
diff -u os/zsh.h Src/zsh.h
--- os/zsh.h	Mon Jun 28 16:04:05 1999
+++ Src/zsh.h	Tue Jun 29 12:26:04 1999
@@ -629,10 +629,12 @@
 #define STAT_INUSE	(1<<6)	/* this job entry is in use             */
 #define STAT_SUPERJOB	(1<<7)	/* job has a subjob                     */
 #define STAT_SUBJOB	(1<<8)	/* job is a subjob                      */
-#define STAT_CURSH	(1<<9)	/* last command is in current shell     */
-#define STAT_NOSTTY	(1<<10)	/* the tty settings are not inherited   */
+#define STAT_WASSUPER   (1<<9)  /* was a super-job, sub-job needs to be */
+				/* deleted */
+#define STAT_CURSH	(1<<10)	/* last command is in current shell     */
+#define STAT_NOSTTY	(1<<11)	/* the tty settings are not inherited   */
 				/* from this job when it exits.         */
-#define STAT_ATTACH	(1<<11)	/* delay reattaching shell to tty       */
+#define STAT_ATTACH	(1<<12)	/* delay reattaching shell to tty       */
 
 #define SP_RUNNING -1		/* fake status for jobs currently running */
 

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

RE: PATCH: that execution stuff

[Andrej Borsenkow]

>
> I don't need to point out that `while true; do gzip ...; done' is not
> expected to be ^C'able again, do I? Maybe we should document this?
> (Together with the ^Z/fg/^C-trick?)
>

It does not work. I can suspend *and* kill 'while true; do gzcat -f; done'. But
after I suspend and resume it, I can neither kill nor suspend it again.

/andrej

Re: PATCH: that execution stuff

[Bart Schaefer]

On Jun 29,  8:56am, Sven Wischnowsky wrote:
} Subject: PATCH: that execution stuff
}
} This tries to get the always-pgrp-behavior back without losing the
} other things that were fixed in the meanwhile. Now please test your
} favorite execution bugs everyone and tell me what does not work.

This gets exactly to where I got, and no farther.  The test case is the
same as for the original problem reported by Jos Backus; the failure is
as I described in 6883:  Suspend the function, then bring it back into
the foreground, and bin_fg() passes zsh's PID to attachtty() as the
process group, which means mutt gets a SIGTTIN as soon as you type.  And
then when you try to bring it back into the foreground yet again, the
wrong thing gets SIGCONT'd and zsh ends up waiting in sigsuspend() for a
job that's never going to signal it.

Trying to debug this the other night I got into a state where zsh tried
to bring jobtab[1] into the foreground but everything in the job table
was zeroed, which produced a crash.  Another time bin_fg() selected [1]
but the entry with the correct gleader was jobtab[2].

Something somewhere is completely messed up with respect to when/whether
to delete a job, but it's almost impossible to debug because if you set
breakpoints the subshells crash and if you attach with gdb at the wrong
time some of the signals get completely thrown away.

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

PATCH: that execution stuff

[Sven Wischnowsky]

Ok, I couldn't hold myself back...

This tries to get the always-pgrp-behavior back without losing the
other things that were fixed in the meanwhile. Now please test your
favorite execution bugs everyone and tell me what does not work.

I don't need to point out that `while true; do gzip ...; done' is not
expected to be ^C'able again, do I? Maybe we should document this?
(Together with the ^Z/fg/^C-trick?)

Bye
 Sven

diff -u os/exec.c Src/exec.c
--- os/exec.c	Mon Jun 28 16:18:30 1999
+++ Src/exec.c	Mon Jun 28 22:03:09 1999
@@ -2210,9 +2210,8 @@
 		    attachtty(jobtab[thisjob].gleader);
 	    }
 	}
-	else if (!(list_pipe || list_pipe_child || pline_level > 1) &&
-		 (!jobtab[thisjob].gleader ||
-		  setpgrp(0L, jobtab[thisjob].gleader) == -1)) {
+	else if (!jobtab[thisjob].gleader ||
+		 setpgrp(0L, jobtab[thisjob].gleader) == -1) {
 	    jobtab[thisjob].gleader = getpid();
 	    if (list_pipe_job != thisjob &&
 		!jobtab[list_pipe_job].gleader)
diff -u os/init.c Src/init.c
--- os/init.c	Mon Jun 28 16:18:31 1999
+++ Src/init.c	Mon Jun 28 20:38:26 1999
@@ -390,16 +390,7 @@
 #ifdef JOB_CONTROL
     /* If interactive, make the shell the foreground process */
     if (opts[MONITOR] && interact && (SHTTY != -1)) {
-      /* Since we now sometimes execute programs in the process group
-       * of the parent shell even when using job-control, we have to
-       * make sure that we run in our own process group. Otherwise if
-       * we are called from a program that doesn't put us in our own
-       * group a SIGTSTP that we ignore might stop our parent process.
-       * Instead of the two calls below we once had:
-       *   attachtty(GETPGRP());
-       */
-	attachtty(getpid());
-	setpgrp(0L, 0L);
+	attachtty(GETPGRP());
 	if ((mypgrp = GETPGRP()) > 0) {
 	    while ((ttpgrp = gettygrp()) != -1 && ttpgrp != mypgrp) {
 		sleep(1);
diff -u os/jobs.c Src/jobs.c
--- os/jobs.c	Mon Jun 28 16:18:31 1999
+++ Src/jobs.c	Mon Jun 28 21:52:44 1999
@@ -800,7 +800,7 @@
 		    if (!p) {
 			jn->stat &= ~STAT_SUPERJOB;
 			if (WIFEXITED(jn->procs->status) &&
-			    !(jn->stat & STAT_CURSH))
+			    killpg(jn->gleader, 0) == -1)
 			    jn->gleader = mypgrp;
 			/* This deleted the job too early if the parent
 			   shell waited for a command in a list that will

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de