This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Ash spawning win32 programs (was Re: bash/cmd CTRL-C problem...)

----- Original Message -----
From: "Andy Piper" <>
> 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
this is
> 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:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]