fd is also great and I install it everywhere.

https://github.com/sharkdp/fd

I also really like:

https://github.com/eza-community/eza (modern ls replacement)

https://github.com/BurntSushi/erd (modern tree replacement)

https://github.com/sharkdp/bat (modern cat(1) replacement)

my .zshrc for every system now uses these as drop in replacements

Wrong erd! https://github.com/solidiquis/erdtree

This looks really cool, though. I might try using this as an `ls` replacement, too, just because of how it shows the recursive directory size like `du`. I've always wished windows explorer did that (do any linux gui file managers?)

And https://github.com/ast-grep/ast-grep maybe

It’s a great tool, but it’s not a posix compliant grep.

I think it's more about having a stable interface. If it's not stable - you can't use it as a base tool long term. But if it's stable, what difference does it make if it's POSIX compliant or not?

Because you aren’t the first one here. Countless lines of software exist which assumes posix. People learned how to use computers and know the grep commands. There is documentation for posix in places where it needs to be. It handles important edge cases which were needed by some groups and that was formalized into a standards requirement.

So changing to the new thing invalidates all that existing value.

That’s not argument to never do anything new, but it’s an argument why for your UNIX-like OS should ship the standard boring thing instead of the shiny new thing in the base install.

Having ripgrep installed by default doesn't preclude grep also being installed.

Indeed. So why it should it come by default?

Have you used ripgrep? It's so much nicer for day to day usage! That's why it should come by default. Seriously, try it out, I'm sure you'll love it!

I'd say POSIX is sometimes overrated.

Example: https://github.com/mpv-player/mpv/commit/1e70e82baa91

Anyway, I don't see any of that as a reason for not having ripgrep installed everywhere by default and as an argument for not using it.

It doesn’t matter if it’s over or underrated - what matters is if you want to be compatible with existing code and documentation.

I wish C didn’t have strtok, but it’s too late.

I don't specifically want to be compatible with it, no. I mean if ripgrep works for my needs - I'll use it and won't worry if it's POSIX compatible or not.

Great. But we don’t need it in base.

That's what I don't necessarily agree with.

So? There are (likely) tons of tools that come installed by default in your distro that aren't POSIX compliant. Or aren't even mentioned by POSIX at all.

For example, on Archlinux, `base` (the minimal set of packages to install) includes `systemd`. `systemd` isn't POSIX.

Now, you could say having both grep and ripgrep installed by default would be somewhat wasteful. As the author of ripgrep, I agree with that. ripgrep is fine being something you opt into so long as coreutils is already included by default.

I'm just tired of people hiding behind POSIX compliance. One wonders how many of your invocations of grep are not POSIX compliant. (A strict POSIX grep is laughably minimal. To the point that not even minimal implementations of coreutils, like busybox, don't stick to the strict set prescribed by POSIX.) I'm not even aware of any grep implementation that doesn't implement something beyond what POSIX requires.

Of course, grep still has a POSIX compliant base. And so long as your scripts only rely on that POSIX compliant base (no -a or -r or -o flags, for example), you can reap the portability benefits of POSIX.

> I'm just tired of people hiding behind POSIX compliance.

grep exists in base primarily to support shell scripting, as well as the benefits of standardization that I mentioned. That’s not hiding - it’s a basic expectation if you want scripts to run.

Why should ripgrep be on base and what kind of overhead are we adding to install?

> how many of your invocations of grep are not POSIX compliant.

It would be a different argument if ripgrep was compliant with extensions, like gnugrep, but being a completely separate tool with a similar name, it doesn’t fill the same role.

I like it and install it when I need it.

I think my comment already addressed every single piece of what you said here. And you're shifting your original claim! You are no longer hiding behind POSIX compliance here. Instead, you're making a more nuanced argument based on more than just POSIX compliance, and one that I find very reasonable! But that's not what you originally said.

> I think my comment already addressed every single piece of what you said here.

You did not mention a word about scripting.

> But that's not what you originally said.

It is. The reason ripgrep should not be in base is because it’s not posix compliant.

As I said, there are tons of things in `base` that aren't POSIX compliant. So that is clearly not a sufficient criteria to exclude something from `base`. You need something else (like what I said, and then you repeated without acknowledging that I had already said it).

> You did not mention a word about scripting.

WTF. Literally right there in my first comment:

> Of course, grep still has a POSIX compliant base. And so long as your scripts only rely on that POSIX compliant base (no -a or -r or -o flags, for example), you can reap the portability benefits of POSIX.

I hate to say, "please re-read my original comment," but I think it might actually apply in your case.

> Literally right there in my first comment:

In regards to ripgrep

> that is clearly not a sufficient criteria to exclude something from `base`. You need something else

The burden is on you to demonstrate why it should be included absent of a standard, not me to show why it should be excluded. Base maintenance work is a scarce resource.

Your only argument so far has been that posix compliance doesn’t matter.

This interaction is actually souring me on the project.

How could you possibly miss this in my first comment???

> Now, you could say having both grep and ripgrep installed by default would be somewhat wasteful. As the author of ripgrep, I agree with that. ripgrep is fine being something you opt into so long as coreutils is already included by default.

...

> This interaction is actually souring me.

You and me both. Maybe you could try actually reading my comments. I feel like I'm talking to an AI that has been trained to be maximally annoying through gaslighting.

So unless you can demonstrate that you're a real person (like my profile does), you're now on my ignore list.

So you agree it’s wasteful to have both - so then your only options are:

1. Put rg in base without grep. I don’t care if scripts that use grep are broken. 2. Rg does not need to be in base

> you're now on my ignore list.

Ditto. But what I’ll remember is that the rg guy struggles to understand and reconcile the needs of people who rely on critical software.