#135 signal handling seems broken
I can't seem to ctrl-c kill golang tests (go test ...) programs that I run in my msys2 terminal. go test programs are run as a child process of go.
I thought it was a bug with Go, but they seem to think this kind of stuff is a bug in the shell.
E.g., here https://github.com/golang/go/issues/4347 they say CYGWIN does not forward the signals properly. This was back in 2012 though...
As an experiment, I grabbed a small signal testing program:
#include <stdio.h> #include <signal.h> #include <unistd.h> void sig_handler(int signo) { printf("sig %d\n", signo); fflush(stdout); } int main(void) { if (signal(SIGINT, sig_handler) == SIG_ERR) { printf("\ncan't catch SIGINT\n"); } while(1) sleep(1); return 0; }
Here's what happens when I run it in msys2, and hit ctrl-c
user@user-PC /d/prog/signal $ gcc signal.c && ./a.exe user@user-PC /d/prog/signal
So it doesn't look like the signal is really being sent; the program is just killed.
Here's what happens when I run the exact same executable in cmd.exe:
D:\prog\signal>a.exe sig 2 ^C D:\prog\signal>
(I had to hit ctrl-c twice to really quit)
So is signal handling just busted in msys2? It seems like there may be issues with native windows processes receiving signals (like in go's case), but why would my own process compiled with gcc not be able to receive signals inside the msys2 shell? In the first case, perhaps you could see if the running programs were a native program, and if so, send the appropriate message instead of signal? In the second case, I don't know what's going on. I'm also not entirely clear about the distinction between CYGWIN/msys2/MinGW, so please redirect me if need be.
FWIW, I'm running msys2 that was installed from msys2-x86_64-20141113.exe
As MSYS2 is derived from Cygwin it have the same issues.
Do you still see the same issue? I compiled this program and I see one "sig 2" per every ^C pressed (the program does not exit) in both mintty and Windows console.
I'm using msys2-runtime 2.1.0.16305.2579661-2.
I updated everything. msys2-runtime is at 2.1.0.16305.2579661-2; mintty is at mintty svn-trunk-r1322 (x86_64-pc-msys).
I still see the same issue. Using mintty, I do not see any ^Cs, the program just immediately exits when I hit control-c. Using windows console, I only see the first ^C, the second causes the program to quit. I'm on windows 7; perhaps this is different in different versions of windows.
Oh, I'm sorry. I compiled using msys2-gcc. I see what you see, when I compile using mingw.
It seems mintty is really somehow eating the Ctrl+C's.
Given the huge amount of results for "mintty ctrl c" on Google, regarding both Cygwin and mintty, I'm not sure who's to blame. Running the program inside bash in a regular Windows console gives "sig 2", so it seems to be tied to something mintty does. Running the program as
wintpy ./areverses the effect.Any update?
I've the same issue. For instance run cdb (Debugging Tools for Windows) inside a Mintty bash shell. Cdb use Ctrl-C to stop debugging, but on Ctrl-C my complete debugging session is kill!
That's a mintty issue. I've tried Cygwin inside a Dos Box and Cygwin inside a Mintty terminal. The Dos Box handles the Ctrl-C signal correct, Mintty not.
Mintty and urxvt have the same issue. Only Cygwin bash via Dos Box works.
Please don't call the Windows terminal "Dos Box", this only confuses people (DOSBox is an unrelated product).
Taking mintty's comment into account, this is either an issue common in mintty and urxvt, or an underlying issue in Cygwin. Either way, it seems there's little incentive for anyone to work on this, possibly because there's no clear solution. I suggest you first try looking around the Internet or digging into the code to find out what exactly makes mintty/urxvt kill processes upon Ctrl+C instead of passing the right signal. A discussion pointing to a specific piece of code will be more effective in persuading people to join and help.
I'm a user and as user I want to execute each command line program via terminal and expect right behaviour. The terminal should handle all signals well. No matter whether is it a Unix based or Windows pty based signal.
It's not possible to come up with code. Cdb is Microsoft closed source tool.
Perpaps this tool [winpty]https://github.com/rprichard/winpty) fills the gap.
As a user of free open-source software maintaned by volunteers, you should also understand that not every user wish can be fulfilled. I'm not saying the current situation is ideal, but it's not bad enough to get much developer attention.
Also, keep in mind that mintty is not advertised as a universal terminal. Its author tries to make it very clear that it's designed to work with Cygwin/MSYS2, and full compatibility with native Windows programs is not among the project's goals.
I was talking about the code of Cygwin and mintty.
If you're okay with using winpty, that should solve the problem for you. I assumed that you didn't want to use it, as you didn't react to me mentioning it.
It's a very unreal working scenario that I use one terminal for Unix like tools and another terminal for Dos tools. Sorry, I do claim that the most user mixing MSYS2 binaries with native Windows binaries in the same session.
Winpty works well and fills the gap. Please place a note at the MSYS2 FAQ for the next one which fall for it. Thanks.
MSYS2 is a very good environment, I like it really.
Good to hear you didn't throw MSYS2 into the trash. :)
https://sourceforge.net/p/msys2/wiki/Porting/#signals-in-mintty
No no it's a create tool suite and I use it every day and stay happy!