Bug 817902 - Bash-completion of file/directory paths hangs bash
Summary: Bash-completion of file/directory paths hangs bash
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: bash-completion
Version: 17
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Ville Skyttä
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-05-01 18:17 UTC by Stephen Gallagher
Modified: 2012-06-22 18:55 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-06-22 18:55:38 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Log of 'set -x' and then completion (3.53 KB, text/plain)
2012-05-02 10:58 UTC, Stephen Gallagher
no flags Details
Comment (84.64 KB, text/plain)
2012-05-01 18:17 UTC, Stephen Gallagher
no flags Details

Description Stephen Gallagher 2012-05-01 18:17:47 UTC
Created attachment 915446 [details]
Comment

(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).

Comment 1 Ville Skyttä 2012-05-02 07:07:04 UTC
I'm fairly certain that this isn't a bash-completion bug, but to give some more confidence to that guess, please reproduce the issue so that the hang starts to happen, then do a "set -x" in a shell, invoke the hanging completion, and post or attach the output here.

Comment 2 Stephen Gallagher 2012-05-02 10:58:44 UTC
Created attachment 581578 [details]
Log of 'set -x' and then completion

Attaching the output as requested. For the record, the command was "cd x<tab>" and it should have expanded to "x86_64" (the only directory in that folder that starts with x).

Comment 3 Ville Skyttä 2012-05-02 18:08:13 UTC
Curious.  The next line in your output should have been this:

    + [[ x == ~* ]]

...which corresponds to the first condition on line 923 in bash_completion's _tilde() function:

    if [[ $1 == ~* && $1 != */* ]]; then

The only vague guess I have at the moment would be that the ~ ends up doing something unexpected.  Can you try replacing the ~* with "~"*, i.e. quoting the tilde and checking if the issue still reproduces?  Ditto with backslash-escaping it like \~* ?

Comment 4 Stephen Gallagher 2012-05-02 20:12:15 UTC
(In reply to comment #3)
> Curious.  The next line in your output should have been this:
> 
>     + [[ x == ~* ]]
> 
> ...which corresponds to the first condition on line 923 in bash_completion's
> _tilde() function:
> 
>     if [[ $1 == ~* && $1 != */* ]]; then
> 
> The only vague guess I have at the moment would be that the ~ ends up doing
> something unexpected.  Can you try replacing the ~* with "~"*, i.e. quoting the
> tilde and checking if the issue still reproduces?  Ditto with
> backslash-escaping it like \~* ?

I've been running with the backslash-escape for a couple hours now and I haven't seen the issue reappear. That seems to do the trick.

Comment 5 Ville Skyttä 2012-05-31 18:35:48 UTC
(In reply to comment #4)
> I've been running with the backslash-escape for a couple hours now and I
> haven't seen the issue reappear. That seems to do the trick.

Thanks for testing.  If you have the time, could you try reverting the backslash-escape and see if the issue starts to appear again, and then applying it again to see if it goes away again?  Sorry about this, but I cannot reproduce the issue myself yet would like to be more certain about this really being the fix before starting to patch things.

Comment 6 Stephen Gallagher 2012-06-06 12:27:06 UTC
I reverted the change and I'm no longer seeing the issue. I don't know what changed. Feel free to close this BZ. I'll reopen it if the problem reappears.

Comment 7 Ville Skyttä 2012-06-06 18:48:26 UTC
Ok, thanks for testing!

Comment 8 Stephen Gallagher 2012-06-11 15:11:21 UTC
Reopening. It apparently wasn't immediate, but it has started reoccurring for me again. I suspect this was related to updating to bash-4.2.29-1.fc17.x86_64 yesterday.

Comment 9 Ville Skyttä 2012-06-13 22:07:50 UTC
Thanks for the info.  Just to make sure, does re-applying the previous workaround fix it again?

Comment 10 Stephen Gallagher 2012-06-14 18:08:29 UTC
(In reply to comment #9)
> Thanks for the info.  Just to make sure, does re-applying the previous
> workaround fix it again?

Yes, it appears to do the trick (after setting it and a day without it reappearing)

Comment 11 Ville Skyttä 2012-06-14 18:56:44 UTC
Ok, pushed upstream, will be in the next package revision.
http://anonscm.debian.org/gitweb/?p=bash-completion/bash-completion.git;a=commitdiff;h=709d6e0

Comment 12 Fedora Update System 2012-06-19 17:31:46 UTC
bash-completion-2.0-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/bash-completion-2.0-1.fc17

Comment 13 Fedora Update System 2012-06-20 19:31:28 UTC
Package bash-completion-2.0-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing bash-completion-2.0-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-9735/bash-completion-2.0-1.fc17
then log in and leave karma (feedback).

Comment 14 Fedora Update System 2012-06-22 18:55:38 UTC
bash-completion-2.0-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.


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