97

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.

Improve this question
1
  • 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, 2017 at 10:55

2 Answers 2

Reset to default
104

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

Improve this answer
10
  • 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
    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
    Jan 11, 2012 at 15:11
  • 2
    @NikosAlexandris: right at the beginning, \e[0m isn't enclosed in \[...\].
    – choroba
    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
    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
    Nov 11, 2016 at 9:22
14

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\] "
Improve this answer
1
  • 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.
    – Steven Aguilar
    Apr 19, 2019 at 14:31

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