cd text TAB to autocomplete fails for dir with spaces (Linux)

[tessus]

$ ble summary

GNU bash, version 5.2.32(1)-release (x86_64-redhat-linux-gnu) [Fedora Linux 41 (KDE Plasma)]
ble.sh, version 0.4.0-devel4+3d8f626 (noarch) [git 2.47.1, 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.13.0 (hash:480ffcc6a751e55621ec526eb5dea7a0d86d9e72, 17877 bytes) (noarch)
fzf key-bindings, (hash:2da32cbab672fc962b4c56c6a052a6bf47ef2c12, 5618 bytes) (noarch) (integration: on)
fzf completion, (hash:afdb947635ba13e3f5a5f6d147f943e43f7dbbf3, 17559 bytes) (noarch) (integration: on)
starship, version 1.21.1 (rustc 1.82.0 (f6e511eec 2024-10-15),stable-x86_64-unknown-linux-gnu 2024-11-16 21:08:30 -05:00)
zoxide, version 0.9.6 (/usr/local/bin/zoxide) (integration: on)
atuin, version 18.4.0 (/usr/local/bin/atuin)
locale: LANG=en_US.utf-8 LC_ALL=en_US.utf-8 LC_CTYPE=en_US.utf-8
terminal: TERM=xterm-256color wcwidth=15.0-west/16.0-2+ri, xterm:2500 (64;2500;0)
options: +extglob +histappend -hostcomplete +inherit_errexit +login_shell

zoxide 0.9.6

I'm using zoxide on my Linux VM, initialized as follows in my .bashrc:

[[ `command -v zoxide` ]] && eval "$(zoxide init --cmd cd bash)"

Steps te reproduce:

1. mkdir -p "tmp/multiple spaces in dir"
2. cd tmp/mul<TAB>

Result:

cd tmp/multiple spaces in dir/
zoxide: no match found

zox1.mp4

Expected result:

cd 'tmp/multiple spaces in dir'/

On macOS, I get the expected result. The dir returned from the TAB autocomplete is quoted with single quotes, iff the dir contains spaces. On Linux, the TAB autocomplete does not have the single quotes, thus changing into that dir fails.

If I deactivate ble, I get: cd tmp/multiple\ spaces\ in\ dir/.
If ble is activated and zoxide deactivated, I get: cd 'tmp/multiple spaces in dir'/

Apparently the combinsation of zoxide and ble does not work. On Linux that is. On macOS it works just fine.

[akinomyoga]

Thanks for the report. I tried it in Fedora 41, but the problem doesn't reproduce with

• bash-5.2 + ble.sh + zoxide

I also tried the following combinations, but none reproduced the problem.

• bash-5.2 + ble.sh + bash-completion + fzf-completon + zoxide
• bash-5.2 + ble.sh + bash-completion + zoxide + fzf-completon (different initialization order)
• bash-5.2 + ble.sh + zoxide + fzf-completon
• bash-5.2 + ble.sh + fzf-completon + zoxide

I also tried turning off auto-complete (bleopt complete_auto_complete=) and syntax highlighting (bleopt highlight_syntax), but the problem doesn't reproduce.

• Q1: What are the results of the following commands?

$ complete -p cd
$ type _fzf_handle_dynamic_completion
$ declare -p _fzf_orig_completion_cd

(These are the results in my environment)

Without fzf

$ complete -p cd
complete -o filenames -F __zoxide_z_complete cd
$ type _fzf_handle_dynamic_completion
bash-5.2: type: _fzf_handle_dynamic_completion: not found
[ble: exit 1]
$ declare -p _fzf_orig_completion_cd
bash-5.2: declare: _fzf_orig_completion_cd: not found
[ble: exit 1]
$

With fzf

$ complete -p cd
complete -o filenames -F _fzf_dir_completion cd
$ type _fzf_handle_dynamic_completion
_fzf_handle_dynamic_completion is a function
_fzf_handle_dynamic_completion ()
{
    ble/function#advice/.proc "$FUNCNAME" "$@"
}
$ declare -p _fzf_orig_completion_cd
declare -- _fzf_orig_completion_cd="complete -o filenames -F %s cd #__zoxide_z_complete"
$

• Q2: Could you minimize the settings that reproduce the problem? (Before minimizing, please save a backup of ~/.bash_history if you want to keep it.)

[tessus]

Thanka for the reply.

$ complete -p cd
complete -o filenames -F __zoxide_z_complete cd

$ type _fzf_handle_dynamic_completion
_fzf_handle_dynamic_completion is a function
_fzf_handle_dynamic_completion ()
{
    ble/function#advice/.proc "$FUNCNAME" "$@"
}

$ declare -p _fzf_orig_completion_cd
-bash: declare: _fzf_orig_completion_cd: not found

Tomorrow I'll minimize the config and also try to figure out why the last command returns an error. The output on macOS is declare -- _fzf_orig_completion_cd="complete -o filenames -F %s cd #__zoxide_z_complete".

Strange thing is that I am using the same setup. I am using dotbot. I do have a few macOS specific configs (aliases, path, gpg pinentry), but not when it comes to setting up ble, zoxide, starship, fzf, completion, and atuin. Weird.

[akinomyoga]

$ declare -p _fzf_orig_completion_cd
-bash: declare: _fzf_orig_completion_cd: not found

[...] try to figure out why the last command returns an error.

Ah, sorry. I forgot to tell you that one needs to run declare -p _fzf_orig_completion_cd after attempting the completion for cd tmp/mul[TAB] at least once in the session. Or doesn't the result change even after attempting the completion?

[tessus]

Same result, even after attempting the auto complete.

I'm about to fall asleep. I'm way past my bed time. ;-) ttyl. And thanks again for looking into this. I'm gonna do more debugging tomorrow and I'll get you a minimal .bashrc.

