You are not logged in.
After a recent system upgrade, I noticed that bash completion of paths with shell variables is somewhat broken. For example:
cd /
cd $HOME/De<tab>
#results
cd \$HOME/Desktop<space>
This definitely worked before, either instantly substituting the value of $HOME and then continuing to complete the directories as normal, or leaving the variable name form and completing the directories - I've seen both behaviors on different systems, but since they both worked fine for me I never cared to figure out why it would pick a particular behavior.
But now, you'll notice that it knows I'm completing a directory, and completes one level, but then escapes the dollar sign so not even that expression works, and further adds a space instead of a forward slash on the end... if you delete the backslash and the space, and type a forward slash and part of another directory you'll get another completion, but then it breaks itself again the same way...
By the way, I don't have bash_completion installed, I tried it after moving my .bashrc and "su - username" and ensuring the environment was clean, and I also moved the bash_completion.d directory out of paranoia, with no luck.
Help?
I guess I should just file a bug report with the bash project - it looks like the kinda completion you sometimes get to help you escape odd characters in filenames, for example
touch 'odd[file'
rm od<tab>
# results
rm odd\[file
Offline
See https://bbs.archlinux.org/viewtopic.php?id=113158
# edit: missed "By the way, I don't have bash_completion installed..."
Offline
I did in fact search around, and found the 4 or so variations on that thread... this is a different issue. This problem is different (and I don't have bash_completion installed).
I did just manage to find the issue on the bash mailing list though: http://lists.gnu.org/archive/html/bug-b … 00274.html
(which I wasn't able to find with duckduckgo)
so sorry for the forum spam
Offline
Indeed, this is an up-stream bug, and Chet isn't sure which direction to take with it. I guess we'll just have to wait to find out, unless someone wants to submit a patch
Offline
This bug is so annoying :-/ Are there any known workarounds to get the old behavior back?
Last edited by splitbrain (2011-04-20 19:51:05)
Offline
the bash maintainer recently posted a "90%" patch: http://lists.gnu.org/archive/html/bug-b … 00235.html - I haven't tried it yet
Offline
I've tried it with my own PKGBUILD copied from ABS with the required patch.
That works as expected.
PKGBUILD : http://pastie.org/2281804
++sputnick;
Offline
Damn, doesn't work anymore, dunno why
Offline
I just now decided to actually rebuild the bash package with this patch, and I was able to get it to work. I downloaded all the bash files from archlinux svn, I saved the patch as "completion.patch", and I added
msg "applying patch ${srcdir}/completion.patch"
patch -Np0 -i "${srcdir}/completion.patch"
right after the patching loop in the PKGBUILD (and I added completion.patch to the source array and its md5sum to md5sums).
Now having tried it, it's better than without the patch, but it's still not perfect - it adds a space after completing a folder in a path starting with a variable, instead of a slash, so to complete further path components you have to type backspace slash after each...
Offline