I’m a die-hard ripgrep fan, but just recently found ugrep looking for one feature that ripgrep lacks: searching in zip archives (without decompressing them to disk).

Ugrep has that. In my case, I’m working with zipped corpora of millions of small text files, so I can skip unpacking the whole thing to the filesystem (certain filesystems have trouble at this scale).

I’m grateful for both tools. Thanks to the respective authors!

That's where ripgrep-all comes into play which will grep through archives, PDFs, ebooks, documents, etc.

I'm scared that if I start using Google search syntax in my grepping that I'll mostly get results trying to sell me something :)

So I was casually searching for "ugrep vs ripgrep" articles, when I stumbled upon a couple reddit posts where apparently the authors of ugrep and ripgrep seemed to have a multi-year feud on reddit, eg. https://www.reddit.com/r/programming/comments/120wqvr/ripgre...

So weird. I mean, it's just about some open source tool, right? :-/

I came across ugrep recently and I immediately recognized the organization as one that I had dealt with starting about 15 years go. The author is brilliant‡, but extremely prickly (sometimes even to paying customers). The author of ripgrep, on the other hand, has always seemed like someone who just wants to get on with the business of writing software that people use.

‡ The main commercial product of the ugrep author's company at the time was the gSOAP code generator (it may still be), and that it not only works but makes a reasonably good C and C++ API from WSDL is proof that it is the product of a genius madman. It also allowed you to create both the API and WSDL from a C++-ish header, and both .NET and Java WSDL tools worked perfectly with it. We needed it to work and work it did.

At the time, the generated API was just difficult enough to use that I generated another ~1k lines of code for that project. IIRC, the generated API is sort of handle-based, which requires a slightly different approach than the strict RAII approach we were using. Generating that code was a minor adventure (generating the gSOAP code from the header-ish file, generating doxygen XML from the generated gSOAP code, then generating the wrapper C++ from the doxygen XML).

Psst, don't tell him about emacs and vi(m)...

There are feuds about open source tools all the time. Text editors, Linux distros, shells, programming languages, desktop environments, etc... And ugrep vs ripgrep may be a poster child for C++ vs Rust.

It is not all bad, it drives progress, and it usually stays at a technical level, I've yet to see people killing each others for their choice of command line search tool.

This is so weird, even ripgrep's author is actively seeking conflict in ugrep's new release posts. Not a good colour on both of them.

Any examples? All I see in the recent release post is:

> ugrep is easily one of the if not most featureful grep programs in existence. And it is also fast.

which is burntsushi, ripgrep's author, defending ugrep from someone saying they only focus on performance at the cost of features.

At least how I read it the linked post was ugrep's author seeking conflict, not the ripgrep's.

How is it "seeking conflict" to correct factually wrong claims about your project?

Is the TUI better than just sending the results through fzf? For me the configurability and flexibility of fzf would be hard to compete with.

Thanks for mentioning this.

I think the killer feature is compatibility with existing grep command line switches. Not needing to learn a whole new set of options is quite nice.

It's also a drop-in replacement for grep as it supports the same flags and regular expression syntax.