2011/2/22 Micah Cowan <mi...@cowan.name>: > 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.
