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
Non-printable characters need to be enclosed in \[ \]. Does it work ok when NORMAL="\[\033[01;0m\]" and SCARY="\[\033[01;31m\]" ?
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...
I didn't see any problems with UTF8 locale, can you please provide steps to reproduce it?
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=
Using the \[ and \] sequences fixes things for me so I think we can mark this as 'works for me' at least.
Ok, closing as NOTABUG. Bert, please have a look at bug #358231, it's a readline bug related to locale setting.
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.