Hacker News Reader

Comment by triyambakam | Hacker News Reader

The default install script asks if you want to install key bindings and adds that to your bashrc. How did you install fzf?

View on HN

apt install? There's no way I'm integrating a core tool like that with a crude "curl | zsh" hack. How and when would it get updated? Am I expected to stick that in an Ansible playbook?

A shoutout to home-manager, where it's just programs.fzf.enableBashIntegration = true;

https://github.com/gantsign/ansible-role-oh-my-zsh

https://github.com/dotstrap/ansible-fzf

I don't see why not

Yes. It's a shell hook, it's expected for you to add it to your bash/zsh .rc yourself. How else can it work?

For an article titled "You've installed fzf. Now what?", I would've expected step 1 to be "how to add the shell hook for your particular shell". Especially since people here are referencing extra integrations that the bundled shell hook doesn't setup.

Packages can place init scripts into /etc/profile.d and those get autoloaded by shells.

This is what happens when tooling providers try to do their own packaging. Homebrew, apt, rpm, and other package managers, as well as bash, zsh and other shells, all offer standardized ways to install configuration loader scripts for the user's environment, and to display installer messages that prompt the user to do it - but fzf has a bunch of functionality to go around all that and auto-update itself in place and hack lines into the user's bashrc/zshrc.

Not trying to single out fzf here - there are many other tools that do this - but I find this behavior really sad because it makes me very disinclined to trust the tool with anything. A command-line tool should not be trying to auto-update itself or manipulate dotfiles in the user's home directory. It's dangerous and unexpected.

There’s no real good mechanism for what fzf is trying to do. profile.d might work, but I think that is more intended for environment variables, rather than interactive shell changing scripts.

There’s no standardised way to extend interactive shell configuration without just appending to /etc/bashrc.

The other problem with this is that it is hard to disable. What if you want fzf but without the key bindings? FZF could add a mechanism for this, but it doesn’t fully solve the problem, because the FZF script being added to global configuration will always be run before any user config.

In this specific case, it is a limitation of bash (and probably ZSH as well) that there is no simple package-manger compatible extension mechanism for interactive shell plugins which doesn’t sacrifice user control.

That is not where interactive shell confs should go, or it'll get loaded in non interactive contexts as well, which you usually don't want.

Not parent but on pop-os, using sudo apt install zfz I got the same behavior, had to add it myself to .bashrc

Pretty much par for the course, Linux distributions don't do per user configuration of tools beyond appending to PATH or setting some essential environment variables using scripts in in /etc/profile.d/. They will most certainly not mess with login scripts.

Yeah sure, that makes sense. I'm surprised that the .deb doesn't install the stuff from `$upstream/shell` into `/usr/share/fzf` though. That's the sort of thing `/usr/share/$prog` is intended for.

Then it would just be (in bash anyway):

   source /usr/share/fzf/keybindings.bash

In debian:

  source /usr/share/doc/fzf/examples/completion.bash
  source /usr/share/doc/fzf/examples/key-bindings.bash

Reply on news.ycombinator.com