Tips/advice for installing latest version of fzf?

[Steve Dondley]

Running bullseye with fzf package 0.24.3-1+b6.

Newer versions of fzf (> .27.) have some advanced abilities I'd like to
use but newer versions are not available in backports (at least not that
I could tell)

I'm thinking of building fzf manually per the instructions here:
https://github.com/junegunn/fzf/blob/master/BUILD.md

Wondering if there is any snags I might hit or if this is just a very
bad idea in general. Thank you.

[Roberto C. Sánchez]

Their build tooling seems very sparse. In particular, it does not
support DESTDIR or PREFIX variables. However, that might be OK in this
case, as it appears to only produce and install a single artifact: a
binary called fzf.

If I were in your position, I would run 'make' and then manually place
the fzf program in a location where the shell's PATH variable setting
will allow the fzf program to be found. Likely either /usr/local/bin
(if you want it to be available to everyone on the system) or ~/bin (if
you only want to make it available to your own login without affecting
others who might be using the system-provided binary).

Either way, the simplicity of the tool (in terms of it being a single
binary artifact that is deployed) makes it unlikely that you would
encounter any issues in doing this.

Regards,

-Roberto
--
Roberto C. Sánchez

[Steve Dondley]

> Their build tooling seems very sparse. In particular, it does not
> support DESTDIR or PREFIX variables. However, that might be OK in this
> case, as it appears to only produce and install a single artifact: a
> binary called fzf.
>
> If I were in your position, I would run 'make' and then manually place
> the fzf program in a location where the shell's PATH variable setting
> will allow the fzf program to be found. Likely either /usr/local/bin
> (if you want it to be available to everyone on the system) or ~/bin (if
> you only want to make it available to your own login without affecting
> others who might be using the system-provided binary).
>
> Either way, the simplicity of the tool (in terms of it being a single
> binary artifact that is deployed) makes it unlikely that you would
> encounter any issues in doing this.
>
> Regards,
>
> -Roberto

OK, thank you, Roberto.

fzf comes with some shell integration tools like key bindings that can
be installed according to the DEBIAN readme at
/usr/share/doc/fzf/README.Debian. I'd prefer to keep those if at all
possible. Based on what you are telling me, maybe I could try replacing
the current binary with the newer one and keep the supporting debian
package files in place.

I can't think of what harm could come from trying it to see if it works
but I'm not very knowledgeable. So if this sounds like a really dumb
idea, just let me know.

[Steve Dondley]

>> Either way, the simplicity of the tool (in terms of it being a single
>> binary artifact that is deployed) makes it unlikely that you would
>> encounter any issues in doing this.
>>
>> Regards,
>>
>> -Roberto
>
> OK, thank you, Roberto.
>
> fzf comes with some shell integration tools like key bindings that can
> be installed according to the DEBIAN readme at
> /usr/share/doc/fzf/README.Debian. I'd prefer to keep those if at all
> possible. Based on what you are telling me, maybe I could try
> replacing the current binary with the newer one and keep the
> supporting debian package files in place.
>
> I can't think of what harm could come from trying it to see if it
> works but I'm not very knowledgeable. So if this sounds like a really
> dumb idea, just let me know.

OK, this is even easier than I thought.

1) I copied /usr/bin/fzf to /usr/bin/fzf to /usr/bin/fzf~
2) Downloaded binary already available at
https://github.com/junegunn/fzf/releases
3) Moved binary to /usr/bin/fzf

Everything appears to work just fine. Key bindings still work.

Now I'm just wondering if it would be better to keep the old fzf around
and put the new fzf into a directory that $PATH loads before /usr/bin.
I'm thinking this might be the proper way of doing this instead of my
quick hack.

[Greg Wooledge]

On Tue, Aug 31, 2021 at 10:45:50AM -0400, Steve Dondley wrote:
> Now I'm just wondering if it would be better to keep the old fzf around and
> put the new fzf into a directory that $PATH loads before /usr/bin. I'm
> thinking this might be the proper way of doing this instead of my quick
> hack.

Yes, this is what I'd recommend. Otherwise, your /usr/bin/fzf is going
to be overwritten next time you upgrade the fzf package.

[Steve Dondley]

