Vscode: Integrated Terminal: ctrl-c doesn't work in PowerShell and cmd.exe

[Chiliyago]

• VSCode Version: 1.31
• OS Version: Windows

Steps to Reproduce:
In version 1.3.1 I noticed that ctrl-c does not work and prevents exiting the current command. In my case I configured terminal to open PowerShell.

Example:

PS: >mkdir
cmdlet mkdir at command pipeline position 1
Supply values for the following parameters:
Path[0]:  <<ctrl-c should exit but it does not work>>

[Tyriar]

@gerane @daviwil is this a recent regression?

[daviwil]

I haven't tried it in previous builds so I'm not sure whether it ever worked.

[gerane]

Yeah, it's never worked for me.

[jmreicha]

Any update on this?

[gerane]

This might be caused by psreadline. I need to test it when I get a chance. I know I've noticed that it sometimes works and sometimes doesn't work. Also, sometimes if you click into a different part of the terminal and try it will work, but other times doing the same thing doesn't work. Ctrl+c doesn't work most often when a long running command is started. Shorter commands seem to have a better chance of worling if I recall. I often have to close the terminal out and open a new one because no matter what I try it won't stop.

I started work on documenting the impact of Psreadline on the terminal late last week here.

https://github.com/gerane/LineEndings

However, I got sick and am still not totally better so I haven't been able to work on it. I'm trying to help get as many of the issues documented with examples so we can start determining how we can improve the experience with powershell. Since windows 8 PSreadline is bundled with the OS and gets imported by default in ConesoleHost, so there are likely a lot of people who see these issues.

Another issue caused by Psreadline is ctrl+c for copy doesn't work in the prompt, only when highlighting in the output. At least I'm assuming it's caused by psreadline, haven't gotten to testing that yet.

I'll try to work on documenting the ctrl+c issues when I'm feeling better. I was starting to talk with @daviwil @tyriar and a few others about it last week, but then I started to get sick.

[midnightfreddie]

I've recently started using the VSCode terminal for Powershell commands. (Windows v1.8.1.) I open the terminal, type Powershell then run commands.

I'm used to hitting control-C to clear the input line when I mistype a command or change my mind, but this does not clear the line in VSCode terminal as it does in the native console, so I have to backspace the entire line.

I mention this in case it's helpful/related to this issue, as it seems to me it might be.

[tylerjwatson]

I heeded some of the comments here alluding to it being PSReadline so I removed it, and can confirm it still happens even with PSReadline removed. The only difference being that PSReadline will echo the ^C glyph to the console, whereas the vanilla console will swallow it as a control character, but still not perform as intended.

[Tyriar]

Upstream issue: https://github.com/Tyriar/node-pty/issues/7

[daveaglick]

I noticed this as well and have some data that may (or may not) be helpful. It looks like Ctrl-C is sent to C# applications as (ConsoleKey)3 from the VS Code terminal, which isn't even a valid value for the ConsoleKey enum. It's also not sent with the ConsoleModifiers.Control modifier as one would expect. However, even though it sends a odd value for Console.ReadKey(), it's still also interpreted as a cancel combination and will be handled by Console.CancelKeyPress. Even though this behavior is all being observed in a C# application, I suspect the terminal is sending similar odd data to any hosted process.

[parkovski]

