Bug Report: Control+Space not sent to terminal emulator. #4005

@zadjii-msft commented on GitHub (Sep 24, 2019):

I'm going to guess this is a combo of:

There might be some discussion here if conpty should interpret a single NUL byte as Ctrl+Space. Isn't Ctrl+@ also NUL though? There might just be no way to handle that, if we can't be sure what it was to begin with.

@zadjii-msft commented on GitHub (Sep 24, 2019): I'm going to guess this is a combo of: * #530 * #879 There might be some discussion here if conpty should interpret a single NUL byte as <kbd>Ctrl+Space</kbd>. Isn't <kbd>Ctrl+@</kbd> also NUL though? There might just be no way to handle that, if we can't be sure what it was to begin with.

claunia commented

@christianparpart commented on GitHub (Sep 24, 2019):

So I tested the following terminals:

xterm
Linux console
Konsole (KDE)
gnome-terminal (VTE)
urxvt
OS/X's standard terminal

And all of them interpret Ctrl+Space as NUL character.

After long digging I finally found where I was first reading about it.

he NULL character (code 0) is represented by Ctrl-@, "@" being the code immediately
before "A" in the ASCII character set.
For convenience, a lot of terminals accept Ctrl-Space as an alias for Ctrl-@.

(Reference: Wikipedia)

In the VT520 docs I sadly didn't find it with crossreading, but in VT220 docs (link found via Chapter 3.2.5) it looks like it is what I was looking for - even though it's not talking about Ctrl+@.

But in case of doubt, I'd go with what most (see list above) terminal emulators do. Mapping Ctrl+Space to emit a NUL byte. :)

EDIT: added OS/X terminal to the list.

