This is the mail archive of the
mailing list for the Cygwin project.
Re: bash/cmd CTRL-C problem...
- From: "Michael Rumpf" <michael at rumpfonline dot de>
- To: <cygwin at cygwin dot com>
- Date: Mon, 7 Jan 2002 09:47:59 +0100
- Subject: Re: bash/cmd CTRL-C problem...
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <20020104170443.GD30445@redhat.com>
> Here's the harsh reality: it is extremely unlikely that anyone is going
> to investigate this. If you are using non-cygwin apps with bash and
> CTRL-C doesn't work then you are on your own.
> I will enthusiastically inspect and evaluate any fixes that you provide
> to cygwin to rectify this situation. The fixes must not break current
> CTRL-C behavior with cygwin apps.
> You are one of a handful of people reporting similar problems. Everyone
> seems to be trying to do basically the same thing. They're building
> non-cygwin java apps and complaining that CTRL-C doesn't work right.
It is not a Java app. It is a plain C/C++ app which forks either a C/C++ or
a Java app. You don't have to compile the included Java app, you can just
use the two C/C++ apps to reproduce the problem.
The problem is that the signal handling of the bash is not working correctly
in the C/C++ app which forks others. The CTRL-C (SIGINT) terminates the app
after executing the signal handler in the same way CTRL-BREAK (SIGBREAK)
does but in opposite to the CTRL-BREAK the child processes are not taken
down. The forking app goes into a loop and waits for a flag to be raised
when the SIGINT occurs. But under bash this never happens. The app is always
terminated after handling the signal. After the loop the app tries to send
CTRL-BREAK signals to the child apps and because it is terminated
immediately the code is never reached.
> However, since we are all *cygwin* developers it is not likely that
> we'll want to go to the effort of loading non-cygwin, java software on
> our system to track your problem down for you.
The problem is in a C/C++ app which is linked against Microsoft runtime libs
and the signal handling goes wrong there. First I suspected that it has
something to do with Java but, and that is what the test case shows, it is
independent of it.
I'm "just" use the Cygwin shell environment to have the same shell under NT
as under UNIX. I had a look at how the signal handling in the bash works,
but I found it very complicated and I don't have the time to track it down.
If nobody is interested making non-cygwin apps work the right way under the
bash than I have to use another approach by starting a windows cmd shell to
launch the C/C++ app to make the signal handling work...
The assumption that
> I could be wrong. Maybe
> someone is actively working on this. If so, I hope that person steps
> forward and offers some insight into how they are progressing and what
> their proposed fix might be.
That would of course be great...
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html