Comment 8 for bug 1312243

This bug is not upstream. This bug does not happen with the bash_completion library provided in the upstream Git repository, neither in its master branch nor in its 2.1 branch (most current stable revision).

Rather, this bug is introduced by an Ubuntu patch that is applied against the upstream 2.1 stable version to produce the bash-completion Ubuntu package.

More precisely, the guilty patch is 00-fix_quote_readline_by_ref.patch by Juan José Ciarlante, a Canonical dev. I have subscribed Juan to this bug report. (Note: use 'apt-get source bash-completion' to obtain the patch in a directory called debian/patches/)

Beside two other changes, this patch introduces the following lines:

+ # Replace double escaping ( \\ ) by single ( \ )
+ # This happens always when argument is already escaped at cmdline,
+ # and passed to this function as e.g.: file\ with\ spaces
+ [[ ${!2} == *\\* ]] && printf -v $2 %s "${1//\\\\/\\}"
+

This change is accompanied by the following comment:

Subject: fix _quote_readline_by_ref to:
...
 - replace double escaping to single (eg for completing file/paths with
   spaces)

Removing those lines fixes this bug. I am not sure what bug these particular lines are supposed to fix: Completing files/paths with spaces works just as well in the upstream version.

Please note that the bug we are talking about here is the error message "unexpected EOF while looking for matching `)'" when attempting to complete a command within $(). Generally, bash completion inside command substitution appears to be broken with Bash 4.3, but at least the upstream version does not output that particular annoying error mesage.

(@Peter Cordes: If you can actually reproduce this bug with an upstream revision, let me know how. However I do not believe that this will be possible. Hence the upstream devs cannot fix this bug. I am not sure whether your proposed fix of slightly changing the [[ ${!2} == \$* ]] test as you explained in https://alioth.debian.org/tracker/?func=detail&aid=314667&group_id=100114&atid=413095 does not break some other intended functionality. If Juan's change described above is not necessary any longer, the best option may simply be to revert this change. Hopefully Juan can shed some light on this.)