What has exactly changed here? I just tested those with bash-4.2 and bash-4.3 and it gave the exact same results. Both with and without bash-completion installed. These are also expected behaviour...

How is it expected that files and directories are not completed (btw, there should be a command before those examples, e.g. `ls ~/.ssh/<TAB>`).

Downgrading to 4.2.045-5 and completion works fine.

This patch[1] solves the completion issue with ls, but vim still has issues.

I've made another workaround (see attached patch) that fixes the issue completely for me. This is very likely unacceptable for upstream bash-completion, but works for now.

[1]: http://lists.alioth.debian.org/pipermail/bash-completion-devel/2013-February/004740.html

Oh, the cause is a behavior change of printf wrt quoting.

$ printf '%q\n' '~/.ssh/'
~/.ssh/ # in bash < 4.3
\~/.ssh/ # in bash >= 4.3

Ah, with a command in front, then it is not expected...

Thought I'd mention more bash 4.3 fail in here...
Using <tab><tab> to list files in a directory with escaped characters in it's name doesn't work in 4.3 either.
e.g. ls ./this\ directory/<tab><tab> does nothing.
downgrading to 4.2 has things working like they always have.

Reassigning - these are all bash-completion issues.

This bug is marked "Waiting for response". Who are we waiting on a response from?

That flag was added in the initial comment, I replied in the post thereafter.

Thanks for the quick reply.
I was under the impression since the bug had been assigned then reassigned it would now be marked "Assigned".
Don't know who would be responsible for that or if it is even relevant...

Another weird autocompletion with bash from [testing]:

$<TAB> -bash: words: bad array subscript
$<TAB> -bash: words: bad array subscript
$<TAB> -bash: words: bad array subscript

$<TAB><TAB> -bash: words: bad array subscript
-bash: words: bad array subscript

pkg/ src/

@Anatol That bad array error was present before the new Bash version although it only happened with:

$ <spaces><TAB>

e.g.

$ -bash: words: bad array subscript
-bash: words: bad array subscript

This is the possible troublesome path where cword becomes negative (in reverse order):
__reassemble_comp_words_by_ref
__get_cword_at_cursor_by_ref
_get_comp_words_by_ref
_init_completion

Display all 148 possibilities? (y or n)

OT: Ubuntu and Debian are also affected:
https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1288031

Tip: if you want to debug this, use `set -x` for more details (its inverse is `set +x`).

Please test bash-completion 2.1-3 from [testing].

There is no 2.1-3 in testing yet,
I applied bash-4.3.patch from r208062 to /usr/share/bash-completion/bash_completion (after reverting my changes),
but the issue persists (unable to tab-complete ~/.ssh/).

I encountered another (related?) issue, file completion does not occur at all when no key words are given. For instance:
$ ls <TAB><TAB>
(completions shown, but without files such as .bashrc)
$ ls .<TAB><TAB>
(now files are included)

ow, sorry, bad bugreport

greetings

Peter: I'm unable to reproduce the issue after installing 2.1-3. "ls <TAB><TAB>" completes available files and directories fine.

Upgrading to bash-completion 2.1-3 and bash 4.3 resolves the issue I brought up.
I can also list the files in .ssh/ with ~/.ssh/<tab><tab>.
Thanks.

bash-completion 2.1-3 fixes only some, but not all, issues.

Specifically, the completion of the type:
$ links $(<~/te<TAB>) doesn't work (it used to). Instead, I get
bash: unexpected EOF while looking for matching `)'
bash: syntax error: unexpected end of file, I think in _quote_readline_by_ref()

I can open a separate bug report, but perhaps it's better to keep completion-related regressions in one place.

Thanks.

This should be reported upstream.

I've applied this[1] patch to bash, please test if these packages[2] fixes completion.

[1] https://lists.gnu.org/archive/html/bug-bash/2014-03/msg00123.html
[2] http://pkgbuild.com/~barthalion/tmp/fs39142/

I've built 4.3-3 with that the pcomplete-dequote patch, tested with bash-completion 2.1-4 and completion still works.

What is this patch supposed to fix?

Thanks.

The above patch makes the error go away (so the length of the input string is calculated properly AFAIU), but the completion still doesn't work:
-----
$ pacman -Q bash bash-completion
bash 4.3-3.1
bash-completion 2.1-4
$ echo 1 > /tmp/1.pid
$ cat /tmp/1.pid
1
$ kill $(cat /tmp/<TAB>)
-----
... and the shell doesn't complete the filename.

I did not look in detail at what happens, but I'll do and report this upstream.

I notice this has not been mentioned:
https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1289597

I seem to be affected by it even in -4.

Apparently this had been fixed in ubuntu (https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1289597), so I guess it is just a matter of updating the repo

bash-completion-2.1-5 has the ubuntu patch. Does that fix the issue?

"$<tab>" results in "$ bash: words: bad array subscript"

Can somebody test this again on the latest version of bash? Ticket hasn't been updated in two years so would like to find the current status of whether this is or is not still occurring.

The original and follow up issue (with tabbing on an empty command) cannot be reproduced anymore here, it can be closed. Thanks!

Awesome, thanks for the response. Will request this be closed.