Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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

I've noticed that many times when I'm reverse-history-searching from the command line via CTRL+r, if I want to edit the command, sometimes the cursor jumps to the wrong position when I press an arrow key or enter CTRL+a or CTRL+e. The specific position it jumps to seems to be an offset equal to the size of my command line prompt as set in PS1.

This causes difficulty because the actual location of the cursor is different from what is rendered on the screen; future edits to the command are rendered as if the cursor is where it jumped to, but the actual command retains the correct location without any jump.

Does anyone know what's causing this or how to fix it?

EDIT: If I add a newline at the end of PS1 the problem seems to go away. However, I would prefer to enter the command on the same line as the prompt.

share|improve this question
up vote 5 down vote accepted

This is often caused by commands in your history that are longer than 1 line. When you select a shorter item out of the history it doesn't seem to take into account the width of the prompt in re-rendering the command line, so everything after that long command is screwy.

The easy solution I've found is to hit the home key, insert "echo " and hit enter. Then recall the last command and edit from there. (First removing the echo. :)

share|improve this answer
Thanks, I actually tried that just a little while ago. In my case I was careless and blew away a file because there was a pipe in the command that swallowed the echo. You are correct, this seems to only affect long commands according to my experimentation. – jonderry Sep 8 '11 at 23:38
A better solution than echo that I just found: Append a '#' to the beginning of the line rather than an echo. This way bash treats the whole line like a comment. – jonderry Sep 8 '11 at 23:46
Yet better: the problem seems to go away if the current line is redrawn. Either C-l to clear screen and redraw current line or creating a key binding for the unbound function redraw-current-line. – jonderry Sep 9 '11 at 0:16
I forgot to mention the C-l solution as I really hate losing the scroll buffer, but yes, it's a temporary rendering glitch from the history navigation, so forcing a redraw will fix it. redraw-current-line sounds like an even better solution! – cabbey Sep 9 '11 at 17:10

Maybe you have non-printing escape sequences in PS1 not enclosed in \[ and \].

Be sure that you enclosed all of them like this:

\[\e[33m\]\w\[\e[31m\] $ \[\e[0m\]
share|improve this answer
Works great if you enclose only the non-printing sequences in \[ and \] (so you need multiple groups of these block quotes) – Andomar Jan 31 at 19:38
This is the correct solution, thanks! – Ozgur May 6 at 14:55

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.