Windows bash takes arrows as symbols via ssh and fish shell on server

Question

I have a bit complicated question. I am using Windows 10 Anniversary Update with Bash for Ubuntu. I am connecting to server via ssh. This server uses fish shell. And when I press arrows it just prints some symbols instead of showing me command history or guessing my next command. Here is what I see:

• arrow up prints [A
• arrow down prints [B
• arrow right prints [C
• arrow left prints [D

However, arrows works fine in bash. Is there any ideas why it is happening?

Answer 1

The why:

The session you are connecting to is using a different terminal emulation than your bash shell.

The easy solution:

Don't use arrow keys in ssh sessions.

The harder solution:

Research the destination server, and fish shell, and determine what terminal emulation they are using, and what options exist for changing it. Research your Bash for Windows to find out what terminal emulation it uses, and what options exist for changing it. Find the overlap between these two and implement it.

The Windows solution:

Use Putty (or another ssh client software) in Windows to connect directly to the destination server.

The Windows FOSS solution:

Use 'Terminals' or something like it.

The HARDCORE solution:

Write a bash script that works in Bash for Windows which automatically detects what terminal emulation is needed and implements that on a case by case basis, so that you can remote into any ssh enabled device and always use arrow keys.

Answer 2

The Windows 10 Anniversary Update with Bash for Ubuntu is essentially running bash in a console window, whose escape sequences (including input such as arrow keys) are documented in MSDN:

• Console Virtual Terminal Sequences

By itself, ssh is largely irrelevant (it passes characters to/from the remote machine unchanged). What matters is the terminal description that your remote machine uses and whether the fish shell initializes things.

Given that you are seeing [A on the remote machine, that says your terminal is sending normal-mode cursor keys (the state when things are not initialized). That's consistent with bash, whose configurations tend to be either hardcoded (look at most .inputrc files) or based on the non-initializing "linux" terminal description. On the Windows side, sure: bash will "work", because it's configured to work with what's there. On the remote side, the fish shell uses whatever is in TERM (which likely is "xterm"). If it's "xterm", then the fish shell would be expecting application mode cursor sequences, e.g., ^[OA versus ^[[A, and seeing the latter would mishandle it.

Further reading:

• Special keys (xterm manual)
• Why can't I use the cursor keys in (whatever) shell? (xterm FAQ)

Answer 3

I ran into the same issue, but with a slightly different setup:

• WSL, with Ubuntu and fish
• SSHed into a remote server, running Ubuntu and Bash

I fixed it by installing fish on the remote server, too.