should be fixed in 4.3, in 14.04 LTS
** Changed in: bash (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bash in Ubuntu.
https://bugs.launchpad.net/bugs/721982
Title:
Corrupt display for history search in vi-mode, 256-color prompt
Status in “bash” package in Ubuntu:
Fix Released
Status in “readline6” package in Ubuntu:
Fix Released
Status in “bash” package in Debian:
New
Status in “readline6” package in Debian:
Fix Released
Bug description:
Binary package hint: bash
This is on Ubuntu 10.10. It very likely still remains in Natty.
I use bash with a prompt that is derived from the current backgrounded
jobs (the script I use to do this is at
http://micah.cowan.name/hg/promptjobs/ - you just source the file and
it does everything). I've customized the colors used, to take
advantage of 256-color support in gnome-terminal. An instance of the
prompt that might be produced is:
PS1="\[\033[m\017\033[38;5;103m\]micah-
acer\[\033[1m\033[38;5;19m\](\[\033[m\017\033[38;5;83m\]\061\[\033[m\017\033[38;5;189m\]wtitle\[\033[1m\033[38;5;19m\])\[\033[m\017\033[m\017\033[38;5;103m\]$
\[\033[m\017\]"
(This prompt will only display correctly in xterm-compatible
terminals; the term I use is gnome-terminal.)
With a prompt like this, and in vi-mode ("set -o vi" in bash),
attempting to initiate a search in the history, results in display
glitches (specifically, the history line bash/readline jumps to is
displayed far over to the right, and with a couple garbage characters
before it).
Steps to reproduce:
1. Be in vi-mode ("set -o vi" in bash): in particular, readline's
"non-incremental-reverse-search-history" MUST be bound to the "/" key, as this
has significant effects on how bash/readline choose to prompt for a history
search string (even though, for me at least, the "bind" command doesn't seem to
reflect this). If you're running these steps, it would be advisible for you to
be sufficiently familiar with vi-style bindings to know how to enter commands.
2. Set PS1 as described above.
3. Invoke the non-incremental-reverse-search-history function by pressing ESC
(to escape vi's insert-mode) and "/" (to prompt for reverse history).
4. At this point, the "/" you just typed may not be showing up properly: this
is the first symptom that something's wrong.
5. Type in some string that should be present in your recent bash history (so
that bash will jump to a different line), and hit enter.
Result:
The history line bash jumps to will be drawn in the wrong location (far right
of the prompt), and with garbage characters; typing "k" or "j" (or the cursor
keys) to move up or down in history continues to draw these lines in the wrong
location.
Expected Result:
The jumped-to line ought to be drawn immediately to the right of the prompt,
and without garbage characters before it.
Cause of bug:
This bug is from readline (it is present both in the readline6 source package
(and probably older, such as readline5), and bash's own built-in readline code
(which has few differences from the sources in readline6). The bug lies in the
function rl_message in display.c, which is called by _rl_nsearch_init, which is
called from noninc_search. rl_message is primarily intended for writing a
"message" on the current line, which doesn't normally include "invisible"
characters (escape sequences, like the one I'm using in my prompt to set
advanced colors), but in this case is being (ab)used to include the prompt. It
uses a buffer of only 128 characters, which in the case of the above
prompt/PS1, is overrun. As long as the system library provides vsnprintf, this
does not lead to a potential buffer overflow, but the results are truncated,
and this is the source of the graphical display glitch, because (a) the prompt
is truncated in the middle of a sequence of "invisible" characters, and (b) I
think the readline code may have other bugs that cause character-counting not
to work properly if the prompt itself is not completely present at the
beginning of a buffer whose value is derived from the result of rl_message.
Solution:
rl_message ought to use a dynamically-allocated buffer instead, so it can
adjust the size as needed. I'll attach a patch to provide this shortly.
Workaround:
The statically-allocated buffer is only used to store the final line in a
multi-line prompt (including any invisible characters, and the special codes
used by readline to mark the start and end of invisible-character sequences).
Thus, if you add a newline in the prompt just before the "\$ ", the static
buffer should have plenty of room. Similar methods might include not using 256
color support, or any other means to shorten the total size of the prompt
string below 127.
I'll attach a patch that implements the described solution
momentarily.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/721982/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
