Ubuntu bash terminal under wsl unexpectedly switches to "jump over the words" input mode

Question

Below I assume that there are two input modes for terminal (console):

1. in "normal mode" when you press ← your cursor moves to the left by 1 symbol, when you press → your cursor moves to the right by 1 symbol (or doesn't moves at all, if already in the begin/end of input)
2. in "jump over the words" mode when you press ← your cursor moves to the left by 1 word to the previous space symbol, when you press → your cursor moves to the right by 1 word to the next space symbol (or doesn't moves at all, if already in the begin/end of input)

By default there is "normal mode". To use "jump over the words" mode just once (this is useful e.g. when editing commands from history), you should press Ctrl+← and Ctrl+→ instead of ← and →.

The problem is sometimes (I don't know what causes it) my terminal unexpectedly switches to "jump over the words" input mode permanently, and so I get my cursor jumping over the words on ← and → pressing.

What is the reason on this behavior? How to return default input mode back, when it switched, without exiting terminal?

I face this problem only on current setup, so it might be related to my certain environment. I use bash in Ubuntu 22.04 running under wsl2, accessed via Windows Terminal 1.18.2822.0 1.18.3181.0 ("New Windows Terminal", not old cmd.exe nor newer PowerShell.exe).

Codes of ← and → when on normal mode: ^[[D^[[C, when on sudden words-jumping mode: ^[OD^[OC

Codes of Ctrl+← and Ctrl+→ when pressed obviously: ^[[1;5D^[[1;5C

cat ~/.inputrc

"\e[2~": overwrite-mode
"\e[5~": beginning-of-history
"\e[6~": end-of-history
"\e[1;5C": forward-word
"\eOC": forward-word
"\e[1;5D": backward-word
"\eOD": backward-word
"\C-h": backward-kill-word

Answer 1

One of your programs outputs a terminal control code to enable the "Application Keys" mode, which switches many special keys to alternate sequences. For example, it makes the number-pad keys output their own special sequences instead of plain symbols (allowing e.g. Num 2 to be distinguished from regular 2 – used to be important for ancient DEC text editors such as EDT).

Then the program forgets to disable that mode again. (For example, you might have been using a full-screen text editor over SSH, then the SSH connection was closed without giving the editor a chance to clean up. I've also had similar issues with Wine on Linux, even when it was running locally.)

One symptom of this mode is that cursor keys begin using the ESC O prefix instead of the regular CSI. And while that's not meant to be "backward one word" in this mode, it just happens to collide with another dialect of the key sequences where it does mean that – I suspect Rxvt, which doesn't report modifiers the same way Xterm-style terminals do, but instead uses e.g. ESC O d for Ctrl-left. (Though Rxvt uses lowercase abcd while the keys send uppercase, so I'm really not 100% sure if this is a conflict with Rxvt specifically; it could be something else along those lines.)

The other problem is that Bash's key mappings apparently are static; instead of looking at $TERM and loading the keys from the terminfo database it has a static "best effort" mix of mappings for multiple terminals. And because Bash does not expect to be running in the 'Application Keys' mode, its mappings assume "ESC O D is Ctrl-Left in Normal mode" so it moves backwards one word.

Search for DECCKM in Xterm control Sequences for more details; the document has both the relevant control sequences and even a table of which keys are remapped to what input sequences.

Terminfo knows how to control this mode, so you can exit it using tput rmkx which is the inverse of tput smkx.¹ However, usually that's not the only mode that stays unexpectedly enabled, so instead of the above 'tput' or 'printf' I would recommend running reset to hopefully clear out all unwanted terminal state.

(For example, if the problem is indeed caused by a full-screen text editor, then you'll also be in the "Alternate Screen" mode which disables scrollback – tput rmcup to get out, tput smcup to enter it again – and you'll probably have mouse reporting enabled, etc.)

¹ (Use infocmp to see the sequences being used. If you prefer doing it manually without terminfo, the mode is controlled through the DECSET sequence CSI ? Pm h / CSI ? Pm l with Pm=1 for DECCKM, so you can use printf '\e[?1l' to disable the mode or \e[?1h to enable.)

accessed via Windows Terminal 1.18.2822.0 1.18.3181.0 ("New Windows Terminal", not old cmd.exe nor newer PowerShell.exe).

cmd.exe is not a terminal, it's a pure shell much like Bash. The "old style" console window is a system component called Conhost (and is the same between cmd.exe and PowerShell).

It's probably relevant here that cmd.exe doesn't use Conhost like a terminal – in fact, Conhost dnd't have any 'terminal'-like capabilities at all until Windows 8.1 – instead it uses the older "Windows Console" model which uses out-of-band control APIs instead of ESC sequences, so there is no opportunity for stray ESC sequences to do much. (In addition to that, line-editing within cmd.exe is also handled entirely by Conhost, not by Cmd; although in PowerShell it shifts towards a more Unix-like architecture.)