Bug 148844

I can confirm that. But I don't think this was found in B4 as B4 is not released yet ;)
Setting to major because this is really ugly.
Stefan: Please take care about that.

Also happens with xterm on 10.0. Nobody complains about this before. Cannot be that important. Setting to NORMAL again.

Werner, Thoams, any ideas?

This has been reported in Debian as a problem with bash.
Look at #343471 and #34811.

Indeed. Assigning to our bash maintainer.

--> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343471

BTW, Debian Bug #34811 does not exist.

sorry: 348111

I'm not able to reproduce this.  Please provide the exact terminal settings
with the output of `stty -a'.

Seems to be a problem of what is done during setting the prompt.
With my prompt it never occurs with some other prompts it happens
only the very first time and I've here a user around who has a
special PROMPT_COMMAND and with this it happens on every line.

My personal prompt:

  tmp$ echo $PS1
  \[\e]2;\u on \h: \w\007\e]1;\h\007\]\W$

the PROMPT_COMMAND

  werner@fatou:/tmp > PROMPT_COMMAND='PS1=`if test "$UID" = 0 ; then \
      echo -e "\[\033[31m\]\h:\`pwd -P\` #  \`tput sgr 0\`\033[m\017"; \
  else \
      echo -e "\[\033[32m\]\u@\h:\`pwd -P\` > \`tput sgr 0\`\033[m\017"; \
  fi `'

Thomas? I'm not sure if this is really a bash bug :)

OK for the PROMPT_COMMAND I've a solution to say the bash to send
escape sequences to the terminal and not to write them onto the
prompt output:

  PROMPT_COMMAND='PS1=`if test "$UID" = 0 ; then \
      echo -e "\[\e[31m\]\h:\`pwd -P\` #  \[\`tput sgr 0\`\e[m\017\]"; \
  else \
      echo -e "\[\e[32m\]\u@\h:\`pwd -P\` > \[\`tput sgr 0\`\033[m\017\]"; \
  fi `'

this is done by the special prompt command sequences \[ ... \].

Now we need to now at which point at xterm start escape sequences will
be written to the prompt output instead to the terminal.

Hmmm ... read last sentence with s/now/know/

(In reply to comment #8)

It's most likely a problem with the escape sequences - you have to mark them as non-characters so they don't get counted. Unfortunately, I don't really understand what your tput command does.

If you use "invisible" characters like escape sequences for changing the color, you always need   \[ ... \]   around them.

However: Try
    PS1='\[\e[32m\]\u@\h:`pwd -P` > \[\e[0m\]'
which should give you the same (user) prompt if I get it right.

And have a look at http://www.cboltz.de/de/linux/bashprompt/?bnc (german) or http://www.cboltz.de/de/linux/bashprompt/?bnc (english) for a "cheaper" *) way to switch the prompt for root ;-)

*) "cheaper" because it is done once at login - not every time the prompt is 
   shown.


For those who only see the problem in the first line of a freshly started bash: please run   script bash-init   - then hit enter twice and call "exit". You can then check the file  bash-init  for the escape sequences used - I guess there will be some additional sequences in the very first prompt.

I've a workaround.  A simple line

       unset TERMCAP

within the /etc/bash.bashrc and we're gone.
It seems that within the source code a

       if (interactive_shell && no_line_editing == 0)
          rl_reset_terminal (get_string_value ("TERM"));

is missed.

I've add this workaround to get it fixed for now.

*** Bug 150833 has been marked as a duplicate of this bug. ***