Embed shell integration scripts in fzf binary (--bash / --zsh / --fish)

[junegunn]

This simplifies the distribution, and the users are less likely to have problems caused by using incompatible scripts and binaries.

• bash

  # Set up fzf key bindings and fuzzy completion
  eval "$(fzf --bash)"

• zsh

  # Set up fzf key bindings and fuzzy completion
  eval "$(fzf --zsh)"

• fish

  # Set up fzf key bindings
  fzf --fish | source

[akinomyoga]

In Bash 3.2, the source builtin doesn't support reading from a pipe, so source <(...) fails (silently). What is the minimal Bash version that fzf supports? As far as I see key-bindings.bash, fzf intends to cover Bash 3. If that is the case, source "$(fzf --bash)" (edit: sorry, I meant eval "$(fzf --bash)") could be used.

[akinomyoga]

Is there a way to turn on either key-bindings.bash or completion.bash while the other is turned off? I'm not sure about a good interface, but for example,

fzf --bash=[key-bindings | completion | all]

defaulted to all.

[junegunn]

In Bash 3.2, the source builtin doesn't support reading from a pipe

Ah, that's unfortunate. I wasn't aware of it. I liked source <(...) better than eval "$(...)" because it looked better (no quotes). It's a superficial cosmetic reason that doesn't justify dropping support for bash 3 (which is the built-in version of bash in macOS), so I'm going to suggest eval instead.

Is there a way to turn on either key-bindings.bash or completion.bash while the other is turned off?

I thought about it, but I decided to keep it simple. We could add a magic comment at the top of each section so that advanced users can sed away the unwanted part.

[akinomyoga]

Thanks for your reply!

[akinomyoga]

@junegunn I suggested evaluating the integration shell scripts by eval (for the Bash compatibility), but I noticed there is a problem with the current content of the integration scripts. [[ $- =~ i ]] || return 0 at the beginning of the integration scripts, when executed in non-interactive shells, terminates the execution of .bashrc, .zshrc, etc. in the middle because eval runs the commands in the context where eval is called.

One solution is to avoid using return 0 and enclose the entire content of the integration scripts with a big if statement as if [[ $- =~ i ]]; then <all the script contents>; fi. Another solution is to enclose the script contents within a temporary function when embedding them in stdout. For example, this function

fzf/main.go

Lines 30 to 34 in 4cd37fc

	func printScript(label string, content []byte) {
	fmt.Println("### " + label + " ###")
	fmt.Println(strings.TrimSpace(string(content)))
	fmt.Println("### end: " + label + " ###")
	}

can be modified to additionally print

• __fzf_initialize() { and unset -f __fzf_initialize }; __fzf_initialize for Bash,
• print () { and } for Zsh
• and something equivalent for Fish.

[junegunn]

@akinomyoga Thanks, I'll update the script files. We used to wrap the whole thing before f103aa4.

[akinomyoga]

Thank you for fixing it! I think the fish integration script also needs to be adjusted.

fzf/shell/key-bindings.fish

Line 14 in 4cd37fc

status is-interactive; or exit 0

[junegunn]

We instruct fish users to use source via pipe.

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

And as far as I can tell, it doesn't have the same issue.

[akinomyoga]

Ah, OK! I missed it. Sorry for the noise, and thank you for the clarification. I think now everything should be fine.

Thank you for your quick responses and actions.