You can make a difference in the Apple Support Community!

When you sign up with your Apple Account, you can provide valuable feedback to other community members by upvoting helpful replies and User Tips.

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Terminal input wrong behaviour

Basically, I have a very strange problem - when I ssh into the machine running CentOS and I open some file in nano to edit it my terminal behaves like crazy.


When I delete something it can put either a simicolon or a closing parathesis or actually delete the thing I want.


Also, the cursor can jump from one place to the other when pressing left/right key. This jumping is only along the line.


Finally, when I press left/right some characters may be overwritten by the characters from the other parts on that line where the cursor happened to be.


It almost seems like the wrong commands are being sent.





Last thing – which is not related to the terminal – if I put mission control to be triggered by Ctrl+Right I can trigger it ALSO by pressing FN. It seems to me that something is very wrong with how character input is being interpreted... Although I do not have ANY problems when typing in other apps.

Mac Book, Mac OS X (10.7)

Posted on Aug 10, 2011 5:20 AM

Reply
16 replies

Aug 12, 2011 7:16 AM in response to Werdan

I have been seeing some of the same strange behaviour as well.. I believe.

When I ssh into another server (which I believe are CentOS servers) and try to edit a file using NANO.. cursor jumps around, deletes what I don't intend. Making it impossible to edit a file safely.


This has all worked before very well. It has been since the upgrade to LION that I have been experiencing this problem.

Aug 16, 2011 9:27 AM in response to miken32

I've been using xterm-color in Lion and still have these issues. It's like Terminal can't figure out the actual size of my window as far as rows & columns goes. This is easily noticeable when running "less" to view a file - the lines of text are often wrapped prematurely, e.g. if my window is 100 cols x 40 rows, the text may wrap at say 75 columns, leaving the remaining columns blank.

Sep 13, 2011 3:33 PM in response to Werdan

What version of nano is on the remote host? You might try installing that version on Mac OS X and see if you can reproduce the problem, or install the Mac OS X version of nano on the remote host and see if the problem goes away. Also, what happens if you try TERM=xterm or vt100 or ansi?


Do these problems occur when using to emacs or vim on the remote host? Or top? Or less?


What happens if you use screen, then make an ssh connection?


Trying these could help narrow down whether it's an issue with Terminal's terminal emulator or an issue with nano.

Jan 10, 2012 1:56 AM in response to Bluebeep

The problem is a combination of the older version of nano + xterm-256color + Terminal.


The older version of nano does some odd things when moving the cursor left and right: if the cursor is one column to the left of a tab stop, moving the cursor one column to the right sends a tab (Control-I) character, and if it's one column to the right of a tab stop, moving the cursor one column to the left sends a "back tab" (ESC [ Z) sequence. I say "odd" because it's odd that it bothers using these sequences when next to tab stops instead of moving the cursor left/right in the same manner as it does when it's farther away from a tab stop.


The reason this is a problem is that Terminal doesn't support the "back tab" escape sequence. So, nano thinks it moved the cursor to the left one column, but Terminal hasn't moved it, and further editing and cursor movement on that line is out of synch with what's displayed in the terminal and it gets progressively more confusing looking. And since it only occurs when moving one character to the left to a tab stop, the user-observable behavior can seem even more surprising and unpredictable.


Now, it only uses "back tab" if the terminfo file says that the terminal supports it. It does this with a "cbt" entry. You can see this with the "infocmp xterm-256color" command, which shows "cbt=\E[Z". This code is supported by modern Xterm and is found in several variations of the xterm terminfo entry, but xterm-color represents an older branch of Xterm and does not include "cbt". So, switching to xterm-color gives you something roughly similar to xterm and xterm-256color, except without "cbt" (and some important behaviors like Background Color Erase and 256 colors) and so this older version of nano behaves better in combination with xterm-color and Terminal.


So, you can work around the problem by setting the TERM environment variable to xterm-color (or, really, any terminfo value that doesn't include "cbt" and is reasonably compatible with Terminal), or by upgrading the older nano on the remote host to a newer version that doesn't have this somewhat odd cursor movement behavior. You could also create a custom terminfo file that's a copy of xterm-256color with cbt removed (assuming you're comfortable creating and editing custom terminfo files).


The easiest way for users to set the TERM value is with the popup menu in Terminal > Preferences > Settings > [profile] > Advanced > Declare terminal as. However, that sets it for every program used with that profile. I recommend one of two approaches:


1. Duplicate (in the "action" menu below the profiles list) the profile you want to use with the remote host and set the "Declare terminal as" value (which just sets the TERM environment variable), then always use that profile for terminals that you use to ssh to CentOS machines. In fact, if you only have one or two remote hosts for which this is a problem, you could customize "… > Settings > Shell > Startup > Run command" to include the "ssh …" command, which will connect to the remote host automatically when you create a new terminal with that profile. Then create a similar custom profile for each remote host.


2. Invoke nano with something like "TERM=xterm-color nano" to set the terminfo value only when running the older version of nano. You could even turn this into an alias, e.g., "alias nano='TERM=xterm-color nano'". If you only have one remote host (or you don't mind doing this on mulitple hosts), customise the appropriate shell startup script to do this so it only does this when invoking nano on that host. Or just remember to "export TERM=xterm-color" after you login to the remote host.


As always, this forum is not an official means to provide feedback to Apple. If this issue is important to you, please file a bug report either at <http://www.apple.com/feedback/macosx.html> (set Feedback Area to Applications/Utilities) or <http://developer.apple.com/bugreporter/> (requires registering for a free developer account). Apple uses reports like these to prioritize work and to decide what's important to put in system updates.

Aug 2, 2013 8:05 AM in response to ovswick

This is an old thread, but the first Google result for my query. I just found the problem for the first time when setting up a CentOS 6 server after working with several CentOS 5 servers. The older servers had nano 1.3 and this new server has nano 2.0.9.


My Terminal.app doesn't have an xterm-color option, but I just changed it to xterm and that cleared up the problem. Thanks for the tip! Now I can edit config files without all the cursor gymnastics.

Aug 5, 2013 5:02 PM in response to Arlo Leach1

Newer versions of Terminal no longer list "xterm-color" as an option in the popup menu, because Terminal is now more compatible with xterm-256color and xterm-color is not recommended, except as a last-resort workaround for specific issues. In particular, Terminal now supports the back-tab sequence and no longer exhibits the problem with older versions of nano. You must be using an older version of Terminal.


You can still set the preference value to any arbitrary string if you need to, but you must either use the "defaults" command from a shell or edit the Terminal preferences plist file directly to do so.

Terminal input wrong behaviour

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.