OK, yes, I see now that was Roberto's original advice and put it in
/usr/local/bin

OK, so I dropped the new fzf into /usr/local/bin. I confirmed it is the
correct version with:

admin@ip-172-30-0-226 /usr/local/bin
> $ ./fzf --version
0.27.2 (e086f0b)

"echo $PATH" reports:

/usr/local/bin:/usr/bin:/bin:/usr/games

So it looks like any binary in /usr/local/bin should load first.

However, "which fzf" reports the /usr/bin as the location:

/usr/bin/fzf

I'm using zsh.

What am I missing?

[The Wanderer]

On 2021-08-31 at 10:58, Steve Dondley wrote:

> OK, so I dropped the new fzf into /usr/local/bin. I confirmed it is the
> correct version with:
>
> admin@ip-172-30-0-226 /usr/local/bin
>> $ ./fzf --version
> 0.27.2 (e086f0b)
>
> "echo $PATH" reports:
>
> /usr/local/bin:/usr/bin:/bin:/usr/games
>
> So it looks like any binary in /usr/local/bin should load first.
>
> However, "which fzf" reports the /usr/bin as the location:
>
> /usr/bin/fzf
>
> I'm using zsh.
>
> What am I missing?

This sounds like a stale-hash situation. According to my understanding,
the shell will typically keep a cache of what path it found a given
command at when it checked for that command in $PATH, so it doesn't have
to re-do the filesystem accesses on every run of the command; this
mapping of known paths to commands is apparently referred to as a set of
hashes.

I'm not familiar with zsh, but in bash, you could try 'hash -d fzf' to
drop the cached known path for fzf (so that the next check will look it
up again from scratch), or even 'hash -r' to forget *all* the known
paths for everything.

I remember reading once upon a time about a command called 'rehash'
which would cause the shell to re-check all its cached paths for
everything, but that hasn't been available in any *nix environment I've
ever actually been running, as far as I'm aware.

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

[Steve Dondley]

> OK, so I dropped the new fzf into /usr/local/bin. I confirmed it is
> the correct version with:
>
> admin@ip-172-30-0-226 /usr/local/bin
>> $ ./fzf --version
> 0.27.2 (e086f0b)
>
> "echo $PATH" reports:
>
> /usr/local/bin:/usr/bin:/bin:/usr/games
>
> So it looks like any binary in /usr/local/bin should load first.
>
> However, "which fzf" reports the /usr/bin as the location:
>
> /usr/bin/fzf
>
> I'm using zsh.
>
> What am I missing?

So I renamed /usr/bin/fzf to /usr/bin/fzf~ and "which" finds the new fzf
in /usr/local/bin. So I guess I have a bad misunderstanding of how $PATH
works and directories that come later get loaded instead of directories
that come earlier. Can this be right?

[Steve Dondley]

> This sounds like a stale-hash situation. According to my understanding,
> the shell will typically keep a cache of what path it found a given
> command at when it checked for that command in $PATH, so it doesn't
> have
> to re-do the filesystem accesses on every run of the command; this
> mapping of known paths to commands is apparently referred to as a set
> of
> hashes.
>
> I'm not familiar with zsh, but in bash, you could try 'hash -d fzf' to
> drop the cached known path for fzf (so that the next check will look it
> up again from scratch), or even 'hash -r' to forget *all* the known
> paths for everything.

Ah, yes, some kind of zsh command caching appears to be implemented. But
rather than guessing at the correct zsh command, logging in with a
totally new shell corrected the problem and "which" now shows the
expected path.

Thanks!

[Greg Wooledge]

On Tue, Aug 31, 2021 at 11:32:12AM -0400, Steve Dondley wrote:
> The "hash" command does not appear to even be installed on my system, even
> with sudo, maybe because I'm using zsh. But I did a little googling around
> and found this tip:

unicorn:~$ zsh
greg@unicorn ~ % type hash
hash is a shell builtin

[Steve Dondley]

On 2021-08-31 11:19 AM, Steve Dondley wrote:
>> This sounds like a stale-hash situation. According to my
>> understanding,
>> the shell will typically keep a cache of what path it found a given
>> command at when it checked for that command in $PATH, so it doesn't
>> have
>> to re-do the filesystem accesses on every run of the command; this
>> mapping of known paths to commands is apparently referred to as a set
>> of
>> hashes.
>>
>> I'm not familiar with zsh, but in bash, you could try 'hash -d fzf' to
>> drop the cached known path for fzf (so that the next check will look
>> it
>> up again from scratch), or even 'hash -r' to forget *all* the known
>> paths for everything.

