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]

Re: SIGINT, bash and non-cygwin apps


A little while back this year, you wrote the following response:

Re: SIGINT, bash and non-cygwin apps
To: Sigbjorn Finne <>,
Subject: Re: SIGINT, bash and non-cygwin apps
From: Earnie Boyd <>
Date: Tue, 18 May 1999 06:56:15 -0700 (PDT)

--- Sigbjorn Finne <> wrote:
> #include <signal.h>
> #include <stdio.h>
> void handler()
> {
>     printf("SIGINT received\n");
>     signal(SIGINT,handler);
> }
> int main()
> {
>     signal(SIGINT,handler);
>     for(;;);
> }
> sa$ gcc -o main-cygwin tst.c
> sa$ gcc -o main-mingw  tst.c -mno-cygwin
> If you run 'main-cygwin' under bash everything is cool, SIGINT is
> repeatedly caught. If you run `main-mingw' though, Ctrl+C delivers the
> signal first time around, but then terminates the application (without
> signalling this to the app, as far as I can gather).
> Running both versions under cmd.exe works as expected - anyone know
> what's the root cause & if there's a work-around or fix for this?

What is the value of the CYGWIN environment variable?  You must set notty or
not specify it at all to communciate properly with non-cygwin programs.  This
must be done before starting bash.
"Earnie Boyd" <>


There was one more email on this thread from the author, Sigbjorn, where he
indicated that his CYGWIN variable was not set.

I too see this SAME exact problem. My CYGWIN variable is not set, but for
kicks and grins I set it to notty. I did this in the Windows NT System Control
Panel (Environment tab) so that it would be set BEFORE BASH ran. I still see
the same exact problem.

I am using Cygwin B20.1:

  CYGWIN_NT-4.0 BASS 20.1 (0.3/1/1) 1998-12-3 20:39:18 i686 unknown

I little while ago, you told me to upgrade the Jan 15 1999 version of the
Cygwin1.dll. I had done this for a while, and then it gave me a new problem
(that I should probably discuss in a different thread of email). Thus, I've
reverted back to the Dec 12, 1998 version of the DLL.

This problem is quite irritating because what happens is that the signal
handler handles signal, but once the signal handler returns, the entire
application exits.

If you run the same (mingw32) binary under a DOS shell instead of a Cygwin
BASH shell, the problem does not occur.

Jon Leichter

Want to unsubscribe from this list?
Send a message to

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