fzf integration: failed to find "fzf" base directory

[mcepl]

I am trying to use ble.sh from git (installed in ~/.local/share/blesh) with bash 5.2.26 on OpenSUSE/MicroOS (packages from OpenSUSE/Tumbleweed) and fzf 0.50 (0.50.0).

When I create ~/.config/blesh/init.sh just with this content:

source /etc/profile.d/bash_completion.sh

# /home/matej/.local/share/blesh/contrib/integration/fzf-completion.bash
ble-import -d integration/fzf-completion
ble-import -d integration/fzf-key-bindings

I get these errors on loading of the shell (using the secure method of starting ble.sh):

tumbleweed-pkg:~ $ [ble: reload]
tumbleweed-pkg:~ $ ble/contrib/integration:fzf: failed to find "fzf" base directory
ble/contrib/integration:fzf: failed to find "fzf" base directory

tumbleweed-pkg:~ $ 

I can run ble-import -q -d integration/fzf-completion on the command line and $? is 0.

FZF_BASE is not set at all.

Any ideas, what do I do wrong?

[akinomyoga]

The module integration/fzf-completion tries to identify the fzf base directory based on the shell variable $_ble_contrib_fzf_base or if it is not set, based on the path to the executable fzf found in the executable paths in PATH.

I can run ble-import -q -d integration/fzf-completion on the command line and $? is 0.

If you can run that on the command line without errors, the problem is probably because the bin path that contains fzf is not yet set in PATH at the point of sourcing ble.sh but is set up somewhere later in ~/.bashrc.

• In this case, you can set the environment variable PATH before sourcing ble.sh.
• Or another option is to set _ble_contrib_fzf_base in .config/blesh/init.sh before importing integration/fzf-completion as described in README of blesh-contrib.

[mcepl]

Hmm,

tumbleweed-pkg:~ $ rpm -ql fzf-bash-completion
/usr/share/bash-completion/completions/fzf
/usr/share/bash-completion/completions/fzf-key-bindings
tumbleweed-pkg:~ $ cat ~/.config/blesh/init.sh 
source /etc/profile.d/bash_completion.sh

# /home/matej/.local/share/blesh/contrib/integration/fzf-completion.bash
_ble_contrib_fzf_base= /usr/share/bash-completion/completions
ble-import -d integration/fzf-completion
ble-import -d integration/fzf-key-bindings
tumbleweed-pkg:~ $ 

and still the same error (plus bash: /usr/share/bash-completion/completions: Is a directory ??? I thought it was supposed to be a directory?).

[akinomyoga]

Thanks. I think the arrangement of those scripts by the package fzf-bash-completion has a problem so tried to ask the package maintainer in openSUSE about the locations of the files. Then, I realized that you are actually the maintainer.

What is the background of putting those files at bash-completion/completions/{fzf,fzf-key-bindings}? The bash-completion/completions directory is supposed to contain completion files for specific commands so that they are not loaded initially but loaded on demand when the completion for the command of the same name is attempted. However, the file fzf is not the completion setting for the fzf command but the completion setting for the general commands. Also, fzf-key-bindings will never be loaded unless one tries to complete the arguments of the non-existent command fzf-key-bindings (or users manually load it by writing source /usr/share/bash-completion/completions/fzf-key-bindings in their ~/.bashrc).

In general, if one wants to always load those files in the session automatically, one should consider putting them inside /etc/bash_completion.d or in /etc/profile.d (with care for the loading order). P.S. In my opinion, /etc/profile.d would be better because the fzf completion setting is designed to work even without bash-completion and users might want to use the fzf's completion without enabling bash-completion.

[akinomyoga]

When combining them with ble.sh, however, such an automatic loading doesn't work well with ble.sh because, to adjust their behavior, ble.sh wants to load those files in a temporarily adjusted environment. ble.sh assumes those files are arranged somewhere in /usr/share/fzf (such as /usr/share/fzf/shell/{completion.bash,key-bindings.bash}).

For example, could you include those files in the main package fzf, without automatic loading, and put only the settings for the automatic loading in the fzf-bash-completion package (such as /etc/bash_completion.d/fzf.sh containing two lines source /usr/share/fzf/shell/completion.bash and source /usr/share/fzf/shell/key-bindings.bash)? With this setup, to use the fzf integration with ble.sh, the user can turn off the automatic loading by removing the fzf-bash-completion package and instead write the corresponding ble-import in ~/.blerc.

[mcepl]

See my question to @junegunn whether I shouldn’t get rid of these scripts completely and then in the beginning of ~/.config/blesh/init.sh I would have just eval $(fzf --bash)?

