woodpecker VS ripgrep

drill

I've recently published servant-benchmark, a small library that produces request files from Servant APIs to be used by external benchmarking tools. It currently supports exports for wrk, siege, and drill.

A search for `rg -e foo -e bar` will return lines that match either foo or bar. Some lines may have both, but it isn't required.

The standard way to run "AND" queries is through shell pipelines. That is, `rg foo | rg bar` will only print lines containing both. But composition usually comes with costs. The output reverts to the standard grep format and it doesn't interact nicely with contextual options like -C/--context.

See: https://github.com/BurntSushi/ripgrep/issues/875

Never will be: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pos...

If you need drop-in compatibility with grep, then use grep. :-)

No. Cargo does. The `build.rs` is basically a Cargo hook that gets compiled as a Rust program and executed just before the ripgrep binary is compiled. It lets you do things like set linker flags[1] so that you can embed an XML manifest into the binary on Windows to enable "long path support."

ripgrep's build.rs used to do more, like build shell completions and the man page. But that's now part of ripgrep proper. e.g., `rg --generate man` writes roff to stdout.

[1]: https://github.com/BurntSushi/ripgrep/blob/2a4dba3fbfef944c5...

[2]: https://github.com/BurntSushi/ripgrep/blob/2a4dba3fbfef944c5...

There's like a whole host of things you could use to explain it. Inertia. Compatibility. Resistance to change. Innovator's dilemma. And so on. (I do not say any of these things pejoratively! All of those things apply to me too.)

With respect to compatibility, see my FAQ on the topic: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pos...

The shell function from this comment works pretty well for me: https://github.com/BurntSushi/ripgrep/issues/152#issuecommen...

BurntSushi (dev) built a grep replacement, `rg` (ripgrep), in Rust, that tends to run circles in terms of speed around grep itself and other grep replacements. The UX is also pretty nice. I install it everywhere now.

I'm curious (like others here) how `rak` is better than `rg`.

https://github.com/BurntSushi/ripgrep

Main purpose: Perform a RipGrep with interface that is very close to the CLI, yet intuitive, and place those results in the QuickFix list The more you use this plugin, the better you should become at using RipGrep from the CLI.

Did you do what I asked and look at ripgrep's changelog?[1] The breaking changes are prominently advertised in each major release. Not all breaking changes are the same or have the same impact. Some major releases don't even have any breaking changes.

The cute thing is that you seem to think "old Unix software" used major version bumps to indicate compatibility breaks. I don't think so. Recent releases of GNU grep, for example, fucked around with the meaning of \d. Did that break your scripts?

I'll never understand why people feel compelled to snub their nose from their cozy armchairs. Like presumably you aren't giving an experience report here based on some real churn you experienced from, ya know, actually using ripgrep. And instead are just pontificating from a soap box based on a single number incrementing.

[1]: https://github.com/BurntSushi/ripgrep/blob/master/CHANGELOG....