Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <010701c199ac$ca415b30$0200a8c0@lifelesswks> From: "Robert Collins" To: References: <03f001c197dd$7a9bec10$0200a8c0 AT lifelesswks> <013201c19812$2125e750$0200a8c0 AT lifelesswks> <20020108161950 DOT GC22944 AT redhat DOT com> <01a401c19892$2f5fa8d0$0200a8c0 AT lifelesswks> <20020109003913 DOT GA28328 AT redhat DOT com> <042a01c198a6$b03bb2a0$0200a8c0 AT lifelesswks> <20020109005523 DOT GA28659 AT redhat DOT com> <044301c198a8$8f0b61a0$0200a8c0 AT lifelesswks> <20020109011311 DOT GB28659 AT redhat DOT com> <045301c198ab$3659f820$0200a8c0 AT lifelesswks> <20020110024653 DOT GA31361 AT redhat DOT com> Subject: Re: bash/cmd CTRL-C problem... Date: Thu, 10 Jan 2002 18:59:54 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 10 Jan 2002 07:59:54.0350 (UTC) FILETIME=[C9E160E0:01C199AC] === ----- Original Message ----- From: "Christopher Faylor" To: Sent: Thursday, January 10, 2002 1:46 PM Subject: Re: bash/cmd CTRL-C problem... > On Wed, Jan 09, 2002 at 12:16:04PM +1100, Robert Collins wrote: > >----- Original Message ----- > >From: "Christopher Faylor" > >>I'm specifically trying not to do the "TRUE" thing, though, since > >>AFAICT it isn't always appropriate. > > > >If you want to SIG_IGN the signal, then it is: "When a CTRL+C signal is > >received, the control handler returns TRUE, indicating that it has > >handled the signal. Doing this prevents other control handlers from > >being called." (note that this is within this process only). > > I was going back over this thread before checking in a change to see if > I'd missed something. > > I just realized that I didn't address this concern. Don't know if it > matters but... > > The difference between the SIG_IGN way and the "return TRUE" way is > that the SIG_IGN way stops the current process from responding to > a cygwin signal but still lets it respond to a Windows "signal". That > means that the code in ctrl_c_handle can do its job, if it has to. Huh? I actually did the reverse - returning TRUE only prevented responding to a windows signal, but allowed responding to a cygwin signal. This meant that 'kill -2 stubpid' from another shell would kill the stub and it's spawned programs, which may alleviate some of the 'CTRL-C doesn't work for me now' grief that you rightly expect. I mention this because IMO the strange behaviour is due to user expectation of ^C behaviour - not signal behaviour. > If we always "return TRUE" in the exec case, then there will be some > situations where the SIGINT is not delivered to the rest of the process > group since the code in ctrl_c_handler would be short circuited. I don't believe that is the case: Every console process attached to that console independently recieves the windows signal. Only one has been disabled. So the execing process's children will still recieve the windows signals and the cygwin signals. > My SIG_IGN "solution" is wrong, too, though. The SIG_IGN would be > inherited by the exec'ed process. Then the execed process would never > see a cygwin SIGINT signal. Yes. I still believe that return TRUE is a good solution... but if you've solved the obvious behaviour I'll be quite now :}. > Btw, if I fix this, I may well fix a problem with CTRL-C and fork() that > I've been noticing for years, too. Or, at least I'll be able to convince > myself its fixed until the next time I see the problem. Cool. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/