[Top][All Lists]

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

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

From: Dennis Williamson
Subject: Re: Patch: Corrupt display for history search in vi-mode, 256-color prompt
Date: Tue, 22 Feb 2011 19:38:57 -0600

2011/2/22 Micah Cowan <address@hidden>:
> 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):
> https://bugs.launchpad.net/debian/+source/bash/+bug/721982
> 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:
> 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. 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
> 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, 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.
> Solution:
> rl_message ought to use a dynamically-allocated buffer instead, so it
> can adjust the size as needed. Patch provided; see link below.
> 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 [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):
> https://bugs.launchpad.net/debian/+source/bash/+bug/721982
> --
> Micah J. Cowan
> http://micah.cowan.name/

I found that PS4 is also truncated so it makes it difficult to use
complex colorized trace output.

Visit serverfault.com to get your system administration questions answered.

reply via email to

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