CTRL-C doesn't interrupt the running process

[improbablepiotr]

When I run any program that will take a bit longer to complete and CTRL-C interrupt it while it runs, the console will release and go back to the command prompt, however the program continues to run and print asynchronously to the console window.

For example:

me@my-pc ~
$ gradle build
<CTRL-C>
me@my-pc ~
$ :buildEnvironment
------------------------------------------------------------
Root project
------------------------------------------------------------
classpath
No dependencies
BUILD SUCCESSFUL
Total time: 1.463 secs

This is the case for any program, not just gradle. I've seen this with Cygwin and GitBash - seems they have the mintty in common, while this doesn't happen with ConEmu.

This only started since I have updated from git-for-windows (GitBash) 2.10.2 to 2.14.1.

[mintty]

Really any program? Try sleep 99, Ctrl+C, check with ps - no more sleep.
What does which gradle say? I guess it's a non-cygwin program. There is lack of interworking with non-cygwin programs in a cygwin environment with respect both to pty handling as well as signal handling.

[improbablepiotr]

Thanks for your response. I have investigated a bit further and it seems that gradle was in fact a choco shim starting another process, which was then not killed after Ctrl-C.

There is still an issue here, however. When I Ctrl-C, the running program gets killed rather than interrupted. This prevents applications from cleaning up properly and leads to leaking the processes.

You can try reproduce with this Go gist.

When I run this in ConEmu, PowerShell, cmd, everything is handled as expected:

$ ./int_test.exe
Still alive...
Still alive... <CTRL-C>
Received signal: interrupt
Died.
$

But, when I run this via GitBash or Cygwin, the interrupt signal is not passed correctly to the program:

$ ./int_test.exe
Still alive...
Still alive... <CTRL-C>
$

Also, this wouldn't be end of the world if the whole process tree was killed properly. Unfortunately, seems like the child processes are not killed. (BTW, taskkill.exe /PID <pid> /T /F can do this properly).

[k-takata]

Obviously int_test.exe is not a Cygwin program.
Such program should work as expected if you execute it via winpty.

[improbablepiotr]

@k-takata thanks for pointing me in the right direction. That's right, when I run this with winpty, it does interrupt correctly.

What is strange is that we did not experience the issue with the whole process tree not being killed with mintty 2.6.2 (git-for-windows 2.10.2). We only started to experience problems when using mintty 2.7.7 (git-for-windows 2.14.1).

[mintty]

Cannot reproduce any processes other than it itself to appear at all, so I cannot check either whether they are killed. Without further evidence, I can only close the issue.
Also, there has been no related change between 2.6.2 and 2.7.7. If thery is a difference, it could be depending on the cygwin DLL.

[improbablepiotr]

@mintty & @k-takata what are our options if we'd like to make our (Golang) program properly interruptible in Cygwin? Having to always run winpty -- <command> for all non-Cygwin programs is not a great user experience.

[mintty]

You could make a wrapper for invocation of course.
But I agree this is not great. You may raise an issue in the git-bash project, or may raise your request directly on the cygwin mailing list. In any case, it's not a mintty issue.

[PhilWim]

Any news here, i'm facing the exact same issue.

We didn't have that problem with pre git-for-windows 2.14.1 versions as well. Problem appeared in 2.14.1 and even reinstalling old didn't change it.

[PhilWim]

Ok, the pointer, that maybe cygwin is the problem here, leaded me to search for cygwin files. Turned out that there are some cygwin related files in git folder - which are not getting deleted on uninstalled.

So these files might have the problem - not sure if this is git-for-windows related or mintty.

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

[mintty]

This sounds mysterious, but glad it's solved for you.

[mintty]

Same issue? gradle? int_test.exe?
If at all, your additional report could only help if you describe your symptoms, what program you invoke, how you built it, etc.

[saleyn]

Having a slightly different issue with Ctrl-C. When a mintty terminal is started like this:
C:\cygwin\bin\mintty.exe -e /bin/xhere /bin/bash.exe "%V"
And a program is run that intercepts Ctrl-C, hitting a Ctrl-C will kill the program without allowing it to run a handler of that keystroke.

On the other hand, if a shell is started by running C:\cygwin\bin\bash.exe directly, then a program executed under bash interrupted with Ctrl-C will handle that interrupt correctly. So it looks like it's a mintty-related Ctrl-C issue.

Version:

mintty 2.8.2 (x86_64-pc-cygwin)
© 2013/2017 Andy Koppe / Thomas Wolff

[mintty]

Why do you think it's mintty-related? Mintty only forwards the Ctrl-C to the pty (the cygwin-managed communication interface), which then may generates an interrupt (or not, as configured) to the application, which may then ignore or catch the interrupt (as configured). If the only difference is xhere in your case, I would suspect that first.

[saleyn]

I tried executing the program by starting a shell in one of the following four ways:

