Git: Capturing Ctrl-C in MINGW-Bash shell

[mrkita]

• [x] I was not able to find an open or closed issue matching what I'm seeing

Setup

git version 2.13.3.windows.1
built from commit: faaf2320f32f6ac52a69502c6b157b6ea4781f50
sizeof-long: 4
machine: x86_64

This is specific to MINGW64

NOTE: This problem does NOT occur with the MINGW32 package.

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

Microsoft Windows [Version 6.1.7601]

• What options did you set as part of the installation? Or did you choose the
  defaults?

Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Enabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

BASH

• What commands did you run to trigger this issue?

This is not specific to GIT, but rather for the GIT for windows installation and MSYS.

I am running a self created C# program, which attempts to capture a Ctrl-C event and cancel using an event handler like so:

    protected static void CheckForConsoleCancel(object sender, ConsoleCancelEventArgs args)
    {
        //Do cleanup here
    }

Main program flow:

Console.CancelKeyPress += new ConsoleCancelEventHandler(CheckForConsoleCancel);

• What did you expect to occur after running these commands?

I expected the program to reach my event handler allowing me to clean up my program before exit.

• What actually happened instead?

The program exits without calling my handler.

This problem DOES NOT happen with a windows CMD prompt, nor SH.exe provided with the installation.

I remember reading before that this was a problem with an older version of MSYS's BASH shell, but I can't find the link anymore... to my knowledge it was fixed there awhile ago.

[dscho]

If you want to intercept Ctrl+C in Git Bash, I fear that is possible only in MSYS2 programs... Maybe there's some stty option you can use before starting your application, but that's sub-optimal.

[PhilWim]

I kind of had the same problem where commands weren't killed when i hit CRTL+C.

This is how it came and how i solved it:

On my fresh windows installation i installed Git-2.14.2-64-bit. Then i faces the issue that commands (docker logs etc) keep on sending to console after i killed them through CRTL+C.

I reinstalled the older version which i know was working (Git-2.10.2-64-bit) on my old windows installation. Still same problem.

Then i found in an issue in mintty tacker a comment which leaded to a probably wrong cygwin dependency.

And exactly this is the case here. Uninstalling of Git-2.14.2-64-bit didn't wipe C:/Program Files/Git completely. Cygwin libs stayed.

So probably these broken libs were used also with the working version Git-2.10.2-64-bit.

Then i did manually clean git folder and reinstalled Git-2.10.2-64-bit and voila no issues anymore.

I guess also for updating to newer versions, old cygwin files stay and some users never face this problem. Obviously fresh installation leads into problems.

[worc]

I'm was running 2.14.2.windows.1 and in the whole MINGW64 Git Bash MinTTY shell on Windows 10 and running into the same or similar issue where CTRL+C didn't seem to be sending the correct signal.

In my case I'm starting up an http server using Node and closing it with CTRL+C. If I start the server using just node index.js, one process is spawned and can be closed with CTRL+C and the used port will be released.

If I start the same server using npm run demo (which itself is actually calling node index.js) two processes are spawned and CTRL+C will only close one of them, orphaning the server process and causing an EADDRINUSE error the next time I try to run npm run demo.

This bug doesn't show up on a Windows 7 box or on a Linux Mint box running Git 2.7.4. In both cases, two processes are spawned, but CTRL+C from the command line will close both and free up the port.

Installing 2.15.1.windows.2 didn't solve the problem. My installation of Git was in C:/Users/<username>/AppData/Local/Programs/Git originally. After uninstalling all of those files were removed and there was no C:/Program Files/Git folder to manually clear out. After reinstalling, Git is now installed at C:/Program Files/Git, but I'm still encountering the bug and still digging for a solution.

@PhilWim Do you have a link to that comment in the mintty tracker?

[jakubnavratil]

Thanks @PhilWim Uninstalling, wiping Program Files/Git folder and installing version 2.10.2-64 helped.
https://github.com/git-for-windows/git/releases/tag/v2.10.2.windows.1

[Broutard]

+1
Please provide a fix :(

[dwjohnston]

@Broutard - I suggest this:

I have a script called portkill.sh

#!/usr/bin/env bash
echo killing process on port $1
taskkill //PID `netstat -aon | grep $1 | grep -P '(?=LISTENING).*' -o -m1 | grep -P '\d*' -o` //F

Add it to your path, then run with portkill.sh 8000 or whatever.

[huyong007]

how to use your script?my solution is netstat -ano|findstr 3000 in cmd，and then taskkill /pid 3000 /F,pardon me my poor english.as a newer do you have a video to teach how to use the script ?

[dwjohnston]

@huyong007 -

Put the script in a file called portkill.sh
Add that folder to your PATH variable
run with portkill.sh 8000

[dscho]

Uninstalling, wiping Program Files/Git folder and installing version 2.10.2-64 helped.
https://github.com/git-for-windows/git/releases/tag/v2.10.2.windows.1

Sadly, this introduces regressions for fixes we made in the meantime.

Please provide a fix :(

Oh wow. This elicits quite a negative reaction here. Probably not what you expected.

If you want anybody to work for you, to solve your problem, you might want to take a different approach.

As to the original report: this should be addressed by our recent change in how processes are killed when the user presses Ctrl+C.

If it still does not work for you in Git for Windows v2.16.2, you may want to consider selecting the "ConHost" option rather than the "MinTTY" option as terminal for the Git Bash. That should fix the issue, too.

[dscho]

I cannot say that I am happy about the enthusiasm to leave all the hard work to me. Nevertheless, I think I have a fix for this now. It should hit https://wingit.blob.core.windows.net/files/index.html within 24h.

[dscho]

The newest snapshot at https://wingit.blob.core.windows.net/files/index.html should fix this. Please test.

[AnthonyPaulO]

Wow... I've been trying to figure out why ctrl-C was taking forever to register in my git bash for windows when running webpack-dev-server (a problem I've had for the past year) and found this issue, and as luck would have it find that it was fixed two days ago! I'll have to wait for it to get to a 'maintained' release state but I'm glad it's been fixed. I've been going through the comments as well as the author's (Johannes) summary of the history of this issue and want to thank him for taking this challenge and fixing it when others in the community would not. @dscho, perhaps an alternative perspective on this would help... perhaps nobody else was up to the task, and you are the only one in this community with the technical expertise to fix it; the Linus Torvalds or Richard Stallman of Git for Windows, so to speak. Whatever the reason, you are indeed the man... thank you!