Summary: | bash prompt weirdness with '\w' and long paths | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jed Liu <jed-gentoo-bugzilla> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | askwar, wrobel, xaon.seb |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
URL: | http://forums.gentoo.org/viewtopic.php?t=117688 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Screenshot showing broken wrapped PS1 |
Description
Jed Liu
2003-12-23 13:56:12 UTC
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. *** Bug 59356 has been marked as a duplicate of this bug. *** 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 |