touch-packages team mailing list archive

[Matthias Klose <doko@xxxxxxxxxx>]

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