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 but if you spent time learning the existing tools you would not have to google it. And this new tool should require time to accomodate too.
> no need to look around for the right line in the output
I feel like the author just don't understand the unix philosophy. Instead of having 1 tool with a quadrillion options, you just have to incrementally plug and use all the available tools that are already part of linux distributions since dozens of years.
You don't need to "find the right line in the output", you just grep/cut/awk the output, after some time it becomes second nature / muscle memory.
> 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
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.
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).
All else aside, grep is _noticeably_ slower than ripgrep.
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.
Maybe, but has been used since dozen of years successfully and productively by millions of programmers. It may be worth learning instead of reinventing...
Your complaint seems to be people are writing new tools.
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.
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 but if you spent time learning the existing tools you would not have to google it. And this new tool should require time to accomodate too.
> no need to look around for the right line in the output
I feel like the author just don't understand the unix philosophy. Instead of having 1 tool with a quadrillion options, you just have to incrementally plug and use all the available tools that are already part of linux distributions since dozens of years. You don't need to "find the right line in the output", you just grep/cut/awk the output, after some time it becomes second nature / muscle memory.