Re: Signal handling in WIN32 console programs
On Jan 22 18:05, avade...@certicom.com wrote: On Thu, Jan 22, 2009 at 05:04:23PM -0500, Christopher Faylor wrote: On Thu, Jan 22, 2009 at 09:58:08PM +, Andy Koppe wrote: avade...@certicom.com wrote: 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. Is there something that I could do inside the native application code to catch what it is getting? I've tried SetConsoleCtrlhandler, but that also never gets invoked prior to the process termination. No. The Cygwin tty apps like rxvt and MinTTY are using POSIX signal handling. The implementation for that only exists in Cygwin and only Cygwin applications are able to deal with them. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: Signal handling in WIN32 console programs
On Fri, Jan 23, 2009 at 05:10:34AM -0500, Corinna Vinschen wrote: On Jan 22 18:05, avade...@certicom.com wrote: On Thu, Jan 22, 2009 at 05:04:23PM -0500, Christopher Faylor wrote: On Thu, Jan 22, 2009 at 09:58:08PM +, Andy Koppe wrote: avade...@certicom.com wrote: 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. Is there something that I could do inside the native application code to catch what it is getting? I've tried SetConsoleCtrlhandler, but that also never gets invoked prior to the process termination. No. The Cygwin tty apps like rxvt and MinTTY are using POSIX signal handling. The implementation for that only exists in Cygwin and only Cygwin applications are able to deal with them. Corinna It seems that it ought to map to something, or else it wouldn't actually do anything. But given that you say I can't do what I'm trying within the posix shell, I suppose I could have the application open its own console (which would be native), and then a Ctrl-C in that window would presumably do what I want. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/ -- 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/
Re: Signal handling in WIN32 console programs
avade...@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. Andy -- 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/
Re: Signal handling in WIN32 console programs
On Thu, Jan 22, 2009 at 09:58:08PM +, Andy Koppe wrote: avade...@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/
Re: Signal handling in WIN32 console programs
On Thu, Jan 22, 2009 at 05:04:23PM -0500, Christopher Faylor wrote: On Thu, Jan 22, 2009 at 09:58:08PM +, Andy Koppe wrote: avade...@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. Is there something that I could do inside the native application code to catch what it is getting? I've tried SetConsoleCtrlhandler, but that also never gets invoked prior to the process termination. 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/ -- 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/
Signal handling in WIN32 console programs
I ran across something under minTTY that I've confirmed behaves the same way in rxvt, but differs under both the native terminal and console2. I expect there is a good reason why this happens, and I'm quite willing to modify the WIN32 app rather than pine for a change in minTTY to accomodate me. But first I need to understand what is really happening and how I could deal with it. 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. If so, is there anything I can do within the WIN32 app to catch what is getting to it from the signal and maintain programmatic control? -- 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/
