Re: bash/cmd CTRL-C problem...

Re: bash/cmd CTRL-C problem...

[Gregory W. Bond]

Michael,

This may be related to a problem that prevents the cygwin bash shell
from propagating ^C to Win32 child processes. This is a bug/feature of
the cygwin bash shell. See the threads at
http://cygwin.com/ml/cygwin/2001-11/msg01579.html and
http://www.cygwin.com/ml/cygwin/2001-08/msg01111.html for discussions of
this problem. I've also included some message excerpts that didn't make
it onto the cywin mailing list that provide some insight into the
rationale for the bug/feature.

Greg.

Charlie wrote:

> Hi,
>
> I submitted some additional posts, along with some stuff from another guy
> that had a pretty good clue what was going on. search for my email address
> as I haven't posted that much to the list so you shouldn't have to pick
> through too much. I'd send you a copy but its not handy at the moment. Let
> me know if you can't find it and I'll see if I can't dig some of them up.
>
> The bottom line is that cygwin/bash executes win32 executables by spawning
> off another bash shell and running the win32 app inside it. Any signals
> generated are received by the bash shell and not the win32 app. If your
> running Win2k run the task manager, compare to the "ps" command in cygwin,
> look at the process IDs, and you'll see this. So the control C kills the
> bash shell and the win32 app at the same time, hence any cleanup/destructors
> never get to finish, assuming they even got to start.
>
> According to the guy I was exchanging info with, who knew a lot more about
> the internals of cygwin, this is a feature that actually lets cygwin run DOS
> applications, and is not something to be "fixed". Given my lack of knowledge
> of the internals, I can argue with that :-)
>
> VR, Charlie
>



Troy Noble wrote:

> And just to be clear, you did set CYGWIN=tty before starting bash per the
> FAQ?
> I just have to double check to be sure.  If you already know this, just
> ignore.
> The best way to ensure this is to start a cmd.exe, type set CYGWIN=tty or
> set CYGWIN= as desired, and then \cygwin\bin\bash.exe.  Or you can set
> CYGWIN
> in your NT environment, logout, and login.  Or edit your cygwin.bat file to
> do
> it before it invokes "bash --login -i".  Any of those options work equally
> well.
> The key is that you do not want to set it in your .bashrc because by then it
> is
> too late because the process initialization has already been done.  The FAQ
> talks
> about this some more.
>

Michael wrote:

> Hi Corinna,
>
> thanks for the answer. No I haven't tried such an option as I must admit
> that I don't know about it.
> I will search for it in the docs and try to play around with it...
>
> Michael
>
>
> On Fri, 2001-12-21 at 16:24, Corinna Vinschen wrote:
> > On Fri, Dec 21, 2001 at 11:09:05AM +0100, Michael Rumpf wrote:
> > > Am I the only one having problems with this, or is this simply the wrong
> > > list to ask a question about the Cygwin bash... ??
> >
> > Nah, this is the right list.  Nobody has an answer, though.
> >
> > Did you try `CYGWIN=... tty ...' setting?
> >
> > Corinna
> >
> > >
> > > Michael
> > >
> > > ----- Original Message -----
> > > From: "Michael Rumpf"
> > > To:
> > > Sent: Thursday, December 20, 2001 10:11 AM
> > > Subject: Re: bash/cmd CTRL-C problem...
> > >
> > >
> > > > Hi,
> > > >
> > > > sorry for following up myself, but I found out that Cygwin equally handles
> > > > CTRL-BREAK and CTRL-C by sending a SIGINT to the process.
> > > > See http://groups.yahoo.com/group/gnu-win32/message/27643 (last sentence).
> > > > This seems to be the source of the problem.
> > > > CTRL-BREAK under the cmd shell terminates the process after handling the
> > > > signal without further executing any code. The bad thing is that under
> > > bash
> > > > the same behaviour follows from pressing CTRL-BREAK  _and_ CTRL-C !!
> > > >
> > > > If this is a design issue, can someone please explain what the reasons
> > > > are...
> > > >
> > > > We have an application that forks other processes. The main thread is
> > > > waiting for the signal handler to return in order to cleanly stop the
> > > child
> > > > processes. By just stopping the parent process the child processes keep
> > > > running and I have to kill them manually each time I press CTRL-C. The
> > > same
> > > > application is working fine under windows cmd shell and bash under Linux ,
> > > > HP-UX 10/11, AIX4.x, and SunOS 2.5+...
> > > >
> > > > Please help, I don't want to use the stupid windows cmd shell.... ;-)
> > > >
> > > > Michael
> > > >
> > > > ----- Original Message -----
> > > > From: "Michael Rumpf"
> > > > To:
> > > > Sent: Thursday, December 20, 2001 7:47 AM
> > > > Subject: bash/cmd CTRL-C problem...
> > > >
> > > >
> > > > > Hi,
> > > > >
> > > > > I'm new to the list and I don't know if this problem is already solved,
> > > > but
> > > > > I couldn't find a hint neither on the archives nor on the FAQ or
> > > somewhere
> > > > > else on the net.
> > > > >
> > > > > My problem is related to bash/cmd and signal handling.
> > > > > In my app I installed a signal handler for SIGINT. The app is going into
> > > a
> > > > > wait loop and waiting for the exit flag from the signal handler to be
> > > set.
> > > > >
> > > > > When pressing CTRL-C in the windows cmd shell the application continues
> > > > > normally after the signal handler has been caught. Under bash the signal
> > > > > handler is also correctly called, but after that the app is exiting
> > > > > immediatly, i.e. not continuing with the code.
> > > > > Here is the source:
> > > > >
> > > > >
> > > >
> > > ////////////////////////////////////////////////////////////////////////////
> > > > > /////////////////
> > > > > #include
> > > > > #include
> > > > > #include
> > > > >
> > > > > bool loop = true;
> > > > >
> > > > > extern "C" void signalHandler(int sig)
> > > > > {
> > > > >    switch( sig )
> > > > >    {
> > > > >       case SIGINT:  // == 2
> > > > >          printf("SIGINT=%d\n",sig);
> > > > >          break;
> > > > >       default:
> > > > >          printf("default=%d\n",sig);
> > > > >          break;
> > > > >    };
> > > > >    loop=false;
> > > > > }
> > > > >
> > > > > int main(int argc, char* argv[])
> > > > > {
> > > > >    if (signal( SIGINT , signalHandler ) == SIG_ERR)
> > > > >       return -1;
> > > > >    printf("### ctrlbreak: Waiting now...\n");
> > > > >    while(loop)
> > > > >      Sleep ((DWORD) 1000) ;
> > > > >    printf("### ctrlbreak: Finished waiting now...\n");
> > > > >    return 0;
> > > > > }
> > > > >
> > > >
> > > ////////////////////////////////////////////////////////////////////////////
> > > > > /////////////////
> > > > >
> > > > > Here the the output of the app under Win2K/bash:
> > > > > // bash                2.05a-2
> > > > > $ ./ctrlbreak.exe
> > > > > ### ctrlbreak: Waiting now...
> > > > > SIGINT=2
> > > > >
> > > > >
> > > > > // GNU bash, version 2.02.1(2)-release (i586-pc-cygwin32) B20.1
> > > > > bash-2.02$ ./ctrlbreak
> > > > > ### ctrlbreak: Waiting now...
> > > > > SIGINT=2
> > > > >
> > > > > // cmd.exe Win2k SP2
> > > > > ### ctrlbreak: Waiting now...
> > > > > SIGINT=2
> > > > > ### ctrlbreak: Finished waiting now...
> > > > >
> > > > >
> > > > > You can see that under the cmd shell the text "Finished waiting now..."
> > > is
> > > > > printed which does not come out under the bash. The app is not linked
> > > > > against any cygwin library. It is a plain VC++ console application. But
> > > > when
> > > > > I compile with gcc from the cygwin package I have the same result.
> > > > > Any hint would be greatly appreciated...
> > > > >
> > > > > Michael
> > > > >
> > > > > PS: I just downloaded the latest stable version 1.3.6 today...
>
--
Gregory W. Bond
AT&T Labs - Research
180 Park Avenue, Rm. D273, Bldg. 103
P.O. Box 971, Florham Park, NJ, 07932-0971, USA
tel: (973) 360 7216 fax: (973) 360 8187



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Michael Rumpf]

Hi Gregory,

thanks for the info.

> This may be related to a problem that prevents the cygwin bash shell
> from propagating ^C to Win32 child processes. This is a bug/feature of
> the cygwin bash shell. See the threads at
> http://cygwin.com/ml/cygwin/2001-11/msg01579.html and
> http://www.cygwin.com/ml/cygwin/2001-08/msg01111.html for discussions of
> this problem. I've also included some message excerpts that didn't make
> it onto the cywin mailing list that provide some insight into the
> rationale for the bug/feature.

There seem to be two problems/features:
1. CTRL-C is not propagated to child processes.
2. Execution of the application is not continued after the CTRL-C signal is
handled.

Both problems seem to happen only when applications are linked against the
MS crt libs and run under the bash.
However, I can't believe that my problem (2nd) is seen as a feature. The
bash behaves differently under Win32 and under any UNIX environment I'm
using here (AIX, HPUX, Solaris, Linux). There I can just press CTRL-C and
the main/parent process receives a SIGINT, sets a flag in the signal
handler, continues execution at the point where it was interrupted and thus
causes the main process to send CTRL-BREAK events to its children. For this
to happen the application code must continue its execution rather than
stopping after handling the signal. The correct behaviour can also be seen
in cmd.exe and I believe in bash when your app is linked against the cygwin
libs (I did not try this yet because it is no option for our application
server launcher program). So the only case where the behaviour is different
is when you have an app linked against the MS crt libs which is running
under the bash. I wouldn't see this as a feature I would see this as a
bug....

Michael

> Greg.
>
> Charlie wrote:
>
> > Hi,
> >
> > I submitted some additional posts, along with some stuff from another
guy
> > that had a pretty good clue what was going on. search for my email
address
> > as I haven't posted that much to the list so you shouldn't have to pick
> > through too much. I'd send you a copy but its not handy at the moment.
Let
> > me know if you can't find it and I'll see if I can't dig some of them
up.
> >
> > The bottom line is that cygwin/bash executes win32 executables by
spawning
> > off another bash shell and running the win32 app inside it. Any signals
> > generated are received by the bash shell and not the win32 app. If your
> > running Win2k run the task manager, compare to the "ps" command in
cygwin,
> > look at the process IDs, and you'll see this. So the control C kills the
> > bash shell and the win32 app at the same time, hence any
cleanup/destructors
> > never get to finish, assuming they even got to start.
> >
> > According to the guy I was exchanging info with, who knew a lot more
about
> > the internals of cygwin, this is a feature that actually lets cygwin run
DOS
> > applications, and is not something to be "fixed". Given my lack of
knowledge
> > of the internals, I can argue with that :-)
> >
> > VR, Charlie
> >
>
>
>
> Troy Noble wrote:
>
> > And just to be clear, you did set CYGWIN=tty before starting bash per
the
> > FAQ?
> > I just have to double check to be sure.  If you already know this, just
> > ignore.
> > The best way to ensure this is to start a cmd.exe, type set CYGWIN=tty
or
> > set CYGWIN= as desired, and then \cygwin\bin\bash.exe.  Or you can set
> > CYGWIN
> > in your NT environment, logout, and login.  Or edit your cygwin.bat file
to
> > do
> > it before it invokes "bash --login -i".  Any of those options work
equally
> > well.
> > The key is that you do not want to set it in your .bashrc because by
then it
> > is
> > too late because the process initialization has already been done.  The
FAQ
> > talks
> > about this some more.
> >
>
> Michael wrote:
>
> > Hi Corinna,
> >
> > thanks for the answer. No I haven't tried such an option as I must admit
> > that I don't know about it.
> > I will search for it in the docs and try to play around with it...
> >
> > Michael
> >
> >
> > On Fri, 2001-12-21 at 16:24, Corinna Vinschen wrote:
> > > On Fri, Dec 21, 2001 at 11:09:05AM +0100, Michael Rumpf wrote:
> > > > Am I the only one having problems with this, or is this simply the
wrong
> > > > list to ask a question about the Cygwin bash... ??
> > >
> > > Nah, this is the right list.  Nobody has an answer, though.
> > >
> > > Did you try `CYGWIN=... tty ...' setting?
> > >
> > > Corinna
> > >
> > > >
> > > > Michael
> > > >
> > > > ----- Original Message -----
> > > > From: "Michael Rumpf"
> > > > To:
> > > > Sent: Thursday, December 20, 2001 10:11 AM
> > > > Subject: Re: bash/cmd CTRL-C problem...
> > > >
> > > >
> > > > > Hi,
> > > > >
> > > > > sorry for following up myself, but I found out that Cygwin equally
handles
> > > > > CTRL-BREAK and CTRL-C by sending a SIGINT to the process.
> > > > > See http://groups.yahoo.com/group/gnu-win32/message/27643 (last
sentence).
> > > > > This seems to be the source of the problem.
> > > > > CTRL-BREAK under the cmd shell terminates the process after
handling the
> > > > > signal without further executing any code. The bad thing is that
under
> > > > bash
> > > > > the same behaviour follows from pressing CTRL-BREAK  _and_ CTRL-C
!!
> > > > >
> > > > > If this is a design issue, can someone please explain what the
reasons
> > > > > are...
> > > > >
> > > > > We have an application that forks other processes. The main thread
is
> > > > > waiting for the signal handler to return in order to cleanly stop
the
> > > > child
> > > > > processes. By just stopping the parent process the child processes
keep
> > > > > running and I have to kill them manually each time I press CTRL-C.
The
> > > > same
> > > > > application is working fine under windows cmd shell and bash under
Linux ,
> > > > > HP-UX 10/11, AIX4.x, and SunOS 2.5+...
> > > > >
> > > > > Please help, I don't want to use the stupid windows cmd shell....
;-)
> > > > >
> > > > > Michael
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Michael Rumpf"
> > > > > To:
> > > > > Sent: Thursday, December 20, 2001 7:47 AM
> > > > > Subject: bash/cmd CTRL-C problem...
> > > > >
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I'm new to the list and I don't know if this problem is already
solved,
> > > > > but
> > > > > > I couldn't find a hint neither on the archives nor on the FAQ or
> > > > somewhere
> > > > > > else on the net.
> > > > > >
> > > > > > My problem is related to bash/cmd and signal handling.
> > > > > > In my app I installed a signal handler for SIGINT. The app is
going into
> > > > a
> > > > > > wait loop and waiting for the exit flag from the signal handler
to be
> > > > set.
> > > > > >
> > > > > > When pressing CTRL-C in the windows cmd shell the application
continues
> > > > > > normally after the signal handler has been caught. Under bash
the signal
> > > > > > handler is also correctly called, but after that the app is
exiting
> > > > > > immediatly, i.e. not continuing with the code.
> > > > > > Here is the source:
> > > > > >
> > > > > >
> > > > >
> > > >
////////////////////////////////////////////////////////////////////////////
> > > > > > /////////////////
> > > > > > #include
> > > > > > #include
> > > > > > #include
> > > > > >
> > > > > > bool loop = true;
> > > > > >
> > > > > > extern "C" void signalHandler(int sig)
> > > > > > {
> > > > > >    switch( sig )
> > > > > >    {
> > > > > >       case SIGINT:  // == 2
> > > > > >          printf("SIGINT=%d\n",sig);
> > > > > >          break;
> > > > > >       default:
> > > > > >          printf("default=%d\n",sig);
> > > > > >          break;
> > > > > >    };
> > > > > >    loop=false;
> > > > > > }
> > > > > >
> > > > > > int main(int argc, char* argv[])
> > > > > > {
> > > > > >    if (signal( SIGINT , signalHandler ) == SIG_ERR)
> > > > > >       return -1;
> > > > > >    printf("### ctrlbreak: Waiting now...\n");
> > > > > >    while(loop)
> > > > > >      Sleep ((DWORD) 1000) ;
> > > > > >    printf("### ctrlbreak: Finished waiting now...\n");
> > > > > >    return 0;
> > > > > > }
> > > > > >
> > > > >
> > > >
////////////////////////////////////////////////////////////////////////////
> > > > > > /////////////////
> > > > > >
> > > > > > Here the the output of the app under Win2K/bash:
> > > > > > // bash                2.05a-2
> > > > > > $ ./ctrlbreak.exe
> > > > > > ### ctrlbreak: Waiting now...
> > > > > > SIGINT=2
> > > > > >
> > > > > >
> > > > > > // GNU bash, version 2.02.1(2)-release (i586-pc-cygwin32) B20.1
> > > > > > bash-2.02$ ./ctrlbreak
> > > > > > ### ctrlbreak: Waiting now...
> > > > > > SIGINT=2
> > > > > >
> > > > > > // cmd.exe Win2k SP2
> > > > > > ### ctrlbreak: Waiting now...
> > > > > > SIGINT=2
> > > > > > ### ctrlbreak: Finished waiting now...
> > > > > >
> > > > > >
> > > > > > You can see that under the cmd shell the text "Finished waiting
now..."
> > > > is
> > > > > > printed which does not come out under the bash. The app is not
linked
> > > > > > against any cygwin library. It is a plain VC++ console
application. But
> > > > > when
> > > > > > I compile with gcc from the cygwin package I have the same
result.
> > > > > > Any hint would be greatly appreciated...
> > > > > >
> > > > > > Michael
> > > > > >
> > > > > > PS: I just downloaded the latest stable version 1.3.6 today...
> >
> --
> Gregory W. Bond
> AT&T Labs - Research
> 180 Park Avenue, Rm. D273, Bldg. 103
> P.O. Box 971, Florham Park, NJ, 07932-0971, USA
> tel: (973) 360 7216 fax: (973) 360 8187
>
>
>
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
>


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Gregory W. Bond]