[akinomyoga]

Thanks! Good night!

[tessus]

I found the issue, even though it is rather weird, since I made changes to this provided by you for an earlier issue. And it works on macOS, so that's even stranger. Usually things work on Linux and have to be adjusted for macOS.

If I source this file in .bashrc, I run into the issue above:

https://evermeet.cx/paste/fzf.7qs6.sh

Here is the other file that is sourced from within that file: https://evermeet.cx/paste/fzf_git.W66w.sh

(The files will be available for 7 days.)

As you can see I made the changes you provided for ble and fzf.

P.S.: I have created a VM that shows that problem. If you want access, please let me know. In that case I'll send the connect info via email.

[akinomyoga]

Thanks. I now tried your files, but I still cannot reproduce the problem.

If I source this file in .bashrc, I run into the issue above:

https://evermeet.cx/paste/fzf.7qs6.sh

What is the content of .bashrc? I guess ble.sh is sourced, at least. Are there other settings such as bash-completion and zoxide?

(The files will be available for 7 days.)

Thanks. I've already copied the file in my development machine, so you can remove those files now (if it is possible and you'd like to do it).

P.S.: I have created a VM that shows that problem. If you want access, please let me know. In that case I'll send the connect info via email.

OK, it works for me. Thank you.

[akinomyoga]

I could minimize the setup in your environment:

# ~/.bashrc

. /etc/profile.d/bash_completion.sh
. ~/.local/share/blesh/ble.sh
ble-import -d integration/fzf-completion
eval "$(zoxide init --cmd cd bash)"

Then, I realized that the version of bash-completion is different from the one I used for the test. With bash-completion-2.13.0, I could reproduce the problem also in my environment.

[tessus]

Thanks for the info. Does this mean it's an upstream issue? e.g. I guess the bash completion on macOS is also different.

[akinomyoga]

I further reduced the setup. It was actually unrelated to the version of bash-completion, but how the bash-completion was sourced. The system bash-completion tries to source /etc/bash_completion.d/*.sh, and one of the files in /etc/bash_completion.d (i.e., /etc/bash_completion.d/fzf) triggers the problem. The bash-completion itself is not even needed to reproduce the behavior. The current reproducer in my environment is this:

# bashrc
source /path/to/ble.sh --norc
source /etc/bash_completion.d/fzf
ble-import -d integration/fzf-completion
eval "$(zoxide init --cmd cd bash)"

This means that the fzf completion setting is loaded by the system and then loaded by ble-import again. This conflicts with the requirement by ble.sh.

I'll further investigate if we could work around the problem even when the raw settings is loaded, but it might be difficult.

[akinomyoga]

I could even simplify the reproducer as follows. The key was dropping -d.

# bashrc
source /path/to/ble.sh --norc
ble-import integration/fzf-completion
eval "$(zoxide init --cmd cd bash)"

I'll later look closer at it.

[tessus]

Interesting, so it seems that ble-import integration/fzf-completion does different things on macOS and Linux - or they behave differently.

Weird though that I am the first one who encountered this. fzf and zoxide are quite common these days.

Thanks again for looking into this.

[akinomyoga]

I fixed it in commit akinomyoga/blesh-contrib@a5d3a2e. This was an issue with the zoxide integration (which is automatically loaded) and was actually identical to the problem reported for fzf in #250 and fixed in akinomyoga/blesh-contrib@e102241. The zoxide integration was created based on the fzf completion and had the same problem, but the problem was left there.

[tessus]

Thanks for the info. I am still a bit confused why this only seemed to be triggering an issue on Linux. (Or maybe anything but macOS.)

[tessus]

Updated ble on macOS and Linux. macOS still works and Linux works now as well! 🎉

Thanks!

[akinomyoga]

Thanks for the info. I am still a bit confused why this only seemed to be triggering an issue on Linux. (Or maybe anything but macOS.)

I'm not sure what causes this difference. If something would affect, it could be an initialization ordering of completion settings, but as far as you use the same setup with the same versions of Bash, ble.sh, bash-completion, etc., the initialization ordering should be identical and the behavior should be the same. Do you think it would be another issue? Should we identify the cause of this difference?

[tessus]

Do you think it would be another issue? Should we identify the cause of this difference?

Right now it makes no sense, since the bash init is identical except for minor changes (different aliases and such).
I still have the macOS VM that you used before. If you want I can start it up and send you the connect info again.

I am happy that it works, but it is certainly strange that it worked on macOS even before your fix akinomyoga/blesh-contrib@a5d3a2e