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 177661 - Bash prompt very slow since bash 3.1
Summary: Bash prompt very slow since bash 3.1
Alias: None
Product: Fedora
Classification: Fedora
Component: bash
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Ben Levenson
Depends On: 217463
Blocks: FC7Target
TreeView+ depends on / blocked
Reported: 2006-01-12 18:55 UTC by Bastien Nocera
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version: 3.2-3.fc7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-01-22 12:39:22 UTC

Attachments (Terms of Use)
bashrc with custom prompt (deleted)
2006-01-12 18:55 UTC, Bastien Nocera
no flags Details

Description Bastien Nocera 2006-01-12 18:55:04 UTC
Description of problem:
Assigning a complicated bash prompt made typing text *much* slower

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
1. Install the attached .bashrc as the user's .bashrc
2. Run a terminal emulator
3. Middle-click to paste a long text (the URL to this bug for example)

Actual results:
You see the characters appearing one-by-one

Expected results:
Text appears instantaneously, as without the custom prompt

Additional info:
I've used this prompt for 5 years, and it was never slow, even on remote
machines from bash 1.something to 3.0. The upgrade to 3.1 seems to have made it
much slower.

Comment 1 Bastien Nocera 2006-01-12 18:55:04 UTC
Created attachment 123131 [details]
bashrc with custom prompt

Comment 2 Tim Waugh 2006-01-13 17:38:10 UTC
This is intentional and is to work around problems on some terminals.

  /* If this is the first line and there are invisible characters in the
     prompt string, and the prompt string has not changed, and the current
     cursor position is before the last invisible character in the prompt,
     and the index of the character to move to is past the end of the prompt
     string, then redraw the entire prompt string.  We can only do this
     reliably if the terminal supports a `cr' capability.

     This is not an efficiency hack -- there is a problem with redrawing
     portions of the prompt string if they contain terminal escape
     sequences (like drawing the `unbold' sequence without a corresponding
     `bold') that manifests itself on certain terminals. */

Comment 3 Bastien Nocera 2006-04-24 20:02:44 UTC
Re-opening the bug since Chet Ramey tells me:
Yes, there is a problem with redrawing the prompt multiple times per
character in bash-3.1.  Things will be improved in bash-3.2.

Would it be possible to disable this work-around in the meanwhile?

Comment 4 Tim Waugh 2007-01-22 12:39:22 UTC
Bash-3.2 is in rawhide now.

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