Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 155444 - Incorrect prompt in some cases
Summary: Incorrect prompt in some cases
Status: CLOSED DUPLICATE of bug 241647
Alias: None
Product: Fedora
Classification: Fedora
Component: bash
Version: 3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2005-04-20 12:37 UTC by Kasper Dupont
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-07-04 18:45:56 UTC
Type: ---

Attachments (Terms of Use)

Description Kasper Dupont 2005-04-20 12:37:13 UTC
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):

How reproducible:

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.

Comment 1 Tim Waugh 2005-04-20 13:35:22 UTC
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.

Comment 2 Kasper Dupont 2005-04-20 14:22:21 UTC
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).

Comment 3 Tim Waugh 2005-04-20 14:27:07 UTC
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!

Comment 4 Kasper Dupont 2005-04-20 15:06:41 UTC
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.

Comment 5 Tim Waugh 2005-04-20 15:24:46 UTC
Can you show me the full output of 'locale' please?

Comment 6 Kasper Dupont 2005-04-20 16:11:15 UTC

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

Comment 7 Kasper Dupont 2005-04-20 16:24:10 UTC
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.

Comment 8 Tim Waugh 2005-04-21 10:08:24 UTC
cat -vet typescript

^M^[[4P(reverse-i-search)`': ^H^H^Hg':
^[]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:


This looks just as if '^[[4l' got inserted inside '^[[30;46m' for some reason.

Comment 9 Matthew Miller 2006-07-10 21:43:39 UTC
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!

Comment 10 Jan Kratochvil 2007-07-04 18:45:56 UTC

*** This bug has been marked as a duplicate of 241647 ***

Note You need to log in before you can comment on or make changes to this bug.