error messages completing args inside $()

[Shriramana Sharma]

Hello. Please observe the following transcript (only [TAB] has been inserted to indicate the position where I hit TAB):

In Trusty:

$ cat <<EOF > foo
> Test
> EOF
$ echo $(< foo)
Test
$ echo $(< fo[TAB]bash: unexpected EOF while looking for matching `)'
bash: syntax error: unexpected end of file
^C
$ echo $(cat fo[TAB]bash: unexpected EOF while looking for matching `)'
bash: syntax error: unexpected end of file

In Saucy:

$ cat <<EOF > foo
> Test
> EOF
$ echo $(< foo)
Test
$ echo $(< fo[TAB]o^C
$ echo $(cat fo[TAB]o^C

Simply put, once I start a command substitution with $( I am not able to use the [TAB] completion in Trusty any longer while this was working file in Saucy. I hope this can be fixed soon since it really hampers use of the command-line. Thanks!

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Yuras (yuras-d)]

Ping?

This is really annoying bug :)

[wojtas (dudwin)]

I probably added in wrong place
https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/123665/comments/20

[Marcelo do Pagode (marfcg)]

This bug, filed in 2011 and fixed in 2012 seems similar (same error message: missing closing matching delimiter):
https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/772571

Since this bug has been fixed then, I hope it can at least shed some light on the current one.
PS: I'm using Trusty as well, having the same error when using $( in a bash for loop:
$for f in $(cat exam[TAB]bash: unexpected EOF while looking for matching `)'
bash: syntax error: unexpected end of file

Cheers!

[Peter Cordes (peter-cordes)]

This is upstream https://alioth.debian.org/tracker/index.php?func=detail&aid=314667&group_id=100114&atid=413095

Patch submitted there that makes it at least not spew errors, even though it still doesn't complete args inside $(command substitution).

[Peter Cordes (peter-cordes)]

BTW, upstream already had the no-results no-errors behaviour, so my patch didn't actually change anything behaviour-wise in upstream, just in trusty.

same change in _quote_readline_by_ref():
- [[ ${!2} == \$* ]] && eval $2=${!2}
+ [[ ${!2} == \$\'* ]] && eval $2=${!2}

I'd suggest going with upstream, not my patch, since I don't really understand what's going on in that code >.<

[Peter Cordes (peter-cordes)]

related: upstream
https://alioth.debian.org/tracker/index.php?func=detail&aid=314895&group_id=100114&atid=413095

Which I opened to report the fact that completion inside either kind of command substitution is broken, even when not spewing errors.

[Malte Skoruppa (malte-countnumber)]

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.)

[Malte Skoruppa (malte-countnumber)]

For everyone's convenience and reference, here's the 00-fix_quote_readline_by_ref.patch file that I mentioned in comment #8.

[Malte Skoruppa (malte-countnumber)]

For everyone's convenience and reference, here's the 00-fix_quote_readline_by_ref.patch file that I mentioned in comment #8.

[Malte Skoruppa (malte-countnumber)]

Looking at the aforementioned patch, it appears that it was made by Juan Ciarlante to fix this bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739835

However, it also introduced the bug described in the current bug report.

Using the unpatched, upstream version of bash-completion, I still cannot reproduce the #739835 Debian bug in Ubuntu 14.04. Maybe Juan's patch is not necessary any longer?

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "The culpable Ubuntu patch that causes bug #1312243" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Paul Graydon (pgraydon-oracle)]

Still seems to be affecting 16.04. It's really quite annoying.

[Vasya Pupkin (shadowlmd)]

Affects me too in 16.04. Bug is present in latest Debian package as well.

[David (abbasi-david)]

Still happening in ubuntu 18.04

[deivid (deivid-rodriguez)]

Hei, any news here? The upstream version does contain the aforementioned patch (https://github.com/scop/bash-completion/blob/master/bash_completion#L511-L541), and it does not dump this error message everytime tab is pressed in this situation. Tab completing inside `$(` does nothing, which is a much friendlier behavior that throwing errors to the screen.

Should that patch be reverted in the packages?

[Tharrrk (tharrrk)]

Just hit this 6-year old bug.
I haven't upgraded to 20.04 yet but in 18.04 it's still present.

This bug potentially has quite fatal consequences, imagine you type...

for a in $(`reboot`)

...and press <TAB>.

(replace reboot with whatever potentially dangerous command)

eval = EVIL !!!

[Tharrrk (tharrrk)]

Just manually installed bash-completion_2.10-1ubuntu1_all.deb from focal.
Seems solved although the very same eval is still there in _quote_readline_by_ref()