| www.delorie.com/archives/browse.cgi | search |
At 10:50 AM 1/12/2002 +1100, Robert Collins wrote: >Have you tried the latest snapshot and confirmed that this still occurs? Yes, this is with the latest snapshot. I actually haven't upgraded past 1.3.2 because the problems (like this) get worse from then on (using bash as /bin/sh being the only solution). I'm just trying to suck your brain dry while the issues are still clear in your mind :) > > 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. So I'm confused. I realise that signals are a cygwin (UNIX) thing but I thought that they were written in such a way as to Do The Right Thing in this instance. Certainly my experience has been that the Right Thing happened at various points in cygwin's history. If you are saying that this is not the right thing anymore then I can accept that but just want to understand why. > > >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. Hmn, ok. So shouldn't we just do the same thing as happens under the DOS console? andy -- 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/
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |