I was getting a little tired of my typeaheads in Bash from messing up the PS1. For instance, I would execute a command, like ls, and while it is running, start typing the next command, like echo, and the typeahead for echo would appear before the PS1, like


(here /$ is the PS1). My solution for this was to add \r to the front of the PS1, so that it would clear the line first.

This seems to work reasonably well, but there seems to be a strange issue. In my .inputrc, I have

"\ep": history-search-backward

to let me type M-p to go backward (iTerm 2 maps Option to escape correctly).

The issue is that sometimes when I type some stuff and then M-p to get the previous command, then I do a C-u C-k to clear the line, the first character stays, and becomes part of the PS1 (it is deleted from the executed line, but it is shown on the PS1). It does away when I execute the command, but whenever I hit that item in the history, even with the regular up arrow, that first character gets stuck there again. This only seems to happen with commands that are of a certain length. It doesn't matter if the \r actually clears any text for it to happen.

Am I hitting a strange bug in bash and/or iTerm? Is adding \r to the front of PS1 the correct way to clear cruft before it?


Signal to bash that the \r is a non-printing character so that the correct length of the prompt string is computed, that is, instead of




I think since \r is at the beginning of the prompt, it's is always a zero-length character, rather than a variable-length negative-width character as it could be considered if it occurs in the middle of the prompt som where, so this should work.

  • Ahh, I didn't know bash was doing some prompt length arithmetic. – asmeurer Apr 7 '14 at 16:28

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.