If $PS1 contains a '\w' with no following '\n', and I am in a path that is longer than my window can display, then the prompt display becomes all messed up. With ANSI escape sequences in $PS1, the prompt wraps back to the beginning of the same line, when it should wrap to the beginning of the next line. Without ANSI escape sequences in $PS1, it gets really strange. The prompt displays okay, except the cursor is at the beginning of the line below where it should be. Furthermore, with each character typed in the prompt, the entire prompt gets redrawn one line after the previous rendering, with the first line of the prompt indented by 10 spaces. Reproducible: Always Steps to Reproduce: 1. LONG="some-really-long-string-thats-wider-than-your-terminal" 2. mkdir $LONG 3. cd $LONG 4. PS1="\w" 5. Type some stuff. Actual Results: The prompt is displayed as expected, except the cursor is at the beginning of the line below where it should be. With each character typed in the prompt, the entire prompt gets redrawn one line after the previous rendering, with the first line of the prompt indented by 10 spaces. Expected Results: After the prompt is displayed, the cursor should be immediately after the prompt. Typing at the prompt should not redraw the prompt (especially not in such an odd manner). Running gnome-terminal. Happens regardless of whether I'm in "screen" or not. Portage 2.0.49-r15 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r3, 2.6.0-gentoo-jed-2) ================================================================= System uname: 2.6.0-gentoo-jed-2 i686 Pentium III (Katmai) Gentoo Base System version 1.4.3.10p1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium3 -O3 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=pentium3 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="sandbox ccache autoaddcvs" GENTOO_MIRRORS="http://mirror.clarkson.edu/pub/distributions/gentoo/ http://gentoo.seren.com/gentoo http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/ http://gentoo.noved.org/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="oss avi cups encode foomaticdb libg++ mad mikmod ncurses nls png spell xml2 gtkhtml gdbm slang svga postgres sdl tcpd libwww perl python esd imlib X gtk gnome alsa acpi apache2 apm bonobo cdr crypt dvd gif gpm gtk2 imap ipv6 java jpeg ldap mmx mozilla mpeg nptl oggvorbis opengl pam pdflib quicktime readline sse ssl tetex truetype usb xmms xv zlib x86 -berkdb -arts -aalib -nas -ggi -tcltk -guile -ruby -mysql -qt -kde -motif -gphoto2 -snmp -scanner moznoirc moznomail moznocompose -mozcalendar -mozxmlterm"
It looks like this was a bug introduced in bash-2.05b. See http://forums.gentoo.org/viewtopic.php?t=117688 for a discussion.
After the update to bash-3.0-r1, I'm having a problem that sounds pretty much like this one. With the Gentoo default PS1, I'm having the problem that the prompt is wrapped at a "certain" position (in the example below, it's after "9i123". However, this 9i123 is already on the 2nd line. When I remove the ANSI escapes to get the color, the wrapping happens as it's supposed to be. With base2, I did NOT have this problem. That forum referenced in a previous post encourages to try "shopt -s checkwinsize". For me, I'm having this wrap problem also checkwinsize=on (default is off). export PS1='\[\033[01;32m\]\u@\h \[\033[01;34m\]\W \$ \[\033[00m\]' alexander@server ~ $ cd /tmp/123456789a123456789b123456789c123456789d123456789e123456789f123456789g123456789h123456789i123456789j123456789k123456789l/ alexander@server 123456789a123456789b123456789c123456789d123456789e123456789f123456789g123456789h123456789i123 456789j123456789k123456789l $ pwd /tmp/123456789a123456789b123456789c123456789d123456789e123456789f123456789g123456789h123456789i123456789j123456789k123456789l alexander@server 123456789a123456789b123456789c123456789d123456789e123456789f123456789g123456789h123456789i123 456789j123456789k123456789l $ cd
Is anything reported here not an UPSTREAM thing?
In some respect: Yes. However, it's also a Gentoo thing, since Gentoo ships with a "broken" configuration. The workaround is to dump the colors.
Ok, I've fixed the bug reported by Alexander in bash-3.0-r2. Regarding the original bug reported here, please re-open if it persists in bash-3.0-r2; I think it might have been fixed at this point.
*** Bug 59356 has been marked as a duplicate of this bug. ***
problem is with bash-3.0-r4 still there !
It looks like with bash-3.0-r4, there is still some line-wrapping issues with prompts having new-line characters. The line-wrapping for the first line of the command seems broken; every subsequent line seems to wrap fine. I did some experimentation in a 30-column terminal. Below what I got for various prompts when I counted the number of characters before the first line of the command wrapped (this anything on that line from the prompt). Here's what I can conclude from my observations: Each new-line character in the prompt reduces the length of the command's first line by 2. Each character in the last line of the prompt increases the length of the command's first line by 1. Any other character in the prompt decreases the length of the command's first line by 1. That is if you have i new-line characters, j characters in the last line of the prompt, and k other characters in the prompt, then the first line of the command will wrap with 2i-j+k characters too few (j-2i-k characters too many). Here's my data: e.g. PS='\nfoo' foo456789012345678901234567890 1 23456 This would be wrapping with 1 character too many. PS1='\n' 2 too few PS1='a\n' 3 too few PS1='aa\n' 4 too few PS1='\na' 1 too few PS1='a\na' 2 too few PS1='aa\na' 3 too few PS1='\naa' ok PS1='a\naa' 1 too few PS1='aa\naa' 2 too few PS1='\naaa' 1 too many PS1='a\naaa' ok PS1='aa\naaa' 1 too few PS1='\n\n' 4 too few PS1='\n\n\n' 6 too few PS1='\n\na' 3 too few PS1='\n\naa' 2 too few PS1='\n\naaa' 1 too few PS1='\na\n' 5 too few PS1='\naa\n' 6 too few PS1='\naaa\n' 7 too few PS1='a\n\n' 5 too few PS1='aa\n\n' 6 too few PS1='aaa\n\n' 7 too few PS1='aaa\naaa\n' 10 too few
Sebastian, please emerge --sync and emerge bash again. I updated the patch shortly after I committed it but didn't bump the rev again. I am anticipating further updates to bash so I didn't think it was necessary. Jed, please do the same, then confirm for me that your original bug report is solved. I have confirmed locally that your new report in comment 8 is true.
i did an emerge --sync and emerged bash (r4) again, but the bug is still alive. And i can confirm the conclusion of Jed Liu.I think, that is my problem,too.
I would still like confirmation from Jed regarding the original report in this bug. There are two bugs being tracked in this one report: (1) long paths with \w and ANSI escape sequences, (2) prompt wierdness when using \n in PS1 I believe that (1) is fixed, but (2) is still a problem. (Please don't respond to confirm (2), I know the bug is still there)
Confirming that the original bug tracked in this report (long paths with '\w' and ANSI escape sequences) has been fixed in bash-3.0-r4. Thanks!
Created attachment 36795 [details] Screenshot showing broken wrapped PS1 I CANNOT confirm that the \w has gone away! For me, it's still present. [06:15:33 alexander@server:~] $ echo $PS1 [\[\033[01;31m\]\t \[\033[01;38m\]\u\[\033[00m\]@\[\033[01;35m\]\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]] \$ (That's alright.) [06:15:36 alexander@server:~] $ cd /home/alexander/Programme/FireFox/Selbst/Zu_Hause/firefox-static_mathml_freetype2_no-xft_no-svg_gcc-3.3.4_athlon-xp.AVIARY_1_0_20040515_BRANCH.20040801,0949/ [06:16:00 alexander@server:~/Programme/FireFox/Selbst/Zu_Hause/firefox-static_mathml_freetype2_no-xft_no-svg_gcc-3.3.4_athlon-xp.AVIARY_1_0_20040515_BRANCH.20040801, 0949] $ That's broken. It is wrapped in line 3 after the "0801," and before the "0949". Another even more broken example: [06:18:12 alexander@server:~] $ cd /tmp/b123456789a123456789b123456789c123456789d123456789e123456789f123456789g123456789h123456789i123456789j123456789k123456789l123456789a123456789b123456789c123456789d123456789e123456789f123456789g123456789h123456789i123456789j123456789k123456789l/ [06:18:15 alexander@server:/tmp/b123456789a123456789b123456789c123456789d123456789e123456789f123456789g123456789h123456789i123456789j123456789k123456789l123456789a12 3456789b123456789c123456789d12345 6789e123456789f123456789g123456789h123456789i123456789j123456789k123456789l] $ It is wrapped after the "89a12" in line 3, after the "d12345" in line 4 - which does NOT fill a whole line.
I can confirm Alexander's observations. Apparently, having a new-line character in the prompt masks the original bug if the '\w' occurs in the last line of the prompt. If it's a single-line prompt, or if '\w' occurs earlier than the last line, then the prompt's line wrapping gets confused.
Is the \w issue supposed to be fixed right now? It seems, that it has transformed a little. Instead of wrapping at the wrong spot, it now doesn't wrap at all anymore. I've got: [14:13:18 alexander@server:~] $ echo $PS1 [\[\033[01;31m\]\t \[\033[01;38m\]\u\[\033[00m\]@\[\033[01;35m\]\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]] $ When I go to a directory with a "long" name, like "/home/alexander/Programme/Mozilla-The_Suite/2004-08-20-22-trunk_mozilla-i686-pc-linux-gnu-gtk2+xft", I see: /Mozilla-The_Suite/2004-08-20-22-trunk_mozilla-i686-pc-linux-gnu-gtk2+xft] $ I'd expect to see: [14:14:43 alexander@server:/home/alexander/Programme/Mozilla-The_Suite/2004-08-20-22-trunk_mozilla-i686-pc-linux-gnu-gtk2+xft] $ It should wrap after the "2004-08-2" and before "0-22-trunk". I'm using bash-3.0-r5 emerged after a sync at about 2004-08-21 09:00 UTC.
basically we're waiting for bash-3.01 (or whatever version chet releases) to get the fix for this problem. the gentoo patch doesn't solve the problem completely, chet says he has a patch for it but he hasn't made it public yet.
My $PS1 from ~/.bash_profile: [code] export PS1='\[\033[00m\][\[\033[01;32m\] \u \[\033[01;34m\]:\[\033[01;32m\] $(pwd)\[\033[01;34m\] | \[\033[01;36m\]$(tty)\[\033[01;34m\] | \d \t\[\033[00m\] ]\n\[\033[01;32m\]\$\[\033[00m\] ' [/code] On upgrading to bash-3.0 I face the following problem: [code] [ endeavor : /home/endeavor/doc | /dev/vc/2 | Thu Sep 02 13:43:59 ] $ The bug is that it breaks the li ne like this. All other lines continue normally till the end of screen..... [/code] It seems that it calculates the width of first line substracting the length of $PS1 from the total width of screen. As if I don't have \n in $PS1 at all ? Example: [code] [ endeavor : /home/endeavor | /dev/vc/2 | Thu Sep 02 13:43:59 ] $ The bug is that it breaks the line l ike this. All other lines continue normally till the end of screen..... [/code] In the end, when $PS1 takes length over one line, the command line completely messes: [ endeavor : /home/endeavor/mcse/PrepLogic/PrepLogic.Microsoft.70-227.Practice.Exams.Premium.Edition.v2.4.89-RBS/crack | /dev/vc/2 | Thu Sep 02 14:00:34 ] $ ?$ echo "That's the mess!" _ ^it's the cursor, does not move from here anymore
I believe this is fixed in 3.0-r6, please test and re-open if necessary
