Overcompensation for colon-including directory names

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)

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 / ble.sh

Overcompensation for colon-including directory names #501