@christianparpart commented on GitHub (Sep 24, 2019): So I tested the following terminals: * xterm * Linux console * Konsole (KDE) * gnome-terminal (VTE) * urxvt * OS/X's standard terminal And all of them interpret <kbd>Ctrl</kbd>+<kbd>Space</kbd> as NUL character. After long digging I *finally* found where I was first reading about it. ``` he NULL character (code 0) is represented by Ctrl-@, "@" being the code immediately before "A" in the ASCII character set. For convenience, a lot of terminals accept Ctrl-Space as an alias for Ctrl-@. ``` (Reference: [Wikipedia](https://en.wikipedia.org/wiki/Control_character#How_control_characters_map_to_keyboards)) In the [VT520 docs](https://vt100.net/docs/vt510-rm/chapter8.html) I sadly didn't find it with crossreading, but in [VT220 docs](http://manx-docs.org/mirror/vt100.net/docs/vt220-rm/table3-5.html) (link found via Chapter 3.2.5) it looks like it is what I was looking for - even though it's not talking about <kbd>Ctrl</kbd>+<kbd>@</kbd>. But in case of doubt, I'd go with what most (see list above) terminal emulators do. Mapping <kbd>Ctrl</kbd>+<kbd>Space</kbd> to emit a NUL byte. :) EDIT: added OS/X terminal to the list.

claunia commented

@zadjii-msft commented on GitHub (Sep 24, 2019):

Ah but see the trick isn't in the Ctrl+Space -> NUL conversion. That's easy. The problem comes from conpty - the layer that's responsible for translating *nix-isms from the terminal into Windows-isms. We need to be able to build an INPUT_RECORD from the input that's sent from the terminal to conpty, so commandline applications can read that INPUT_RECORD. When commandline applications are attached to conpty, they still assume that they're able to read full INPUT_RECORDs from the input, not just a stream of characters. The problem comes from the fact that we can't be sure if NUL meant Ctrl+Space or Ctrl+@. If we also added the appropriate Ctrl+@ -> NUL mapping to the terminal, then conpty would be unable to differentiate between those keypresses.

I guess we could just presume one of them, with a note that it's by design, and hope for more robust input encoding to be able to support the other keystroke.

@zadjii-msft commented on GitHub (Sep 24, 2019): Ah but see the trick isn't in the <kbd>Ctrl+Space</kbd> -> NUL conversion. That's easy. The problem comes from conpty - the layer that's responsible for translating *nix-isms from the terminal into Windows-isms. We need to be able to build an `INPUT_RECORD` from the input that's sent from the terminal to conpty, so commandline applications can read that `INPUT_RECORD`. When commandline applications are attached to conpty, they still assume that they're able to read full INPUT_RECORDs from the input, not just a stream of characters. The problem comes from the fact that we can't be sure if NUL meant <kbd>Ctrl+Space</kbd> or <kbd>Ctrl+@</kbd>. If we also added the appropriate <kbd>Ctrl+@</kbd> -> NUL mapping to the terminal, then conpty would be unable to differentiate between those keypresses. I guess we could just presume one of them, with a note that it's by design, and hope for more robust input encoding to be able to support the other keystroke.

claunia commented

@christianparpart commented on GitHub (Sep 24, 2019):

Hey @zadjii-msft, thx for the quick response. I am not a Windows-isms-dev, so I can't talk much about Windows internals, but how I'd see that, is, that Ctrl+space, A..Z, [, , ], ^, _ is being translated to C0 control codes.

I'm not sure you can simply construct an INPUT_RECORD that contains a C0 byte.

typedef struct _KEY_EVENT_RECORD {
  BOOL  bKeyDown;
  WORD  wRepeatCount;
  WORD  wVirtualKeyCode;
  WORD  wVirtualScanCode;
  union {
    WCHAR UnicodeChar;
    CHAR  AsciiChar;
  } uChar;
  DWORD dwControlKeyState;
} KEY_EVENT_RECORD;

Maybe KEY_EVENT_RECORD.AsciiChar could do the trick, since C0 is part of ASCII, that's how I'd understand that. p.s.: Please don't shoot at me, because I'm referencing the MSDN's KEY_EVENT_RECORD struct. :-)

The problem comes from the fact that we can't be sure if NUL meant Ctrl+Space or Ctrl+@. If we also added the appropriate Ctrl+@

WRT that, I don't think you really have to (from a console application's point of view, as - on the above terminal emulators, you can't either).

What part could I be missing?

@christianparpart commented on GitHub (Sep 24, 2019): Hey @zadjii-msft, thx for the quick response. I am not a Windows-isms-dev, so I can't talk much about Windows internals, but how I'd see that, is, that <kbd>Ctrl</kbd>+<kbd>space, A..Z, [, \, ], ^, _</kbd> is being translated to C0 control codes. I'm not sure you can simply construct an `INPUT_RECORD` that contains a C0 byte. ```cpp typedef struct _KEY_EVENT_RECORD { BOOL bKeyDown; WORD wRepeatCount; WORD wVirtualKeyCode; WORD wVirtualScanCode; union { WCHAR UnicodeChar; CHAR AsciiChar; } uChar; DWORD dwControlKeyState; } KEY_EVENT_RECORD; ``` Maybe `KEY_EVENT_RECORD.AsciiChar` could do the trick, since C0 is part of ASCII, that's how I'd understand that. p.s.: Please don't shoot at me, because I'm referencing the MSDN's [KEY_EVENT_RECORD](https://docs.microsoft.com/en-us/windows/console/key-event-record-str) struct. :-) > The problem comes from the fact that we can't be sure if NUL meant Ctrl+Space or Ctrl+@. If we also added the appropriate Ctrl+@ WRT that, I don't think you really have to (from a console application's point of view, as - on the above terminal emulators, you can't either). What part could I be missing?

claunia commented

@zadjii-msft commented on GitHub (Sep 24, 2019):

So you're definitely on the right track here, but I'll point you straight at the meat of the code we're talking about: https://github.com/microsoft/terminal/blob/master/src/terminal/parser/InputStateMachineEngine.cpp

The InputStateMachineEngine is the part of conpty that's responsible for translating a stream of characters into a stream of INPUT_RECORDs. You can see here us attempting to manually translate a bunch of other control keys already. Or here, where we're building the INPUT_RECORDs.

We absolutely could use the UnicodeChar/AcsiiChar part of the struct to hold the C0 char. That's true. However, the job of conpty is to try and maintain compatibility for Windows-like programs. So for something like powershell.exe, vim.exe, far manager, etc, these are all programs that only know the world through the Win32 Console API. When they're running in a conpty session, they still need to be able to read input as if they were running in a real console window. That's where the InputStateMachineEngine comes in. It takes the other C0 characters and translates them into full-fledged INPUT_RECORDs, similar to the records that would be generated by typing input directly into the console window.
So, we'll translate them into not into a singular INPUT_RECORD holding only that char, but a series of records, indicating a full sequence of keypresses. For something like Ctrl+H, we'll generate sequences akin to "ctrl down", "h down (with char=0x8)", "h up", "ctrl up". If a win32 console application wants to use these Win32 style keys, they can without any changes to their code. For something like WSL that doesn't actually care about these keys, and only cares about the chars, we'll actually do another translation from INPUT_RECORD back to a sequence of chars, but that's a entirely separate discussion 😉.

So we can do this translation, and we can just pick one of Ctrl+Space or Ctrl+@ to be the translation for NUL, but we'd have to document it as such, because Windows client applications would no longer be able to differentiate between the two when running in conpty. I suppose that's not such a big deal, considering that neither works at all right now, but we'd still have to document it clearly, otherwise we'd inevitably get bug reports that say "when I press Ctrl+@ in the Terminal powershell thinks I pressed Ctrl+Space".

@zadjii-msft commented on GitHub (Sep 24, 2019): So you're definitely on the right track here, but I'll point you straight at the meat of the code we're talking about: https://github.com/microsoft/terminal/blob/master/src/terminal/parser/InputStateMachineEngine.cpp The InputStateMachineEngine is the part of conpty that's responsible for translating a stream of characters into a stream of INPUT_RECORDs. You can see [here](https://github.com/microsoft/terminal/blob/a862f3196f6b1b7effcc3d164c34734af0728c86/src/terminal/parser/InputStateMachineEngine.cpp#L119-L143) us attempting to manually translate a bunch of other control keys already. Or [here](https://github.com/microsoft/terminal/blob/a862f3196f6b1b7effcc3d164c34734af0728c86/src/terminal/parser/InputStateMachineEngine.cpp#L615), where we're building the INPUT_RECORDs. We absolutely _could_ use the `UnicodeChar`/`AcsiiChar` part of the struct to hold the C0 char. That's true. However, the job of conpty is to try and maintain compatibility for Windows-like programs. So for something like powershell.exe, vim.exe, far manager, etc, these are all programs that only know the world through the Win32 Console API. When they're running in a conpty session, they still need to be able to read input as if they were running in a real console window. That's where the InputStateMachineEngine comes in. It takes the other C0 characters and translates them into full-fledged INPUT_RECORDs, similar to the records that would be generated by typing input directly into the console window. So, we'll translate them into not into a singular INPUT_RECORD holding only that char, but a series of records, indicating a full sequence of keypresses. For something like <kbd>Ctrl+H</kbd>, we'll generate sequences akin to "ctrl down", "h down (with char=0x8)", "h up", "ctrl up". If a win32 console application wants to use these Win32 style keys, they can without any changes to their code. For something like WSL that doesn't actually care about these keys, and only cares about the chars, we'll actually do another translation from INPUT_RECORD back to a sequence of chars, but that's a entirely separate discussion 😉. So we can do this translation, and we can just pick one of <kbd>Ctrl+Space</kbd> or <kbd>Ctrl+@</kbd> to be the translation for NUL, but we'd have to document it as such, because _Windows_ client applications would no longer be able to differentiate between the two when running in conpty. I suppose that's not such a big deal, considering that _neither works at all right now_, but we'd still have to document it clearly, otherwise we'd inevitably get bug reports that say "when I press <kbd>Ctrl+@</kbd> in the Terminal powershell thinks I pressed <kbd>Ctrl+Space</kbd>".

claunia commented

@christianparpart commented on GitHub (Sep 25, 2019):

Thanks for the detailed explanation. I keep forgetting it's Windows OS, nah. When it comes to documentation, I'd go with what most common terminal emulators to at the time of this writing (I try hard being objectively here :-D).

But OTOH, I think maybe the #1173 could probably mitigate this issue?

@christianparpart commented on GitHub (Sep 25, 2019): Thanks for the detailed explanation. I keep forgetting it's Windows OS, nah. When it comes to documentation, I'd go with what most common terminal emulators to at the time of this writing (I try hard being objectively here :-D). But OTOH, I *think* maybe the #1173 could probably mitigate this issue?

claunia commented

@zadjii-msft commented on GitHub (Sep 25, 2019):

You're definitely right. #1173 will also apply to input to the client application, as well as output.

@zadjii-msft commented on GitHub (Sep 25, 2019): You're definitely right. #1173 will also apply to input to the client application, as well as output.

claunia commented

@impguard commented on GitHub (Nov 7, 2019):

Is this why ctrl-6 doesn't currently get passed through/interpreted properly? ctrl-any number seems to not be handled as expected at the moment

@impguard commented on GitHub (Nov 7, 2019): Is this why ctrl-6 doesn't currently get passed through/interpreted properly? ctrl-any number seems to not be handled as expected at the moment

claunia commented

@zadjii-msft commented on GitHub (May 14, 2020):

Oh hey, did this get solved long before 1.1? I'm testing out a bunch of the #4999 scenarios right now, and this one just so happens to already work fine in the 0.11.1333 build of the Terminal I'm running. It's hard to know for sure, but I think we did something a while back that improved out NUL handling.

@zadjii-msft commented on GitHub (May 14, 2020): Oh hey, did this get solved long before 1.1? I'm testing out a bunch of the #4999 scenarios right now, and this one just so happens to already work fine in the 0.11.1333 build of the Terminal I'm running. It's hard to know for sure, but I think we did something a while back that improved out NUL handling.

claunia commented

@lzybkr commented on GitHub (May 14, 2020):

Ctrl+Space and Ctrl+2 are indistinguishable - the application sees Ctrl+2.

This is probably fine for most PSReadLine users since MenuComplete is bound to both of these keys in Windows mode.

Unfortunately Emacs mode binds those keys differently and we get SetMark instead of MenuComplete for Ctrl+Space.

@lzybkr commented on GitHub (May 14, 2020): <kbd>Ctrl+Space</kbd> and <kbd>Ctrl+2</kbd> are indistinguishable - the application sees <kbd>Ctrl+2</kbd>. This is probably fine for most PSReadLine users since `MenuComplete` is bound to both of these keys in Windows mode. Unfortunately Emacs mode binds those keys differently and we get `SetMark` instead of `MenuComplete` for <kbd>Ctrl+Space</kbd>.

claunia commented

@ghost commented on GitHub (May 21, 2020):

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

@ghost commented on GitHub (May 21, 2020): This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for **4 days**. It will be closed if no further activity occurs **within 3 days of this comment**.

claunia commented

@tompazourek commented on GitHub (Jun 3, 2020):

Can this be re-opened, please? Auto-complete in PowerShell using Ctrl+Space is kind of an important feature...

@tompazourek commented on GitHub (Jun 3, 2020): Can this be re-opened, please? Auto-complete in PowerShell using Ctrl+Space is kind of an important feature...

claunia commented

@DHowett commented on GitHub (Jun 3, 2020):

You'll want #4999.

@DHowett commented on GitHub (Jun 3, 2020): You'll want #4999.

claunia commented

@tompazourek commented on GitHub (Jun 3, 2020):

@DHowett Thanks, I searched for this, but didn't find that one!

@tompazourek commented on GitHub (Jun 3, 2020): @DHowett Thanks, I searched for this, but didn't find that one!

claunia commented

@ghost commented on GitHub (Jun 18, 2020):

:tada:This issue was addressed in #6309, which has now been successfully released as Windows Terminal Preview v1.1.1671.0.🎉

Handy links:

@ghost commented on GitHub (Jun 18, 2020): :tada:This issue was addressed in #6309, which has now been successfully released as `Windows Terminal Preview v1.1.1671.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.1.1671.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)

claunia commented

@kellytrinh commented on GitHub (Aug 31, 2020):

I came across this as dup of #4317
(https://github.com/microsoft/terminal/issues/4317)

In Windows Terminal Preview Version: 1.2.2381.0 the bug highlight in #4137 (ie CTRL+SPACE is not passing to ssh/tmux sessions) still exists. Can you please not close this as the other was closed as a dup and this should not be closed until also resolve this problem.

@kellytrinh commented on GitHub (Aug 31, 2020): I came across this as dup of #4317 (https://github.com/microsoft/terminal/issues/4317) In `Windows Terminal Preview Version: 1.2.2381.0` the bug highlight in #4137 (ie CTRL+SPACE is not passing to ssh/tmux sessions) still exists. Can you please not close this as the other was closed as a dup and this should not be closed until also resolve this problem.

claunia commented

@DHowett commented on GitHub (Aug 31, 2020):

@kellytrinh win32-openssh handles its own input queue and has its own version of this issue. There is nothing Terminal can do about that, so there is no value in us keeping a bug open for it 😄

@DHowett commented on GitHub (Aug 31, 2020): @kellytrinh win32-openssh handles its own input queue and has its own version of this issue. There is nothing Terminal can do about that, so there is no value in us keeping a bug open for it 😄

claunia commented

@kellytrinh commented on GitHub (Aug 31, 2020):

Fair enough; was hitting the issue and googling lead me to these pair of pages and thought that folks were closing prematuring; but if it is still being consider on a more appropriate venue then sounds fair to close this off.

@kellytrinh commented on GitHub (Aug 31, 2020): Fair enough; was hitting the issue and googling lead me to these pair of pages and thought that folks were closing prematuring; but if it is still being consider on a more appropriate venue then sounds fair to close this off.

claunia commented

2026-01-30 23:35:33 +00:00

@hjmus commented on GitHub (Feb 19, 2021):

@kellytrinh win32-openssh handles its own input queue and has its own version of this issue. There is nothing Terminal can do about that, so there is no value in us keeping a bug open for it 😄

I inserted a ConWriteString((char *)octets, n); statement on the following two lines, so that I can see what win32-openssh is seeing when I type in something:
8ab565c53f/contrib/win32/win32compat/tncon.c (L201)
8ab565c53f/contrib/win32/win32compat/tncon.c (L255)

With those two lines, I'll see win32-openssh print something whenever I type in something: If I type without the ctrl key, then just the plain char will be printed (doubly printed because the remote server will also echo). If I type with the ctrl key held down, I'll see some junk char being printed. So far so good.

But if I press ctrl+space, nothing, I mean nothing, is printed, even the remote server doesn't echo anything.

Does this mean win32-openssh actually cannot see ctrl+space at all, and the key combination is intercepted by Windows Terminal?

@hjmus commented on GitHub (Feb 19, 2021): > @kellytrinh win32-openssh handles its own input queue and has its own version of this issue. There is nothing Terminal can do about that, so there is no value in us keeping a bug open for it 😄 I inserted a `ConWriteString((char *)octets, n);` statement on the following two lines, so that I can see what win32-openssh is seeing when I type in something: https://github.com/PowerShell/openssh-portable/blob/8ab565c53f3619d6a1f5ac229e212cad8a52852c/contrib/win32/win32compat/tncon.c#L201 https://github.com/PowerShell/openssh-portable/blob/8ab565c53f3619d6a1f5ac229e212cad8a52852c/contrib/win32/win32compat/tncon.c#L255 With those two lines, I'll see win32-openssh print something whenever I type in something: If I type without the `ctrl` key, then just the plain char will be printed (doubly printed because the remote server will also echo). If I type with the `ctrl` key held down, I'll see some junk char being printed. So far so good. But if I press `ctrl+space`, nothing, I mean nothing, is printed, even the remote server doesn't echo anything. Does this mean win32-openssh actually cannot see `ctrl+space` at all, and the key combination is intercepted by Windows Terminal?

claunia commented

@zadjii-msft commented on GitHub (Feb 19, 2021):

When you're seeing "some junk char" printed - those are "control characters". Control characters are the lowest 32 chars on the ascii table. Generally, when you press Ctrl+key, the character that's sent is control character that's on the same row as that char. So Ctrl+M is ^M which is carriage return, ^I is tab, ^[ is ESC, etc. Ctrl+Space just so happens to be mapped to the control char NUL. So when you're printing a literal NUL to the buffer, I'd expect nothing to happen. You might want to format the string in a different way if that's how you're going to test.

That being said, I'm positive that Ctrl+Space does work in the Terminal: In emacs, C-h k, C-Spc shows the following:

So the NUL is definitely making its way to emacs in WSL. I'd bet that win32-openssh is losing track of the NUL byte somewhere.

@zadjii-msft commented on GitHub (Feb 19, 2021): When you're seeing "some junk char" printed - those are "control characters". Control characters are the lowest 32 chars on the [ascii table](http://www.asciitable.com/). Generally, when you press Ctrl+key, the character that's sent is control character that's on the same row as that char. So Ctrl+M is ^M which is carriage return, ^I is tab, ^[ is ESC, etc. `Ctrl+Space` just so happens to be mapped to the control char NUL. So when you're printing a literal NUL to the buffer, I'd expect nothing to happen. You might want to format the string in a different way if that's how you're going to test. That being said, I'm positive that Ctrl+Space does work in the Terminal: In emacs, `C-h k`, `C-Spc` shows the following: ![image](https://user-images.githubusercontent.com/18356694/108505875-ac2c6080-727d-11eb-8a75-3ff98bcba678.png) So the NUL is definitely making its way to emacs in WSL. I'd bet that win32-openssh is losing track of the NUL byte somewhere.

claunia commented

2026-01-30 23:35:33 +00:00

@DHowett commented on GitHub (Feb 19, 2021):

Win32-OpenSSH (7.7, which is the version shipped with windows) is using its own implementation for generating VT characters out of human input. They have since stopped, but the broken version is present on a great many machines.

@DHowett commented on GitHub (Feb 19, 2021): Win32-OpenSSH (7.7, which is the version shipped with windows) is using its own implementation for generating VT characters out of human input. They have since stopped, but the broken version is present on a great many machines.

claunia commented

2026-01-30 23:35:33 +00:00

@DHowett commented on GitHub (Feb 19, 2021):

This is where they do not have appropriate handling for VK_SPACE.

8ab565c53f/contrib/win32/win32compat/tncon.c (L271-L844)

@DHowett commented on GitHub (Feb 19, 2021): This is where they do _not_ have appropriate handling for `VK_SPACE`. https://github.com/PowerShell/openssh-portable/blob/8ab565c53f3619d6a1f5ac229e212cad8a52852c/contrib/win32/win32compat/tncon.c#L271-L844

claunia commented

@hjmus commented on GitHub (Feb 21, 2021):

When you're seeing "some junk char" printed - those are "control characters". Control characters are the lowest 32 chars on the ascii table. Generally, when you press Ctrl+key, the character that's sent is control character that's on the same row as that char. So Ctrl+M is ^M which is carriage return, ^I is tab, ^[ is ESC, etc. Ctrl+Space just so happens to be mapped to the control char NUL. So when you're printing a literal NUL to the buffer, I'd expect nothing to happen. You might want to format the string in a different way if that's how you're going to test.

@zadjii-msft Thank you very much for the info! With the knowledge you shared, I was able to hack a fix. I changed 8ab565c53f/contrib/win32/win32compat/tncon.c (L191) from the following:

						if (inputRecord.Event.KeyEvent.uChar.UnicodeChar != L'\0') {

to the following:

						DWORD dwControlKeyState = inputRecord.Event.KeyEvent.dwControlKeyState;
						DWORD dwCtrlPressed = (dwControlKeyState & LEFT_CTRL_PRESSED);
						if (inputRecord.Event.KeyEvent.uChar.UnicodeChar != L'\0' || 
						    (dwCtrlPressed && inputRecord.Event.KeyEvent.wVirtualKeyCode == 50)) {

and now my Win32 open-ssh build can forward ctrl+space to tmux!

As you said, ctrl+space is just NUL. So when inputRecord.Event.KeyEvent.uChar.UnicodeChar == L'\0', I just need to check if it is indeed ctrl+space being pressed. But I don't know why the VK is 50 rather than VK_SPACE, which is 32. I highly suspect that somewhere in some code, someone treated 32 as 0x32, which is 50... 🤣

I don't believe mine is a proper fix, so I'll just keep it to myself. 😉

For those who want this hack, here is how to build your own Win32 open-ssh: https://github.com/PowerShell/Win32-OpenSSH/wiki/Building-OpenSSH-for-Windows-(using-LibreSSL-crypto).

Windows Terminal is nice. I have decided to switch from PuTTY. Keep up with the good work, folks! 👍

@hjmus commented on GitHub (Feb 21, 2021): > When you're seeing "some junk char" printed - those are "control characters". Control characters are the lowest 32 chars on the [ascii table](http://www.asciitable.com/). Generally, when you press Ctrl+key, the character that's sent is control character that's on the same row as that char. So Ctrl+M is ^M which is carriage return, ^I is tab, ^[ is ESC, etc. `Ctrl+Space` just so happens to be mapped to the control char NUL. So when you're printing a literal NUL to the buffer, I'd expect nothing to happen. You might want to format the string in a different way if that's how you're going to test. @zadjii-msft Thank you very much for the info! With the knowledge you shared, I was able to hack a fix. I changed https://github.com/PowerShell/openssh-portable/blob/8ab565c53f3619d6a1f5ac229e212cad8a52852c/contrib/win32/win32compat/tncon.c#L191 from the following: ``` if (inputRecord.Event.KeyEvent.uChar.UnicodeChar != L'\0') { ``` to the following: ``` DWORD dwControlKeyState = inputRecord.Event.KeyEvent.dwControlKeyState; DWORD dwCtrlPressed = (dwControlKeyState & LEFT_CTRL_PRESSED); if (inputRecord.Event.KeyEvent.uChar.UnicodeChar != L'\0' || (dwCtrlPressed && inputRecord.Event.KeyEvent.wVirtualKeyCode == 50)) { ``` and now my Win32 open-ssh build can forward `ctrl+space` to tmux! As you said, `ctrl+space` is just `NUL`. So when `inputRecord.Event.KeyEvent.uChar.UnicodeChar == L'\0'`, I just need to check if it is indeed `ctrl+space` being pressed. But I don't know why the VK is `50` rather than `VK_SPACE`, which is `32`. I highly suspect that somewhere in some code, someone treated `32` as `0x32`, which is `50`... 🤣 I don't believe mine is a proper fix, so I'll just keep it to myself. 😉 For those who want this hack, here is how to build your own Win32 open-ssh: https://github.com/PowerShell/Win32-OpenSSH/wiki/Building-OpenSSH-for-Windows-(using-LibreSSL-crypto). Windows Terminal is nice. I have decided to switch from PuTTY. Keep up with the good work, folks! 👍

claunia commented

@zadjii-msft commented on GitHub (Feb 22, 2021):

Oh that might be because VK 50 is VK 0x32 which is the 2 key. And here's another weird thing - Ctrl+@ is also encoded as NUL. And on an en-us keyboard, the key that you need to press to get an @ is the 2 key. the-more-you-know.gif.
You can see how we deal with this in both conhost and the Terminal around this function:
a158cc81ae/src/terminal/input/terminalInput.cpp (L630-L637)

@zadjii-msft commented on GitHub (Feb 22, 2021): Oh that might be because VK 50 is VK 0x32 which is the `2` key. And here's another weird thing - Ctrl+@ is _also_ encoded as NUL. And on an en-us keyboard, the key that you need to press to get an `@` is the 2 key. _the-more-you-know.gif_. You can see how we deal with this in both conhost and the Terminal around this function: https://github.com/microsoft/terminal/blob/a158cc81aea7df5bc9994ed194395135c5741021/src/terminal/input/terminalInput.cpp#L630-L637

claunia commented

@cwfparsonson commented on GitHub (May 21, 2021):

Has this been fixed? How can we type ctrl+space when ssh'ing via PowerShell?

@cwfparsonson commented on GitHub (May 21, 2021): Has this been fixed? How can we type ctrl+space when ssh'ing via PowerShell?

claunia commented

@zadjii-msft commented on GitHub (May 21, 2021):

@cwfparsonson This should be fixed, but it'd be helpful to know which ssh you're using, which version, which powershell you're using, what shell you're running on the remote host - there's a lot of factors at play here that all might eat NUL bytes

@zadjii-msft commented on GitHub (May 21, 2021): @cwfparsonson This should be fixed, but it'd be helpful to know which `ssh` you're using, which version, which powershell you're using, what shell you're running on the remote host - there's a lot of factors at play here that all might eat NUL bytes

claunia commented

@cwfparsonson commented on GitHub (May 21, 2021):

Powershell version: 5.1.19041.610

I am running bash

OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5

@cwfparsonson commented on GitHub (May 21, 2021): Powershell version: 5.1.19041.610 I am running bash OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5

claunia commented

@zadjii-msft commented on GitHub (May 21, 2021):

Well yep, that'd explain it. The OpenSSH 7.7 ssh.exe just simply won't work with ctrl+space. Unsure if @hjmus ever submitted a PR to fix that upstream, or if it's fixed in a 8.x release of OpenSSH.

@zadjii-msft commented on GitHub (May 21, 2021): Well yep, that'd explain it. The OpenSSH 7.7 `ssh.exe` just simply won't work with <kbd>ctrl+space</kbd>. Unsure if @hjmus ever submitted a PR to fix that upstream, or if it's fixed in a 8.x release of OpenSSH.

claunia commented

@latipun7 commented on GitHub (Jun 24, 2021):

Sorry to intrude, since I didn't quite understand, I'll just ask here.

Does my issue is related to this issue?

I remapped key binding in vim nnoremap <C-/> 5j, it means whenever I press ctrl+/ in normal mode, it should navigate the cursor down 5 times, but it does nothing. Tried alt+/ not work too. Then remap it to alt+\, it's worked.

I don't have a chance to try the mapping in another terminal yet.

Thank you.

@latipun7 commented on GitHub (Jun 24, 2021): Sorry to intrude, since I didn't quite understand, I'll just ask here. Does my issue is related to this issue? I remapped key binding in vim `nnoremap <C-/> 5j`, it means whenever I press <kbd>ctrl</kbd>+<kbd>/</kbd> in normal mode, it should navigate the cursor down 5 times, but it does nothing. Tried <kbd>alt</kbd>+<kbd>/</kbd> not work too. Then remap it to <kbd>alt</kbd>+<kbd>\\</kbd>, it's worked. I don't have a chance to try the mapping in another terminal yet. Thank you.

claunia commented

@heeh commented on GitHub (Jun 25, 2021):

Strange enough, control+space works in wsl.
However, sshing to the linux from powershell using hvc ssh does not.
Can anyone explain this?

@heeh commented on GitHub (Jun 25, 2021): Strange enough, control+space works in wsl. However, sshing to the linux from powershell using `hvc ssh` does not. Can anyone explain this?

claunia commented

@cwfparsonson commented on GitHub (Jun 25, 2021):

In the end I had to dual boot Linux. I tried many different Windows solutions but nothing worked.

@cwfparsonson commented on GitHub (Jun 25, 2021): In the end I had to dual boot Linux. I tried many different Windows solutions but nothing worked.

claunia commented

@heeh commented on GitHub (Jun 27, 2021):

For emacs, I finally resolve this issue by remapping C-SPC to C-z using PowerToys.
You also have to bind C-z to set-mark-command as follows.
(global-set-key (kbd "C-z") 'set-mark-command)

@heeh commented on GitHub (Jun 27, 2021): For emacs, I finally resolve this issue by remapping `C-SPC` to `C-z` using [PowerToys](https://github.com/microsoft/PowerToys). You also have to bind `C-z` to `set-mark-command` as follows. `(global-set-key (kbd "C-z") 'set-mark-command)`

claunia commented

@xvzc commented on GitHub (Aug 22, 2021):

In my case, i use Korean keyboard, my hardware keyboard layout was set to something that cannot interpret Ctrl + Space as itself: Ctrl + Space was mapped to Chinese Character key in hardware level. So i went to Windows settings, and changed the layout to something that doesn't remap Ctrl + Space, now Ctrl + Space works totally fine in Windows Terminal.

environment : Windows 11, Windows Terminal, wsl, tmux, neovim

@xvzc commented on GitHub (Aug 22, 2021): In my case, i use Korean keyboard, my hardware keyboard layout was set to something that cannot interpret ```Ctrl + Space``` as itself: ```Ctrl + Space``` was mapped to ```Chinese Character``` key in hardware level. So i went to Windows settings, and changed the layout to something that doesn't remap ```Ctrl + Space```, now ```Ctrl + Space``` works totally fine in Windows Terminal. environment : Windows 11, Windows Terminal, wsl, tmux, neovim

claunia commented

@DanielGibson commented on GitHub (Sep 7, 2021):

I'm using Git Bash (from Git 2.32.0.2) in Windows Terminal 1.9.1942.0 (installed via Windows Store), on Win10.

I connect to another machine via SSH and use screen there.
In screen I should be able to switch between the "windows" with Ctrl-A Space.

Right now this only works if I don't press Ctrl anymore when pressing Space - I'm pretty sure it wasn't like this before, and it definitely isn't like that with the (Putty-based, AFAIK?) mintty Terminal emulator that comes with Git for Windows (or any terminal emulator I tried on Linux).
So Ctrl-A release keys Space works, Ctrl-A- keep pressing those keys Space does not work (when using Windows Terminal), even though it should (and after almost 20 years of doing this I don't think I can retrain my muscle memory).

UPDATE: When I connect to a Linux machine per SSH and run cat -v and then press Ctrl-Space, it prints ^@ with mintty (from git) and nothing at all with Windows Terminal.

@DanielGibson commented on GitHub (Sep 7, 2021): I'm using Git Bash (from Git 2.32.0.2) in Windows Terminal 1.9.1942.0 (installed via Windows Store), on Win10. I connect to another machine via SSH and use screen there. In screen I should be able to switch between the "windows" with `Ctrl-A Space`. Right now this only works if I don't press Ctrl anymore when pressing Space - I'm pretty sure it wasn't like this before, and it definitely isn't like that with the (Putty-based, AFAIK?) **mintty** Terminal emulator that comes with Git for Windows (or any terminal emulator I tried on Linux). So `Ctrl-A` *release keys* `Space` works, `Ctrl-A-` *keep pressing those keys* `Space` does not work (when using Windows Terminal), even though it should (and after almost 20 years of doing this I don't think I can retrain my muscle memory). **UPDATE:** When I connect to a Linux machine per SSH and run `cat -v` and then press `Ctrl-Space`, it prints `^@` with mintty (from git) and nothing at all with Windows Terminal.

claunia commented

@digash commented on GitHub (Sep 28, 2021):

Similar to this https://github.com/microsoft/terminal/issues/2865#issuecomment-869087333
just using less used sequence and windows terminal key remapping.

;; TODO: remove this hack when bug fixed: https://github.com/PowerShell/Win32-OpenSSH/issues/1842
;; Add this to your Windows Terminal settings.json
;; {
;;   "command":
;;   { "action": "sendInput",
;;     "input": "\u001b[9~"
;;   },
;;   "keys": "ctrl+space"
;; }

(global-set-key "\e[9~" 'set-mark-command)

And if you use scree on the other side then you only need this in your .screenrc:

bindkey "^[[9~" stuff ^@

@digash commented on GitHub (Sep 28, 2021): Similar to this https://github.com/microsoft/terminal/issues/2865#issuecomment-869087333 just using less used sequence and windows terminal key remapping. ```elisp ;; TODO: remove this hack when bug fixed: https://github.com/PowerShell/Win32-OpenSSH/issues/1842 ;; Add this to your Windows Terminal settings.json ;; { ;; "command": ;; { "action": "sendInput", ;; "input": "\u001b[9~" ;; }, ;; "keys": "ctrl+space" ;; } (global-set-key "\e[9~" 'set-mark-command) ``` And if you use scree on the other side then you only need this in your .screenrc: ``` bindkey "^[[9~" stuff ^@ ```

claunia commented

@kim-dae-hyun commented on GitHub (Mar 11, 2022):

I had same issue in my development environment.
When I connect to WSL, windows terminal send Ctrl+space exatly, but when I connect to remote linux server via ssh, then Ctrl+Sapce is not sent to linux server.
I confirmed with cat -v command.
In conclusion, open-ssh for windows program does not send ctrl+sapce.
This issues was fixed by below patch
https://github.com/PowerShell/openssh-portable/pull/569
If you use higher version than 8.9 of open-ssh ( 8.9 version does not include this patch)
this issue will be fixed.

@kim-dae-hyun commented on GitHub (Mar 11, 2022): I had same issue in my development environment. When I connect to WSL, windows terminal send Ctrl+space exatly, but when I connect to remote linux server via ssh, then Ctrl+Sapce is not sent to linux server. I confirmed with cat -v command. In conclusion, open-ssh for windows program does not send ctrl+sapce. This issues was fixed by below patch https://github.com/PowerShell/openssh-portable/pull/569 If you use higher version than 8.9 of open-ssh ( 8.9 version does not include this patch) this issue will be fixed.

claunia commented

@cpbotha commented on GitHub (Jul 19, 2022):

To fix this, you can install this fixed version of the PowerShell openssh-portable project: https://github.com/PowerShell/openssh-portable/pull/569#issuecomment-1130048955

I just did so with msiexec, then re-connected from Windows with the newly installed c:\Program Files\OpenSSH\ssh.exe and Ctrl-Space was happily recognized by Emacs in tmux on the other side.

@cpbotha commented on GitHub (Jul 19, 2022): To fix this, you can install this fixed version of the PowerShell openssh-portable project: https://github.com/PowerShell/openssh-portable/pull/569#issuecomment-1130048955 I just did so with `msiexec`, then re-connected from Windows with the newly installed `c:\Program Files\OpenSSH\ssh.exe` and Ctrl-Space was happily recognized by Emacs in tmux on the other side.

claunia commented

@mkq commented on GitHub (Jul 26, 2022):

Using Cygwin zsh inside Windows Terminal 1.13.11431.0, Ctrl+Space seems to do nothing, while it shoud do

> bindkey | grep set-mark
"^@" set-mark-command

so I can do Ctrl+Space to start selection, move the cursor, Ctrl+W ⇒ cut, move the cursor, Ctrl+Y ⇒ paste.

Will that be addressed in #1173 (which is much too technical for me)?

@mkq commented on GitHub (Jul 26, 2022): Using Cygwin zsh inside Windows Terminal 1.13.11431.0, Ctrl+Space seems to do nothing, while it shoud do ``` > bindkey | grep set-mark "^@" set-mark-command ``` so I can do Ctrl+Space to start selection, move the cursor, Ctrl+W ⇒ cut, move the cursor, Ctrl+Y ⇒ paste. Will that be addressed in #1173 (which is much too technical for me)?

claunia commented

@DHowett commented on GitHub (Jul 26, 2022):

That seems like a Cygwin bug to me. Here's what I get in WSL...

@DHowett commented on GitHub (Jul 26, 2022): That seems like a Cygwin bug to me. Here's what I get in WSL... ![](https://howettnet.blob.core.windows.net/public/share/WindowsTerminal_kGWmmzvZUD.gif)

claunia commented

@mkq commented on GitHub (Jul 27, 2022):

That seems like a Cygwin bug to me. Here's what I get in WSL...

Thanks. I don't know how to report that to the Cygwin devs, though, since Cygwin zsh inside Cygwin mintty works. I'll just live with this workaround: bindkey '\e[3;5~' set-mark-command (i.e. Ctrl+Del) in my .zshrc.

(Found by pressing Ctrl+V, Ctrl+Del, which prints ^[[3;5~, Ctrl+V being bound to quoted-insert.)

@mkq commented on GitHub (Jul 27, 2022): > That seems like a Cygwin bug to me. Here's what I get in WSL... Thanks. I don't know how to report that to the Cygwin devs, though, since Cygwin zsh inside Cygwin mintty works. I'll just live with this workaround: `bindkey '\e[3;5~' set-mark-command` (i.e. Ctrl+Del) in my .zshrc. (Found by pressing Ctrl+V, Ctrl+Del, which prints `^[[3;5~`, Ctrl+V being bound to quoted-insert.)

claunia commented

@thammegowda commented on GitHub (Nov 19, 2022):

If anyone still facing this issue: This issue seems to be on ssh, as mentioned in the previous comments.
There maybe two ssh clients inside your $PATH.

# WSL / bash
$ which ssh ssh.exe
/usr/bin/ssh
/mnt/c/WINDOWS/System32/OpenSSH/ssh.exe

# Powershell 
PS C:>  get-command ssh
CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     ssh.exe                                            8.6.0.1    C:\WINDOWS\System32\OpenSSH\ssh.exe

The ssh.exe client from windows does not handle CTRL+Space as the way it should be (atleast as of the latest windows today). Remember to use ssh client from WSL and CTRL+Space works on emacs as expected!

@thammegowda commented on GitHub (Nov 19, 2022): If anyone still facing this issue: This issue seems to be on `ssh`, as mentioned in the previous comments. There maybe two `ssh` clients inside your $PATH. ``` # WSL / bash $ which ssh ssh.exe /usr/bin/ssh /mnt/c/WINDOWS/System32/OpenSSH/ssh.exe # Powershell PS C:> get-command ssh CommandType Name Version Source ----------- ---- ------- ------ Application ssh.exe 8.6.0.1 C:\WINDOWS\System32\OpenSSH\ssh.exe ``` The ssh.exe client from windows does not handle CTRL+Space as the way it should be (atleast as of the latest windows today). Remember to use `ssh` client from WSL and CTRL+Space works on emacs as expected!

claunia commented

@michael-ts commented on GitHub (Dec 2, 2022):

Remember to use ssh client from WSL and CTRL+Space works on emacs as expected!

@thammegowda
Uh... how? Powershell can't see anything in the WSL filesystem. I tried copying /usr/bin/ssh over to the Windows side, but when I try to execute it in Powershell it asks me what application I want to open it with. (Hey, since I can run Windows executables from within WSL I figured why not the reverse?)

Oh, and in case you ask, I can't run ssh within WSL because for some reason it times out trying to connect to the host. Which is in a Hyper-V VM on the same machine.

@michael-ts commented on GitHub (Dec 2, 2022): > Remember to use `ssh` client from WSL and CTRL+Space works on emacs as expected! @thammegowda Uh... how? Powershell can't see anything in the WSL filesystem. I tried copying /usr/bin/ssh over to the Windows side, but when I try to execute it in Powershell it asks me what application I want to open it with. (Hey, since I can run Windows executables from within WSL I figured why not the reverse?) Oh, and in case you ask, I can't run ssh within WSL because for some reason it times out trying to connect to the host. Which is in a Hyper-V VM on the same machine.

claunia commented

@thammegowda commented on GitHub (Dec 2, 2022):

@michael-ts I run ssh inside WSL (first, bash then ssh) and that's the way it works for me.

Looks like you have issue with networking setup inside WSL, and your ssh is unable to reach to the remote. Verify that internet works inside WSL by ping bing.com

@thammegowda commented on GitHub (Dec 2, 2022): @michael-ts I run ssh inside WSL (first, `bash` then `ssh`) and that's the way it works for me. Looks like you have issue with networking setup inside WSL, and your ssh is unable to reach to the remote. Verify that internet works inside WSL by `ping bing.com`

claunia commented

@michael-ts commented on GitHub (Dec 2, 2022):

@thammegowda Thanks, I can ping the Internet from WSL, but I have had no end to the networking issues with Hyper-V. I used to be able to ssh to it but had more serious issues, namely that networking would completely stop working outside of between the host and the VM at odd intervals. The fix for that apparently which I no longer recall caused this issue. Trying to administer my own machine is too much work sometimes... ;-)
Anyway, I was hoping there was some solution besides running in WSL, but I guess not.

@michael-ts commented on GitHub (Dec 2, 2022): @thammegowda Thanks, I can ping the Internet from WSL, but I have had no end to the networking issues with Hyper-V. I used to be able to ssh to it but had more serious issues, namely that networking would completely stop working outside of between the host and the VM at odd intervals. The fix for that apparently which I no longer recall caused this issue. Trying to administer my own machine is too much work sometimes... ;-) Anyway, I was hoping there was some solution besides running in WSL, but I guess not.

claunia commented

@thammegowda commented on GitHub (Dec 2, 2022):

@michael-ts I think the solution is that somebody has to patch the OpenSSH inside windows dir ( C:\WINDOWS\System32\OpenSSH\ssh.exe) to resolve this issue. I don't know who that somebody is and if they are aware of this issue.

@thammegowda commented on GitHub (Dec 2, 2022): @michael-ts I think the solution is that somebody has to patch the OpenSSH inside windows dir (` C:\WINDOWS\System32\OpenSSH\ssh.exe`) to resolve this issue. I don't know who that somebody is and if they are aware of this issue.

claunia commented

@DHowett commented on GitHub (Dec 2, 2022):

For what it's worth, this issue has been fixed in newer versions of Win32-OpenSSH. They are often released to earlier versions of Windows by way of servicing updates.

At my disposal I have v8.9, which does properly record Ctrl+Space

@DHowett commented on GitHub (Dec 2, 2022): For what it's worth, this issue has been fixed in newer versions of Win32-OpenSSH. They are often released to earlier versions of Windows by way of servicing updates. At my disposal I have v8.9, which does properly record <kbd>Ctrl+Space</kbd> <img width="814" alt="image" src="https://user-images.githubusercontent.com/189190/205409760-b2dd4501-f930-46ad-98ea-b6bc48cc6650.png">

claunia commented

@michael-ts commented on GitHub (Dec 7, 2022):

@DHowett Thanks! I went searching for that and discovered I could update to that version from PowerShell using winget install "openssh beta".

@michael-ts commented on GitHub (Dec 7, 2022): @DHowett Thanks! I went searching for that and discovered I could update to that version from PowerShell using ` winget install "openssh beta"`.

claunia commented

@chiendo97 commented on GitHub (Dec 7, 2022):

For anyone which doesn't have admin rights, you guys can use scoop to install the latest verison of OpenSSH.
Then in any terminal apps (Windows Terminal, Iterms, PowerShell), use the scoop's ssh version to connect to any servers, the Ctrl-Space will work correctly.

scoop install openssh
cd .\scoop\shims\
.\ssh.exe ip:port

@chiendo97 commented on GitHub (Dec 7, 2022): For anyone which doesn't have admin rights, you guys can use [scoop](https://scoop.sh/) to install the latest verison of `OpenSSH`. Then in any terminal apps (Windows Terminal, Iterms, PowerShell), use the scoop's ssh version to connect to any servers, the `Ctrl-Space` will work correctly. ``` scoop install openssh cd .\scoop\shims\ .\ssh.exe ip:port ```

claunia commented

@fagg commented on GitHub (Jun 2, 2023):

This doesn't appear to be fixed for me, even in a local WSL Ubuntu instance. cat -v confirms that Ctrl-<SPACE> is ignored.

I am running Terminal version 1.16.10261.0 on Windows 10 19045.3031.

@fagg commented on GitHub (Jun 2, 2023): This doesn't appear to be fixed for me, even in a local WSL Ubuntu instance. `cat -v` confirms that `Ctrl-<SPACE>` is ignored. I am running Terminal version `1.16.10261.0` on Windows 10 `19045.3031`.

claunia commented

@iHeadway commented on GitHub (Jun 2, 2023):

Windows 11, Terminal 1.17.11461, powershell 7.3.4. ctrl-space isn't working in neovimj (no keycode sent after ctrl-q)

@iHeadway commented on GitHub (Jun 2, 2023): Windows 11, Terminal 1.17.11461, powershell 7.3.4. ctrl-space isn't working in neovimj (no keycode sent after ctrl-q)

claunia commented