Git: Ctrl+C no longer kills running process in Git Bash

[adamvoss]

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

There are older issues about Ctrl + c but this is specifically about a regression in behavior from 1.15.1.2 (confirmed by downgrading) to 1.16.1.

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.15.1.windows.2
built from commit: 5d5baf91824ec7750b103c8b7c4827ffac202feb
sizeof-long: 4
machine: x86_64

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

$ cmd.exe /c ver
Microsoft Windows [Version 10.0.15063]

# (Windows 10 64-bit)

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

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: VIM
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?

I don't believe so

Details

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

Git Bash

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

git clone https://github.com/rimerosolutions/maven-wrapper-example
cd maven-wrapper-example
./mvnw
*press crtl+c*

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

The ./mvnw command to be aborted

• What actually happened instead?

The ./mvnw command continued until it stops for unrelated reasons

A machine-local Maven install presents the same issue, I don't have a lot of other long-running commands to test with.

[dscho]

Hmm. We recently did change the way Ctrl+C works in Git Bash (MinTTY), to resemble more closely what happens in Git Bash (CMD). That should have made it more robust, though, not less robust.

[adamvoss]

Would it be helpful if I tested both version with Git Bash (CMD) installs as well?

[dscho]

@adamvoss it certainly would not hurt, but in general, the Ctrl+C handling is so different between MinTTY and a CMD window that I would always expect the latter to work, without even hitting the code paths we patched in the past few years to address Ctrl+C issues.

[dscho]

@adamvoss could you try running winpty ./mvnw?

(I do not really want to install Java just to test this, let alone risk Maven downloading half the internet, in that sense this MCVE is not really "minimal" for me ;-))

[adamvoss]

winpty does does not work with the Maven wrapper:

$ winpty ./mvnw
winpty: error: cannot start 'C:/Users/user/dev/maven-wrapper-example/mvnw': %1 is not a valid Win32 application. (error 0xc1)

For reasons I don't understand, winpty can't start Maven:

$ winpty mvn
winpty: error: cannot start 'mvn': Not found in PATH

even though it does exist on the path:

$ winpty which mvn
/c/Users/user/AppData/Roaming/maven/apache-maven-3.5.2/bin/mvn

circumventing the path lookup does not help:

$ winpty $(which mvn)
winpty: error: cannot start 'C:/Users/user/AppData/Roaming/maven/apache-maven-3.5.2/bin/mvn': %1 is not a valid Win32 application. (error 0xc1)

mvn is a shell script. If I directly execute the command its execs to do the work, Ctrl + C works:

/c/Program Files/Java/jdk1.7.0_80/bin/java -Djansi.passthrough=true -classpath /c/Users/user/AppData/Roaming/maven/apache-maven-3.5.2/boot/plexus-classworlds-2.5.2.jar -Dclassworlds.conf=/c/Users/user/AppData/Roaming/maven/apache-maven-3.5.2/bin/m2.conf -Dmaven.home=/c/Users/user/AppData/Roaming/maven/apache-maven-3.5.2 -Dlibrary.jansi.path=/c/Users/user/AppData/Roaming/maven/apache-maven-3.5.2/lib/jansi-native -Dmaven.multiModuleProjectDirectory=/c/Users/user/dev/maven-wrapper-example org.codehaus.plexus.classworlds.launcher.Launcher clean compile

^ Ctrl+C works fine

[dscho]

Is mvnw a shell script? Or a .bat/.cmd file?

[adamvoss]

mvnw is a shell script.

[dscho]

mvnw is a shell script.

Okay, then...

$ winpty ./mvnw
winpty: error: cannot start 'C:/Users/user/dev/maven-wrapper-example/mvnw': %1 is not a valid Win32 application. (error 0xc1)

probably means that you have to use winpty sh "$(which mvnw)" instead...

[Thex-PiedDroit]

Hi, sorry to interrupt!
I have this same issue, but i'm kind of new to all things git and console, so i followed the discussion until you started talking about winpty, which i don't really understand what it is.

Anyways, from what i gathered, i understand that changing the way Ctrl+C is handled couldn't hurt, however i would like to know if you (or anyone, really) could tell of an alternative hotkey or workaround to do what Ctrl+C used to, please?
I personally mainly used it to cancel stuff like pulls and pushes, or simply close gitk/gui without having to find the window, so i don't really need anything rough like kill command with pid and all

[adamvoss]

winpty sh "$(which mvn)"

