[dlivingston]

My biggest problem with this list is that when I write shell scripts, I usually intend for them to be used by colleagues or others.

Having non-POSIX applications used in these scripts means that portability is limited.

Yes, I know that with aliases I can override this, but I’m not convinced yet that straying from “this will work on everyone’s machine” to “set an alias for X, and X will probably be an appropriate stand-in for Y” is good enough to guarantee zero-issue compatibility.

[Zhyl]

Absolutely, and I think this raises the question of "in what sense are these 'replacements' for existing software?".

If we see them as "immediate drop-in replacements" then the value of them must be that they're identical in every way and the value in them would be in the reduced maintenance overhead for the developers, with maybe a small performance boost if we're lucky. This would be fine, but it's not something that we'd notice if our distro went from using C `grep` to using a Rust rewrite of `grep`. We certainly wouldn't need a list telling us what replacements are available.

However, if we see these as spiritual successors, ones that perform the same function but aren't intended to be aliased to be precisely the same thing, then it makes a lot more sense. We're not looking for backwards compatibility, portability or identical feature sets. We're instead being offered a smorgasbord of options on what ideas we want to embrace and which ones we would want to leave behind.

If ripgrep is better in all use cases than grep, then eventually ripgrep will be the one being used in the scripts organically. We shouldn't be dismissing ripgrep out of hand just because a colleague won't have it on their system. Or, at the very least, we should be noting the good points while also noting that we won't be using the tools ourselves for portability reasons.

[scns]

Let a thousand flowers bloom https://gigamonkeys.com/flowers/

[kstrauser]

I see scripting and interacting as inherently different use cases. I absolutely love Fish shell for interactive use, but I don't use its scripting (other than to write functions I use from the command line) because it's not available everywhere. POSIX sh is much more appropriate for scripting, but I definitely wouldn't want to use it as my command line because it lacks all the greatness that Fish brings to the table.

Same with POSIX tools and their replacements: `find` is perfect when I know I'm going to run a script on a bunch of similar Linux hosts where I can't count on `fd` being available, but if fd is around I'm definitely going to use it at the shell prompt over find. As a side note, if you're doing cross-platform work, the new tools are better in some ways than the things they're replacing. Sure, `fd` isn't going to be installed by default on our out-of-the-box EC2 instances, but once it's installed at least it has the same arguments on Linux as on BSD and macOS. If I'm going to have to install GNU utils on a system to manage it, it's no extra work to install fd at the same time.

[b3morales]

It's a fair point, but I find I can get along quite well using the new tools myself interactively and falling back to the standard versions if I need to write a shareable script. For me the degree to which ripgrep is better for day-to-day use more than outweighs the cost of remembering how to use grep once in a while.

[stouset]

Don’t you think it’s beyond time we start expecting people to have command-line tools newer than those written in the seventies?

[pjmlp]

Given that most people don't use POSIX rather GNU extensions, that is besides the point.

[seoaeu]

Honestly this just highlights a weakness of shell scripts. The idea that you cannot use any new dependencies (or even upgraded versions of the current dependencies!) would be unthinkable in most other settings.