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.

  • 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
    Commented Feb 19, 2017 at 10:55
  • I had problem with perl dynamic PS1 and my workaround was not so beautiful, I put a \n before " $" so line history changes is after \n , I mean PS1="what you want\n \$" Commented May 3 at 18:25
  • I have posted one solution in superuser.com/questions/382456/… Commented May 4 at 3:03

2 Answers 2


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).

  • 4
    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
    Commented Jan 11, 2012 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
    Commented Jan 11, 2012 at 15:11
  • 2
    @NikosAlexandris: right at the beginning, \e[0m isn't enclosed in \[...\].
    – choroba
    Commented Mar 27, 2015 at 12:09
  • 7
    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
    Commented Nov 10, 2016 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
    Commented Nov 11, 2016 at 9:22

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


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


PS1="\[\e[36m\]\W ⇨ [\e[m\] "
  • I'm getting this \[\e[36m\]\W ⇨ \[\e[m\] \[\033[m\033[1;37m\]\u\[\033[m\[\e[0;36m\]\] \w$(prompt_git)\n\[\033[m\033[1;37m\]$ \[\033[m\] as my prompt. U update PS1 in .bash_profile to the above but that didn't worked. Commented Apr 19, 2019 at 14:31

Not the answer you're looking for? Browse other questions tagged .