Signal handling in WIN32 console programs
Christopher Faylor
cgf-use-the-mailinglist-please@cygwin.com
Thu Jan 22 23:21:00 GMT 2009
On Thu, Jan 22, 2009 at 09:58:08PM +0000, Andy Koppe wrote:
> avadekar@certicom.com wrote:
>>My WIN32 app is compiled under vc7 and uses signal() to trap SIGINT,
>>SIGABRT and SIGTERM. If I run the application under console2 or a
>>native terminal, pressing ^C triggers the handler and the application
>>stops programmatically due to a state change made by the handler. When
>>I do the same under rxvt (not the X based one) or minTTY, the ^C stops
>>the process without the signal handler executing. Similarly, even when
>>run from the native console, kill (-INT, -ABRT, -TERM) causes the
>>application to end without the handler catching the signal. So I
>>wonder if the native console passes the character to the process
>>directly whereas the minTTY/rxvt shells interpret it and send a signal
>>that the native app doesn't really understand properly.
>
>MinTTY and rxvt do not interpret the ^C keypress in any special way.
>They simply write a ^C (0x03) character to the child process' pty. The
>pty driver may translate that into a signal depending on the pty's line
>settings (as shown by stty). Sorry I don't know how ^C is processed in
>a Windows console or why the behaviour would be different with ptys.
The operative term here is, once again, "Windows Console". A pure
Windows program running in MinTTY or rxvt does not have a windows
console and so won't see the type of SIGINT that the windows console
generates.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
More information about the Cygwin
mailing list