Ctrl+C broken

[parkovski]

"OpenSSH for Windows" version
((Get-Item (Get-Command sshd).Source).VersionInfo.FileVersion)
0.0.21.0

Server OperatingSystem
((Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows nt\CurrentVersion\" -Name ProductName).ProductName)
Windows 10 Pro

Client OperatingSystem
macOS High Sierra via iTerm2 and zsh

What is failing
Using Ctrl+C to cancel an input line in both PowerShell and cmd.

Expected output

> ecjo (<- press ^C here)
>

Actual output

> ecjo (<- press ^C here, and nothing happens)

This is a real pain point for me because I've spent hours disassembling cmd and conhost trying to figure out how to trigger this to fix winpty, with limited success, but still haven't entirely got it. I highly recommend that being at MS, you look at the code for cmd and conhost and base your implementation on that, because it's very particular about what it accepts. Here's what I know:

• GenerateConsoleCtrlEvent doesn't trigger either cmd or PowerShell. It does, at least for me, trigger other programs (e.g. it quits node). For a Terminate batch job prompt, it prints ^C but doesn't quit the batch file. This is your current implementation. You should probably continue calling this along with whatever triggers the shells.
• Printing ^C triggers PowerShell, but not cmd. This is because PSReadLine disables processed mode and handles all input itself. You have to set the vk code to '\x03' and the ASCII/Unicode char to 'C', otherwise it will just print ^C.
• Cmd does have a CtrlEvent handler that looks in the disassembly like it should trigger a line cancel, but it doesn't. Presumably I missed something there. Reading dissasembly is hard 🙁. Writing the ^C character just prints ^C to the console. None of the various console modes I've tried fix this. I've also tried separate programs with AttachConsole and spawning cmd with different flags. It's very stubborn.
• Cmd also looks like it handles a ^C in the input, but I could never get this working. I know it handles piped input different from CONIN$ input, so that might be what I was seeing. It also looks like it calls GetKeyboardState rather than checking for a control down message.
• Sending WM_KEYDOWN to the window works reliably - it's the only thing that does, but I don't know how that would work under sshd.

[bagajjal]

Following up with the conhost team...
Moving the bug to backlog items..

[parkovski]

Cool, please update this thread if you can when you have an answer from them - the node-pty and winpty issues where I referenced this affect the vscode integrated terminal (same issue - Ctrl-C does nothing) which I'd like to fix.

[bagajjal]

It's fixed. Verified this in the windows Version 10.0.19041.172.