[akinomyoga]

I also pay attention to that change in the upstream Fzf 0.48.0. I actually left a review in the corresponding PR junegunn/fzf#3675.

For now, as noted in README of fzf (quoted below) and as @junegunn commented on junegunn/fzf#3722 (comment), I assume the package are still supposed to provide the individual scripts for the users' finer control. I intend that the use case with ble.sh corresponds to the one with the finer control.

---

Quoted from https://github.com/junegunn/fzf?tab=readme-ov-file#setting-up-shell-integration:

Note

--bash, --zsh, and --fish options are only available in fzf 0.48.0 or later. If you have an older version of fzf, or want finer control, you can source individual script files in the /shell directory. The location of the files may vary depending on the package manager you use. Please refer to the package documentation for more information. (e.g. apt show fzf)

Quoted from junegunn/fzf#3722 (comment):

Thanks, but I'm going to keep it simple and not add more options. As noted in the instruction, you can still load individual script files if you need finer control.

[akinomyoga]

So I expect the main package fzf provides /shell directory somewhere such as /usr/share/fzf/shell to allow the users wanting finer control to use them as an option.

For the users who don't want to (or don't know how to) edit ~/.bashrc, the package fzf-bash-completion (or maybe better named as fzf-bash-integration?) might still offer a single-line script if [[ ${BASH_VERSION-} ]]; then eval "$(fzf --bash)"; fi at /etc/profile.d/fzf-bash.sh, etc. (Note that this would be incompatible with ble.sh. The user still needs to configure fzf's integration with blesh without using the fzf-bash-completion package.)

then in the beginning of ~/.config/blesh/init.sh I would have just eval $(fzf --bash)?

ble.sh wants the finer control, so I still expect the users to use ble-import, in which source <path to individual scripts> is performed internally.

[mcepl]

Thank you, this seems helpful. I have tried to incorporate your suggestions to our package (see https://paste.opensuse.org/pastes/b78848ca886d). Do you have any thoughts on those changes?

[akinomyoga]

/etc/profile.d in openSUSE: I've checked the handling of /etc/profile.d in openSUSE. As far as I look at /etc/bash.bashrc and /etc/profile, the scripts /etc/profile.d/*.sh are sourced with mysterious conditions. Maybe the files in /etc/profile.d are treated differently in openSUSE compared to the typical configurations. I haven't tested it in the actual openSUSE system, but I think it's better to test whether the scripts in /etc/profile.d are correctly sourced in both login and non-login sessions (which are started by bash -l and bash, respectively). If not, you might also need to submit a patch to /etc/bash.bashrc.

line 31: I think the dependency on bash-completion (line 31) can now be dropped (or it could be turned into an optional dependency if the packaging system of openSUSE supports the optional dependency).

line 100: Since /etc/profile.d/*.sh are sourced by arbitrary POSIX/Bourne shells, we want the test for Bash in the file fzf-bash.sh. For this, I wrote something like if [[ ${BASH_VERSION-}]] above, but I'm sorry. It should instead be if [ "${BASH_VERSION-}" ] because [[ is not POSIX. We also want to include the test for the interactive shell, [[ $- == *i* ]] (where you can use the Bash constructs after testing the shell). Also, In case a custom PATH doesn't contain the fzf command, we can redirect stderr to /dev/null. To summarize, I suggest the following:

echo 'if [ "${BASH_VERSION-}" ] && [[ $- == *i* ]]; then eval "$(fzf --bash 2>/dev/null)"; fi' > \

[akinomyoga]

The twisted usage of /etc/profile.d/*.sh in openSUSE is discussed in openSUSE/aaa_base#141. Maybe it will be shifted to the normal scheme in the future, but for now, the scripts in /etc/profile.d/*.sh seem supposed to be hard coded in /etc/bash.bashrc. You can request a change similar to /etc/bash.bashrc in openSUSE/aaa_base#141.

[mcepl]

On Wed Apr 24, 2024 at 1:22 PM CEST, Koichi Murase wrote: The twisted usage of `/etc/profile.d/*.sh` in openSUSE is discussed in openSUSE/aaa_base#141. Maybe it will be shifted to the normal scheme in the future, but for now, the scripts in `/etc/profile.d/*.sh` seem supposed to be hard coded in `/etc/bash.bashrc`. You can request a change similar to [`/etc/bash.bashrc` in openSUSE/aaa_base#141](https://github.com/openSUSE/aaa_base/pull/141/files#diff-d62bf7c43ba9a0e8a95d5d01a034ff61ee1d739c13e946486cc76b31763106be).

Thank you very much. I have modified my commit accordingly.