[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Patch: Corrupt display for history search in vi-mode, 256-color prompt

From: Micah Cowan
Subject: Patch: Corrupt display for history search in vi-mode, 256-color prompt
Date: Tue, 22 Feb 2011 17:15:56 -0800
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101208 Thunderbird/3.1.7

This bug affects both readline and bash (however, it is expected that
this bug is far more likely to affect bash than other typical
readline-using applications). It was experienced on bash 4.1-2ubuntu4
(on Ubuntu 10.10, "Maverick Meercat"), but I checked the sources for
readline 6.2 and bash 4.2, and the relevant code is unchanged.

The original report is on Ubuntu's "Malone" bugtracker (on Launchpad):

Following is a copy-paste from that bugtracker, with slight
modifications to make it slightly more appropriate for this forum.

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:


(This prompt will only display correctly in xterm-compatible terminals;
the term I use is gnome-terminal. PLEASE remove all newlines that appear
due to wrapping by my MUA.)

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
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.

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, and is also found in bash's own built-in
readline code. 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.

rl_message ought to use a dynamically-allocated buffer instead, so it
can adjust the size as needed. Patch provided; see link below.

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 [final line of the] prompt string below 127.

A patch that fixes this issue for me may be found at the Ubuntu
bugtracker link given above (here it is again):


Micah J. Cowan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]