CTRL+C abort does not work via pre-built executable #2592
Description
Setup
- Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
Comparing the same 2.26.1 version with Windows 10 and Windows 8.1, 64-bit.
$ git --version --build-options
git version 2.26.1.windows.1
cpu: x86_64
built from commit: 14af9f9d205f4a6a033c7b6f48980d1eeee2c610
sizeof-long: 4
sizeof-size_t: 8
- Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
Windows 10 64-bit, comparing with Windows 8.1 64-bit
$ cmd.exe /c ver
Microsoft Windows [Version 10.0.18363.778]
- What options did you set as part of the installation? Or did you choose the
defaults?
Same options in both Windows 10 and Windows 8.1.
$ cat /etc/install-options.txt
Editor Option: VIM
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Disabled
Enable Symlinks: Disabled
- Any other interesting things about your environment that might be related
to the issue you're seeing?
Have enabled/installed WSL (Windows Subsystem for Linux) and installed VS Code in Windows 10.
Details
- Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other
Bash, Run Command (WIN+R)
- 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.
mvn package
Or any other long-running executable process, except any Windows Batch (.cmd/.bat) script, preferably a complex shell-native script (a simple script with a while loop will not reproduce the issue).
- What did you expect to occur after running these commands?
The running process is immediately aborted, in certain cases via a confirmation (Windows 10):
Terminate batch job (Y/N)? y
- What actually happened instead?
Nothing. The process could not be aborted. No confirmation to abort.
- Are there any other reproducible tests?
All recent similar issues have been closed without resolution, for e.g. #2471, #1470. One that was resolved some time ago is #1317. StackOverflow has an interesting discussion, centred on the --login argument.
I am filing this ticket to seek help in troubleshooting this, with some added information. Here is some testing outcome:
- Running the Windows Batch script equivalent (.cmd/.bat) directly with the absolute path does not exhibit this issue, e.g.
/c/programs/maven/bin/mvn.cmd - Running a shell-native wrapper script exhibits this issue, e.g.
/c/programs/maven/bin/mvn - Changing the shebang in shell scripts using
/bin/sh,/bin/bash,/usr/bin/sh,/usr/bin/bashmakes no difference - Running
C:\Program Files\Git\bin\sh.exe --login -ifrom Run Command (WIN-R) does not exhibit this issue - Windows 8 did not originally exhibit this issue
- After running the shell script explicitly with the absolute path, and not the Batch script, Windows 8 exhibits this issue
The only sure-fire way to get CTRL+C to work is to invoke directly the Batch script equivalent of whatever you want to run, if any (if not, tough luck), AND, to execute directly the Bash binary via Run Command.
Running (Git) Bash via the branded shipped executable in the binary distribution exhibits this problem, mostly in Windows 10 but not in Windows 8.1. The interpreter defaults to calling the shell-native script, instead of the Windows script, if available (it appears that in Windows 8.1 this is not the case).
As a first step, it would be good to learn what the default executable binary git-bash does differently from executing Bash directly via Run Command. (Side note: it looks "uglier"; dull colours, huge default window size) Another hypothesis is that it has got something to do with Java (the example I used) or exec (forking and subprocesses promotion).
Caveat: I used mvn as an example and generalized it to a "shell-native script". I also used mvn.cmd as an example and generalized it to a "Windows Batch script equivalent".