This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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/


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