This question already has an answer here:

Often when I start looking at history of commands some of the characters from a command displayed aren't erased, for example:

What's happening:

prompt$ some_command
prompt$ some_commanother_command

What should have happened:

prompt$ some_command
prompt$ another_command

I can't erase those characters and bash ignores them when executing the command. They also disappear when a new prompt is being displayed (after pressing Enter for example).

I asked other people who work on Linux at my workplace and they said that they have that problem sometimes too, but they didn't have an idea on how solve that issue.

I have Ubuntu 11.10 and I'm using guake. Here is my PS1:

\e[0;31m\u \A ${PWD##*/}\e[0;32m$(parse_git_branch)\e[0;31m$\e[m

where parse_git_branch is

parse_git_branch () {
    git name-rev HEAD 2> /dev/null | sed 's#HEAD\ \(.*\)# (\1)#'
}

As far as I know my colleagues have that problem even with less "fancy" PS1.

marked as duplicate by Jeff Schaller, Anthon, Satō Katsura, Stephen Rauch, Hauke Laging Aug 29 '17 at 19:06

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • As mentioned already, non-printable sequences need to be wrapped with \[...\] in order to let bash calculate the correct length of the prompt. However, what also seems to be important from my testing is if you have a multi-line prompt, the \r\n sequence should not go in the \[...\] wrapping. – Geraden Feb 19 '17 at 10:55
up vote 57 down vote accepted

Use \[...\] around the parts of PS1 that have length 0. It helps bash to get the length of the prompt right. Even with this measure, your command line can get spoiled when using multibyte characters (at least mine does). Hitting Ctrl+L also helps in such cases (but clears the screen at the same time).

  • 2
    I modified my bashrc and now I have PS1="\\[\e[0;31m\\]\u \A \${PWD##*/}\\[\e[0;32m\\]\$(parse_git_branch)\\[\e[0;31m\\]$\\[\e[m\\] ". Kinda hard to understand when I'm looking at it but it seems that it helped. – korda Jan 11 '12 at 8:46
  • @korda I find using single quotes to remove the backslash doubling helps a lot. I also set the character sequences to variables, which helps a bit as well. My PS1 looks like PS1="${reset_color}[${cyan}\A${reset_color}]${reset_color}${user_color}\u@\h(\l)${white}:${blue}\W${reset_color}[${yellow}\$?${reset_color}]${white}"'\$'"${reset_color} " – jw013 Jan 11 '12 at 15:11
  • 2
    @NikosAlexandris: right at the beginning, \e[0m isn't enclosed in \[...\]. – choroba Mar 27 '15 at 12:09
  • 5
    Is there a bash bug report? This is a bug which has wasted too much of my time, and should be fixable in general (without PS1 hacks). – dhardy Nov 10 '16 at 15:53
  • 1
    @choroba that bash does some odd behaviour given incorrect PS1 instead of either doing the right thing or stopping with an error. It's a bit like the "undefined behaviour" in C etc.: allowed, but not likable, except in this case it should be fixable. – dhardy Nov 11 '16 at 9:22

You need to make sure you are escaping all of the non-printable characters.

Good

PS1="\[\e[36m\]\W ⇨ \[\e[m\] "

Bad

PS1="\[\e[36m\]\W ⇨ [\e[m\] "

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