----- 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?). 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). 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. For the other though, win32's closest generic equivalent is to send a WM_QUIT message to the application. I think that a proof-of-concept application that opens an app by winpid, grabs the top level hwnd for the app, and sends WM_QUIT would provide the basis to integrate such functionality into Cygwin. Until someone (I don't have the time to _volunteer_ for this) writes such as proof-of-concept, this will remain unsolved. 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/