Prompt Corruption (Long Dir Names + Long Commands)

[timerlenmeyer]

>From Tim Erlenmeyer Fri Jul 11 12:54:39 2008
Return-Path: <tim>
Received: (from timerlenmeyer@berkeley.edu)
        by localhost.localdomain (8.14.1/8.14.1/Submit) id m6BJsd8F007265;
        Fri, 11 Jul 2008 12:54:39 -0700
Date: Fri, 11 Jul 2008 12:54:39 -0700
Message-Id: <200807111954.m6BJsd8F007265@localhost.localdomain>
From: timerlenmeyer@berkeley.edu
To: bug-bash@gnu.org
Subject: Prompt Corruption (Long Dir Names + Long Commands)

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu'
-DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' 
-DLOCALEDIR='/usr/local/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -g -O2
uname output: Linux cyclops4 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:47:07 EDT 
2007 x86_64 x86_64 x86_64
GNU/Linux
Machine Type: x86_64-unknown-linux-gnu

Bash Version: 3.2
Patch Level: 39
Release Status: release

Description:
        With a color prompt that includes the working directory, a long working 
directory name (or many
nested directories) with a long command name corrupts the prompt. The 
corruption is also dependent
on the xterm width. Depending on the lengths of the directory name and command 
and the width of the
xterm various kinds of corruption have been observed. Usually the prompt is 
completely erased and
the cursor position (prompt position) jumps to higher positions on the xterm 
each time a long
command is encountered.


Repeat-By:
        I have removed all of my xterm and bash customizations to try to 
provide more useful information to
you. I have also tested this effect on a 32bit machine and with different 
versions of bash
(including the latest version (3.2.39)).

I am sure the following steps will duplicate the problem on any machine:

With /usr/bin/xterm& I get a default geometry of 80x24+600+360 on this machine.

I then enter:
                  PS1='\[\e[31;2m\]\w\[\e[0m\] '

I then make a test directory:
        mkdir 
/tmp/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstu
vwxyzabcdefghijklmnopqrstuvwxyz

              (only 105 characters long)

The problem is not the directory name length, high nesting creates the same 
problem:
        mkdir 
/tmp/abcdefghijklmnopqrstuvwxyz/abcdefghijklmnopqrstuvwxyz/abcdefghijklmnopqrstuvwxyz/
abcdefghijklmnopqrstuvwxyz/abcdefghijklmnopqrstuvwxyz/abcdefghijklmnopqrstuvwxyz/abcdefghijklmnopqrstuvwxyz/
then:
        cd /tmp/abcd*

If I then scroll back through the command history (up or down arrow keys), a 
long command will corrupt the
prompt and usually position the prompt a few lines higher on the xterm window.

example long command:
        while (( 1 )) ; do sleep 10; date '+%y%m%d_%H%M%S'; sensors 
-f|/bin/grep '^[Ct]' ; done>/tmp/TEMP_LOG

Experimenting with different directory name lengths, command lengths, and xterm 
widths produces different
kinds of prompt corruption. It looks like an array is being overrun.


Fix:
        I apologize if this is just my ignorance of bash configuration and not 
a real bug. I have also
searched the bug reports and applied the latest patches(to my knowledge) before 
assuming that this
is a bug.

Thanks,

Tim Erlenmeyer