Mail Archives: cygwin/2001/05/08/18:11:44
On Tue, May 08, 2001 at 03:38:38PM -0600, Troy Noble wrote:
>> >Exactly. I am using FSF NT Emacs 20.7.1, which is a native win32 GUI
>app.
>> >However, the fact that it creates a console is probably what's confusing
>> >cygwin's bash, right?
>>
>> I would not call it confused. It is working as designed.
>
>Agreed if I understand you correctly. So, you would classify FSF NT
>Emacs as not being a "pure windows" app, at least not from bash's
>perspective... since it creates a console. If so, that makes sense.
>
>
>> >> Are you using a Cygwin version of bash? Why is it ignoring SIGINT?
>> >> ctrl_c_handler in bash should be sending CTRL-Cs to its children.
>> >
>> >I've tried with both: 2.05.0(5)-release and 2.04.7(2)-release
>> >that I used cygwin's setup.exe to install.
>> >
>> >And I have mis-spoken again. I think bash DOES send CTRL-C's to
>> >its children, since I see each of them pop into their ctrl_c_handler.
>
>> Actually, I misspoke. The question is why isn't bash sending SIGINTs
>> to its children. The CTRL-Cs come from Windows.
>
>The subprocesses do seem to get the SIGINT. So why aren't they
>responding to it and killing themselves correctly?
>
>I ran bash, set CYGWIN_SLEEP=15000, typed "ls -lR", attached to
>the process, told gdb to continue, then went to my bash shell and
>hit CTRL-C.
>
>I immediately got a SIGINT in the child process, even before its
>CTRL-C handler got invoked.
That's a "Windows" SIGINT, which is the only thing that gdb can
detect. A Cygwin SIGINT is a different thing entirely. Since Cygwin
has the full complement of Windows signals, it uses another complicated
method for sending signals between processes.
Running in strace would tell whether you received a SIGINT or not. You'd
see the signal_thread responding to a SIGINT.
cgf
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -