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: bash/cmd CTRL-C problem...

On Mon, 2002-01-07 at 19:47, Michael Rumpf wrote:

> The problem is that the signal handling of the bash is not working correctly
> in the C/C++ app which forks others.

I'm not clear: Is the app that forks others a Cygwin app, or not?

ie: as a process chain is it
bash (cygwin)
app1 (cygwin)
app2 (MS CRT)

or is it
bash (cygwin)
app1 (MS CRT)
app2 (MS CRT)

> 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. 

By this are you implying that this:
app1 (cygwin/MS CRT (see above))
app2 (MS CRT)
behaves as you expect?

> > 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.

> I'm "just" use the Cygwin shell environment to have the same shell under NT
> as under UNIX. 

> 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...

It's not a matter of interest. Developer time spent fixing bugs is much
more effective that developer time spent isolating bugs. If you can
provide clear documentation on whats occuring, then maybe we can fix it.

I for one am not going to contribute 8-16 hours trying to isolate a bug
that doesn't affect me, and that I've no motivation (per se) to solve.

> > 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...

Unfortunately, AFAIK Chris is correct. He's got a pretty good feel what
the 'core' developers are working on :}.

This doesn't affect me, but I'm willing to put a coupla hours in on it -
starting with a clear repeatable test case - which you are part way to


Unsubscribe info:
Bug reporting:

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