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...)
At 10:50 AM 1/12/2002 +1100, Robert Collins wrote:
>Have you tried the latest snapshot and confirmed that this still occurs?
Yes, this is with the latest snapshot. I actually haven't upgraded past
1.3.2 because the problems (like this) get worse from then on (using bash
as /bin/sh being the only solution). I'm just trying to suck your brain dry
while the issues are still clear in your mind :)
> > 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.
So I'm confused. I realise that signals are a cygwin (UNIX) thing but I
thought that they were written in such a way as to Do The Right Thing in
this instance. Certainly my experience has been that the Right Thing
happened at various points in cygwin's history. If you are saying that this
is not the right thing anymore then I can accept that but just want to
> > >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.
Hmn, ok. So shouldn't we just do the same thing as happens under the DOS
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html