Re: Bash 3.0 / Readline 5.0: broken prompt handling

[Paul Jarc]

"Ralf S. Engelschall" <rse@engelschall.com> wrote:
> After upgrading the OpenPKG "bash" package to 3.0, we had to discover
> that the prompt handling on Bash 3.0 / Readline 5.0 is broken if a
> multiline prompt (a string containing newlines) is used.

This happens for me too.  I also normally have lots of color control
sequences in just the first line of my prompt.  With 2.05b, I didn't
need to protect the with \[...\].  With 3.0, if I don't protect them,
then bash refuses to use the last line of my tty, and every character
I type causes bash to jump upwards a line or two and split out
gibberish like this:
ÏÏÏÏÏÏ÷U(GÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏÏUU

The way I have it set right now, some of the escape sequences in the
prompt are coming from a command substitution in $PS1.  There's no way
to protect those individually; \[ and \] coming from command
substitution are output literally.  So I tried protecting the whole
first line of my prompt.  But then with 2.05b, when I type a long
stream of "x", the cursor wraps one character early, and the second
line overwrites the first.  (Subsequent lines correctly move to new
lines on the tty.)
bash-2.05b
1234xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
At this point, the cursor is on the "1", and further "x"s overwrite
"1234", but things proceed normally after that.

With 3.0, there is no overwriting, but the first
line wraps two characters too late.  (The last line of my prompt is
two characters long.)
$ PS1='\[bash-3.0\n\]1234'
bash-3.0
1234xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


paul