Re: interrupt handling bug (again?)

[Peter Stephenson <p.stephenson@samsung.com>]

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
> 
> I'm not 100% sure but this is most likely a TTY process group issue.
> 
> If I change "xterm" to
> 
> % for a in 1 2 3; do; sleep 10; echo $a; done
> 
> then I can reproduce the behavior on "bg".

Yes, this version is very straightforward to see.

> ...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.

The shell forked to run the rest of the loop is running as a SUPERJOB
with a different PGID from the parent shell (I checked the latter
though haven't gone into the SUBJOB / SUPERJOB code again yet). I think
that means it should never need to get the SIGINT. The parent shell
knows (or can deduce simply by means of the job table) it's now not
associated with a foreground SUBJOB, so I don't see why it shouldn't be
able to handle this case properly.

Haven't tracked down the specific code, though.

pws