This is the mail archive of the
mailing list for the Cygwin project.
Re: Ash spawning win32 programs (was Re: bash/cmd CTRL-C problem...)
----- Original Message -----
From: "Andy Piper" <firstname.lastname@example.org>
> 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)
> does not work (it used to) it is reported as terminated but is still
The script dies quite happily for me. The win32 process doesn't though
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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html