Package: bash Version: 4.1-2ubuntu4 Severity: normal Tags: patch (Forwarded from my bug report against Ubuntu 10.10 (bash 4.1-2ubuntu4, copy/pasted here)
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. *** A patch for this bug may be found at https://bugs.launchpad.net/ubuntu/+source/bash/+bug/721982 *** -- System Information: Debian Release: squeeze/sid APT prefers lucid-updates APT policy: (500, 'lucid-updates'), (500, 'lucid-security'), (500, 'lucid') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-26-generic (SMP w/4 CPU cores) Locale: LANG=ja_JP.utf8, LC_CTYPE=ja_JP.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages bash depends on: ii base-files 5.0.0ubuntu20.10.04.3 Debian base system miscellaneous f ii dash 0.5.5.1-3ubuntu2 POSIX-compliant shell ii debianutils 3.2.2 Miscellaneous utilities specific t ii libc6 2.11.1-0ubuntu7.8 Embedded GNU C Library: Shared lib ii libncurses5 5.7+20090803-2ubuntu3 shared libraries for terminal hand Versions of packages bash recommends: ii bash-completion 1:1.1-3ubuntu2 programmable completion for the ba Versions of packages bash suggests: pn bash-doc <none> (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
