From mboxrd@z Thu Jan 1 00:00:00 1970 From: Troy Noble To: "'cygwin@cygwin.com'" Subject: RE: broken CTRL-BREAK handling Date: Wed, 18 Jul 2001 12:55:00 -0000 Message-id: <8F23E55D511AD5119A6800D0B76FDDE1CA2EF7@cpex3.channelpoint.com> X-SW-Source: 2001-07/msg01062.html > I don't think that that has ever been a stated goal for cygwin. That would explain why it has been a non-issue for most folks. The only product I've ever used on windows that relies no CTRL_BREAK is Sun's JVM. Oh, and then there's MKS Toolkit's ksh of course (no, not the M word!). Maybe there are other products out there that rely on ctrl handler, but I suspect it would be rare due to the flakiness of the console event handling model. Maybe zsh, tcsh, etc? > What would a program, ported from UNIX expect in this situation? With > your patch, I believe that it would just unceremoniously terminate with > no way to handle cleanup other than to add windows-specific code for > dealing with ctrl-break. Agreed. However, if CYGWIN=ttl is set they would be fine since ctrl_c_handler is not en force with that configuration. If they did not use CYGWIN=ttl and pressed CTRL-BREAK the default handler provided by Win32 would kick in and terminate the program as soon as your ctrl_c_handler returned FALSE. Yet another argument indicating the crippled nature of the whole console control handler CTRL_*_EVENT model. Seems like the ideal situation, which I don't think the Win32 API would let you do, would be: 1. inside ctrl_c_handler check if there is something other than the default CtrlHandler and your ctrl_c_handler. This would definitely be the case for the JVM, but not for unix-ported apps. 2. if not, do a SIGTERM within ctrl_c_handler just like you do today. Which means CTRL_BREAK == CTRL_C. 3. if so return FALSE in ctrl_c_handler if type==CTRL_BREAK_EVENT, that way the other app-specific control handler would still get called. The Win32 does not have a GetConsoleCtrlHandler or GetConsoleCtrlHandlers function, so #1 would not be possible if I read the API docs correctly. Stalemate. You've probably thought this through already. Anyway, given these limitations, it's probably better to live with the evil you know rather than introduce an evil you don't. Yet another argument for withdrawing my CTRL_BREAK proposal. Thanks, Troy -----Original Message----- From: Christopher Faylor [ mailto:cgf@redhat.com ] Sent: Wednesday, July 18, 2001 10:56 AM To: cygwin@cygwin.com Subject: Re: broken CTRL-BREAK handling On Wed, Jul 18, 2001 at 10:32:35AM -0600, Troy Noble wrote: >Bottom line... that still feels broken to me if the intent is for >cygwin (more specifically, the bash shell running with cygwin) to >be able to launch/stop native win32 apps with the same semantics one >has come to expect when running cmd shell. >If that's not the goal, then it's a non-issue. I don't think that that has ever been a stated goal for cygwin. What would a program, ported from UNIX expect in this situation? With your patch, I believe that it would just unceremoniously terminate with no way to handle cleanup other than to add windows-specific code for dealing with ctrl-break. cgf -- 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/ -- 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/