Michael,

I agree that this behavior should be considered a bug since the bash cygwin
behavior differs from bash behavior on other unix platforms. This has caused
headaches for our project too.

Greg.

For the record, here is a very simple java test program that I sent to Troy when
we discussed this problem last November. This program simply intercepts CTL-C
and runs a shutdown hook prior to shutting down the Java VM. It works fine under
cmd.exe and cygwin ash, but does not work under cygwin bash.

public static void main(String[] argv) {

  Runtime.getRuntime().addShutdownHook(new Thread(new Shutdown(), "Shutdown"));
  Object waitingPlace = new Object();
  synchronized(waitingPlace) {
   try {
    waitingPlace.wait();
   } catch (InterruptedException e) {}
  }
 }
 private static class Shutdown implements Runnable {

  public void run() {
   System.out.println("ProcessManager - shutting down...");
  }
 }
}


Michael Rumpf wrote:

> Hi Gregory,
>
> thanks for the info.
>
> > This may be related to a problem that prevents the cygwin bash shell
> > from propagating ^C to Win32 child processes. This is a bug/feature of
> > the cygwin bash shell. See the threads at
> > http://cygwin.com/ml/cygwin/2001-11/msg01579.html and
> > http://www.cygwin.com/ml/cygwin/2001-08/msg01111.html for discussions of
> > this problem. I've also included some message excerpts that didn't make
> > it onto the cywin mailing list that provide some insight into the
> > rationale for the bug/feature.
>
> There seem to be two problems/features:
> 1. CTRL-C is not propagated to child processes.
> 2. Execution of the application is not continued after the CTRL-C signal is
> handled.
>
> Both problems seem to happen only when applications are linked against the
> MS crt libs and run under the bash.
> However, I can't believe that my problem (2nd) is seen as a feature. The
> bash behaves differently under Win32 and under any UNIX environment I'm
> using here (AIX, HPUX, Solaris, Linux). There I can just press CTRL-C and
> the main/parent process receives a SIGINT, sets a flag in the signal
> handler, continues execution at the point where it was interrupted and thus
> causes the main process to send CTRL-BREAK events to its children. For this
> to happen the application code must continue its execution rather than
> stopping after handling the signal. The correct behaviour can also be seen
> in cmd.exe and I believe in bash when your app is linked against the cygwin
> libs (I did not try this yet because it is no option for our application
> server launcher program). So the only case where the behaviour is different
> is when you have an app linked against the MS crt libs which is running
> under the bash. I wouldn't see this as a feature I would see this as a
> bug....
>
> Michael
>
> > Greg.
> >
> > Charlie wrote:
> >
> > > Hi,
> > >
> > > I submitted some additional posts, along with some stuff from another
> guy
> > > that had a pretty good clue what was going on. search for my email
> address
> > > as I haven't posted that much to the list so you shouldn't have to pick
> > > through too much. I'd send you a copy but its not handy at the moment.
> Let
> > > me know if you can't find it and I'll see if I can't dig some of them
> up.
> > >
> > > The bottom line is that cygwin/bash executes win32 executables by
> spawning
> > > off another bash shell and running the win32 app inside it. Any signals
> > > generated are received by the bash shell and not the win32 app. If your
> > > running Win2k run the task manager, compare to the "ps" command in
> cygwin,
> > > look at the process IDs, and you'll see this. So the control C kills the
> > > bash shell and the win32 app at the same time, hence any
> cleanup/destructors
> > > never get to finish, assuming they even got to start.
> > >
> > > According to the guy I was exchanging info with, who knew a lot more
> about
> > > the internals of cygwin, this is a feature that actually lets cygwin run
> DOS
> > > applications, and is not something to be "fixed". Given my lack of
> knowledge
> > > of the internals, I can argue with that :-)
> > >
> > > VR, Charlie
> > >
> >
> >
> >
> > Troy Noble wrote:
> >
> > > And just to be clear, you did set CYGWIN=tty before starting bash per
> the
> > > FAQ?
> > > I just have to double check to be sure.  If you already know this, just
> > > ignore.
> > > The best way to ensure this is to start a cmd.exe, type set CYGWIN=tty
> or
> > > set CYGWIN= as desired, and then \cygwin\bin\bash.exe.  Or you can set
> > > CYGWIN
> > > in your NT environment, logout, and login.  Or edit your cygwin.bat file
> to
> > > do
> > > it before it invokes "bash --login -i".  Any of those options work
> equally
> > > well.
> > > The key is that you do not want to set it in your .bashrc because by
> then it
> > > is
> > > too late because the process initialization has already been done.  The
> FAQ
> > > talks
> > > about this some more.
> > >
> >
> > Michael wrote:
> >
> > > Hi Corinna,
> > >
> > > thanks for the answer. No I haven't tried such an option as I must admit
> > > that I don't know about it.
> > > I will search for it in the docs and try to play around with it...
> > >
> > > Michael
> > >
> > >
> > > On Fri, 2001-12-21 at 16:24, Corinna Vinschen wrote:
> > > > On Fri, Dec 21, 2001 at 11:09:05AM +0100, Michael Rumpf wrote:
> > > > > Am I the only one having problems with this, or is this simply the
> wrong
> > > > > list to ask a question about the Cygwin bash... ??
> > > >
> > > > Nah, this is the right list.  Nobody has an answer, though.
> > > >
> > > > Did you try `CYGWIN=... tty ...' setting?
> > > >
> > > > Corinna
> > > >
> > > > >
> > > > > Michael
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Michael Rumpf"
> > > > > To:
> > > > > Sent: Thursday, December 20, 2001 10:11 AM
> > > > > Subject: Re: bash/cmd CTRL-C problem...
> > > > >
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > sorry for following up myself, but I found out that Cygwin equally
> handles
> > > > > > CTRL-BREAK and CTRL-C by sending a SIGINT to the process.
> > > > > > See http://groups.yahoo.com/group/gnu-win32/message/27643 (last
> sentence).
> > > > > > This seems to be the source of the problem.
> > > > > > CTRL-BREAK under the cmd shell terminates the process after
> handling the
> > > > > > signal without further executing any code. The bad thing is that
> under
> > > > > bash
> > > > > > the same behaviour follows from pressing CTRL-BREAK  _and_ CTRL-C
> !!
> > > > > >
> > > > > > If this is a design issue, can someone please explain what the
> reasons
> > > > > > are...
> > > > > >
> > > > > > We have an application that forks other processes. The main thread
> is
> > > > > > waiting for the signal handler to return in order to cleanly stop
> the
> > > > > child
> > > > > > processes. By just stopping the parent process the child processes
> keep
> > > > > > running and I have to kill them manually each time I press CTRL-C.
> The
> > > > > same
> > > > > > application is working fine under windows cmd shell and bash under
> Linux ,
> > > > > > HP-UX 10/11, AIX4.x, and SunOS 2.5+...
> > > > > >
> > > > > > Please help, I don't want to use the stupid windows cmd shell....
> ;-)
> > > > > >
> > > > > > Michael
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Michael Rumpf"
> > > > > > To:
> > > > > > Sent: Thursday, December 20, 2001 7:47 AM
> > > > > > Subject: bash/cmd CTRL-C problem...
> > > > > >
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I'm new to the list and I don't know if this problem is already
> solved,
> > > > > > but
> > > > > > > I couldn't find a hint neither on the archives nor on the FAQ or
> > > > > somewhere
> > > > > > > else on the net.
> > > > > > >
> > > > > > > My problem is related to bash/cmd and signal handling.
> > > > > > > In my app I installed a signal handler for SIGINT. The app is
> going into
> > > > > a
> > > > > > > wait loop and waiting for the exit flag from the signal handler
> to be
> > > > > set.
> > > > > > >
> > > > > > > When pressing CTRL-C in the windows cmd shell the application
> continues
> > > > > > > normally after the signal handler has been caught. Under bash
> the signal
> > > > > > > handler is also correctly called, but after that the app is
> exiting
> > > > > > > immediatly, i.e. not continuing with the code.
> > > > > > > Here is the source:
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> ////////////////////////////////////////////////////////////////////////////
> > > > > > > /////////////////
> > > > > > > #include
> > > > > > > #include
> > > > > > > #include
> > > > > > >
> > > > > > > bool loop = true;
> > > > > > >
> > > > > > > extern "C" void signalHandler(int sig)
> > > > > > > {
> > > > > > >    switch( sig )
> > > > > > >    {
> > > > > > >       case SIGINT:  // == 2
> > > > > > >          printf("SIGINT=%d\n",sig);
> > > > > > >          break;
> > > > > > >       default:
> > > > > > >          printf("default=%d\n",sig);
> > > > > > >          break;
> > > > > > >    };
> > > > > > >    loop=false;
> > > > > > > }
> > > > > > >
> > > > > > > int main(int argc, char* argv[])
> > > > > > > {
> > > > > > >    if (signal( SIGINT , signalHandler ) == SIG_ERR)
> > > > > > >       return -1;
> > > > > > >    printf("### ctrlbreak: Waiting now...\n");
> > > > > > >    while(loop)
> > > > > > >      Sleep ((DWORD) 1000) ;
> > > > > > >    printf("### ctrlbreak: Finished waiting now...\n");
> > > > > > >    return 0;
> > > > > > > }
> > > > > > >
> > > > > >
> > > > >
> ////////////////////////////////////////////////////////////////////////////
> > > > > > > /////////////////
> > > > > > >
> > > > > > > Here the the output of the app under Win2K/bash:
> > > > > > > // bash                2.05a-2
> > > > > > > $ ./ctrlbreak.exe
> > > > > > > ### ctrlbreak: Waiting now...
> > > > > > > SIGINT=2
> > > > > > >
> > > > > > >
> > > > > > > // GNU bash, version 2.02.1(2)-release (i586-pc-cygwin32) B20.1
> > > > > > > bash-2.02$ ./ctrlbreak
> > > > > > > ### ctrlbreak: Waiting now...
> > > > > > > SIGINT=2
> > > > > > >
> > > > > > > // cmd.exe Win2k SP2
> > > > > > > ### ctrlbreak: Waiting now...
> > > > > > > SIGINT=2
> > > > > > > ### ctrlbreak: Finished waiting now...
> > > > > > >
> > > > > > >
> > > > > > > You can see that under the cmd shell the text "Finished waiting
> now..."
> > > > > is
> > > > > > > printed which does not come out under the bash. The app is not
> linked
> > > > > > > against any cygwin library. It is a plain VC++ console
> application. But
> > > > > > when
> > > > > > > I compile with gcc from the cygwin package I have the same
> result.
> > > > > > > Any hint would be greatly appreciated...
> > > > > > >
> > > > > > > Michael
> > > > > > >
> > > > > > > PS: I just downloaded the latest stable version 1.3.6 today...
> > >

--
Gregory W. Bond
AT&T Labs - Research
180 Park Avenue, Rm. D273, Bldg. 103
P.O. Box 971, Florham Park, NJ, 07932-0971, USA
tel: (973) 360 7216 fax: (973) 360 8187



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Michael Rumpf]

> For the record, here is a very simple java test program that I sent to
Troy when
> we discussed this problem last November. This program simply intercepts
CTL-C
> and runs a shutdown hook prior to shutting down the Java VM. It works fine
under
> cmd.exe and cygwin ash, but does not work under cygwin bash.

In my test case (myclass.java) I also added a shutdown hook but this app is
spawned as a child process from signals.exe with the CREATE_PROCESS_GROUP
flag enabled. This causes the Win32 kernel to call SetConsoleCtrlHandler on
behalf of the CreateProcess call and disable the CTRL-C handler (See the
MSDN entry for CreateProcess). Therefore child apps can only be killed  by
sending a CTRL-BREAK event. The effect on this is that the VM does not call
the shutdown hooks (And you have to call java with the -Xrs parameter
otherwise you will see just a thread dump of your child process)....

So I see your problem. We are currently not using any Shutdown hooks in our
Java services, but I suspect that we might be in the future and then we will
run into the same troubles you are facing today...

So I'm definitely interested in a solution of your problem as well....

Michael



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Christopher Faylor]

On Mon, Jan 07, 2002 at 12:08:51PM -0500, Gregory W. Bond wrote:
>I agree that this behavior should be considered a bug since the bash
>cygwin behavior differs from bash behavior on other unix platforms.
>This has caused headaches for our project too.

Hmm.  How does bash on "other unix platforms" deal with programs that
are not compiled for the specific platform?  We are talking about a
cygwin app calling a non-cygwin app.  There is no analogue in unix land.

>For the record, here is a very simple java test program that I sent to
>Troy when we discussed this problem last November.  This program simply
>intercepts CTL-C and runs a shutdown hook prior to shutting down the
>Java VM.  It works fine under cmd.exe and cygwin ash, but does not work
>under cygwin bash.

If you think it's a bug and it causes headaches for your project then
why not invest time in providing a fix?  It must be obvious by now that
the problem isn't going to be fixed unless someone who is experiencing
it takes time to fix it.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Andy Piper]

Chris Faylor wrote:

>There is a snapshot up there now which seems to work ok.
>
>Again, many thanks to Robert Collins for tracking this down.
>
>Although I said I wasn't overly interested in tracking this down
>myself, I was interested in seeing the lessening in email traffic that I
>hope this fix engenders.
>
>I do expect that, when this cygwin DLL is released, there could be a
>reaction from another, previously silent camp who relied on the old
>CTRL-C behavior.  I guess it will be interesting to see if that is the
>case.

Many thanks for looking at this. While the iron is hot - this problem is 
still outstanding and I don't know whether you would expect this to be 
fixed also:

Interactive bash shell starts:
         -> shell script using ash starts:
                 -> java program

^C-ing the script does not have any visible effect (i.e. the java program 
is not killed). As noted previously this problem is resolved if you make 
/bin/sh be bash rather than ash.

Thanks

andy


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Christopher Faylor]

On Thu, Jan 10, 2002 at 06:59:54PM +1100, Robert Collins wrote:
>> I was going back over this thread before checking in a change to see if
>> I'd missed something.
>>
>> I just realized that I didn't address this concern.  Don't know if it
>> matters but...
>>
>> The difference between the SIG_IGN way and the "return TRUE" way is
>> that the SIG_IGN way stops the current process from responding to
>> a cygwin signal but still lets it respond to a Windows "signal".  That
>> means that the code in ctrl_c_handle can do its job, if it has to.
>
>Huh? I actually did the reverse - returning TRUE only prevented
>responding to a windows signal, but allowed responding to a cygwin
>signal.

Yep.  Wrong behavior.  The stub should respond to windows signals
while the child is initializing.  Remember this discussion?

>>If we always "return TRUE" in the exec case, then there will be some
>>situations where the SIGINT is not delivered to the rest of the process
>>group since the code in ctrl_c_handler would be short circuited.
>
>I don't believe that is the case: Every console process attached to
>that console independently recieves the windows signal.  Only one has
>been disabled.  So the execing process's children will still recieve
>the windows signals and the cygwin signals.

The newly executed subprocess may not have yet set up ctrl_c_handler so
it will not do anything but die when CTRL-C comes in.  The stub will
ignore the CTRL-C.  That means that the rest of the processes in the
process group will not receive a CTRL-C.

>> My SIG_IGN "solution" is wrong, too, though.  The SIG_IGN would be
>> inherited by the exec'ed process.  Then the execed process would never
>> see a cygwin SIGINT signal.
>
>Yes. I still believe that return TRUE is a good solution... but if
>you've solved the obvious behaviour I'll be quite now :}.

I guess I'm having a hard time understanding why I couldn't just say
"race" and have you understand that there is a race but I'll stop
now, too.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Robert Collins]

===
----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>
To: <cygwin@cygwin.com>
Sent: Thursday, January 10, 2002 1:46 PM
Subject: Re: bash/cmd CTRL-C problem...


> On Wed, Jan 09, 2002 at 12:16:04PM +1100, Robert Collins wrote:
> >----- Original Message -----
> >From: "Christopher Faylor" <cgf@redhat.com>
> >>I'm specifically trying not to do the "TRUE" thing, though, since
> >>AFAICT it isn't always appropriate.
> >
> >If you want to SIG_IGN the signal, then it is: "When a CTRL+C signal
is
> >received, the control handler returns TRUE, indicating that it has
> >handled the signal.  Doing this prevents other control handlers from
> >being called." (note that this is within this process only).
>
> I was going back over this thread before checking in a change to see
if
> I'd missed something.
>
> I just realized that I didn't address this concern.  Don't know if it
> matters but...
>
> The difference between the SIG_IGN way and the "return TRUE" way is
> that the SIG_IGN way stops the current process from responding to
> a cygwin signal but still lets it respond to a Windows "signal".  That
> means that the code in ctrl_c_handle can do its job, if it has to.

Huh? I actually did the reverse - returning TRUE only prevented
responding to a windows signal, but allowed responding to a cygwin
signal. This meant that 'kill -2 stubpid' from another shell would kill
the stub and it's spawned programs, which may alleviate some of the
'CTRL-C doesn't work for me now' grief that you rightly expect. I
mention this because IMO the strange behaviour is due to user
expectation of ^C behaviour - not signal behaviour.

> If we always "return TRUE" in the exec case, then there will be some
> situations where the SIGINT is not delivered to the rest of the
process
> group since the code in ctrl_c_handler would be short circuited.

I don't believe that is the case: Every console process attached to that
console independently recieves the windows signal. Only one has been
disabled. So the execing process's children will still recieve the
windows signals and the cygwin signals.

> My SIG_IGN "solution" is wrong, too, though.  The SIG_IGN would be
> inherited by the exec'ed process.  Then the execed process would never
> see a cygwin SIGINT signal.

Yes. I still believe that return TRUE is a good solution... but if
you've solved the obvious behaviour I'll be quite now :}.

> Btw, if I fix this, I may well fix a problem with CTRL-C and fork()
that
> I've been noticing for years, too.  Or, at least I'll be able to
convince
> myself its fixed until the next time I see the problem.

Cool.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Christopher Faylor]

There is a snapshot up there now which seems to work ok.

Again, many thanks to Robert Collins for tracking this down.

Although I said I wasn't overly interested in tracking this down
myself, I was interested in seeing the lessening in email traffic that I
hope this fix engenders.

I do expect that, when this cygwin DLL is released, there could be a
reaction from another, previously silent camp who relied on the old
CTRL-C behavior.  I guess it will be interesting to see if that is the
case.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Christopher Faylor]

On Wed, Jan 09, 2002 at 12:16:04PM +1100, Robert Collins wrote:
>----- Original Message -----
>From: "Christopher Faylor" <cgf@redhat.com>
>>I'm specifically trying not to do the "TRUE" thing, though, since
>>AFAICT it isn't always appropriate.
>
>If you want to SIG_IGN the signal, then it is: "When a CTRL+C signal is
>received, the control handler returns TRUE, indicating that it has
>handled the signal.  Doing this prevents other control handlers from
>being called." (note that this is within this process only).

I was going back over this thread before checking in a change to see if
I'd missed something.

I just realized that I didn't address this concern.  Don't know if it
matters but...

The difference between the SIG_IGN way and the "return TRUE" way is
that the SIG_IGN way stops the current process from responding to
a cygwin signal but still lets it respond to a Windows "signal".  That
means that the code in ctrl_c_handle can do its job, if it has to.

If we always "return TRUE" in the exec case, then there will be some
situations where the SIGINT is not delivered to the rest of the process
group since the code in ctrl_c_handler would be short circuited.

My SIG_IGN "solution" is wrong, too, though.  The SIG_IGN would be
inherited by the exec'ed process.  Then the execed process would never
see a cygwin SIGINT signal.

So, I made a minor change to the signal handling code to ignore SIGINTs
when the program is a stub.

I also thought that I'd brilliantly worked around the potential
intialization signal race but after a night's sleep I realize that is
not the case.  Bleah.  I really don't want to use a mutex for such a
rare corner case.

Btw, if I fix this, I may well fix a problem with CTRL-C and fork() that
I've been noticing for years, too.  Or, at least I'll be able to convince
myself its fixed until the next time I see the problem.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Michael Rumpf]

> Did you mean to take this off-list? My preference is to keep discussions
> on-list where possible.

Sorry, hadn't looked at the To: field when replying...

> ----- Original Message -----
> From: "Michael Rumpf" <michael@rumpfonline.de>
> To: "Robert Collins" <robert.collins@itdomain.com.au>
> Sent: Wednesday, January 09, 2002 2:01 AM
> Subject: Re: bash/cmd CTRL-C problem...
>
>
> > The output is looking as if it is working correctly now. Great work
> !!!!
> >
> > If this is accepted which module needs to be updated ? Is it the bash
> only
> > or does the code belong to the cygwin DLL ? And what are the public
> release
> > plans for those modules, i.e. when do you expect to see this hit any
> stable
> > module release...?
>
> It's a cygwin1.dll change, nothing to do with bash. Once Chris and I
> agree on the minor details to make this happen, it'll be available in
> snapshots within a day or two. Then the next release will have the code
>
> > The fact is that our integration team which does provide the
> infrastructure
> > for the build process will not accept any other version than an
> officially
> > released one...
>
> *shrug*. I'm pretty sure that a new release won't be rushed out to fix a
> minor non-security related bug.

A snapshot is perfect. I just don't think that our integration team would
take the effort to build cygwin from source ...

Michael



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Charles Wilson]

Christopher Faylor wrote:


> For the record, I really appreciate your tracking this down.  I finally
> understand the issues here.  These issues have been around for a long time
> and the problems that you uncovered are probably responsible for some
> longstanding cygwin strangeness.


Ditto.  For he's a jolly good fellow, for he's a jolly good fellow....

--Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Robert Collins]

----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>


> On Wed, Jan 09, 2002 at 11:57:04AM +1100, Robert Collins wrote:
> >----- Original Message -----
> >From: "Christopher Faylor" <cgf@redhat.com>
> >
> >> So, I think the easiest fix for the current problem is just to do a
> >> 'signal (SIGINT, SIG_IGN)' prior to calling CreateProcess,
restoring
> >> the previous signal handler if the CreateProcess fails.
> >
> >You do realise, that thats what I've done, but via the more efficient
> >way of returning TRUE to the signal.
>
> Sure.  I understand what you are doing.  It usually only takes me a
> couple of tries to "get it".

:}. Lol.

> I'm specifically trying not to do the "TRUE" thing, though, since
AFAICT
> it isn't always appropriate.

If you want to SIG_IGN the signal, then it is:
"When a CTRL+C signal is received, the control handler returns TRUE,
indicating that it has handled the signal. Doing this prevents other
control handlers from being called."
(note that this is within this process only).

> For the record, I really appreciate your tracking this down.  I
finally
> understand the issues here.  These issues have been around for a long
time
> and the problems that you uncovered are probably responsible for some
> longstanding cygwin strangeness.

No probs.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Christopher Faylor]

On Wed, Jan 09, 2002 at 11:57:04AM +1100, Robert Collins wrote:
>----- Original Message -----
>From: "Christopher Faylor" <cgf@redhat.com>
>
>> So, I think the easiest fix for the current problem is just to do a
>> 'signal (SIGINT, SIG_IGN)' prior to calling CreateProcess, restoring
>> the previous signal handler if the CreateProcess fails.
>
>You do realise, that thats what I've done, but via the more efficient
>way of returning TRUE to the signal.

Sure.  I understand what you are doing.  It usually only takes me a
couple of tries to "get it".

I'm specifically trying not to do the "TRUE" thing, though, since AFAICT
it isn't always appropriate.

For the record, I really appreciate your tracking this down.  I finally
understand the issues here.  These issues have been around for a long time
and the problems that you uncovered are probably responsible for some
longstanding cygwin strangeness.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Robert Collins]

===
----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>

> So, I think the easiest fix for the current problem is just to do a
> 'signal (SIGINT, SIG_IGN)' prior to calling CreateProcess, restoring
> the previous signal handler if the CreateProcess fails.

You do realise, that thats what I've done, but via the more efficient
way of returning TRUE to the signal.

> That doesn't solve the double sending of CTRL-Cs but that's a separate
> problem, I think.

Yes.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Christopher Faylor]

On Wed, Jan 09, 2002 at 11:43:41AM +1100, Robert Collins wrote:
>>I have to think about the race issues here.  It seems like you can't
>>get away without some kind of additional communication between the
>>parent and the child.
>
>True.  The problem is that we can't communicate with non-cygwin
>children.

I think basically you just have to ensure that the stub doesn't exit
on CTRL-C.  I can't think of a scenario where that's desireable now.

I think you could get just about the same behavior that you're describing
if you just blocked SIGINT prior to calling CreateProcess.

However, you've uncovered another problem in that it is possible for
both the stub and the child to fire off a kill() resulting in double
sending of CTRL-C during an exec().

So, I think the easiest fix for the current problem is just to do a
'signal (SIGINT, SIG_IGN)' prior to calling CreateProcess, restoring
the previous signal handler if the CreateProcess fails.

That doesn't solve the double sending of CTRL-Cs but that's a separate
problem, I think.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Robert Collins]

----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>
> >* The new process must not have signalled it's creation back to us.
>
> I don't think this is right, actually.  You basically don't want the
stub
> to *ever* send a CTRL-C in your scenario.  I don't see why it matters
that
> the subprocess has been reparented.  You especially don't want the
parent to
> be responding to CTRL-Cs when the child has indicated "Yep!  I'm a
cygwin
> process."

What I meant was, that once the child has signaled it's a cygwin
process, we terminate the stub immediately anyway. But yes, perhaps we
should not re-enable CTRL-C processing.

> >Hangon, look closer.
> >If the execed process is a *cygwin* process, then my patch makes no
> >difference - the stub is about to quit no matter what, and from a
POSIX
> >point of view, already has!
>
> You're right.  I did need to look closer.
>
> However, IMO, there's a race here.  It's possible that killing other
> members of the process group is the right thing to do if the child is
> still initializing and is unable to handle the CTRL/C correctly.  Your
> patch eliminates that capability so it may mean that CTRL-C's are
lost.
>
> >If the execed process is not a cygwin process, then it will handle
(or
> >not) CTRL-C itself. We should *not* force quit it when the stub
recieves
> >CTRL-C.
>
> Oddly enough, that is behavior that I reinstated when I had eliminated
> it for a while because people complained that they couldn't kill their
> processes.  If you don't do that then GUI windows apps don't go away
> when you hit CTRL-C, IIRC.
>
> This is the usual cygwin damned if you do/damned if you don't
scenario.

Hmm. Well CTRL-C and CTRL-BREAK are identified separately. I'll go have
a browse of the lists I guess.

> >I don't reinstate default behaviour, we simply ignore the keyboard
> >generated CTRL-C which we know that the non-cygwin child has already
> >recieved.
>
> We know that the child will receive or is about to receive it but we
> don't know that the child is about to do the right thing as a result
> of receiving it.

True.  The issue IMO is whether we assume the child will do the right
thing, or whether we assume the child won't. If it's a cygwin child
it'll do the right thing after being reparented. If it's a non-cygwin
child it'll do the right thing on it's own.

> >> Also, your change seems to make no distinction between a spawned
and
> >> execed process.
>
> As I mentioned, this observation was just completely wrong.  :-(
>
> I have to think about the race issues here.  It seems like you can't
get
> away without some kind of additional communication between the parent
and
> the child.

True. The problem is that we can't communicate with non-cygwin children.
So there will always be a window (from when a process is created to when
we find out it's a cygwin process) where we have to guess :}.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Christopher Faylor]

On Wed, Jan 09, 2002 at 09:16:55AM +1100, Robert Collins wrote:
>----- Original Message -----
>From: "Christopher Faylor" <cgf@redhat.com>
>
>
>> On Tue, Jan 08, 2002 at 06:00:16PM +1100, Robert Collins wrote:
>> >FWIW this patch (Chris where should I put the in_stub declaration)
>>
>> There is already an indicator that an execed process is running --
>> hExeced, so I don't think you need the 'in_stub' thing.
>
>No, hExeced is set far too early... There is a very narrow window where
>we want to ignore CTRL-C.

We want to deal with CTRL-C as soon as the process enters its "stub
state".  That's when hExeced is set.

>>However, it seems to me that this solution is racy.  If a person types
>>CTRL-C during process startup, it's possible that a cygwin process will
>>never see a true cygwin signal.  Hmm.  I guess this race is already in
>>signal_exit, in fact.  I have to fix that.
>
>Yes there is.  I asked for thoughts, but got none :}.

Yes, as I mentioned, I wasn't actually interested in debugging this
myself but I would investigate patches.

>However, note the requirements to drop the signal:
>* The process startup must be in _P_OVERLAY mode.

I completely missed this before.  Sorry.

>* The new process must have successfully been created.

It wouldn't be much of a process if it didn't exist, I guess.

>* Their must be no cygwin parent to the spawning process, or the
>spawning process must be the top of the process group.

Yes.  It must be at the top of a process group.  Period.

>* The new process must not have signalled it's creation back to us.

I don't think this is right, actually.  You basically don't want the stub
to *ever* send a CTRL-C in your scenario.  I don't see why it matters that
the subprocess has been reparented.  You especially don't want the parent to
be responding to CTRL-Cs when the child has indicated "Yep!  I'm a cygwin
process."

>> Regardless, it is not always the correct behavior for CTRL-C just do
>> the "default thing".  If the execed process is supposed to be ignoring
>> SIGINT then it isn't right for the process to exit.
>
>Hangon, look closer.
>If the execed process is a *cygwin* process, then my patch makes no
>difference - the stub is about to quit no matter what, and from a POSIX
>point of view, already has!

You're right.  I did need to look closer.

However, IMO, there's a race here.  It's possible that killing other
members of the process group is the right thing to do if the child is
still initializing and is unable to handle the CTRL/C correctly.  Your
patch eliminates that capability so it may mean that CTRL-C's are lost.

>If the execed process is not a cygwin process, then it will handle (or
>not) CTRL-C itself. We should *not* force quit it when the stub recieves
>CTRL-C.

Oddly enough, that is behavior that I reinstated when I had eliminated
it for a while because people complained that they couldn't kill their
processes.  If you don't do that then GUI windows apps don't go away
when you hit CTRL-C, IIRC.

This is the usual cygwin damned if you do/damned if you don't scenario.

>I don't reinstate default behaviour, we simply ignore the keyboard
>generated CTRL-C which we know that the non-cygwin child has already
>recieved.

We know that the child will receive or is about to receive it but we
don't know that the child is about to do the right thing as a result
of receiving it.

>> Also, your change seems to make no distinction between a spawned and
>> execed process.

As I mentioned, this observation was just completely wrong.  :-(

I have to think about the race issues here.  It seems like you can't get
away without some kind of additional communication between the parent and
the child.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Robert Collins]

----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>


> On Tue, Jan 08, 2002 at 06:00:16PM +1100, Robert Collins wrote:
> >FWIW this patch (Chris where should I put the in_stub declaration)
>
> There is already an indicator that an execed process is running --
> hExeced, so I don't think you need the 'in_stub' thing.

No, hExeced is set far too early... There is a very narrow window where
we want to ignore CTRL-C.

> However, it seems to me that this solution is racy.  If a person types
> CTRL-C during process startup, it's possible that a cygwin process
will
> never see a true cygwin signal.  Hmm.  I guess this race is already
> in signal_exit, in fact.  I have to fix that.

Yes there is. I asked for thoughts, but got none :}. However, note the
requirements to drop the signal:
* The process startup must be in _P_OVERLAY mode.
* The new process must have successfully been created.
* Their must be no cygwin parent to the spawning process, or the
spawning process must be the top of the process group.
* The new process must not have signalled it's creation back to us.

> Regardless, it is not always the correct behavior for CTRL-C just do
> the "default thing".  If the execed process is supposed to be ignoring
> SIGINT then it isn't right for the process to exit.

Hangon, look closer.
If the execed process is a *cygwin* process, then my patch makes no
difference - the stub is about to quit no matter what, and from a POSIX
point of view, already has!
If the execed process is not a cygwin process, then it will handle (or
not) CTRL-C itself. We should *not* force quit it when the stub recieves
CTRL-C.
I don't reinstate default behaviour, we simply ignore the keyboard
generated CTRL-C which we know that the non-cygwin child has already
recieved.

> Also, your change seems to make no distinction between a spawned and
> execed process.  It looks like if the user had called spawn, a CTRL-C
> would just cause the parent process to die.

No, if the user had called spawn, with mode != _P_OVERLAY, then this
patch makes no difference.
If the user had called spawn with mode == _P_OVERLAY and it's spawning a
cygwin program then the user will notice no difference, or worst case a
_perfectly timed_ CTRL-C is ignored. (Note: Ctrl-Break is not altered).
If the user had called spawn with mode == _P_OVERLAY and it's spawning a
non cygwin program then the user will notice no difference - the non
cygwin program will handle it's own CTRL-C.




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Christopher Faylor]

On Tue, Jan 08, 2002 at 06:00:16PM +1100, Robert Collins wrote:
>FWIW this patch (Chris where should I put the in_stub declaration)

There is already an indicator that an execed process is running --
hExeced, so I don't think you need the 'in_stub' thing.

However, it seems to me that this solution is racy.  If a person types
CTRL-C during process startup, it's possible that a cygwin process will
never see a true cygwin signal.  Hmm.  I guess this race is already
in signal_exit, in fact.  I have to fix that.

Regardless, it is not always the correct behavior for CTRL-C just do
the "default thing".  If the execed process is supposed to be ignoring
SIGINT then it isn't right for the process to exit.

Also, your change seems to make no distinction between a spawned and
execed process.  It looks like if the user had called spawn, a CTRL-C
would just cause the parent process to die.

cgf

>====
>Index: exceptions.cc
>===================================================================
>RCS file: /cvs/src/src/winsup/cygwin/exceptions.cc,v
>retrieving revision 1.103
>diff -u -p -r1.103 exceptions.cc
>--- exceptions.cc       2002/01/05 22:25:34     1.103
>+++ exceptions.cc       2002/01/08 06:54:23
>@@ -890,11 +890,14 @@ setup_handler (int sig, void *handler, s
> #error "Need to supply machine dependent setup_handler"
> #endif
>
>+// Yeah, well. Where to put this?
>+bool in_stub = false;
>+
> /* CGF Keyboard interrupt handler.  */
> static BOOL WINAPI
> ctrl_c_handler (DWORD type)
> {
>-  if (type == CTRL_LOGOFF_EVENT)
>+  if (type == CTRL_LOGOFF_EVENT || (type == CTRL_C_EVENT && in_stub ==
>true))
>     return TRUE;
>
>   /* Return FALSE to prevent an "End task" dialog box from appearing
>Index: spawn.cc
>===================================================================
>RCS file: /cvs/src/src/winsup/cygwin/spawn.cc,v
>retrieving revision 1.94
>diff -u -p -r1.94 spawn.cc
>--- spawn.cc    2001/11/05 06:09:08     1.94
>+++ spawn.cc    2002/01/08 06:54:25
>@@ -314,6 +314,9 @@ av::unshift (const char *what, int conv)
>   return 1;
> }
>
>+// From exceptions.cc
>+extern bool in_stub; // indicate when we are wrapping a non-cygwin
>program
>+
> static int __stdcall
> spawn_guts (HANDLE hToken, const char * prog_arg, const char *const
>*argv,
>            const char *const envp[], int mode)
>@@ -804,8 +807,10 @@ spawn_guts (HANDLE hToken, const char *
>   MALLOC_CHECK;
>   if (mode == _P_OVERLAY)
>     {
>+      in_stub = true; // don't close on CTRL C.
>       int nwait = 3;
>       HANDLE waitbuf[3] = {pi.hProcess, signal_arrived, spr};
>+      // If spr is not triggered, it's not a cygwin process ?
>       for (int i = 0; i < 100; i++)
>        {
>          switch (WaitForMultipleObjects (nwait, waitbuf, FALSE,
>INFINITE))
>@@ -823,6 +828,7 @@ spawn_guts (HANDLE hToken, const char *
>              reset_signal_arrived ();
>              continue;
>            case WAIT_OBJECT_0 + 2:
>+             // SPR
>              if (myself->ppid_handle)
>                res |= EXIT_REPARENTING;
>              if (!my_parent_is_alive ())
>@@ -847,6 +853,7 @@ spawn_guts (HANDLE hToken, const char *
>            }
>          break;
>        }
>+
>
>       ForceCloseHandle (spr);
>
>@@ -874,6 +881,8 @@ spawn_guts (HANDLE hToken, const char *
>              system_printf ("old hProcess %p, hProcess %p", oldh,
>myself->hProcess);
>            }
>        }
>+      in_stub = false; // We're safely reparented now, or a cygwin
>wrapped win32
>+      // program has terminated.
>
>     }
>====
>
>means that I get this output from the test programs:
>=============
>Administrator@LIFELESSWKS ~/t
>$ ./signals.exe
>
>>>> signals: Waiting now...
>>>>>>> myclass CPP: Installing atexit handler...
>
>>>>>>> myclass CPP: Installing signal handler...
>>>>>>> myclass CPP: Falling asleep...
>............................................................
>>>> signals: Signal SIGINT=2 received
>......................................
>>>> signals: Finished waiting now...
>
>>>> signals: Forwarding CTRL_BREAK_EVENT to the child process...
>..
>>>>>>> myclass CPP: SIGBREAK caught...
>>>>>>> myclass CPP: Process terminating...
>
>
>=================
>
>So it looks like it solves it. I've noticed no side effects either.
>
>Rob
>
>
>--
>Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>Bug reporting:         http://cygwin.com/bugs.html
>Documentation:         http://cygwin.com/docs.html
>FAQ:                   http://cygwin.com/faq/

-- 
cgf@redhat.com                        Red Hat, Inc.
http://sources.redhat.com/            http://www.redhat.com/

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Robert Collins]

FWIW this patch (Chris where should I put the in_stub declaration)

====
Index: exceptions.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/exceptions.cc,v
retrieving revision 1.103
diff -u -p -r1.103 exceptions.cc
--- exceptions.cc       2002/01/05 22:25:34     1.103
+++ exceptions.cc       2002/01/08 06:54:23
@@ -890,11 +890,14 @@ setup_handler (int sig, void *handler, s
 #error "Need to supply machine dependent setup_handler"
 #endif

+// Yeah, well. Where to put this?
+bool in_stub = false;
+
 /* CGF Keyboard interrupt handler.  */
 static BOOL WINAPI
 ctrl_c_handler (DWORD type)
 {
-  if (type == CTRL_LOGOFF_EVENT)
+  if (type == CTRL_LOGOFF_EVENT || (type == CTRL_C_EVENT && in_stub ==
true))
     return TRUE;

   /* Return FALSE to prevent an "End task" dialog box from appearing
Index: spawn.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/spawn.cc,v
retrieving revision 1.94
diff -u -p -r1.94 spawn.cc
--- spawn.cc    2001/11/05 06:09:08     1.94
+++ spawn.cc    2002/01/08 06:54:25
@@ -314,6 +314,9 @@ av::unshift (const char *what, int conv)
   return 1;
 }

+// From exceptions.cc
+extern bool in_stub; // indicate when we are wrapping a non-cygwin
program
+
 static int __stdcall
 spawn_guts (HANDLE hToken, const char * prog_arg, const char *const
*argv,
            const char *const envp[], int mode)
@@ -804,8 +807,10 @@ spawn_guts (HANDLE hToken, const char *
   MALLOC_CHECK;
   if (mode == _P_OVERLAY)
     {
+      in_stub = true; // don't close on CTRL C.
       int nwait = 3;
       HANDLE waitbuf[3] = {pi.hProcess, signal_arrived, spr};
+      // If spr is not triggered, it's not a cygwin process ?
       for (int i = 0; i < 100; i++)
        {
          switch (WaitForMultipleObjects (nwait, waitbuf, FALSE,
INFINITE))
@@ -823,6 +828,7 @@ spawn_guts (HANDLE hToken, const char *
              reset_signal_arrived ();
              continue;
            case WAIT_OBJECT_0 + 2:
+             // SPR
              if (myself->ppid_handle)
                res |= EXIT_REPARENTING;
              if (!my_parent_is_alive ())
@@ -847,6 +853,7 @@ spawn_guts (HANDLE hToken, const char *
            }
          break;
        }
+

       ForceCloseHandle (spr);

@@ -874,6 +881,8 @@ spawn_guts (HANDLE hToken, const char *
              system_printf ("old hProcess %p, hProcess %p", oldh,
myself->hProcess);
            }
        }
+      in_stub = false; // We're safely reparented now, or a cygwin
wrapped win32
+      // program has terminated.

     }
====

means that I get this output from the test programs:
=============
Administrator@LIFELESSWKS ~/t
$ ./signals.exe

>>> signals: Waiting now...
>>>>>> myclass CPP: Installing atexit handler...

>>>>>> myclass CPP: Installing signal handler...
>>>>>> myclass CPP: Falling asleep...
............................................................
>>> signals: Signal SIGINT=2 received
......................................
>>> signals: Finished waiting now...

>>> signals: Forwarding CTRL_BREAK_EVENT to the child process...
..
>>>>>> myclass CPP: SIGBREAK caught...
>>>>>> myclass CPP: Process terminating...


=================

So it looks like it solves it. I've noticed no side effects either.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Gregory W. Bond]

Christopher,

I addressed my message to you out of politeness since it was intended for you. I
addressed the message to cygwin since I thought it might also be of interest to the
readers of the mailing list. It's not an unusual convention to follow on mailing
lists, however, I won't do this with you in the future.

When thinking about the purpose of cygwin prior to drafting my message, it did
occur to me that interop between cygwin and win32 apps might simply be incidental
(as you state) but there is also evidence that cygwin has gone to some efforts to
explicitly provide support for win32 (e.g. the cygpath utility). This leads me, and
clearly others, to the apparently mistaken conclusion that cygwin strives to
support win32 apps. This is what prompted me, and a number of others to report what
we saw as a cygwin bash bug.

You state that your message was intended to stem the flow of bug reports but the
cygwin bug reports page specifically states that bug reports should be sent to the
mailing list. Furthermore, looking over the contents of this and related threads I
can see no "me too" postings. All the postings shed additional light on the problem
so they all contribute to the eventual solution of the problem. Even if you argue
that the "problem" discussed in this thread isn't really a problem because cygwin
doesn't currently provide support for win32 apps, it certainly doesn't hurt to
discuss it in the off chance that members of the cygwin community feel that cygwin
should begin to explicitly support win32 apps. After all, it is the community that
defines the direction of cygwin by making contributions to it, and the mailing list
is where the community discusses issues like this.

The goals of cygwin notwithstanding, I agree wholeheartedly with your comments
regarding community software development. As you say, this is a process in which
"core developers" and others are free to take part in if they wish. Just so you
know that I believe in this approach to software development in general, and to
cygwin in particular, I should mention that I have made a modest contribution to
the cygwin project myself which solved a problem that I (and others) had posted bug
reports for. In the case of the bug reported in the current thread, I recognize
that I have neither the background, nor the time to acquire the background
necessary to solve this problem, so I am willing to live with it.... (but if Robert
Collins is looking at it, my thanks go out to him!)

The tone of your message indicates that you are fed up with "bug reports" that are
nothing more than veiled requests to "core developers" to fix a problem. I can
certainly sympathize with you since I see these "bug reports" myself on the mailing
list. On the other hand, you should recognize that, to a cygwin newcomer, the
codebase is more than a little daunting, even to an experienced Unix programmer.
Furthermore, as cygwin gets easier to install and use, cygwin users are
increasingly Unix users, not Unix system programmers. While I completely agree with
setting people straight on the "community development" aspect of the cygwin
project, my guess is that the reason for these requests is more more likely due to
a misunderstanding of how the cygwin project works rather than due to sloth.

Greg.

Christopher Faylor wrote:

> On Mon, Jan 07, 2002 at 12:30:33PM -0500, Gregory W. Bond wrote:
> >(I just returned from vacation so excuse me for responding to an old
> >message but I really feel compelled to respond to this one...)
>
> Why did you Cc me when I specifically set the Reply-To to
> cygwin@cygwin.com and am obviously reading that mailing list?
>
> >Christopher,
> >
> >This reply puzzles me. What is the point of cygwin if not to support
> >interoperability between win32 and unix environments? If all I wanted
> >was an all-unix environment on a 386 box, I'd run linux not cygwin. To
> >me, the great advantage of cygwin over linux is that I can (mostly) mix
> >and match Unix and Win32 apps (win32 Java under cygwin bash being the
> >notable exception :-)
>
> The point of cygwin is to provide a UNIX environment on Windows.  A
> cygwin app has lots and lots of extra stuff in it to support that
> functionality.  One of the extra things in a cygwin app is a substantial
> amount of code to make signals work right.  Native windows apps don't
> have this.  Having native windows apps work with cygwin is something that
> we get pretty much "for free" and many native apps work fine.
>
> However boundary cases like "My win32 process doesn't CTRL-C right" are
> of little interest to me.  My focus, when I am working on cygwin (which
> is less and less these days) is to improve UNIX functionality.
>
> Since cygwin is a community free software project, you have one privilege
> and possibly one detriment over commercial software:
>
> Privilege: It's free.  Source is available.  You can fix problems yourself.
>
> Detriment: It's free.  It is controlled by volunteers.  The volunteers are
>            under zero obligation to look at problems which don't interest them.
>
> I responded to the original message because I thought it was better to
> do that than let people continue to send "bug reports" and "me toos"
> here.  I was trying to set expectations.
>
> I also thought that it was just vaguely possible that someone would
> actually take some time to contribute something back to the cygwin
> project beyond the bug reports and me toos.
>
> It looks like Robert Collins may be investigating the problem now so
> you're lucky.  It's too bad that, as always, it reverts to one of the
> "core developers" to investigate something like this.  Very occasionally
> we actually get people who are reporting bugs to attempt fixes.  It's
> a shame that no one was willing to do that in this case.
>
> cgf

--
Gregory W. Bond
AT&T Labs - Research
180 Park Avenue, Rm. D273, Bldg. 103
P.O. Box 971, Florham Park, NJ, 07932-0971, USA
tel: (973) 360 7216 fax: (973) 360 8187



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Christopher Faylor]

On Mon, Jan 07, 2002 at 12:30:33PM -0500, Gregory W. Bond wrote:
>(I just returned from vacation so excuse me for responding to an old
>message but I really feel compelled to respond to this one...)

Why did you Cc me when I specifically set the Reply-To to
cygwin@cygwin.com and am obviously reading that mailing list?

>Christopher,
>
>This reply puzzles me. What is the point of cygwin if not to support
>interoperability between win32 and unix environments? If all I wanted
>was an all-unix environment on a 386 box, I'd run linux not cygwin. To
>me, the great advantage of cygwin over linux is that I can (mostly) mix
>and match Unix and Win32 apps (win32 Java under cygwin bash being the
>notable exception :-)

The point of cygwin is to provide a UNIX environment on Windows.  A
cygwin app has lots and lots of extra stuff in it to support that
functionality.  One of the extra things in a cygwin app is a substantial
amount of code to make signals work right.  Native windows apps don't
have this.  Having native windows apps work with cygwin is something that
we get pretty much "for free" and many native apps work fine.

However boundary cases like "My win32 process doesn't CTRL-C right" are
of little interest to me.  My focus, when I am working on cygwin (which
is less and less these days) is to improve UNIX functionality.

Since cygwin is a community free software project, you have one privilege
and possibly one detriment over commercial software:

Privilege: It's free.  Source is available.  You can fix problems yourself.

Detriment: It's free.  It is controlled by volunteers.  The volunteers are
           under zero obligation to look at problems which don't interest them.

I responded to the original message because I thought it was better to
do that than let people continue to send "bug reports" and "me toos"
here.  I was trying to set expectations.

I also thought that it was just vaguely possible that someone would
actually take some time to contribute something back to the cygwin
project beyond the bug reports and me toos.

It looks like Robert Collins may be investigating the problem now so
you're lucky.  It's too bad that, as always, it reverts to one of the
"core developers" to investigate something like this.  Very occasionally
we actually get people who are reporting bugs to attempt fixes.  It's
a shame that no one was willing to do that in this case.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Gregory W. Bond]

(I just returned from vacation so excuse me for responding to an old
message but I really feel compelled to respond to this one...)

Christopher,

This reply puzzles me. What is the point of cygwin if not to support
interoperability between win32 and unix environments? If all I wanted
was an all-unix environment on a 386 box, I'd run linux not cygwin. To
me, the great advantage of cygwin over linux is that I can (mostly) mix
and match Unix and Win32 apps (win32 Java under cygwin bash being the
notable exception :-)

Greg.

Christopher Faylor wrote:

> 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.
>
> 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 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.
>
> cgf
>
--
Gregory W. Bond
AT&T Labs - Research
180 Park Avenue, Rm. D273, Bldg. 103
P.O. Box 971, Florham Park, NJ, 07932-0971, USA
tel: (973) 360 7216 fax: (973) 360 8187



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Michael Rumpf]

> Yes, that is what I meant.
>
> > bash (cygwin, of course)
> > app1 = "signals (MS CRT)"
> > app2 = "myclass.exe (MS CRT)" or "java myclass (???)"
>
> Lets leave java to the side. If we solve it with MS CRT, and java apps
> still have problems, then that becomes a new bug. Why? because there are
> multiple JVM's to consider, making it harder to setup a test
> environment. And because I suspect that a solution to one will solve the
> other.

OK, no problem. Java processes are created and they can be taken down by
sending them CTRL-BREAK signals (You need to start the Sun VM with
parameter -Xrs to make this work, otherwise you will just see a thread dump
because the standard VM establishes a SIGBREAK handler which prints stack
dumps of all running threads)

> > > By this are you implying that this:
> > > cmd.exe
> > > app1 (cygwin/MS CRT (see above))
> > > app2 (MS CRT)
> > > behaves as you expect?
> >
> > cmd.exe
> > bash (cygwin, of course)
> > app1="signals (MS CRT)"     app1
> > app2="myclass.exe (MS CRT)" or "java myclass (???)"
> >
> > yes here the behaviour is correct !! When pressing CTRL-C the
> execution
> > continues after handling the signal. The child apps are taken down by
> > sending a CTRL-BREAK event.
>
> Ok. let me confirm I understand everything.
>
> * Failure case *
> 1) double click on a shortcut to cygwin.bat from a default install of
> cygwin
> 2) run ./signals.exe
> 3) ./myclass.exe is automatically executed (BTW: this is not fork()  -
> fork() requires a cygwin linked signals.exe. In unix terms, this is a
> spawned program.
> 4) Hit CTRL-C.
> 5) The user is returned to the bash shell started via 1), but
> myclass.exe is left running.
>
> * success case *
> 1) double click on a shortcut to cmd.exe
> 2) run X:\cygwin\cygwin.bat

No. I do not run cygwin.bat ! It is just pure cmd.exe !!!

> 3) run ./signals.exe
> 4) ./myclass.exe is automatically executed (BTW: this is not fork()  -
> fork() requires a cygwin linked signals.exe. In unix terms, this is a
> spawned program.

OK, myclass.exe is spawned program...

> 5) Hit CTRL-C.
> 6) The user is returned to the bash shell started via 2), and
> myclass.exe is terminated correctly.

The user is returned to the cmd.exe shell started via 1) and myclass.exe is
terminated correctly.

> Please edit the above as needed to correctly show the actions taken and
> the expected outcome, to prevent me erroneously reporting no-fault-found
> or no-success-found etc.
>
> > Great, the attachment of one of my previous mails should give you a
> > repeatable test case at hand. It includes the signals.cpp (app1),
> > myclass.cpp/myclass.java (app2) and a Makefile to compile it (the
> makefile
> > needs some updates to the paths used there). You don't have to compile
> the
> > Java class just compile the C/C++ apps and launch "signals cpp" which
> > results in forking the C/C++ child app myclass.exe.
>
> I've not archived those mails. Can you please send me (as an off-list
> email, separate to your on-list response) the relevant files. I presume
> they will build with gcc -mno-cygwin ? (If Visual C++ is required to
> build them, please provide a .exe).

I have no Makefile for compiling the test case with gcc at hand. The general
opinion here at my company is that the code generated by gcc is too slow. So
we are using the native compilers under the different platforms. The
decision to use the native compilers has been made a few years ago and I
guess a lot has changed since then, but we have decided last year to move to
Java and so adapting everything to gcc would be a one year effort which
nobody wants to invest because we have finally decided to move to Java
completely. This is also not a single step task and until that has not been
achieved many of the building blocks, like the app server launcher, remains
in C++

AIX -> xlC_r
NT/IA64 -> cl.exe
Linux -> GCC
HPUX -> aCC
Solaris -> CC

Michael



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Robert Collins]

----- Original Message -----
From: "Michael Rumpf" <michael@rumpfonline.de>



Yes, that is what I meant.

> bash (cygwin, of course)
> app1 = "signals (MS CRT)"
> app2 = "myclass.exe (MS CRT)" or "java myclass (???)"

Lets leave java to the side. If we solve it with MS CRT, and java apps
still have problems, then that becomes a new bug. Why? because there are
multiple JVM's to consider, making it harder to setup a test
environment. And because I suspect that a solution to one will solve the
other.

> > By this are you implying that this:
> > cmd.exe
> > app1 (cygwin/MS CRT (see above))
> > app2 (MS CRT)
> > behaves as you expect?
>
> cmd.exe
> bash (cygwin, of course)
> app1="signals (MS CRT)"     app1
> app2="myclass.exe (MS CRT)" or "java myclass (???)"
>
> yes here the behaviour is correct !! When pressing CTRL-C the
execution
> continues after handling the signal. The child apps are taken down by
> sending a CTRL-BREAK event.

Ok. let me confirm I understand everything.

* Failure case *
1) double click on a shortcut to cygwin.bat from a default install of
cygwin
2) run ./signals.exe
3) ./myclass.exe is automatically executed (BTW: this is not fork()  -
fork() requires a cygwin linked signals.exe. In unix terms, this is a
spawned program.
4) Hit CTRL-C.
5) The user is returned to the bash shell started via 1), but
myclass.exe is left running.

* success case *
1) double click on a shortcut to cmd.exe
2) run X:\cygwin\cygwin.bat
3) run ./signals.exe
4) ./myclass.exe is automatically executed (BTW: this is not fork()  -
fork() requires a cygwin linked signals.exe. In unix terms, this is a
spawned program.
5) Hit CTRL-C.
6) The user is returned to the bash shell started via 2), and
myclass.exe is terminated correctly.

Please edit the above as needed to correctly show the actions taken and
the expected outcome, to prevent me erroneously reporting no-fault-found
or no-success-found etc.

> Great, the attachment of one of my previous mails should give you a
> repeatable test case at hand. It includes the signals.cpp (app1),
> myclass.cpp/myclass.java (app2) and a Makefile to compile it (the
makefile
> needs some updates to the paths used there). You don't have to compile
the
> Java class just compile the C/C++ apps and launch "signals cpp" which
> results in forking the C/C++ child app myclass.exe.

I've not archived those mails. Can you please send me (as an off-list
email, separate to your on-list response) the relevant files. I presume
they will build with gcc -mno-cygwin ? (If Visual C++ is required to
build them, please provide a .exe).

Cheers,
Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Michael Rumpf]

Hi Robert,

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

Ok, I assume that the comment "cygwin" means that the app is linked against
cygwin runtime libs. If I got that right it is the second case:
bash (cygwin, of course)
app1 = "signals (MS CRT)"
app2 = "myclass.exe (MS CRT)" or "java myclass (???)"

> > 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:
> cmd.exe
> app1 (cygwin/MS CRT (see above))
> app2 (MS CRT)
> behaves as you expect?

cmd.exe
bash (cygwin, of course)
app1="signals (MS CRT)"     app1
app2="myclass.exe (MS CRT)" or "java myclass (???)"

yes here the behaviour is correct !! When pressing CTRL-C the execution
continues after handling the signal. The child apps are taken down by
sending a CTRL-BREAK event.

*snip*
>
> 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 know this, sorry if phrasing to harsh. I'm not a native speaker so please
don't get me wrong, I simply don't have the time to get familiar with the
complex Cygwin internals. I would never be able to tell whether a patch will
not break other cygwin apps so it will always be some kind of quick hack...

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

Great, the attachment of one of my previous mails should give you a
repeatable test case at hand. It includes the signals.cpp (app1),
myclass.cpp/myclass.java (app2) and a Makefile to compile it (the makefile
needs some updates to the paths used there). You don't have to compile the
Java class just compile the C/C++ apps and launch "signals cpp" which
results in forking the C/C++ child app myclass.exe.

Thanks a lot for investigating the issue. I will provide you any help you
need. We are around 200 developers here building a fairly huge application
server and most of the developers have to stick with the windows cmd shell
as it is inconvenient under Windows to start the Task Manager each time when
shutting down the application server in order to kill around 7 processes
manually.
We are currently using a very old version (B20.1) for our internal *build
process* and we are evaluating currently to move to a current version. It
would be great if the issue could be fixed so that we could use an updated
version of the bash to make the only but most annoying problem go away...
I have used the latest stable version of Cygwin and the bash to reproduce
the problem. The old version mentioned above is only used in the build
process of our application server...

Michael



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Robert Collins]

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:
cmd.exe
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
providing.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Michael Rumpf]

Hi Christopher,

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

OK.

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

Thanks,
    Michael



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Christopher Faylor]

On Fri, Jan 04, 2002 at 12:52:43PM +0100, Michael Rumpf wrote:
>I further investigated the bash CTRL-C problem and found out that pressing
>CTRL-C in the bash is "nearly" the same as CTRL-BREAK. I tried all the
>CYGWIN=tty/notty/<empty> combinations but that did not change anything...
>
>[snip]
>
>The cmd shell works as it should be. CTRL-BREAK stops everything immediatly
>and CTRL-C continues with the main thread after the signal was handled.
>
>I guess it is worth mentioning that I don't use any of the Cygwin libc
>stuff. The apps are linked against MS runtime libs.

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.

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

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Michael Rumpf]

[-- Attachment #1: Type: text/plain, Size: 7963 bytes --]

Hi Corinna,

I further investigated the bash CTRL-C problem and found out that pressing
CTRL-C in the bash is "nearly" the same as CTRL-BREAK. I tried all the
CYGWIN=tty/notty/<empty> combinations but that did not change anything...

Test application:
I have several sample applications, one in Java (myclass.java) and one in
C/C++ (myclass.cpp) which are forked via the Win32API call CreateProcess()
from the main application (signals.cpp). The main application installs
signal handlers for SIGINT and SIGBREAK. In the SIGINT case the code in the
main thread should be further executed when the signal handler finishes. In
the SIGBREAK case the process should just stop and also stop all the forked
children. The continuation of the process in the SIGINT case is crucial
because the handler sets a flag which causes the main thread to leave a loop
and send the child processes a CTRL-BREAK event. The CTRL-BREAK event is
important because the process has been created with the flag
CREATE_PROCESS_GROUP and only CTRL_BREAK can be used to terminate the
process (see
http://msdn.microsoft.com/library/en-us/dllproc/prothred_9dpv.asp:
CreateProcess disables the CTRL-C signal handler for processes created as a
process group). The problem is that the bash does not continue executing the
main thread of the process after the handling of SIGINT, the process
terminates without being able to send the termination message
(GenerateConsoleCtrlEvent) to the child processes. The main process stops
but the child process continue to live (You can see that the child process
is still running as it writes dots "." to the console). When pressing
CTRL-BREAK the behaviour is as it should be, the main thread is not further
executed and the main process and all the child processes are stopped.

The cmd shell works as it should be. CTRL-BREAK stops everything immediatly
and CTRL-C continues with the main thread after the signal was handled.

I guess it is worth mentioning that I don't use any of the Cygwin libc
stuff. The apps are linked against MS runtime libs. The application is just
started from the bash (I can't switch to another runtime lib as our project
is huge and only the MS runtime is officially supported). I use the bash for
convenience reasons as we support several UNIX platforms where the bash is
our standard shell. Only under Win2K we "officially" use the cmd shell
because of the broken signal handling...

You can reproduce the problem with the sample applications attached. You
need to tweak the paths in the Makefile and the path to the Java VM in the
file signals.cpp. I also attached an output of "cygcheck -s -v -h" to the
mail.

Michael

----- Original Message -----
From: "Michael Rumpf" <michael@rumpfonline.de>
To: <cygwin@cygwin.com>
Sent: Friday, December 21, 2001 11:09 AM
Subject: Re: bash/cmd CTRL-C problem...


> Am I the only one having problems with this, or is this simply the wrong
> list to ask a question about the Cygwin bash... ??
>
> Michael
>
> ----- Original Message -----
> From: "Michael Rumpf" <michael@rumpfonline.de>
> To: <cygwin@cygwin.com>
> Sent: Thursday, December 20, 2001 10:11 AM
> Subject: Re: bash/cmd CTRL-C problem...
>
>
> > Hi,
> >
> > sorry for following up myself, but I found out that Cygwin equally
handles
> > CTRL-BREAK and CTRL-C by sending a SIGINT to the process.
> > See http://groups.yahoo.com/group/gnu-win32/message/27643 (last
sentence).
> > This seems to be the source of the problem.
> > CTRL-BREAK under the cmd shell terminates the process after handling the
> > signal without further executing any code. The bad thing is that under
> bash
> > the same behaviour follows from pressing CTRL-BREAK  _and_ CTRL-C !!
> >
> > If this is a design issue, can someone please explain what the reasons
> > are...
> >
> > We have an application that forks other processes. The main thread is
> > waiting for the signal handler to return in order to cleanly stop the
> child
> > processes. By just stopping the parent process the child processes keep
> > running and I have to kill them manually each time I press CTRL-C. The
> same
> > application is working fine under windows cmd shell and bash under Linux
,
> > HP-UX 10/11, AIX4.x, and SunOS 2.5+...
> >
> > Please help, I don't want to use the stupid windows cmd shell.... ;-)
> >
> > Michael
> >
> > ----- Original Message -----
> > From: "Michael Rumpf" <michael@rumpfonline.de>
> > To: <cygwin@cygwin.com>
> > Sent: Thursday, December 20, 2001 7:47 AM
> > Subject: bash/cmd CTRL-C problem...
> >
> >
> > > Hi,
> > >
> > > I'm new to the list and I don't know if this problem is already
solved,
> > but
> > > I couldn't find a hint neither on the archives nor on the FAQ or
> somewhere
> > > else on the net.
> > >
> > > My problem is related to bash/cmd and signal handling.
> > > In my app I installed a signal handler for SIGINT. The app is going
into
> a
> > > wait loop and waiting for the exit flag from the signal handler to be
> set.
> > >
> > > When pressing CTRL-C in the windows cmd shell the application
continues
> > > normally after the signal handler has been caught. Under bash the
signal
> > > handler is also correctly called, but after that the app is exiting
> > > immediatly, i.e. not continuing with the code.
> > > Here is the source:
> > >
> > >
> >
>
////////////////////////////////////////////////////////////////////////////
> > > /////////////////
> > > #include <windows.h>
> > > #include <stdio.h>
> > > #include <signal.h>
> > >
> > > bool loop = true;
> > >
> > > extern "C" void signalHandler(int sig)
> > > {
> > >    switch( sig )
> > >    {
> > >       case SIGINT:  // == 2
> > >          printf("SIGINT=%d\n",sig);
> > >          break;
> > >       default:
> > >          printf("default=%d\n",sig);
> > >          break;
> > >    };
> > >    loop=false;
> > > }
> > >
> > > int main(int argc, char* argv[])
> > > {
> > >    if (signal( SIGINT , signalHandler ) == SIG_ERR)
> > >       return -1;
> > >    printf("### ctrlbreak: Waiting now...\n");
> > >    while(loop)
> > >      Sleep ((DWORD) 1000) ;
> > >    printf("### ctrlbreak: Finished waiting now...\n");
> > >    return 0;
> > > }
> > >
> >
>
////////////////////////////////////////////////////////////////////////////
> > > /////////////////
> > >
> > > Here the the output of the app under Win2K/bash:
> > > // bash                2.05a-2
> > > $ ./ctrlbreak.exe
> > > ### ctrlbreak: Waiting now...
> > > SIGINT=2
> > >
> > >
> > > // GNU bash, version 2.02.1(2)-release (i586-pc-cygwin32) B20.1
> > > bash-2.02$ ./ctrlbreak
> > > ### ctrlbreak: Waiting now...
> > > SIGINT=2
> > >
> > > // cmd.exe Win2k SP2
> > > ### ctrlbreak: Waiting now...
> > > SIGINT=2
> > > ### ctrlbreak: Finished waiting now...
> > >
> > >
> > > You can see that under the cmd shell the text "Finished waiting
now..."
> is
> > > printed which does not come out under the bash. The app is not linked
> > > against any cygwin library. It is a plain VC++ console application.
But
> > when
> > > I compile with gcc from the cygwin package I have the same result.
> > > Any hint would be greatly appreciated...
> > >
> > > Michael
> > >
> > > PS: I just downloaded the latest stable version 1.3.6 today...
> > >
> > >
> > >
> > > --
> > > Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> > > Bug reporting:         http://cygwin.com/bugs.html
> > > Documentation:         http://cygwin.com/docs.html
> > > FAQ:                   http://cygwin.com/faq/
> > >
> > >
> >
> >
> > --
> > Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> > Bug reporting:         http://cygwin.com/bugs.html
> > Documentation:         http://cygwin.com/docs.html
> > FAQ:                   http://cygwin.com/faq/
> >
>
>
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
>
>

[-- Attachment #2: Cygcheck.zip --]
[-- Type: application/x-zip-compressed, Size: 4013 bytes --]

[-- Attachment #3: Signals.zip --]
[-- Type: application/x-zip-compressed, Size: 3778 bytes --]

[-- Attachment #4: Type: text/plain, Size: 214 bytes --]

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Michael Rumpf]

Hi Corinna,

thanks for the answer. No I haven't tried such an option as I must admit
that I don't know about it.
I will search for it in the docs and try to play around with it...

Michael


On Fri, 2001-12-21 at 16:24, Corinna Vinschen wrote:
> On Fri, Dec 21, 2001 at 11:09:05AM +0100, Michael Rumpf wrote:
> > Am I the only one having problems with this, or is this simply the wrong
> > list to ask a question about the Cygwin bash... ??
> 
> Nah, this is the right list.  Nobody has an answer, though.
> 
> Did you try `CYGWIN=... tty ...' setting?
> 
> Corinna
> 
> > 
> > Michael
> > 
> > ----- Original Message -----
> > From: "Michael Rumpf" <michael@rumpfonline.de>
> > To: <cygwin@cygwin.com>
> > Sent: Thursday, December 20, 2001 10:11 AM
> > Subject: Re: bash/cmd CTRL-C problem...
> > 
> > 
> > > Hi,
> > >
> > > sorry for following up myself, but I found out that Cygwin equally handles
> > > CTRL-BREAK and CTRL-C by sending a SIGINT to the process.
> > > See http://groups.yahoo.com/group/gnu-win32/message/27643 (last sentence).
> > > This seems to be the source of the problem.
> > > CTRL-BREAK under the cmd shell terminates the process after handling the
> > > signal without further executing any code. The bad thing is that under
> > bash
> > > the same behaviour follows from pressing CTRL-BREAK  _and_ CTRL-C !!
> > >
> > > If this is a design issue, can someone please explain what the reasons
> > > are...
> > >
> > > We have an application that forks other processes. The main thread is
> > > waiting for the signal handler to return in order to cleanly stop the
> > child
> > > processes. By just stopping the parent process the child processes keep
> > > running and I have to kill them manually each time I press CTRL-C. The
> > same
> > > application is working fine under windows cmd shell and bash under Linux ,
> > > HP-UX 10/11, AIX4.x, and SunOS 2.5+...
> > >
> > > Please help, I don't want to use the stupid windows cmd shell.... ;-)
> > >
> > > Michael
> > >
> > > ----- Original Message -----
> > > From: "Michael Rumpf" <michael@rumpfonline.de>
> > > To: <cygwin@cygwin.com>
> > > Sent: Thursday, December 20, 2001 7:47 AM
> > > Subject: bash/cmd CTRL-C problem...
> > >
> > >
> > > > Hi,
> > > >
> > > > I'm new to the list and I don't know if this problem is already solved,
> > > but
> > > > I couldn't find a hint neither on the archives nor on the FAQ or
> > somewhere
> > > > else on the net.
> > > >
> > > > My problem is related to bash/cmd and signal handling.
> > > > In my app I installed a signal handler for SIGINT. The app is going into
> > a
> > > > wait loop and waiting for the exit flag from the signal handler to be
> > set.
> > > >
> > > > When pressing CTRL-C in the windows cmd shell the application continues
> > > > normally after the signal handler has been caught. Under bash the signal
> > > > handler is also correctly called, but after that the app is exiting
> > > > immediatly, i.e. not continuing with the code.
> > > > Here is the source:
> > > >
> > > >
> > >
> > ////////////////////////////////////////////////////////////////////////////
> > > > /////////////////
> > > > #include <windows.h>
> > > > #include <stdio.h>
> > > > #include <signal.h>
> > > >
> > > > bool loop = true;
> > > >
> > > > extern "C" void signalHandler(int sig)
> > > > {
> > > >    switch( sig )
> > > >    {
> > > >       case SIGINT:  // == 2
> > > >          printf("SIGINT=%d\n",sig);
> > > >          break;
> > > >       default:
> > > >          printf("default=%d\n",sig);
> > > >          break;
> > > >    };
> > > >    loop=false;
> > > > }
> > > >
> > > > int main(int argc, char* argv[])
> > > > {
> > > >    if (signal( SIGINT , signalHandler ) == SIG_ERR)
> > > >       return -1;
> > > >    printf("### ctrlbreak: Waiting now...\n");
> > > >    while(loop)
> > > >      Sleep ((DWORD) 1000) ;
> > > >    printf("### ctrlbreak: Finished waiting now...\n");
> > > >    return 0;
> > > > }
> > > >
> > >
> > ////////////////////////////////////////////////////////////////////////////
> > > > /////////////////
> > > >
> > > > Here the the output of the app under Win2K/bash:
> > > > // bash                2.05a-2
> > > > $ ./ctrlbreak.exe
> > > > ### ctrlbreak: Waiting now...
> > > > SIGINT=2
> > > >
> > > >
> > > > // GNU bash, version 2.02.1(2)-release (i586-pc-cygwin32) B20.1
> > > > bash-2.02$ ./ctrlbreak
> > > > ### ctrlbreak: Waiting now...
> > > > SIGINT=2
> > > >
> > > > // cmd.exe Win2k SP2
> > > > ### ctrlbreak: Waiting now...
> > > > SIGINT=2
> > > > ### ctrlbreak: Finished waiting now...
> > > >
> > > >
> > > > You can see that under the cmd shell the text "Finished waiting now..."
> > is
> > > > printed which does not come out under the bash. The app is not linked
> > > > against any cygwin library. It is a plain VC++ console application. But
> > > when
> > > > I compile with gcc from the cygwin package I have the same result.
> > > > Any hint would be greatly appreciated...
> > > >
> > > > Michael
> > > >
> > > > PS: I just downloaded the latest stable version 1.3.6 today...
> > > >
> > > >
> > > >
> > > > --
> > > > Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> > > > Bug reporting:         http://cygwin.com/bugs.html
> > > > Documentation:         http://cygwin.com/docs.html
> > > > FAQ:                   http://cygwin.com/faq/
> > > >
> > > >
> > >
> > >
> > > --
> > > Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> > > Bug reporting:         http://cygwin.com/bugs.html
> > > Documentation:         http://cygwin.com/docs.html
> > > FAQ:                   http://cygwin.com/faq/
> > >
> > 
> > 
> > --
> > Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> > Bug reporting:         http://cygwin.com/bugs.html
> > Documentation:         http://cygwin.com/docs.html
> > FAQ:                   http://cygwin.com/faq/
> 
> -- 
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Developer                                mailto:cygwin@cygwin.com
> Red Hat, Inc.
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Corinna Vinschen]

