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?

  • 2
    What's the output of infocmp | head and tty and stty -a & from within that remote ssh session? Does it work better if you use TERM=xterm ssh host instead of ssh host, or tput smkx; ssh host instead of ssh host? – Stéphane Chazelas Oct 18 '16 at 15:36
  • I'm having a similar problem. Arrow keys work fine in bash over ssh but stop working when I run an R shell. Python works fine as well. Awfully perplexed about that. – ApproachingDarknessFish Mar 2 '18 at 4:41

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:

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:


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.