Hiya guys, I noticed since I upgraded to bash-4.0_p10 that bash completion on filenames with escaped characters no longer seemed to be working as it used to. Here's an example: directory structure: a/b\ c/d\ e/ cd a/<tab> => cd a/b\ c/ cd a/b\ c/<tab><tab> => cd a/b\ c/<beep><beep> cd a/b\ <tab> => cd a/b\ <beep> cd a/b<tab> => cd a/b\ c/ So it's clear that it's stopping on the escaped character. There's exactly the same behaviour with b\(c. I'm not sure how to go about debugging bash-completion scripts, but in case it's useful here's my shopt output: autocd off cdable_vars off cdspell off checkhash off checkjobs off checkwinsize on cmdhist on compat31 off compat32 off dirspell off dotglob off execfail off expand_aliases on extdebug off extglob on extquote on failglob off force_fignore on globstar off gnu_errfmt off histappend on histreedit off histverify off hostcomplete off huponexit off interactive_comments on lithist off login_shell on mailwarn off no_empty_cmd_completion off nocaseglob off nocasematch off nullglob off progcomp on promptvars on restricted_shell off shift_verbose off sourcepath on xpg_echo off I've CCed base-system in case the bash-maintainers have seen anything like this before. If there's any further information I can provide, or any tests you want me to run, just let me know... 5:)
I'm having the same issue with =bash-4.0_p10 on two boxes. Tab completion "dies" when it meets an escaped character in a file/dir name. Downgrading to =bash-3.2_p48-r1 fixes the issue.
Same problem, autocompletion fails due to the escape character.
*** Bug 262474 has been marked as a duplicate of this bug. ***
Same problem with bash-4.0_p10
My bad with bash-4.0_p10-r1
You can find at least a partial solution to this problem at http://lists.gnu.org/archive/html/bug-bash/2009-03/msg00165.html
Created attachment 185932 [details, diff] patch that (partially) fixes completion with escaped characters in >=app-shells/bash-4.0 patch taken from http://lists.gnu.org/archive/html/bug-bash/2009-03/msg00165.html
Created attachment 185934 [details, diff] ebuild patch for =app-shells/bash-completion-20081219-r1.ebuild that applies above patch if has_version >=app-shells/bash-4.0
Created attachment 185935 [details] patched app-shells/bash-completion ebuild that uses the above patch
It is not clear to me if this is a bash or bash-completion issue as you have referenced a patch sent to the *bash* mailing list.
Doh, I should read better. It is solely completion related. I am talking with bash-completion upstream and will have a version bump or patched ebuild soon. thx. (base-system doesn't need to be on this bug)
Created attachment 186772 [details, diff] bash-completion-20081219-bash4.patch This patch combines the one previously suggested with one from the redhat bugzilla, this mostly seems to fix the problem. https://bugzilla.redhat.com/show_bug.cgi?id=490322
sorry for the delay guys. Some of this has been fixed in v1.0 which should be in the tree within a day
(In reply to comment #13) > sorry for the delay guys. Some of this has been fixed in v1.0 which should be > in the tree within a day > Oh, you will have to "downgrade" to use v1.0. Please fill me in on any problems now. It is hard to determine what is fixed or not. thx.
scp-autocompletion is still not working for me: after completing the host (adding a colon), the ssh completion does not complete file names on the remote side but another instance of known_hosts on the local side. If I add a / after the colon, I get completion for local files (starting with /). versions: $ eix -Ic bash [I] app-shells/bash (4.0_p17 2009/04/09/11:58 net nls plugins -afs -bashlogger -examples -vanilla) [I] app-shells/bash-completion (1.0 2009/04/09/12:15 ) [I] app-shells/gentoo-bashcomp (20090222 2009/03/17/10:49 ) Found 3 matches.
Ok, I followed all the links and various bug reports and they all lead me to upstream patch: http://git.debian.org/?p=bash-completion/bash-completion.git;a=commitdiff_plain;h=1421e55aac075e13491cd212b796bdd453214a2c;hp=27daafa76fe1821e5ff3d46f5b64fe8464708084 So, I committed that in 1.0-r1. I don't have bash4 easily available to me here so I will depend on feedback from you guys. Please re-open if needed.
*** Bug 263109 has been marked as a duplicate of this bug. ***
(In reply to comment #17) > *** Bug 263109 has been marked as a duplicate of this bug. *** > This means that other people are hitting this issue with bash-4. I have now fixed the upgrade path in bash-completion. v0.* is stable, v1.0* is ~arch. bash-4 users will now get the correct b-c package without fuss. thx for all the reports and testing, people.
*** Bug 267149 has been marked as a duplicate of this bug. ***
