Bug 70819 - TAB-completion of `pwd`-started pathname never completes
TAB-completion of `pwd`-started pathname never completes
Product: Red Hat Public Beta
Classification: Retired
Component: bash (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: wdovlrrw
Ben Levenson
Depends On:
Blocks: 67218
  Show dependency treegraph
Reported: 2002-08-05 15:28 EDT by Alexandre Oliva
Modified: 2007-04-18 12:45 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-08-22 07:37:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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-21 23:05 EDT, Alexandre Oliva
no flags Details | Diff

  None (edit)
Description Alexandre Oliva 2002-08-05 15:28:59 EDT
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:

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 07:00:07 EDT
I can't reproduce this problem with bash-2.05b-3.  What version are you using?
Comment 2 Alexandre Oliva 2002-08-19 08:17:33 EDT
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-21 23:04:32 EDT
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-21 23:05:50 EDT
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 07:37:13 EDT
Fixed package is bash-2.05b-4.
Comment 6 Alexandre Oliva 2002-08-25 18:36:23 EDT
Confirmed fixed in bash-2.05b-5

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