Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 463880

Summary: bash completion in UTF8 locale has cursor positioning errors with long $PS1
Product: Red Hat Enterprise Linux 5 Reporter: Tim Connors <tim.w.connors>
Component: bashAssignee: Roman Rakus <rrakus>
Status: CLOSED ERRATA QA Contact: BaseOS QE <qe-baseos-auto>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.2CC: bnater, mhusnain, rvokal, tim.w.connors, tsmetana
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: bash-3.2-25.el5 Doc Type: Bug Fix
Doc Text:
When the tab key was pressed for auto-completion options for the typed text, the cursor moved to an unexpected position on a previous line if the prompt contained unviewable characters and a "\]". This is now fixed to retain the cursor at the expected position at the end of the target line after autocomplete options correctly display.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2011-07-21 10:37:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Backported bash32-027 patch from upstream none

Description Tim Connors 2008-09-25 04:15:43 UTC 
Description of problem:

I suspect this is the same as bug https://bugzilla.redhat.com/show_bug.cgi?id=249987 for fedora.

I recently moved over to a UTF-8 environment from ISO-8859, such that LANG=LC_MESSAGES=en_AU.UTF-8
My PS1 is a multiline one, with:
$?-\j-\t, \d \[ESC[33;1m\]\u\[ESC[0m\]@\[ESC[34m\]aatlxz\[ESC[0m\]:\w (bash)\n\[ESC[7m\]\!,\#>\[ESC[m\]
(ie, I have correctly wrapped non printing characters in \[...\], and you'll have to expand those ESC characters to reproduce this)

As soon as I logged in with UTF-8 settings, my prompt would occasionally get messed up with the cursor being positioned on the line above in a strange location.  I just tracked it down to the random occasions when my fingers would do tab-completion for me - it would reproducably get the cursor wrong.  If I set LC_MESSAGES=$LANG=en_AU (ie, straight ISO-8859-1) in the same bash session, then the cursor positioning error goes away.  If I copy a bash from a debian sid version, (version GNU bash, version 3.2.39(1)-release (x86_64-pc-linux-gnu)), then the error went away.  It only appears with the the current redhat version (ie, no bug in 3.00.15(1)-release on a centos 4 box I am on)

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

3.2.25(1)-release

How reproducible:

with the above $PS1 and $LANG and $LC_MESSAGES:
0-0-14:07:05, Thu Sep 25 twc@aatlxz:~ (bash)
79953,1> echo $BASH_VERSION 
3.2.25(1)-release
0-0-14:11:43, Thu Sep 25 twc@aatlxz:~ (bash)
79954,2> getent passwd<position cursor here and press tab> | grep -i star

Actual results:

line half draws on line above, and cursor is placed in the right hand column of the screen.  Screen then ends up horribly confused if you invoke commandline history by pressing the up arrow.  Does not become unconfused until you press enter (ie, even ctrl-C,ctrl-U, or a keyboard binding for redraw-current-line etc fail to reposition the cursor properly)

Expected results:

Tab expansion happens and cursor is placed after the expanded text with possible completions

Additional info:
Comment 1 Roman Rakus 2008-09-30 12:42:36 UTC 
backporting patch bash32-027 from rawhide fix this problem.
Comment 2 RHEL Program Management 2009-03-26 16:53:34 UTC 
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 3 RHEL Program Management 2009-11-06 18:49:36 UTC 
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 5 RHEL Program Management 2010-08-09 18:36:18 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 6 RHEL Program Management 2011-01-11 21:01:38 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 7 RHEL Program Management 2011-01-11 22:18:54 UTC 
This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.
Comment 8 Roman Rakus 2011-01-18 15:07:59 UTC 
Created attachment 474069 [details]
Backported bash32-027 patch from upstream
Comment 9 Roman Rakus 2011-02-10 15:00:03 UTC 
Fixed in bash-3.2-25.el5
Comment 11 Misha H. Ali 2011-04-20 08:50:09 UTC 
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
When the tab key was pressed to display completion options for text, the cursor would move to an unexpected position on a line before the target line if the prompt contained characters not directly viewable followed by a "\]". This is now corrected to retain the cursor at the expected location at the end of the target line after autocomplete options correctly display.
Comment 12 Misha H. Ali 2011-04-21 00:02:33 UTC 
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-When the tab key was pressed to display completion options for text, the cursor would move to an unexpected position on a line before the target line if the prompt contained characters not directly viewable followed by a "\]". This is now corrected to retain the cursor at the expected location at the end of the target line after autocomplete options correctly display.+When the tab key was pressed for auto-completion options for the typed text, the cursor moved to an unexpected position on a previous line if the prompt contained unviewable characters and a "\]". This is now fixed to retain the cursor at the expected position at the end of the target line after autocomplete options correctly display.
Comment 14 errata-xmlrpc 2011-07-21 10:37:14 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-1073.html