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" <email@example.com>
> Its a console app that happily responds to ^C. If you run it directly
> within bash then ^C works, so I assume from what you say above that
> 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
> (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
> >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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html