From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Fedora/1.7.6-1.3.2 Description of problem: Using some combination of features in the PS1 prompt and searching in history causes prompt to be printed incorrectly. Version-Release number of selected component (if applicable): bash-3.0-18 How reproducible: Always Steps to Reproduce: 1. export PS1="\[\033[30;46m\][\u@\h:pts/11:\W]\[\033[0m\] " 2. Press C-r and search for a command 3. Press C-e Actual Results: The first escape character of the prompt is not printed Expected Results: The prompt is printed with correct escape sequences. Additional info: This is a regression, the same prompt worked fine with bash-2.0. It is difficult to find out exactly what the prompt have to look like to trigger this bug. The given example fails every time, but even a minor change like replacing pts/11 with pts/1 makes it work. And I need to use all of /u, /h, and /W to trigger this bug.
Can't reproduce the problem from your description. I strongly suspect it is dependent on what you are searching for and what history lines are found. Please find a reproducible description of this bug, e.g. "Type this line, then enter, then set PS1, then press C-r, 'l', 's', ..." etc.
Seems it does depend on the contents of the found lines. The bug can be reproduced by chosing a command containing any international characters. Sometimes the bug can be reproduced even if you have just seen a command with international characters, but I can only reliably reproduce the bug by chosing that command. Can you reproduce it with these steps? 1. export PS1="\[\033[30;46m\][\u@\h:pts/11:\W]\[\033[0m\] " 2. touch /tmp/sydhavs$(printf '\xf8') 3. ls /tmp/sydhavsø 4. press C-r l C-e (In step 3 use tab completion).
What locale is that? What's the character that you're trying to get there? If you just have random bytes, I can well imagine it would show up wrong!
You need LC_CTYPE=da_DK for the problem to show up (I wonder how I could miss that). And ø is not a random byte, it is a printable character in this locale.
Can you show me the full output of 'locale' please?
LANG= LC_CTYPE="da_DK" LC_NUMERIC="da_DK" LC_TIME="da_DK" LC_COLLATE="da_DK" LC_MONETARY="da_DK" LC_MESSAGES="da_DK" LC_PAPER="da_DK" LC_NAME="da_DK" LC_ADDRESS="da_DK" LC_TELEPHONE="da_DK" LC_MEASUREMENT="da_DK" LC_IDENTIFICATION="da_DK" LC_ALL=da_DK But only CTYPE seems to have any effect. And I found that I can in fact reproduce the problem even without anything special in the command I search for. Even a simple ls will trigger the bug. Longer commands will not trigger the bug, but as soon as the bug has been triggered it keeps misbehaving until that shell is closed. I think these may be the simplest steps to reproduce the bug: LC_ALL=da_DK PS1="\[\033[30;46m\][\u@\h:pts/11:\W]\[\033[0m\] " bash ls C-r l s C-e Maybe the length of the username and hostname have some influence, this is what my prompt should look like in the above case: [kasperd@frodo:pts/11:kasperd]
Turns out the bug is more likely to show up if \W translates to a short string than if it translates to a longer string. So a cd / command first should make it easier to reproduce. Same holds if \w is used rather than \W.
cat -vet typescript ^[]0;tim@cyberelk:/tmp/tim^G^[[30;46m[tim@cyberelk:pts/11:tim]^[[0m ^M^[[4P(reverse-i-search)`': ^H^H^Hg': gene-vncviewer&exit^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^M^[[4h^[[3^[[4l0;46m[tim@cyberelk:pts/11:tim]^[[0m gene-vncviewer&exit^M$ ^[]0;tim@cyberelk:/tmp/tim^G^[[30;46m[tim@cyberelk:pts/11:tim]^[[0m ^[[Kexit^M$ Here is one occurrence of this. It looks like the problem part is this: ^[[3^[[4l0;46m This looks just as if '^[[4l' got inserted inside '^[[30;46m' for some reason.
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
*** This bug has been marked as a duplicate of 241647 ***