1. C:\cygwin\bin\mintty.exe -e /bin/xhere /bin/bash.exe "%L" - Ctrl-C doesn't work correctly
2. C:\cygwin\bin\mintty.exe -e /bin/bash.exe - Ctrl-C doesn't work correctly
3. C:\cygwin\bin\bash.exe - Ctrl-C works correctly
4. C:\cygwin\bin\bash.exe -c "/bin/xhere /bin/bash.exe '%L'" - Ctrl-C works correctly

The test program is a very simple .NET console app listed below. Correct "Ctrl-C" behavior: "Setting abort flag" is printed, and the program is exited gracefully. Incorrect behavior - nothing is printed, the process is killed:

namespace Test {
  class Program {
    static bool Abort { get; set; }
    static void Main(string[] args)
      Console.CancelKeyPress += (c, ev) => {
        Console.WriteLine("Setting abort flag");
        ev.Cancel = true;
        Abort = true;
      };

      var end = DateTime.Now.AddSeconds(60);
      while(!Abort && DateTime.Now < end)
        Thread.Sleep(1000);
    }
  }
}

Or a similar test in C++:

#include "stdafx.h"
#include <windows.h>
#include <stdio.h>

BOOL CtrlHandler( DWORD code )
{
  switch( code )
  {
    // Handle the CTRL-C signal.
    case CTRL_C_EVENT:
      printf( "Ctrl-C event\n\n" );
      return true;

    // CTRL-CLOSE: confirm that the user wants to exit.
    case CTRL_CLOSE_EVENT:
      printf( "Ctrl-CLOSE event\n\n" );
      return true;

    // Pass other signals to the next handler.
    case CTRL_BREAK_EVENT:
      printf( "Ctrl-BREAK event\n\n" );
      return false;

    case CTRL_LOGOFF_EVENT:
      printf( "Ctrl-LOGOFF event\n\n" );
      return false;

    case CTRL_SHUTDOWN_EVENT:
      printf( "Ctrl-SHUTDOWN event\n\n" );
      return false;

    default:
      return false;
  }
}

int main()
{
  if(!SetConsoleCtrlHandler( (PHANDLER_ROUTINE) CtrlHandler, TRUE)) {
    printf( "ERROR: Could not set control handler: %d", GetLastError());
    return 1;
  }

  printf( "\nThe Control Handler is installed.\n" );
  printf( " -- Now try pressing Ctrl+C or Ctrl+Break, or\n" );
  printf( "    try logging off or closing the console...\n\n" );

  while (true)
    Sleep(1000);
}

[mintty]

So it's not a cygwin program (which you didn't mention before).
This explains everything. Windows console signal handling is not compatible with cygwin signal handling.
The winpty wrapper can mediate between them, however, plus other goodies.
This has been mentioned before. It's not a mintty issue.

[saleyn]

Thank you for clarifying

[mihab]

I have the same issue running maven. If I execute
mvn clean install

and then try to stop the process with CTRL+C, it does not work. It terminates fine in CMD and WSL ubuntu bash.

Is there any specific trick needed to get this working?

[mintty]

winpty

[mihab]

Actually it does not work:

miha@DESKTOP-CEC4TIT MINGW64 ~/Desktop
$ winpty mvn
winpty: error: cannot start 'mvn': Not found in PATH

miha@DESKTOP-CEC4TIT MINGW64 ~/Desktop
$ winpty which mvn
/c/Users/miha/Dev/maven/3.5.2/bin/mvn

So maven quite obviously is installed, and cannot be interrupted without winpty, and does not work with winpty. Any other possible solution?

[chocolatekitkat]

I'm on Windows 10 and when doing a git diff after it's completed I hit CTRL+C then the process ends and when I get to prompt I can't see any characters that I type, but when I hit return it shows what I typed even though I can't see the characters. So if I type dddksdjfl I can't see it but when I hit enter I see - bash: dddksdjfl: command not found. This is new the last couple of releases. Any way to show the characters again? Should I try not using mintty in setup of Git? Have to keep starting new windows to get any work done :( (newbie) Thanks!

[mintty]

What do the following commands respond:
echo $TERM
uname -a
type git
type less

[chocolatekitkat]

echo $term - nothing
uname -a
MINGW64_NT-10.0 fizz 2.10.0(0.325/5/3) 2018-02-12 08:49 x86_64 Msys
type git
git is /mingw64/bin/git
type less
less is /usr/bin/less

[mintty]

echo $TERM, please, verbatim as I had requested.

[chocolatekitkat]

< echo $term

<

[mintty]

I was asking $TERM, not $term.

[chocolatekitkat]

