Bug 155444 - Incorrect prompt in some cases
Incorrect prompt in some cases
Status: CLOSED DUPLICATE of bug 241647
Product: Fedora
Classification: Fedora
Component: bash (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-20 08:37 EDT by Kasper Dupont
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-04 14:45:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kasper Dupont 2005-04-20 08:37:13 EDT
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.
Comment 1 Tim Waugh 2005-04-20 09:35:22 EDT
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 10:22:21 EDT
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 10:27:07 EDT
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 11:06:41 EDT
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 11:24:46 EDT
Can you show me the full output of 'locale' please?
Comment 6 Kasper Dupont 2005-04-20 12:11:15 EDT
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] 
Comment 7 Kasper Dupont 2005-04-20 12:24:10 EDT
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 06:08:24 EDT
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.
Comment 9 Matthew Miller 2006-07-10 17:43:39 EDT
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 14:45:56 EDT

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