Bug 344031 - readline/bash are confused when $PS1 contains ANSI control characters
readline/bash are confused when $PS1 contains ANSI control characters
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: readline (Show other bugs)
7
All Linux
low Severity medium
: ---
: ---
Assigned To: Miroslav Lichvar
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-20 15:41 EDT by John Schmitt
Modified: 2009-05-26 01:34 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-06 07:44:23 EST
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 John Schmitt 2007-10-20 15:41:17 EDT
Description of problem: multi-line $PS1 variables confuse readline when using 
the up arrow to edit the previous line


Version-Release number of selected component (if applicable): all
Using: readline-5.2-7.fc8

How reproducible:
sometimes

Steps to Reproduce:
I use this in my .bashrc:
----------------snip----------------------------------------
export PS1="[\u@\H][\d \@][\w] \$\r\n"
PS1_SAVE=$PS1
NORMAL="\033[01;0m"
SCARY="\033[01;31m"
PS1="\033[01;31m:-( $PS1_SAVE\033[01;32m"; fi'
PROMPT_COMMAND='if [ $? == 0 ]; then PS1="$NORMAL:-) $PS1_SAVE"; else 
PS1="$SCARY:-( $PS1_SAVE$NORMAL"; fi'
----------------snip----------------------------------------
Type in a long command like:
$ 
yum --disablerepo=atrpms --disablerepo=livna  --enablerepo=kde --exclude=\*i18n\* 
install kde-multimedia\* kde-addons\* 
'you must be root to do this' -- I forgot to use sudo
$ <press up arrow key>
$ <press the HOME key or CONTROL+a>

Actual results:

The cursor doesn't go to the first character of the line and typing now 
totally confuses readline/bash and using the left-arrow key will not move the 
cursor all the way to the left, the cursor stops on the 8th character

Expected results:

The cursor should have gone all the way to the first character of the line so 
that I could just type 'sudo'

Additional info:

Long time bug; probably occurs with all versions of readline/bash
Comment 1 Miroslav Lichvar 2007-10-22 05:33:39 EDT
Non-printable characters need to be enclosed in \[ \].

Does it work ok when NORMAL="\[\033[01;0m\]" and SCARY="\[\033[01;31m\]" ?
Comment 2 Bert DeKnuydt 2007-10-23 04:59:36 EDT
I've had this problem with bash since 3.1.  Enclosing in \[ \] indeed
solves the problem, as documented in the manual, but _only_ if LANG
is not set to something UTF; I guess many people have LANG=en_US.utf8 by 
default...
Comment 3 Miroslav Lichvar 2007-10-23 05:14:31 EDT
I didn't see any problems with UTF8 locale, can you please provide steps to
reproduce it?
Comment 4 John Schmitt 2007-10-31 03:02:59 EDT
Adding the \[ and \] does indeed seem to relieve my symptoms.  
$ echo $NORMAL
\[\033[01;0m\]
$ echo $SCARY
\[\033[01;31m\]


For the record, I'm using the default locale settings:
$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
Comment 5 John Schmitt 2007-11-05 13:01:00 EST
Using the \[ and \] sequences fixes things for me so I think we can mark this as
'works for me' at least.
Comment 6 Miroslav Lichvar 2007-11-06 07:44:23 EST
Ok, closing as NOTABUG.

Bert, please have a look at bug #358231, it's a readline bug related to locale
setting.
Comment 7 Tim Connors 2009-05-26 01:34:35 EDT
It will be this bug which *still* hasn't been included in deadrat:

https://bugzilla.redhat.com/show_bug.cgi?id=463880

It only affects multiline PS1 in UTF-8 environments (the \n in the OP's first line), and is triggered by tab completion prior to using the up arrow.

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