Works. However, it is near unusable because all the color control characters are not interpreted so I get a bunch of extra control characters like in [?[1;31mERROR?[m].

[dscho]

@adamvoss yet another question: if you run plain mvn, does it use java.exe or javaw.exe to run?

(I am trying to get to the point where I understand which Win32 Console is used by mvn, and whether it may be different from the Win32 Console used by the Java process, which would explain things.)

[adamvoss]

It uses java.exe.

I also confirmed by watching in task manager when I called mvn and double checked $(which java):

$ echo $(which java)
/c/Program Files/Java/jdk1.8.0_152/bin/java

[dscho]

Ah, but you talked about mvnw earlier, right? Is there a difference with regards to Ctrl+C whether you call mvn or mvnw?

[adamvoss]

Nope, same problem with both. I only used mvnw to start with to give an example that did not require having Maven installed.

[dscho]

One more tack: if you choose the ConHost option for Git Bash (as opposed to MinTTY) -- you can simulate that by installing a portable Git (that won't interfere with your current installation), deleting usr\bin\mintty.exe and then running git-bash.exe -- does it work? Ctrl+C and coloring?

[adamvoss]

Just to make sure I did everything expected:

1. Download "64-bit Git for Windows Portable"
2. Extract the download (used 7zip)
3. Within the extracted directory delete usr\bin\mintty.exe (using Windows Explorer)
4. Within the extracted directory, run git-bash.exe (by double-click in Windows Explorer)

Doing the above then cding to a Maven project and running mvn I find that Ctrl+C works, but coloring prints as gibberish control characters.

[ozymandias13]

Not sure if this helps, but I can confirm that the winpty solution also overcomes the CTRL-C issue for me, but it also does wreck the colors in the output. I see similar gibberish characters being printed for the color control characters.

[alebr001]

You can also use ConEmu and open git bash there. There are no problems whatsoever. Ctrl-C works and the colors are normal (and adjustable to your own liking).

[jeacott1]

ctrl+x doesnt do anything either in at least the latest rev. an earlier version I was using worked fine.

[dscho]

I worked about 50 hours on this during the past two weeks and I think I finally got a workable solution to this. Stay tuned.

[dscho]

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

[Thex-PiedDroit]

I tried to kill git gui and gitk in this fashion but it still doesn't seem to be working i'm afraid.
(I did double-check that i was running the correct version)

[ozymandias13]

Confirmed it still doesn't work for mvn or mvnDebug, I'm sorry to say. Tested the latest snapshot. I very much appreciate your effort on this!

[dscho]

I just had a look at this, and it seems that

/c/ProgramData/Oracle/Java/javapath/java -Dmaven.home=/d/test-git/mvnw-ctrl-c-1470 -Dmaven.multiModuleProjectDirectory=/d/test-git/mvnw-ctrl-c-1470/maven-wrapper-example -classpath /d/test-git/mvnw-ctrl-c-1470/maven-wrapper-example/maven/maven-wrapper.jar org.apache.maven.wrapper.MavenWrapperMain

can be interrupted, but wrapping that call in sh -c "exec [...]" makes it uninteruptible. That makes me believe that somewhere along the lines, a process in the child process chain goes missing and when we enumerate the processes together with their parent process IDs, we have no way of knowing that the java.exe process was a transitive child process of the one we want to kill. That analysis might be very wrong, of course.

One way to find out would be for you to go ahead and simplify the reproducer to not run a full-blown Maven, but instead a custom class. This class can be very simple, e.g. outputting a . every second or so. Then call this class' main function via sh -c "exec ..." and inspect the processes, in particular their parent IDs. (You can use ps -W in another Git Bash for that.)

[JanMosigItemis]

I can confirm that this bug exists in 2.20.1.windows.1 and it is very annoying ;) Is there anything I can help you with?

• Windows 10.0.17763.195
• git 2.20.1.windows.1 64 bit
• Java 1.8.0_192
• Maven 3.3.9

Updated on 2018-21-12

[dscho]

I got stuck on other projects, so I cannot continue on https://github.com/git-for-windows/msys2-runtime/compare/master...dscho:ctrl-c-harder for now, but I suspect that this will help.

Assuming that you are unfamiliar with C++ and therefore cannot help, I fear that you'll have to wait until that stabilizes and then lands.

[JanMosigItemis]

Thanks for the info. Do you have any idea when this will be released? Will it come with the next version?

[dscho]

Dude, I just told you that I am stuck on other projects, and prodding me even further is not exactly helpful.

[JanMosigItemis]

Sry, this wasn't my intention. I just wanted to check because this information helps with deciding whether or not to "roll out" workarounds. If the answer is "When it's done" then this is just fine.

[dscho]

@JanMosigItemis you could check out the branch I indicated, test in 64-bit and 32-bit SDKs and come back with your findings. That would help. I did not yet have a chance to test in a 32-bit SDK, in particular with 64-bit processes that need to be interrupted.

Also, we need to skip the signaling when IsProcessCritical() says that it is critical. This function was added only in Windows 8.1, according to the documentation, so we will have to load that symbol dynamically, similar to this code, and we will have to handle the case gracefully where NULL was returned.

Those are all things you can help with.

[JanMosigItemis]

Unfortunately I am no Windows C developer, so I could not provide any support on this I'm afraid. However, I just wanted to document for the occasional reader, that the issue is still valid and did not went away with latest release 2.20.1.windows.1.

[dscho]

I am no Windows C developer

I am no Windows C developer, either.

Whatever I picked up over the course of the years is what (and when) I needed it. If you truly want to see this issue resolved, you can do the same. It's not witch craft, and I even documented how to (re-)build the msys2-runtime. In the meantime, it has become even easier: install Git for Windows' SDK, sdk build msys2-runtime. Then, to hack on it, sdk cd msys2-runtime and work on the source e.g. by pulling my branch (but then rebuilding the msys2-runtime not via sdk build msys2-runtime, as that would do the wrong thing, I haven't gotten around to fixing that yet, too many other fires to put out, but instead use the instructions at https://github.com/git-for-windows/git/wiki/Building-msys2-runtime#rebuild-the-msys2-runtime).

And whenever you get stuck, just reach out, I'll help. What I won't do is to look favorably on bystanders who are happy to leave all the work to me.

[dscho]

I'll close this ticket due to inactivity.