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
Steve Dondley writes:
> I'm using zsh.
>
> What am I missing?
In zsh, run rehash. Or start a new terminal.
"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
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
(tl;dr: use type, not which)
OK, thanks.
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.
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
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
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
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
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
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
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
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
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.
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
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
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
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:
19 matches
Mail list logo