I fixed this on my own copy - the issue was src/agent/ConsoleInput.cc:398 which should not depend on the input mode:

    if (input[0] == '\x03') {
        // ...

and line 403, the early return in that block, should be deleted.

I'm not sure how this affects other uses of winpty, but it fixes Ctrl-C in the VSCode console for me. Here's a patched copy of winpty-agent.exe for anyone that needs this now (64-bit) - replace C:\Program Files\Microsoft VS Code\resources\app\node_modules\node-pty\build\Release\winpty-agent.exe with this and Ctrl-C should work in your integrated terminal.

[Gonkers]

So what's the status on this? ctrl+c still doesn't work for me.

If I use c:\windows\System32\cmd.exe the keystroke just gets swallowed somewhere and has no effect.

If I use C:\WINDOWS\Sysnative\WindowsPowerShell\v1.0\powershell.exe as my shell, it just replicates ^C on my console output.

If I use C:\Windows\Sysnative\bash.exe as my shell ctrl-c works just fine.

Windows 10 pro fully patched as of today using v1.16.0 of VS Code.

Edit: powershell example

[parkovski]

Can you try my patched copy of winpty-agent.exe and let me know if it works? If that fixes it for more than just me I can try to get that change merged into the project.

[campersau]

@parkovski Thanks! It works better now. But in the normal powershell you can also abort the Terminate batch job (Y/N)? by pressing ctrl-c.

[parkovski]

@campersau Hmm, I didn't realize that wasn't working. Looks like this fix only works for powershell, not cmd.exe. I'll look into that.

[parkovski]

It seems like the only thing that works on both is to send WM_KEYDOWN/KEYUP to the hidden console, but winpty has a comment about that breaking certain scenarios. Apparently the “correct” way to do it is a function in kernel32 that is not exported and the address changes between versions of windows :/. So i have it working but I don’t think that winpty will accept that solution - I’ll have to ask specifically which scenarios that comment is talking about and see if there’s a way to make it work.

[appetizermonster]

@parkovski Thanks! the patched copy of winpty-agent.exe works for me. (in PowerShell, Windows 10)

[effolkronium]

@parkovski What is the function in kernel32 ?

[parkovski]

It's called CtrlRoutine, and this program will invoke it in another process ("send a signal"), but

• It works by capturing a stack backtrace and calling a known offset which will break if MS changes the implementation.
• Cmd.exe ignores the signal.

So it's great if you have, say, a node process running in the background that you want to send a SIGINT; not so great for implementing a terminal 🙁.

If you're feeling adventurous, I think cmd checks the keyboard state which is per-thread. You could try modifying that windows-kill program to, when it creates the remote thread, suspend the thread by waiting on some IPC primitive, have the kill process call AttachThreadInput and set the keyboard state to show that Ctrl-C is pressed, and then notify the remote thread to generate the signal. It's a lot of work though and still breaks for admin shells because you can't inject stuff into higher privileged processes.

[parkovski]

All of this won't work with winpty anyways though, because it supports running a console in a background desktop, and you're not allowed to attach to other desktops' inputs, and I doubt that spawning a remote thread would work either.

[vicatcu]

I can confirm @parkovski commented on Sep 13, 2017 patched winpty-agent works with Win10 x64 and PowerShell terminal.

Version 1.19.2
Commit 490ef761b76b3f3b3832eff7a588aac891e5fe80
Date 2018-01-10T15:55:03.538Z
Shell 1.7.9
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64

[entozoon]

The proffered solutions do not work for me, when opening a fresh terminal with ctrl-shift-c on Win10 x64 - ctrl-c often still being swallowed, which is odd because it's not powershell but doesn't seem to be the same terminal as typical cmd either.

[awsmhacks]

ctrl+break works for me. However, some keyboards wont have a break key and you will need to determine the mapping. On my dell laptop Break is mapped to ctrl+fn+b, which appears to act like ctrl+c did formally.

[oliverjanik]

This is a regression for me. I downloaded Jan 2018 update and this started happening again. There are many closed issues on this bug tracker for this strange problem already.

For me it's vscode -> Ctrl+Shift+C -> terminal opens -> run any process -> Ctrl-C does not kill the process.

It's somehow swallowed.

[Gonkers]

VSCode terminal window is dead to me. I've seen the issues as well with no movement on them. So I gave up on it. In fact you reminded me to mute this thread. I have tried VSCode on a few brand new installs of windows and it's the same thing on each one. Maybe in a year or two it will work.

[parkovski]

For future reference, some Windows terminal issues (including this Ctrl-C one) are not easily fixed. There is currently an effort to design a PTY API for Windows, but until that ships, we have to rely on hacks because the functionality just isn’t there in Windows yet.

This is disappointing for me too. I don’t work for MS but I am participating in the API discussion because it’s something I’m passionate about seeing solved. Progress is being made, it’s just going to be a while.

For reference: https://github.com/Microsoft/console/issues/57

[BilibiliHentai]

By the way if you want to run python, you could press Ctrl-shift-p and "Python: Create Terminal", which let you create a terminal named "Python". Within this terminal Ctrl+c always works immediately.

This could be a temporary solution for ones working with python.

[thw0rted]

Just started seriously using VSCode on Windows after a year or so on Ubuntu. Looks like I'm stuck with Git Bash for my shell until they fix this?

[parkovski]

It's in progress. PTY support is enabled in skip ahead insider builds, it's just not exposed as a stable documented API yet so only usable through WSL interop, but it's working pretty well. You could actually have a better terminal at this point on skipahead builds by running the Linux VSCode in WSL and setting your shell to a Windows exe, which will go through a Linux PTY to an NT interop PTY.

[davegear]

I'm not sure how to fix this or any workarounds... I'm on Windows (7 Pro 64-bit), latest VS Code, and using Git Bash shell in the Terminal tab with User Settings "terminal.integrated.shell.windows": "C:\Program Files\Git\bin\bash.exe",

I also don't have a Break key on my laptop keyboard... and I'm right in the middle of a node session I need to restart. I can completely close the terminal but that's obnoxious.

[parkovski]

Find the node process, and type "kill -id \

[saostad]

I have same problem with git bash, but after press ctrl+c, if I wait like 5 minutes it will stop the "npm start" process for me.
I am using create-react-app typescript package
but if I use "docker-compose up" to run my docker container after I press ctrl+c it stop the container without problem.

After this problem I start using regular windows console and it works well, now my system works much faster! which is another problem with integrated terminal!

[saostad]

I find what was my problem.
for some reason I had this in my settings:
"terminal.integrated.rendererType": "dom"
after I remove it it start working and it's much faster

[simeyla]

How quaint.
I remember the first time I used Ctrl+C.
It was 22 years ago. I'm pretty sure it worked every time :-/

[Tyriar]

Update on this: I'm currently working on conpty support which is expected to fix this for newer versions of Windows 10 https://github.com/Microsoft/node-pty/issues/216

[oliverjanik]

Will this fix the external terminal as well?

[shinebayar-g]

2 years lol

[openm]

It seems like the intent of Ctrl+C as "copy" is to maintain consistent behavior across the Editor and the Terminal areas in VS Code on Windows. Keeping that in mind, are there alternative commands that can be used in the Terminal to send an interrupt (SIGINT) to the running process? Can anyone (maybe @Tyriar) explain how to create a new keyboard shortcut (Edit > Preferences > Keyboard Shortcuts) binding that sends a POSIX-style Ctrl+C to the Terminal while allowing the Windows Ctrl+C to remain "copy"?

[RReverser]

For anyone else experiencing this in Powershell, as a workaround you can add the following key handler to your $PROFILE:

Set-PSReadLineKeyHandler -Key (0x03 -as [char]) -Function CancelLine

This should fix the issue of not clearing a line on Ctrl+C while preserving default behaviour of copying text if it's already selected.

This won't help with the original issue though (Ctrl+C in other contexts), but at least should help with the most common annoyance.

[Tyriar]

ConPTY support is landing in the next Insiders build, this uses a new backend for the terminal on WIndows 10 build number 17692+, this is expected to fix many bugs in the terminal on Windows as we're adopting Microsoft's official pty API. For earlier versions winpty will still be used a many bugs will still remain (unless they're fixed in that project).

If you find any issues with conpty please report them to https://github.com/Microsoft/console (the team who own ConPTY) or this repo (if you think it's an integration issue). You can opt out of conpty by adding this setting:

"terminal.integrated.windowsEnableConpty": false