Re: [BUG] Bash not reacting to Ctrl-C

[Chet Ramey]

> On 03/07, Chet Ramey wrote:
> >
> > > So I don't think my patch is really doing what it _intends_ to do.
> >
> > Let's take a step back and approach this a different way.  Instead of
> > trying to intuit whether or not the child did anything with the SIGINT,
> > let's try to make the race condition smaller.
> 
> OK, I'll try to test this patch later to see if it make the difference...
> At least the subjective difference.
> 
> But,
> 
> > The following patch is a very small change to jobs.c that makes
> > wait_sigint_handler only pay attention and set wait_sigint_received when
> > the shell is actually in waitpid() waiting for the child.  It uses a
> > semaphore around the call to waitpid to effect that, with a little
> > bookkeeping and cleanup code.  When the shell gets a SIGINT while not
> > actually waiting for a child, it restores the old handler and sends
> > SIGINT to itself.
> 
> Hmm. It is very possible I do not understand the patch correctly.
> 
> But doesn't this patch introduce another problem?
> 
> > *** 3090,3096 ****
> > --- 3099,3107 ----
> >       waitpid_flags |= WNOHANG;
> >     }
> >
> > +       waiting_for_child++;
> >         pid = WAITPID (-1, &status, waitpid_flags);
> 
> OK, and what if ^C comes before waiting_for_child++ ?
> 
> IIUC, in this case bash exits and leaves the current application
> (say, emacs which threats SIGINT specially) alone, no?

Yes, it does.  However, the same problem exists now.  There is a window
between the time bash forks, the child execs, and bash waits when a SIGINT
can arrive and the same thing will happen.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/