31–40 of 89 posts
Can this be hooked in kinda like pagers ? so ever long listing gets piped automatically to fzf ?
I use it for a slew of git subcommands for example, e.g. if they expect a ref and I don't provide one, open log and fzf a SHA.
I also use it in vim to find files or lines within them.
I also use it with my password manager to find the one I want if what I specify isn't an exact match.
fzf is great.
Been using linux for 15 years and I never found any use case for all these fancy grep/ctrl+r/find replacements. Honestly I just feel like the authors of these tools were just too lazy to learn grep/find/cut/tr/bash/awk/etc and decided to implement everything in their own toy program, which always The list of "features" in the article lead me to the same conclusion > no need of googling the right command Yeah right bu…
And it does respect Unix philosophy, as I just wrote in another comment it's easy to pipeline between source (of the stuff to find) and sink (of what to do with the fuzzy-found one).
It does one thing, and it does it well.
Been using linux for 15 years and I never found any use case for all these fancy grep/ctrl+r/find replacements. Honestly I just feel like the authors of these tools were just too lazy to learn grep/find/cut/tr/bash/awk/etc and decided to implement everything in their own toy program, which always The list of "features" in the article lead me to the same conclusion > no need of googling the right command Yeah right bu…
I used grep for over ten years, almost every day, before I sat down and wrote ripgrep. Hell, I still use grep. So no, I'm pretty sure you're just a bit off the mark here. You might consider that speculating on the motivation of others without the facts is pretty counter productive.
> Instead of having 1 tool with a quadrillion options
Have you looked at the man page of pretty much any GNU tool? The Unix philosophy is just a means to an end, not an end itself. ripgrep, for example, has _tons_ of options and flags. But if you went and looked at the number of flags for GNU grep, you'd find an approximately similar amount!
Besides, grep/cut/awk/find/whatever do not even remotely come close to providing the user experience of fzf, so your entire analysis here seems way off the mark to me.
I'm pretty junior at coding but I find FZF great. Ctrl-r for shell history Ctrl-t for file search Especially writing `code` and then ctrl-t, finding the file and then enter to open it in visual studio. Game changer.
Ctrl-t is a game changer, thank you for sharing this, I only knew the notation.
Earlier quoted context omitted.
> I feel like the author just don't understand the unix philosophy. The unix philosophy isn't magically better and faster than other software philosophies
Maybe, but has been used since dozen of years successfully and productively by millions of programmers. It may be worth learning instead of reinventing...
Earlier quoted context omitted.
> I feel like the author just don't understand the unix philosophy. The unix philosophy isn't magically better and faster than other software philosophies
Maybe, but has been used since dozen of years successfully and productively by millions of programmers. It may be worth learning instead of reinventing...
You have provided absolutely no evidence that these tools don’t fit the Unix philosophy (and you cannot, because the 2 tools mentioned actually do a great job fitting the Unix philosophy). In fact, the first example is piping the output of ls into fzf. I’m not sure what could be more Unix philosophy like than that.
I can't really fault both of these tools at all. They have good defaults and are easy to configure and are well documented. Of course they are very performant too, but if you take the time to configuring your wildignore, learn how to use find's and rgrep's flags (maybe script some of this with shell or vimscript if necessary) you can get close to the performance of these tools and define your own usability if needed.…
Not to argue with you as I see where you're coming from (all things being equal I too usually go with the defaults) but the argument about "not having to install and setup additional tools...on lots of different machines" is very weak in these days of: git clone https://gitlab.com/myaccount/mydotfiles followed by an optional: ./deploy_stuff_if_required which for me I have working on any number of linux boxes as well…
Been using linux for 15 years and I never found any use case for all these fancy grep/ctrl+r/find replacements. Honestly I just feel like the authors of these tools were just too lazy to learn grep/find/cut/tr/bash/awk/etc and decided to implement everything in their own toy program, which always The list of "features" in the article lead me to the same conclusion > no need of googling the right command Yeah right bu…
Once I started using ripgrep I couldn't really go back. Maybe you don't work with huge files, but I do. And everyday I'm thankful to burntsushi for all the hard work he put in to making ripgrep.
Earlier quoted context omitted.
Not to argue with you as I see where you're coming from (all things being equal I too usually go with the defaults) but the argument about "not having to install and setup additional tools...on lots of different machines" is very weak in these days of: git clone https://gitlab.com/myaccount/mydotfiles followed by an optional: ./deploy_stuff_if_required which for me I have working on any number of linux boxes as well…
I do hope you don't do this on production servers!