erg. sorry. newbie... :(

< echo $TERM
xterm

[mintty]

First diagnostics give not immediate hint, I'll check tomorrow.
However, you don't need to leave git diff with Ctrl+C, just type q to exit the display tool (most likely less).

[chocolatekitkat]

Yeah, I just found q. Still a strange result. Thanks!

[dereklin]

I am running cygwin 2.10.0(0.325/5/3)
I have a UI project with storybook installed: https://github.com/storybooks/storybook
When storybook is running (on port 6006), I can see this:

$ netstat -o -n -a | findstr 0.0:6006
  TCP    0.0.0.0:6006           0.0.0.0:0              LISTENING       26956

When I do Ctrl + c, the process is still running

When I run storybook on a normal Command Prompt, Ctrl + c kills the process as expected.

[mintty]

netstat is not a cygwin program. Signal handling of native Windows program and cygwi does not interoperate well. For a workaround, see comments above about winpty.

[dereklin]

which npm produces this:

/cygdrive/c/Users/delin/AppData/nvm/v8.9.1/npm

How can I tell if this is a cygwin program or not?

The issue I am facing is that when I start an app with

npm start

The site is hosted, say, at http://localhost:3000

When I do CTRL-C, and then npm start again, it would complain the port is still in use.

$ winpty -- npm start
winpty: error: cannot start 'npm': Not found in PATH

$ winpty /cygdrive/c/Users/delin/AppData/nvm/v8.9.1/npm start
winpty: error: cannot start 'C:\Users\delin\AppData\nvm\v8.9.1\npm start': %1 is not a valid Win32 application. (error 0xc1)

I am trying to use winpty, but what is the correct syntax?

[k-takata]

If a command is a batch file (*.bat or *.cmd) or another script file, winpty cannot execute it without the extension.

How can I tell if this is a cygwin program or not?

Normally cygwin programs are installed in /bin, /usr/bin or /usr/local/bin.

[dereklin]

@k-takata Thanks for the tip on adding .cmd. This is working for me:

winpty -- /cygdrive/c/Users/delin/AppData/nvm/v8.9.1/npm.cmd start

[0xR]

Putting this in .bashrc / .zshrc might help:

alias npm="winpty -- /cygdrive/c/Program\ Files/nodejs/npm.cmd"

Adjust to the location of your npm installation accordingly.

[Bilge]

I have this problem with Symfony Console commands; they cannot be aborted with CTRL+C. I don't believe this ever used to happen on Windows 7, though, only since upgrading to Windows 10.

[mintty]

From the point of view of the terminal, Ctrl+C is a plain normal character, nothing special.
Its interpretation as an interrupt signal is a matter of the terminal driver (tty/pty).
"Symfony" sounds like a non-cygwin tool, so in addition you have the interworking problem with Windows programs. This will be much improved (if not even solved) with the next cygwin release, supporting the ConPTY API. Again, this is not a terminal issue, thus marking invalid.

[mintty]

This will be much improved (if not even solved) with the next cygwin release

In the meantime, there is still the winpty tool which mediates also signal processing.

[Bilge]

winpty does nothing for me but spit out errors. Again, it's something I believe worked on Windows 7 but not on 10. Specifically, it always returns:

winpty: error: cannot start '"C:/Users/Bilge/foo"' %1 is not a valid Win32 application. (error 0xc1)

Do you know when the next Cygwin release might be?

[mintty]

You can try test release 3.1.0 already.

[Sleepful]

winpty does nothing for me but spit out errors. Again, it's something I believe worked on Windows 7 but not on 10. Specifically, it always returns:

winpty: error: cannot start '"C:/Users/Bilge/foo"' %1 is not a valid Win32 application. (error 0xc1)

you have to specify the extension of the file you run with the comment, refer to my comment here:
rprichard/winpty#154 (comment)

It's funny because git-for-windows has no problem terminating the processes with ctrl-c, no idea if this is a mitty or cygwin issue. I'm using Msys2.

[Bilge]

you have to specify the extension of the file you run

No, you don't. You do, however, have to specify a real binary. It does not work with shebang lines.

[Sleepful]

oh well I can't tell what your foo is, if it did have an extension then you need to put the full name of the file, otherwise ignore

[agorgl]

Problem persists in mintty 3.5.0 with programs such as maven.
Running mvn clean spring-boot:run on a sample project and then typing Ctrl-C, does NOT send the signal to the maven process and it seems like the process is semi-killed?/backgrounded? because I need to do taskkill /f /im java.exe to kill the zombie process. Same happens with node/npm and similar if I remember correctly. Similar workflow on ConEmu/conhost works fine.

Using mintty bundled with latest msys2.

[agorgl]

Interestingly enough, same operations on mintty bundled with git for windows work as they should. I suppose their fork handles some things in a different way?

[mintty]

MSYS2 and Git for Windows disable "ConPTY" support by default. Actually ConPTY is supposed to improve such interworking problems, not make them worse. Please report this to the cygwin mailing list, it's not a terminal issue.