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/
