Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 6145 - editing command lines on >80 char wide terminals results in corrupt display
Summary: editing command lines on >80 char wide terminals results in corrupt display
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: bash
Version: 6.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-10-20 16:51 UTC by blah
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2000-02-04 17:29:06 UTC

Attachments (Terms of Use)

Description blah 1999-10-20 16:51:10 UTC
using bash a 93x68 gnome terminal window will result in a
corrupt display after pressing up-arrow to retrieve a long
command line and then using left arrow (or ctrl-a) to move
to the beginning of the command line.

Comment 1 Bill Nottingham 1999-10-20 17:18:59 UTC
What's your prompt string like?

Comment 2 Bill Nottingham 1999-10-20 18:23:59 UTC
Hm... can't reproduce this here. You aren't doing anything
odd like putting the prompt in the titlebar, are you?

Comment 3 Harvey Stein 1999-11-24 17:49:59 UTC
I've seen this since 5.2, maybe earlier.  It's a major pain in the ...  It
happens with xterm too.  It's been reported on the beta tester's mailing
list several times.  I most often see it when doing ^R to reverse search for
a long command.  Rather than properly wrapping the lines, the line display
gets totally hosed.

I just tried to give a sequence of commands which reproduces it consistently,
but failed.  I had two windows up (143x24), one exhibiting this hosed behavior,
and a newly created identical one without problems.

However, I finally noticed that in the hosed window, the COLUMNS env variable
was still set to 80, whereas in the good window it was set to 143.

Resizing the window made the problem go away.

So, it seems like sometimes bash is missing the resize notification or getting
it wrong or some such thing.

Fiddling this some more I was able to recreate the symptoms:

1. start bash in an xterm (when in your home directory):
   xterm -geometry 80x24 -e bash &

2. Run less:
   less .bashrc

3. Resize the window to 149 columns.

4. exit less

5. echo $COLUMNS
   (should still be 80 instead of 149)

6. issue command:
   echo this is a test of the american broadcast system.  If this were an actual
emergency then this broadcast would not work. ha ha ha ha ha ha ha ha ha ha ha
ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha
ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha

   (all on one line).

7. Do a reverse search for 'echo this is'

    ^Recho this is

As the characters for the reverse search are entered, the screen update of the
line gets seriously munged.

It could be that the line length was always missed if a program was running
when the window was resized (I recall something like this occurring in the
past), but that bash/xterm interaction in the past might have been better when
the line length was wrong.

Comment 4 Cristian Gafton 2000-02-04 17:29:59 UTC
This works fine for me here. Did you install a brand new 6.1 or is this a result
of an upgrade? DId you install packages like ncurses that are not provided by
Red Hat?

Note You need to log in before you can comment on or make changes to this bug.