On Fri, Dec 21, 2001 at 11:09:05AM +0100, Michael Rumpf wrote:
> Am I the only one having problems with this, or is this simply the wrong
> list to ask a question about the Cygwin bash... ??

Nah, this is the right list.  Nobody has an answer, though.

Did you try `CYGWIN=... tty ...' setting?

Corinna

> 
> Michael
> 
> ----- Original Message -----
> From: "Michael Rumpf" <michael@rumpfonline.de>
> To: <cygwin@cygwin.com>
> Sent: Thursday, December 20, 2001 10:11 AM
> Subject: Re: bash/cmd CTRL-C problem...
> 
> 
> > Hi,
> >
> > sorry for following up myself, but I found out that Cygwin equally handles
> > CTRL-BREAK and CTRL-C by sending a SIGINT to the process.
> > See http://groups.yahoo.com/group/gnu-win32/message/27643 (last sentence).
> > This seems to be the source of the problem.
> > CTRL-BREAK under the cmd shell terminates the process after handling the
> > signal without further executing any code. The bad thing is that under
> bash
> > the same behaviour follows from pressing CTRL-BREAK  _and_ CTRL-C !!
> >
> > If this is a design issue, can someone please explain what the reasons
> > are...
> >
> > We have an application that forks other processes. The main thread is
> > waiting for the signal handler to return in order to cleanly stop the
> child
> > processes. By just stopping the parent process the child processes keep
> > running and I have to kill them manually each time I press CTRL-C. The
> same
> > application is working fine under windows cmd shell and bash under Linux ,
> > HP-UX 10/11, AIX4.x, and SunOS 2.5+...
> >
> > Please help, I don't want to use the stupid windows cmd shell.... ;-)
> >
> > Michael
> >
> > ----- Original Message -----
> > From: "Michael Rumpf" <michael@rumpfonline.de>
> > To: <cygwin@cygwin.com>
> > Sent: Thursday, December 20, 2001 7:47 AM
> > Subject: bash/cmd CTRL-C problem...
> >
> >
> > > Hi,
> > >
> > > I'm new to the list and I don't know if this problem is already solved,
> > but
> > > I couldn't find a hint neither on the archives nor on the FAQ or
> somewhere
> > > else on the net.
> > >
> > > My problem is related to bash/cmd and signal handling.
> > > In my app I installed a signal handler for SIGINT. The app is going into
> a
> > > wait loop and waiting for the exit flag from the signal handler to be
> set.
> > >
> > > When pressing CTRL-C in the windows cmd shell the application continues
> > > normally after the signal handler has been caught. Under bash the signal
> > > handler is also correctly called, but after that the app is exiting
> > > immediatly, i.e. not continuing with the code.
> > > Here is the source:
> > >
> > >
> >
> ////////////////////////////////////////////////////////////////////////////
> > > /////////////////
> > > #include <windows.h>
> > > #include <stdio.h>
> > > #include <signal.h>
> > >
> > > bool loop = true;
> > >
> > > extern "C" void signalHandler(int sig)
> > > {
> > >    switch( sig )
> > >    {
> > >       case SIGINT:  // == 2
> > >          printf("SIGINT=%d\n",sig);
> > >          break;
> > >       default:
> > >          printf("default=%d\n",sig);
> > >          break;
> > >    };
> > >    loop=false;
> > > }
> > >
> > > int main(int argc, char* argv[])
> > > {
> > >    if (signal( SIGINT , signalHandler ) == SIG_ERR)
> > >       return -1;
> > >    printf("### ctrlbreak: Waiting now...\n");
> > >    while(loop)
> > >      Sleep ((DWORD) 1000) ;
> > >    printf("### ctrlbreak: Finished waiting now...\n");
> > >    return 0;
> > > }
> > >
> >
> ////////////////////////////////////////////////////////////////////////////
> > > /////////////////
> > >
> > > Here the the output of the app under Win2K/bash:
> > > // bash                2.05a-2
> > > $ ./ctrlbreak.exe
> > > ### ctrlbreak: Waiting now...
> > > SIGINT=2
> > >
> > >
> > > // GNU bash, version 2.02.1(2)-release (i586-pc-cygwin32) B20.1
> > > bash-2.02$ ./ctrlbreak
> > > ### ctrlbreak: Waiting now...
> > > SIGINT=2
> > >
> > > // cmd.exe Win2k SP2
> > > ### ctrlbreak: Waiting now...
> > > SIGINT=2
> > > ### ctrlbreak: Finished waiting now...
> > >
> > >
> > > You can see that under the cmd shell the text "Finished waiting now..."
> is
> > > printed which does not come out under the bash. The app is not linked
> > > against any cygwin library. It is a plain VC++ console application. But
> > when
> > > I compile with gcc from the cygwin package I have the same result.
> > > Any hint would be greatly appreciated...
> > >
> > > Michael
> > >
> > > PS: I just downloaded the latest stable version 1.3.6 today...
> > >
> > >
> > >
> > > --
> > > Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> > > Bug reporting:         http://cygwin.com/bugs.html
> > > Documentation:         http://cygwin.com/docs.html
> > > FAQ:                   http://cygwin.com/faq/
> > >
> > >
> >
> >
> > --
> > Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> > Bug reporting:         http://cygwin.com/bugs.html
> > Documentation:         http://cygwin.com/docs.html
> > FAQ:                   http://cygwin.com/faq/
> >
> 
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Michael Rumpf]

Am I the only one having problems with this, or is this simply the wrong
list to ask a question about the Cygwin bash... ??

Michael

----- Original Message -----
From: "Michael Rumpf" <michael@rumpfonline.de>
To: <cygwin@cygwin.com>
Sent: Thursday, December 20, 2001 10:11 AM
Subject: Re: bash/cmd CTRL-C problem...


> Hi,
>
> sorry for following up myself, but I found out that Cygwin equally handles
> CTRL-BREAK and CTRL-C by sending a SIGINT to the process.
> See http://groups.yahoo.com/group/gnu-win32/message/27643 (last sentence).
> This seems to be the source of the problem.
> CTRL-BREAK under the cmd shell terminates the process after handling the
> signal without further executing any code. The bad thing is that under
bash
> the same behaviour follows from pressing CTRL-BREAK  _and_ CTRL-C !!
>
> If this is a design issue, can someone please explain what the reasons
> are...
>
> We have an application that forks other processes. The main thread is
> waiting for the signal handler to return in order to cleanly stop the
child
> processes. By just stopping the parent process the child processes keep
> running and I have to kill them manually each time I press CTRL-C. The
same
> application is working fine under windows cmd shell and bash under Linux ,
> HP-UX 10/11, AIX4.x, and SunOS 2.5+...
>
> Please help, I don't want to use the stupid windows cmd shell.... ;-)
>
> Michael
>
> ----- Original Message -----
> From: "Michael Rumpf" <michael@rumpfonline.de>
> To: <cygwin@cygwin.com>
> Sent: Thursday, December 20, 2001 7:47 AM
> Subject: bash/cmd CTRL-C problem...
>
>
> > Hi,
> >
> > I'm new to the list and I don't know if this problem is already solved,
> but
> > I couldn't find a hint neither on the archives nor on the FAQ or
somewhere
> > else on the net.
> >
> > My problem is related to bash/cmd and signal handling.
> > In my app I installed a signal handler for SIGINT. The app is going into
a
> > wait loop and waiting for the exit flag from the signal handler to be
set.
> >
> > When pressing CTRL-C in the windows cmd shell the application continues
> > normally after the signal handler has been caught. Under bash the signal
> > handler is also correctly called, but after that the app is exiting
> > immediatly, i.e. not continuing with the code.
> > Here is the source:
> >
> >
>
////////////////////////////////////////////////////////////////////////////
> > /////////////////
> > #include <windows.h>
> > #include <stdio.h>
> > #include <signal.h>
> >
> > bool loop = true;
> >
> > extern "C" void signalHandler(int sig)
> > {
> >    switch( sig )
> >    {
> >       case SIGINT:  // == 2
> >          printf("SIGINT=%d\n",sig);
> >          break;
> >       default:
> >          printf("default=%d\n",sig);
> >          break;
> >    };
> >    loop=false;
> > }
> >
> > int main(int argc, char* argv[])
> > {
> >    if (signal( SIGINT , signalHandler ) == SIG_ERR)
> >       return -1;
> >    printf("### ctrlbreak: Waiting now...\n");
> >    while(loop)
> >      Sleep ((DWORD) 1000) ;
> >    printf("### ctrlbreak: Finished waiting now...\n");
> >    return 0;
> > }
> >
>
////////////////////////////////////////////////////////////////////////////
> > /////////////////
> >
> > Here the the output of the app under Win2K/bash:
> > // bash                2.05a-2
> > $ ./ctrlbreak.exe
> > ### ctrlbreak: Waiting now...
> > SIGINT=2
> >
> >
> > // GNU bash, version 2.02.1(2)-release (i586-pc-cygwin32) B20.1
> > bash-2.02$ ./ctrlbreak
> > ### ctrlbreak: Waiting now...
> > SIGINT=2
> >
> > // cmd.exe Win2k SP2
> > ### ctrlbreak: Waiting now...
> > SIGINT=2
> > ### ctrlbreak: Finished waiting now...
> >
> >
> > You can see that under the cmd shell the text "Finished waiting now..."
is
> > printed which does not come out under the bash. The app is not linked
> > against any cygwin library. It is a plain VC++ console application. But
> when
> > I compile with gcc from the cygwin package I have the same result.
> > Any hint would be greatly appreciated...
> >
> > Michael
> >
> > PS: I just downloaded the latest stable version 1.3.6 today...
> >
> >
> >
> > --
> > Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> > Bug reporting:         http://cygwin.com/bugs.html
> > Documentation:         http://cygwin.com/docs.html
> > FAQ:                   http://cygwin.com/faq/
> >
> >
>
>
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
>


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: bash/cmd CTRL-C problem...

[Michael Rumpf]

Hi,

sorry for following up myself, but I found out that Cygwin equally handles
CTRL-BREAK and CTRL-C by sending a SIGINT to the process.
See http://groups.yahoo.com/group/gnu-win32/message/27643 (last sentence).
This seems to be the source of the problem.
CTRL-BREAK under the cmd shell terminates the process after handling the
signal without further executing any code. The bad thing is that under bash
the same behaviour follows from pressing CTRL-BREAK  _and_ CTRL-C !!

If this is a design issue, can someone please explain what the reasons
are...

We have an application that forks other processes. The main thread is
waiting for the signal handler to return in order to cleanly stop the child
processes. By just stopping the parent process the child processes keep
running and I have to kill them manually each time I press CTRL-C. The same
application is working fine under windows cmd shell and bash under Linux ,
HP-UX 10/11, AIX4.x, and SunOS 2.5+...

Please help, I don't want to use the stupid windows cmd shell.... ;-)

Michael

----- Original Message -----
From: "Michael Rumpf" <michael@rumpfonline.de>
To: <cygwin@cygwin.com>
Sent: Thursday, December 20, 2001 7:47 AM
Subject: bash/cmd CTRL-C problem...


> Hi,
>
> I'm new to the list and I don't know if this problem is already solved,
but
> I couldn't find a hint neither on the archives nor on the FAQ or somewhere
> else on the net.
>
> My problem is related to bash/cmd and signal handling.
> In my app I installed a signal handler for SIGINT. The app is going into a
> wait loop and waiting for the exit flag from the signal handler to be set.
>
> When pressing CTRL-C in the windows cmd shell the application continues
> normally after the signal handler has been caught. Under bash the signal
> handler is also correctly called, but after that the app is exiting
> immediatly, i.e. not continuing with the code.
> Here is the source:
>
>
////////////////////////////////////////////////////////////////////////////
> /////////////////
> #include <windows.h>
> #include <stdio.h>
> #include <signal.h>
>
> bool loop = true;
>
> extern "C" void signalHandler(int sig)
> {
>    switch( sig )
>    {
>       case SIGINT:  // == 2
>          printf("SIGINT=%d\n",sig);
>          break;
>       default:
>          printf("default=%d\n",sig);
>          break;
>    };
>    loop=false;
> }
>
> int main(int argc, char* argv[])
> {
>    if (signal( SIGINT , signalHandler ) == SIG_ERR)
>       return -1;
>    printf("### ctrlbreak: Waiting now...\n");
>    while(loop)
>      Sleep ((DWORD) 1000) ;
>    printf("### ctrlbreak: Finished waiting now...\n");
>    return 0;
> }
>
////////////////////////////////////////////////////////////////////////////
> /////////////////
>
> Here the the output of the app under Win2K/bash:
> // bash                2.05a-2
> $ ./ctrlbreak.exe
> ### ctrlbreak: Waiting now...
> SIGINT=2
>
>
> // GNU bash, version 2.02.1(2)-release (i586-pc-cygwin32) B20.1
> bash-2.02$ ./ctrlbreak
> ### ctrlbreak: Waiting now...
> SIGINT=2
>
> // cmd.exe Win2k SP2
> ### ctrlbreak: Waiting now...
> SIGINT=2
> ### ctrlbreak: Finished waiting now...
>
>
> You can see that under the cmd shell the text "Finished waiting now..." is
> printed which does not come out under the bash. The app is not linked
> against any cygwin library. It is a plain VC++ console application. But
when
> I compile with gcc from the cygwin package I have the same result.
> Any hint would be greatly appreciated...
>
> Michael
>
> PS: I just downloaded the latest stable version 1.3.6 today...
>
>
>
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
>
>


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

bash/cmd CTRL-C problem...

[Michael Rumpf]

Hi,

I'm new to the list and I don't know if this problem is already solved, but
I couldn't find a hint neither on the archives nor on the FAQ or somewhere
else on the net.

My problem is related to bash/cmd and signal handling.
In my app I installed a signal handler for SIGINT. The app is going into a
wait loop and waiting for the exit flag from the signal handler to be set.

When pressing CTRL-C in the windows cmd shell the application continues
normally after the signal handler has been caught. Under bash the signal
handler is also correctly called, but after that the app is exiting
immediatly, i.e. not continuing with the code.
Here is the source:

////////////////////////////////////////////////////////////////////////////
/////////////////
#include <windows.h>
#include <stdio.h>
#include <signal.h>

bool loop = true;

extern "C" void signalHandler(int sig)
{
   switch( sig )
   {
      case SIGINT:  // == 2
         printf("SIGINT=%d\n",sig);
         break;
      default:
         printf("default=%d\n",sig);
         break;
   };
   loop=false;
}

int main(int argc, char* argv[])
{
   if (signal( SIGINT , signalHandler ) == SIG_ERR)
      return -1;
   printf("### ctrlbreak: Waiting now...\n");
   while(loop)
     Sleep ((DWORD) 1000) ;
   printf("### ctrlbreak: Finished waiting now...\n");
   return 0;
}
////////////////////////////////////////////////////////////////////////////
/////////////////

Here the the output of the app under Win2K/bash:
// bash                2.05a-2
$ ./ctrlbreak.exe
### ctrlbreak: Waiting now...
SIGINT=2


// GNU bash, version 2.02.1(2)-release (i586-pc-cygwin32) B20.1
bash-2.02$ ./ctrlbreak
### ctrlbreak: Waiting now...
SIGINT=2

// cmd.exe Win2k SP2
### ctrlbreak: Waiting now...
SIGINT=2
### ctrlbreak: Finished waiting now...


You can see that under the cmd shell the text "Finished waiting now..." is
printed which does not come out under the bash. The app is not linked
against any cygwin library. It is a plain VC++ console application. But when
I compile with gcc from the cygwin package I have the same result.
Any hint would be greatly appreciated...

Michael

PS: I just downloaded the latest stable version 1.3.6 today...



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/