Bug 70819 - TAB-completion of `pwd`-started pathname never completes
Summary: TAB-completion of `pwd`-started pathname never completes
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: bash
Version: limbo
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: wdovlrrw
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks: 67218
TreeView+ depends on / blocked
 
Reported: 2002-08-05 19:28 UTC by Alexandre Oliva
Modified: 2007-04-18 16:45 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-08-22 11:37:19 UTC
Embargoed:


Attachments (Terms of Use)
Implementation of the fix for ADVANCE_CHAR in case it reaches the end of the string (312 bytes, patch)
2002-08-22 03:05 UTC, Alexandre Oliva
no flags Details | Diff

Description Alexandre Oliva 2002-08-05 19:28:59 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020724

Description of problem:
Earlier versions of bash (e.g. in 7.3) would expand `pwd`/ to the current
pathname when TAB-completing them.  The current version enters and endless loop.

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


How reproducible:
Always

Steps to Reproduce:
1.Log in as root
2.Type ls `pwd`/anaconda
3.Type TAB
	

Actual Results:  Nothing happens.
Still nothing happens.
Nothing keeps on happening. :-)
CPU usage goes up as bash uses up a lot of it.
Control-C is the only way to get it out of this loop.

Expected Results:  I'd expect it to expand `pwd` into /root, and complete the
pathname to /root/anaconda-ks.cfg

Additional info:

There's nothing special about root or anaconda-ks.cfg, it was just an example
that was readily-available on any Red Hat Linux install.  The same problem can
be easily replicated as any other user with any other pathname.

Comment 1 Tim Waugh 2002-08-19 11:00:07 UTC
I can't reproduce this problem with bash-2.05b-3.  What version are you using?

Comment 2 Alexandre Oliva 2002-08-19 12:17:33 UTC
The same.  It's odd.  I just had trouble duplicating it myself, but it is surely
there.  It seems that it only shows up in the shell started within
gnome-terminal.  In a `su -' or `ssh'-started login shell, it works just fine.

Comment 3 Alexandre Oliva 2002-08-22 03:04:32 UTC
I couldn't identify what causes the problem to show up or not, but it occurs in
subst.c:unclosed_pair(), when checking whether the closing backtick is unpaired.
 The counter reaches the end of the string, and from then on ADVANCE_CHAR no
longer increments i in the case of MB_CUR_MAX > 1, even though it will do so
just fine when MB_CUR_MAX == 1 (which is the case of a ssh-started bash).  The
idiom of testing for mblength < 1 is present in several of the other
multibyte-enabled macros in include/shmbutil.h, so I used it in ADVANCE_CHAR too.

Comment 4 Alexandre Oliva 2002-08-22 03:05:50 UTC
Created attachment 72144 [details]
Implementation of the fix for ADVANCE_CHAR in case it reaches the end of the string

Comment 5 Tim Waugh 2002-08-22 11:37:13 UTC
Fixed package is bash-2.05b-4.

Comment 6 Alexandre Oliva 2002-08-25 22:36:23 UTC
Confirmed fixed in bash-2.05b-5


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