Bugzilla – Bug 148844
terminal text wrapping bug
Last modified: 2006-02-14 20:48:33 UTC
This affects at least xterm and gnome-terminal when you first open gnome-terminal or xterm and type a really long command-line (one which would wrap), instead of wrapping to the next line, it wraps on the same line thus appearing to overwrite text you've already typed. it seems this problem goes away after you hit return and then type a second really long command-line, so it's important to open a fresh xterm/gnome-term to test this.
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. ***