terminal: Incorrect keycode for "CTRL+H" in Windows Terminal

Environment

Windows: 
Platform ServicePack Version      VersionString
-------- ----------- -------      -------------
 Win32NT             10.0.18363.0 Microsoft Windows NT 10.0.18363.0

Vim.exe: 8.2.701

Steps to reproduce

start “cmd.exe” in windows terminal.
run vim.exe (https://github.com/vim/vim-win32-installer/releases)
input “iaaaaaaa” to enter insert mode and append some characters.
press “CTRL+h” several times

Expected behavior

The previous “aaaaa” should get deleted (CTRL+H in vim’s insert mode will delete previous character), just like running vim.exe in the traditional cmd.exe window.

Actual behavior

“CTRL+h” inserts some strange characters: “ÎzÎzÎzÎzÎzÎzÎz”

after some inspection, I located the difference, if I use getch in msvcrt.dll to display keycode:

Run cmd.exe directly:

D:\>python -c "import msvcrt;print(msvcrt.getch())"
b'\x08'                   <--- press CTRL+H

D:\>python -c "import msvcrt;print(msvcrt.getch())"
b'\x08'                   <--- press BackSpace

Both “CTRL+H” and “BackSpace” are b'\x08', vim.exe works fine with it .

Run cmd.exe in Windows Terminal:

D:\>python -c "import msvcrt;print(msvcrt.getch())"
b'\x7f'                   <--- press CTRL+H

D:\>python -c "import msvcrt;print(msvcrt.getch())"
b'\x08'                   <--- press BackSpace

Now, “CTRL+H” becomes b'\x7f' in Windows Terminal, which is different from running cmd.exe directly without windows terminal, and that difference breaks some terminal softwares like vim.exe .

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 6
Comments: 23 (5 by maintainers)

Most upvoted comments

Is there a fix or a way to remap this in the future planned?

I wanted to switch over to Windows Terminal as my main terminal client, but unfortunately this breaks my ability to use backspace on our Huawei routers over Telnet. When I am able to reconfigure it (like PuTTY using Control-?(127) instead of Control-H, the backspace works fine in the Huawei telnet connections.

Any update on this?

Hi, I had the same problem and solved it using this custom setting:

{ "command": { "action": "sendInput", "input": "\b" }, "keys": "backspace" }

+12

ghost on Aug 18, 2021

Oh, I didn’t know that such simple setting can solve the problem. I added the following lines in my settings.json, and works fine.

{ "command": { "action": "sendInput", "input": "\b" }, "keys": "backspace" },
{ "command": { "action": "sendInput", "input": "\u007f" }, "keys": "delete" }

sgk on Aug 18, 2021

Is there a fix or a way to remap this in the future planned?

I wanted to switch over to Windows Terminal as my main terminal client, but unfortunately this breaks my ability to use backspace on our Huawei routers over Telnet. When I am able to reconfigure it (like PuTTY using Control-?(127) instead of Control-H, the backspace works fine in the Huawei telnet connections.

Any update on this?

Toxic-Waste- on Jul 31, 2021

@DHowett , the xterm app you are using are too old, you can try one of:

windows: Putty, MinTTY, XShell
linux: gnome-terminal
macos: iterm2, terminal.app

Most modern terminal apps send 0x08 for CTRL+H, 0x7f for BackSpace by default, and they provide options for customizing:

XShell’s default:

PuTTY’s default:

Terminal.app’s default:

iTerm2’s default:

I think I made my point.

skywind3000 on May 19, 2020

In the xterm standard:

CTRL+H is 0x08.
BackSpace is 0x1f.
CTRL+BackSpace is 0x1f.

They won’t conflict with each other.

skywind3000 on May 19, 2020

Is there a fix or a way to remap this in the future planned? I wanted to switch over to Windows Terminal as my main terminal client, but unfortunately this breaks my ability to use backspace on our Huawei routers over Telnet. When I am able to reconfigure it (like PuTTY using Control-?(127) instead of Control-H, the backspace works fine in the Huawei telnet connections. Any update on this?

Hi, I had the same problem and solved it using this custom setting:

{ "command": { "action": "sendInput", "input": "\b" }, "keys": "backspace" }

Not all heroes wear capes, you are my hero today sir 😃

Toxic-Waste- on Aug 19, 2021

I just used xterm 351 and pressed <kbd>Backspace</kbd>, <kbd>Ctrl+H</kbd> and <kbd>Ctrl+Backspace</kbd>.

They have the same encoding.

DHowett on May 19, 2020

I came here because I use Ctrl+H to move to the left pane in tmux and vim, and I use Ctrl+Backspace to delete a word backwards. I am used to making adjustments to ensure that all three work.

The way to make this work for Windows Terminal (which is growing so well and I no longer try to run Alacritty on windows anymore, and haven’t ran Putty in years) to be consistent with what I believe to be the ideal modern Linux and BSD mapping of these keys:

	{ "command": { "action": "sendInput", "input": "\u007f" }, "keys": "backspace" },
	{ "command": { "action": "sendInput", "input": "\u001b\u007f" }, "keys": "ctrl+backspace" }

I’m not sure what \b in sendInput is supposed to emit. Anyone know? Yeah I was thrown off with it deleting the whole word in powershell when I tried that.

Also, It’s a bit surprising to me that my Delete and Ctrl+Delete keys worked out of the box in tmux over ssh. Funny that those worked transparently when Ctrl+Backspace didn’t. Anyway this is why standards are good because it’s impossible for computers to effectively talk to each other when details are not nailed down.

unphased on Aug 17, 2022

I tested this running cmd prompt in Windows Terminal, thought it might be useful here.

That keyboard section of the table is what I typed.

The common section of the table is what is “correct” for that keycode - not necacerily the most common usage.

Keyboard	Decimal	Hex	Binary	Unicode	Common
Backspace	8	8	1000	Backspace	Backspace, ^h
^?	8	8	1000	Backspace	Backspace, ^h
^h	127	7F	1111111	Delete	Delete, ^?
Delete	330	14A	101001010	Ŋ	LATIN CAPITAL LETTER ENG
^Backspace	127	7F	1111111	Delete	Delete, ^?
^Delete	527	20F	100000111	ȏ	LATIN SMALL LETTER O WITH INVERTED BREVE

Following the pattern that ^a ^b ^c are 0x1 0x2 and 0x3, I would assume that ^h would be 0x8, it is not.

^h should be identical to Backspace.

These kinds of “errors” appear to happen with other keys as well. This isn’t always a bad thing as keyboards keys meanings do evolve over time. And for correct usage the key may have to change what it represents.

However here is what I think the “correct” table would be:

Keyboard	Decimal	Hex	Binary	Unicode	Common
Backspace	8	8	1000	Backspace	Backspace, ^h
^?	127	7F	1111111	Delete	Delete ^?
^h	8	8	1000	Backspace	Backspace, ^h
Delete	127	7F	1111111	Delete	Delete ^?

^Backspace and ^Delete don’t have a standard for what the should be as far as I know.

EDIT: My markdown was broken. EDIT 2: Some other oddities:

Keyboard	Output	Out Hex	Expected	Exp Hex
^H	^?	7F	^H	8
^J	ȑ	211	^J	A
^M	^J	A	^M	D
^Enter	ȑ	211	^Enter	N/A

(I can’t test ^V for obvious reasons)

GoodClover on Jun 2, 2020

@DHowett

Thanks for including this in milestone 1.1,

@tasogare3710 ,

Vim doesn’t require PDCurses, it uses Win32 console APIs directly. You may say PDCurses and old console apps have bugs for this, but why getch in msvcrt.dll can’t produce the same keycode for CTRL+H ?

Try this:

python -c "import msvcrt;print(msvcrt.getch())"

and press CTRL+H.

At least, Windows Terminal should not break msvcrt, isn’t it ?

skywind3000 on May 19, 2020

So, yes. We placed the Windows encoding for <kbd>Ctrl+H</kbd> on the sacrificial altar when we fixed <kbd>Ctrl+Backspace</kbd>. We’ve got plans in the works that’ll make this better.

Thanks.

DHowett on May 18, 2020

I checked with WSL in Windows Terminal:

It works as expected, “CTRL+H” sends 0x08 and “BackSpace” sends 0x1f. This is what most linux terminal do.

But why “CTRL+H” behaves differently with cmd.exe ??

skywind3000 on May 18, 2020