Re: interrupt handling bug (again?)

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

On Fri, 30 Jun 2017 14:33:47 +0100
Peter Stephenson <p.stephenson@samsung.com> wrote:

> On Sat, 24 Jun 2017 12:03:10 -0700
> Bart Schaefer <schaefer@brasslantern.com> wrote:
> 
> > On Jun 6,  9:08pm, Mikael Magnusson wrote:
> > }
> > } % for a in 1 2 3; do xterm; done
> > } then hit ctrl-z in that term and bg it, do stuff and at some point hit
> > } ctrl-c, the backgrounded for loop will be interrupted
> > ...if you interrupt before the foreground job is done, the
> > parent faithfully propagates the signal to the entry in the job
> > table, and that kills the loop when it finally does restart.
> 
> I think that is happening, but I'm not sure where.

It's check_cursh_sig(SIGINT) from the interrupt handler.  It propagates
to jobs marked as STAT_CURSH.

I think when the SUPERJOB is put into the background it should no longer
have STAT_CURSH status.  Does that sound reasonable?  I'm not sure why
it would have it anyway, should it perhaps be removed when we mark it as
STAT_SUPERJOB, which is kind of decurrentshellising it in any case?

Anyway, this minimal fix seems to do the right thing for the case in
question.  It might have side effects, though.  More specificaly, if it
didn't have side effects that would be some kind of record.

pws

diff --git a/Src/jobs.c b/Src/jobs.c
index d1b98ac..09a8bab 100644
--- a/Src/jobs.c
+++ b/Src/jobs.c
@@ -2303,6 +2303,7 @@ bin_fg(char *name, char **argv, Options ops, int func)
 			}
 			pn = next;
 		    }
+		    jobtab[job].stat &= ~STAT_CURSH;
 		}
 	    } else if (func == BIN_BG) {
 		/* Silly to bg a job already running. */