... and it's driving me insane.

Basically (this has been happening over the past couple months), I log into a few different CentOS servers (one Linode, another VPS, and a shared host to which I have shell access), running 5.5, 5.7, and 6, from my Mac running OS X Lion, using Terminal.


$ ssh [email protected]

[remote-host] $ nano somefile.txt

Once I start editing the file, if I use the arrow keys to move around the cursor, or start deleting, then typing again, the cursor jumps around a bit, and if I save the file and reopen it, it's obvious that the cursor was, in fact, jumping all over the place on a line for no apparent reason.

I end up getting things like "This is a neof text." When I had typed in (to the cursor-crazy editor) "This is a line of text."

It's a big problem when it comes to editing configuration files, because I often have to edit one line, save and close, then reopen just to make sure that line is right... then edit another line... and it's getting quite annoying.

I found Linode Lish Shell Vim and Nano rendering troubles: lines not appearing / cursor positions wrong, but I don't know if that relates much, since that's specifically referring to lish.

  • 1
    Hey @geerlingguy, I posted an answer to this question years ago when your name meant nothing to me, but now I use your work regularly. Thanks for all your ansible contributions!
    – dbenton
    Mar 23, 2018 at 17:57
  • 1
    @dbenton - I help you, you help me, we’re a happy community :) Mar 24, 2018 at 18:50

7 Answers 7


[Update: As of Mac OS X Mountain Lion 10.8, Terminal supports the Backtab escape sequence, eliminating this issue.]

The version(s?) of nano on those servers sometimes sends a Backtab (ESC [ Z) sequence when moving the cursor left by one character, but Terminal doesn't support this sequence, so nano thinks the cursor has moved when it hasn't and its idea about the current position of the cursor is out of synch with the terminal.

For reasons I can't fathom, nano sends a Backtab when moving to the left and the cursor is one character to the right of a tab stop. Similarly, IIRC, it sends a Tab (Control-I) when moving to the right and the cursor is one character to the left of a tab stop. I don't know why it does this around tab stops instead of always moving left/right using the same character sequences. The version of nano shipped with Mac OS X Lion 10.7 doesn't do this.

Nano only does this when the terminfo says the cbt capability is supported. The default terminfo for Terminal is xterm-256color, which declares this capability and maps it to the Backtab sequence. A workaround is to set the TERM environment variable to something that doesn't declare this capability. You can do this on the local machine before invoking ssh or in the shell startup file on the remote host. Setting it to xterm-color will do in a pinch, though it is not recommended, as it disables other important behaviors (e.g. 256 colors, BCE, alternate screen content preservation). (A more heavyweight approach is to customize your xterm-256color (or xterm) terminfo file on the remote host to remove cbt.)

Customizing the remote host (one way or another) is recommended, so the customizations don't apply locally or to other remote hosts, but the simplest workaround is to change a Terminal preference setting to use xterm-color instead of xterm-256color:

Terminal > Preferences > Settings > [profile] > Advanced > Declare terminal as:

I recommend duplicating an existing settings profile, customizing it and only using it when you're connecting to those remote hosts.

  • Setting xterm-color definitely works - could you elaborate on how to customize my terminfo file on the remote host? A link would do, but I will probably be coming back to this post every now and then to remember this tip :) Nov 9, 2011 at 16:40
  • 1
    @geerlingguy Modifying an existing terminfo definition. Remove the cbt=\E[Z entry in the .ti source file. Mar 15, 2013 at 16:22
  • This helped me, I set the option from xterm-256color to xterm and now I can select, copy, etc.. as I used to do before. (I do not know how or who changed this option). Thanks!
    – spacebiker
    Aug 11, 2016 at 15:48
  • This one is so frustrating. Everyone else was recommending TERM=xterm or TERM=linux but with Centos 8 on Docker for Windows on Win 10 only TERM=xterm-color works.
    – mdisibio
    Apr 2, 2020 at 5:56

I was having this same problem. I found this thread which recommended, among other solutions, an environment variable on the remote server:

export TERM=xterm-color

Adding this to ~/.bash_profile solved the issue for me. This solution is simple and has the benefit of only affecting a specific user on a specific host.


I had the same issue in MobaXTerm program. Cause of the problem was -K key which I used to enable numpad in Nano when using PuTTY. As I have found out in MobaXTerm -K is not needed (numpad works by default) and without it arrow keys work correctly and doesn't insert garbage randomly.


OSX 10.7.4 with Centos running as a guest OS

Within OSX terminal preferences, settings, advanced

Declare terminal as:xterm-color
Strict VT-100 keypad behaviour - TICKED!

No more issues :)

  • Note that the “VT-100 keypad behavior” preference is entirely unrelated to this Q&A and has no effect on the outcome.
    – Chris Page
    Mar 17, 2013 at 13:51

For users of MobaXterm. If you are not using -K and are still experiencing the problem. Make sure that the following lines are commented out in your /etc/nanorc file.

# set rebinddelete

# set rebindkeypad


The likely problem is that, yes, both your local machine and your server ARE on unix systems which have nano, but those nano versions might be different.

export TERM=xterm-color

If what you get is "This is a neof text" and what you typed is "This is a line of text" (I must presume your report is correct) then you have a flaky "control" key whatever it is on Mac (command? apple?). Because nano is using control+keys to "jump around" and you have less characters than typed so we have a) disappearing characters b) control sequences appearing out of nothing deducing that a) becomes b) is logical.

You might also have some obnoxious hotkey / macro / whatnot program. I suspect this belongs to superuser and not serverfault but I will hold flagging maybe someone has a realistic, SSH-bound answer.

  • It happens when I use arrow keys to move back and forth on a line, more often than when I am simply typing. But it does seem pretty random. I'm going to try Chris' suggestion quickly to see if it works, but thanks for answering! Nov 9, 2011 at 16:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .