Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #239513 > unrolled thread

Tips/advice for installing latest version of fzf?

Back to article view | Back to linux.debian.user

Contents

  Tips/advice for installing latest version of fzf? Steve Dondley <s@dondley.com> - 2021-08-31 15:20 +0200
    Re: Tips/advice for installing latest version of fzf? Roberto C. Sánchez <roberto@debian.org> - 2021-08-31 15:50 +0200
      Re: Tips/advice for installing latest version of fzf? Steve Dondley <s@dondley.com> - 2021-08-31 16:40 +0200
        Re: Tips/advice for installing latest version of fzf? Steve Dondley <s@dondley.com> - 2021-08-31 16:50 +0200
          Re: Tips/advice for installing latest version of fzf? Greg Wooledge <greg@wooledge.org> - 2021-08-31 16:50 +0200
            Re: Tips/advice for installing latest version of fzf? Steve Dondley <s@dondley.com> - 2021-08-31 17:00 +0200
              Re: Tips/advice for installing latest version of fzf? The Wanderer <wanderer@fastmail.fm> - 2021-08-31 17:10 +0200
                Re: Tips/advice for installing latest version of fzf? Steve Dondley <s@dondley.com> - 2021-08-31 17:20 +0200
                  Re: Tips/advice for installing latest version of fzf? Steve Dondley <s@dondley.com> - 2021-08-31 17:40 +0200
                    Re: Tips/advice for installing latest version of fzf? Greg Wooledge <greg@wooledge.org> - 2021-08-31 17:40 +0200
                  Re: Tips/advice for installing latest version of fzf? <tomas@tuxteam.de> - 2021-08-31 18:10 +0200
                    Re: Tips/advice for installing latest version of fzf? Steve Dondley <s@dondley.com> - 2021-08-31 20:30 +0200
                      Re: Tips/advice for installing latest version of fzf? Greg Wooledge <greg@wooledge.org> - 2021-08-31 20:50 +0200
                        Re: Tips/advice for installing latest version of fzf? Steve Dondley <s@dondley.com> - 2021-08-31 23:30 +0200
              Re: Tips/advice for installing latest version of fzf? Steve Dondley <s@dondley.com> - 2021-08-31 17:10 +0200
              Re: Tips/advice for installing latest version of fzf? Greg Wooledge <greg@wooledge.org> - 2021-08-31 17:40 +0200
                Re: Tips/advice for installing latest version of fzf? Steve Dondley <s@dondley.com> - 2021-08-31 20:30 +0200
                Re: Tips/advice for installing latest version of fzf? Richard Hector <richard@walnut.gen.nz> - 2021-09-04 11:30 +0200
              Re: Tips/advice for installing latest version of fzf? Anssi Saari <as@sci.fi> - 2021-09-01 12:20 +0200

#239513 — Tips/advice for installing latest version of fzf?

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.

[toc] | [next] | [standalone]

#239515

On Tue, Aug 31, 2021 at 09:07:59AM -0400, Steve Dondley wrote:
> 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.
> 

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

[toc] | [prev] | [next] | [standalone]

#239524

> 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.

[toc] | [prev] | [next] | [standalone]

#239526

>> 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.

[toc] | [prev] | [next] | [standalone]

#239528

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.

[toc] | [prev] | [next] | [standalone]

#239529

On 2021-08-31 10:48 AM, Greg Wooledge wrote:
> 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.

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?

[toc] | [prev] | [next] | [standalone]

#239530

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#239532

> 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!

[toc] | [prev] | [next] | [standalone]

#239533

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.

[toc] | [prev] | [next] | [standalone]

#239535

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

[toc] | [prev] | [next] | [standalone]

#239536

[Multipart message — attachments visible in raw view] — view raw

On Tue, Aug 31, 2021 at 11:19:10AM -0400, 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.
> 
> 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.

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

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#239540

> 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.

[toc] | [prev] | [next] | [standalone]

#239542

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.

[toc] | [prev] | [next] | [standalone]

#239546

>> "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!

[toc] | [prev] | [next] | [standalone]

#239531

> 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?

[toc] | [prev] | [next] | [standalone]

#239534

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)

[toc] | [prev] | [next] | [standalone]

#239539

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

OK, thanks.

[toc] | [prev] | [next] | [standalone]

#239666

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

[toc] | [prev] | [next] | [standalone]

#239554

Steve Dondley <s@dondley.com> writes:

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

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web