I'm sure you can get creative. :-) You can set an environment variable to control the encoding, expose a flag or any one of a number of other things to control the encoding. Either way, now you're just shifting the goalposts.

You've also continued to ignore my most substantive rebuttal: that a specific example where ripgrep is not compatible with grep or doesn't behave the same doesn't mean it can't be used in shell pipelines. I use ripgrep in shell pipelines all of the time. As do many others. Literally nothing you've said has invalidated anything I've said. All you're doing is finding things that some implementations of grep can do that ripgrep (intentionally) cannot do in exactly the same way. But that's fine, because ripgrep was never, isn't and will never be compatible with grep: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pos...

So if you need grep compatibility get a fucking clue and just use grep.

> You can set an environment variable to control the encoding

Yes, that's what LC_ALL is. Every other tool understands it except ripgrep. Even if you parse it by hand, there's no guarantee that ripgrep will support the encoding.

ripgrep intentionally doesn't understand it. It is far from the only tool that doesn't. For example, busybox doesn't either:

    $ echo $'O\xF0uz' | LC_ALL=en_US.ISO-8859-1 busybox grep -E '^.{4}$'

So that's yet another lie from you.

If you want or need LC_ALL support, then don't use ripgrep. It's right there in the FAQ entry as a reason to use grep instead:

> Do you care about POSIX compatibility? If so, then you can't use ripgrep because it never was, isn't and never will be POSIX compatible.

Maybe learn how to read. Your complaint boils down to "ripgrep doesn't do this thing that it says it doesn't do." What a fucking revelation.

>busybox

Apples vs. oranges. Busybox is a suite of minimal tools for low-resource systems, lack of QoL features you wouldn't need in such an environment is its selling point. Besides you won't see anyone claiming individual busybox tools can be used in shell scripts just fine.

It's easier to admit ripgrep is rather a supplementary tool that is incompatible with the tooling your typical Unix-like operating system provides out of the box than a "modern replacement" for grep and move on.

So you lied. Now you've shifted the goalposts after being called out on it. And ripgrep has no problems being used in shell pipelines. What ripgrep has a problem doing is being drop-in compatible for grep, because that isn't its goal.

> "modern replacement" for grep

I have literally never called ripgrep this. So more lies and straw-manning from you. ripgrep's repo neither positions itself as a replacement or as "modern." And in the FAQ about "replacing" grep, it makes a nuanced claim that accounts for all of this. It specifically says you should use grep when you need the features of grep that aren't in ripgrep.