The "hash" command does not appear to even be installed on my system,
even with sudo, maybe because I'm using zsh. But I did a little googling
around and found this tip:

PATH="$PATH"

This will reset the command cache in zsh. I don't think this is the
official way to do it, though.

[Greg Wooledge]

On Tue, Aug 31, 2021 at 10:58:12AM -0400, Steve Dondley wrote:
> However, "which fzf" reports the /usr/bin as the location:
>
> /usr/bin/fzf
>
> I'm using zsh.

unicorn:~$ zsh
greg@unicorn ~ % type which
which is a shell builtin

Zsh is caching the old location, and because "which" is a shell builtin
in your shell, it's reporting the cached value.

In bash, which is *not* a shell builtin -- it's a separate program,
/usr/bin/which. So, using "which" from bash would have reported the
wrong thing in this situation. Just FYI.

(tl;dr: use type, not which)

[to...@tuxteam.de]

There's `hash -r' for that (bash, dash). I'd bet that zsh has something
along that lines, too.

Cheers
- t

[Steve Dondley]

> There's `hash -r' for that (bash, dash). I'd bet that zsh has something
> along that lines, too.
>
> Cheers
> - t

Ok, it is there after all, as a built-in. I was mindlessly trying "sudo
hash -d fzf". I guess trying with sudo doesn't work.

"sudo which hash" shows nothing. Not sure whey.

[Steve Dondley]

> (tl;dr: use type, not which)

OK, thanks.

[Greg Wooledge]

On Tue, Aug 31, 2021 at 02:20:12PM -0400, Steve Dondley wrote:
> Ok, it is there after all, as a built-in. I was mindlessly trying "sudo hash
> -d fzf". I guess trying with sudo doesn't work.
>
> "sudo which hash" shows nothing. Not sure whey.

sudo is an external program, which launches other external programs.

When you type "sudo which hash", your shell (zsh) forks a child, and
that child executes "sudo". sudo does its authentication/authorization
dance, and then executes "which hash", looking for an external command
in $PATH. It will find /usr/bin/which, and it will run that.

So effectively, you're running sudo /usr/bin/which hash.

/usr/bin/which, being an external program, has no concept of shell
builtins. It can only look for other external programs. And there is
no program named hash. Only shell builtins.

You would get a similar non-answer if you ran "/usr/bin/which hash"
in your shell. The sudo part doesn't change anything, since there are
no directories in $PATH that require superuser privileges to search.
At least, there shouldn't be.

[Steve Dondley]

>> "sudo which hash" shows nothing. Not sure whey.
>
> sudo is an external program, which launches other external programs.
>
> When you type "sudo which hash", your shell (zsh) forks a child, and
> that child executes "sudo". sudo does its authentication/authorization
> dance, and then executes "which hash", looking for an external command
> in $PATH. It will find /usr/bin/which, and it will run that.
>
> So effectively, you're running sudo /usr/bin/which hash.
>
> /usr/bin/which, being an external program, has no concept of shell
> builtins. It can only look for other external programs. And there is
> no program named hash. Only shell builtins.
>
> You would get a similar non-answer if you ran "/usr/bin/which hash"
> in your shell. The sudo part doesn't change anything, since there are
> no directories in $PATH that require superuser privileges to search.
> At least, there shouldn't be.

OK, got it. I never knew this. Lots of nuances to all this stuff. That's
what keeps it interesting, I suppose. Thanks!

[Anssi Saari]

Steve Dondley <s...@dondley.com> writes:

> I'm using zsh.
>
> What am I missing?

In zsh, run rehash. Or start a new terminal.

[Richard Hector]

On 1/09/21 3:32 am, Greg Wooledge wrote:
> In bash, which is *not* a shell builtin -- it's a separate program,
> /usr/bin/which.

Well _that_ took a while to parse correctly :-) I know bash is not a
shell builtin, that would be weird ...

Cheers,
Richard