Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When I hit Home if my current input is short enough (say, <36 characters), it works fine. However, when I've typed a longer command and then want to go back to the beginning, it seems like it does its job, but the command isn't displayed right anymore. It looks as if I'm not in the beginning but about 10 characters off. Although if I type "blindly", it works fine, but it looks like a total mess, as if the whole input is shifted to the right, but not redrawn. So I type over it, but "in fact" not, because the place I'm "erasing" is "actually" 10 characters to the right. Accordingly, if I try to erase the command, the first 10 characters are still displayed, but if I hit Enter it just displays another prompt as if the previous input was empty.

I know it's not the best explanation ever, but the point is that bash recognizes it and tries to do the right thing, but often fails.

I reproduce this both in tty and in a terminal in an X session. When I hit Ctrl+V and then Home I see different sequences (^[OH in X, ^[[1~ in tty), but both seem to be in my /etc/inputrc:

# do not bell on tab-completion
#set bell-style none

set meta-flag on
set input-meta on
set convert-meta off
set output-meta on

$if mode=emacs

# for linux console and RH/Debian xterm
"\e[1~": beginning-of-line
"\e[4~": end-of-line
"\e[5~": beginning-of-history
"\e[6~": end-of-history
"\e[7~": beginning-of-line
"\e[3~": delete-char
"\e[2~": quoted-insert
"\e[5C": forward-word
"\e[5D": backward-word
"\e\e[C": forward-word
"\e\e[D": backward-word
"\e[1;5C": forward-word
"\e[1;5D": backward-word

# for rxvt
"\e[8~": end-of-line

# for non RH/Debian xterm, can't hurt for RH/DEbian xterm
"\eOH": beginning-of-line
"\eOF": end-of-line

# for freebsd console
"\e[H": beginning-of-line
"\e[F": end-of-line

echo $TERM shows linux in tty and xterm in X session.


GNU bash, version 4.2.24(2)-release (i686-pc-linux-gnu)

Anyone have clues about this?

share|improve this question
How long is your prompt? Does typing a command line about 36 characters long fill one line of your terminal, and thus cause side scrolling? Does it still happen if you use this prompt? PS1='$ ' – Mikel Mar 30 '12 at 15:14
@Mikel I don't know what you have in mind, but you are most probably near the right track. It doesn't seem to happen when I use the minimalistic prompt. The one I used was a little modified as compared to the default one: PS1="\e[0;36m[\u@\h \W]\$ \e[m". Is there anythig wrong with it? Typing 36 characters doesn't fill one line (by far). Also, I don't have side scrolling in tty :) – Lev Levitsky Mar 30 '12 at 17:11
@Mikel I followed jw013's advice and adjusted the prompt, that seems to solve it. Maybe you could elaborate on what the problem was so that I could reward you with some rep as the one to figure it out first :) – Lev Levitsky Mar 30 '12 at 17:47
up vote 9 down vote accepted

You need to surround the non-printing parts of your prompt (including but not limited to escape sequences for changing colors) with \[ and \].

Your original prompt: \e[0;36m[\u@\h \W]\$ \e[m
Fixed prompt: \[\e[0;36m\][\u@\h \W]\$ \[\e[m\]

The \[ and \] tell bash that everything in between does not actually print to the screen, i.e. has zero length. The calculated prompt length is needed to know where to echo characters you type. Leaving out \[ \] causes bash to compute an incorrect prompt length, which often leads to strange terminal geometry-dependent behavior due to bash's idea of where the cursor is not matching up with reality.

share|improve this answer
Thanks, this solves the problem. I'd appreciate some explanation, though: what was the reason of that behavior, what do square brackets do, etc. It would be nice to have it all on one page and could help someone else in the future. – Lev Levitsky Mar 31 '12 at 21:16
@LevLevitsky I added a short explanation to the answer. – jw013 Mar 31 '12 at 21:26
Great, thanks! That makes more sense to me now. – Lev Levitsky Mar 31 '12 at 21:37

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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