Created attachment 915446 [details] Comment (This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
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.
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).
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 \~* ?
(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.
(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.
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.
Ok, thanks for testing!
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.
Thanks for the info. Just to make sure, does re-applying the previous workaround fix it again?
(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)
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
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
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).
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.