Bug 155444

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 ***