[fzf-completion] Overcompensation for colon-including directory names

[mcepl]

tumbleweed-pkg:cpython (opensuse_3.6 %) $ ble/widget/display-shell-version
GNU bash, version 5.2.32(1)-release (x86_64-suse-linux) [openSUSE Tumbleweed]
ble.sh, version 0.4.0-devel4+670c7ea0 (noarch) [git 2.46.0, GNU Make 4.4.1, GNU Awk 5.3.0, API 4.0, PMA Avon 8-g1, (GNU MPFR 4.2.1, GNU MP 6.3.0)]
bash-completion, version 2.12.0 (hash:480ffcc6a751e55621ec526eb5dea7a0d86d9e72, 17877 bytes) (noarch)
fzf key-bindings, (hash:2da32cbab672fc962b4c56c6a052a6bf47ef2c12, 5618 bytes) (noarch) (integration: on)
fzf completion, (hash:abeb2e9a08b2fd5cf60d7aa6889028dc9de744dc, 17494 bytes) (noarch) (integration: on)
locale: LANG=cs_CZ.utf8 LC_CTYPE=cs_CZ.UTF-8
terminal: TERM=xterm-256color wcwidth=15.1-west/15.1-2+ri, foot:11801 (1;011801;0)
options: +autocd +extglob +failglob +globstar +histappend -hostcomplete +inherit_errexit +login_shell
tumbleweed-pkg:cpython (opensuse_3.6 %) $ 

When completing a file in directory which names contains colon character (specifically ~/build/devel\:languages\:python\:Factory/python36/) ble.sh tries to quote colon characters, but during the completion process, it does it too much, so the result is ~/build/devel\\\:languages\\\:python\\\:Factory/python36/CVE-2024-6232-ReDOS-backtrack-tarfile.patch, which doesn’t work.

See https://asciinema.org/a/JS7xiLCezmNnOhEhcJb0HjZj0 (play it in the full screen)

[akinomyoga]

Thanks for the report. Sorry for the delayed reply. I could reproduce the problem in my environment, so I have been testing the behavior locally. This seems to be related to Bash's compgen's behavior called by the bash-completion framework. The compgen builtin turned out to behave differently inside/outside Readline. Since bash-completion is designed and tested with the behavior of the compgen builtin inside Readline, it can generate broken results when the programmable completion is called outside Readline (as done in ble.sh).

The following example demonstrates the behavior of the compgen builtin in a plain Bash (without ble.sh):

$ cat bashrc
mkdir -p ~/tmp1/a:b
touch ~/tmp1/a:b/{a..c}.txt
function _test1 {
  COMPREPLY=($(compgen -f -- '\~/tmp1/a\\:b/'))
  printf '\e[32;1m<%s>\e[m' "${COMPREPLY[@]}" >/dev/tty
}
complete -F _test1 test1
$ bash --rcfile bashrc
$ _test1[RET]
<~/tmp1/a\:b/a.txt><~/tmp1/a\:b/b.txt><~/tmp1/a\:b/c.txt>$
$ test1 [TAB]<~/tmp1/a\:b/a.txt><~/tmp1/a\:b/b.txt><~/tmp1/a\:b/c.txt>~/tmp1/a\:b/[TAB]<~/tmp1/a:b/a.txt><~/tmp1/a:b/b.txt><~/tmp1/a:b/c.xt>

In the above results, one can observe the following behavior of the compgen builtin:

• When one directly calls the function _test1 outside Bash's programmable completion, the colons in the result of compgen -f '\~/tmp1/a\\:b/' are quoted as \:.
• When _test1 calls compgen -f '\~/tmp1/a\\:b/' for the empty word, the colons are still quoted.
• However, when _test1 calls compgen -f '\~/tmp1/a\\:b/' for the word ~/tmp/a\:b/, the colons are somehow not quoted.

The bash-completion framework basically calls compgen for the current word, so it usually sees the result of the third case. However, when the programmable completion setting of bash-completion is used by ble.sh, it falls into the first case, where extra escaping of the colons are generated. ble.sh considers that \: would mean the literal ':', so it considers \: would need to be quoted as \\\: in the command line.

[akinomyoga]

I added a fix in akinomyoga/blesh-contrib@ce3409d. Could you check the behavior in the latest master?

I realized that the reported issue doesn't arise when the fzf completion is not loaded. The adjustments made by ble.sh somehow sidestepped the behavior change of the compgen builtin. The problem happened with the fzf completion because the fzf completion needs to bypass the adjustments by ble.sh as implemented in the integration script contrib/integration/fzf-completion.bash. I adjusted contrib/integration/fzf-completion.bash so as to revert the adjustments for the fzf completion in the dynamic completion called by the fzf completion.