At 01:22 AM 1/12/2002 +1100, Robert Collins wrote: >----- Original Message ----- >From: "Andy Piper" <[EMAIL PROTECTED]> > > > ash script pid reported by shell: 828 > > ash script pid in task manager: 856 > > java pid reported by ps 1640 PPID 828 > > java pid reported by task mnager 1640 > > bash pid 1248 > >Right, so we've got a win32 process, _with no cygwin stub_. This is a >lot harder to solve than the one Chris and I just solved. The >fundamental difference being that when you CTRL-C in the console window, >every attached program recieves a win32 CTRLC interrupt. Your java >program - by virtue of not quitting - is either deliberately ignoring >those interrupts, or is a gui program with a hidden window. (are you >running javaw or javac?).
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. >For console programs, the CTRL-C in the window should work fine. kill >(script) won't work (because no keyboard interrupt is generated). > > > BTW with the script started in the background (or indeed fg and ^Z) >kill %1 > > does not work (it used to) it is reported as terminated but is still >running. > >The script dies quite happily for me. The win32 process doesn't though >(as expected). I guess I don't understand why this is expected. It always used to work (i.e. the subprocess would get killed also). >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. 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/
