Corrupt display for history search in vi-mode, 256-color prompt
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
bash (Debian) |
Fix Released
|
Unknown
|
|||
bash (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
readline6 (Debian) |
Fix Released
|
Unknown
|
|||
readline6 (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
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://
PS1="\[
(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-incrementa
2. Set PS1 as described above.
3. Invoke the non-incremental
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-
Workaround:
The statically-
I'll attach a patch that implements the described solution momentarily.
Related branches
tags: | added: patch |
Changed in bash (Debian): | |
status: | Unknown → New |
Changed in readline6 (Debian): | |
status: | Unknown → New |
Changed in bash (Ubuntu): | |
status: | New → Confirmed |
Changed in readline6 (Ubuntu): | |
status: | New → Confirmed |
Changed in readline6 (Debian): | |
status: | New → Fix Released |
Changed in bash (Debian): | |
status: | New → Fix Released |
This patch fixes the graphical display glitch.
In some instances, it seems that when I type "/", it still may not show up in some circumstances, so that would be a separate and remaining bug that still needs looking to, but the history search itself consistently and correctly shows the lines immediately after the prompt, which is all I really cared about.
The patch is quite straightforward, as it simply replaces the static buffer with a dynamically allocated one, and expands it when it needs to be expanded.
Problems will still arise on systems that don't support vsnprintf, as bash will quite happily overflow the buffer (static or dynamic), but there's little I can do about that, short of a more invasive rewrite; and readline is full of cases like that anyway. Anyway, no such situation will arise in Debian or Ubuntu, or any modern system for that matter.