----- Original Message ----- From: "Andy Piper" <[EMAIL PROTECTED]> > > Its a console app that happily responds to ^C. If you run it directly from > within bash then ^C works, so I assume from what you say above that this is > a bug of some description.
Have you tried the latest snapshot and confirmed that this still occurs? If you have not done this then you are _not_ seeing ^C get handled by the application. You are seeing cygwin terminate the process incorrectly (as though Ctrl-Break was hit). > I guess I don't understand why this is expected. It always used to work > (i.e. the subprocess would get killed also). It's expected because win32 programs don't understand cygwin signals. Console programs that appear to understand signals actually get told by the OS when CTRL-C is hit on the console. > >The key question here is : what semantics should apply to a _non signal > >aware program_ when cygwin detects a signal is generated for it? > > > >I.e., to pick a couple, for SIGINT and SIGKILL. > > > >One is obvious, we call (IIRC) TerminateProcess and *boom* it's gone. > >Hope your work was saved. > > Er, why isn't it signal aware. It is AFAIK. I thought this was obvious. Is it linked against cygwin1.dll? No? Then it's not signal aware. Signals are one of the cygwin additions to the win32 platform. Rob -- 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/