[Zhyl]

Wow, a lot of hate for this list, but I'll unpick something that is slightly below the surface here:

We are currently seeing a bit of a command line renaissance. The justification for this is a 'rust rewrite', but as many have pointed out, just because something is in such-and-such a language doesn't make it good.

However, what I tend to find with the new rust CLI tools is that they bring with them modern design sensibilities. They can use better conventions, better defaults, assume things like colour terminal emulators (or fallback to non-colour if not outputting to a terminal).

The experience of using them is often much different to using the old GNU versions made in the 80s which reimplement tools made in the 60s and 70s.

I'm not saying all the other criticisms in this thread aren't valid, but I think it's worth highlighting the positives of the tools mentioned in a list like this rather than just throwing negativity on it.

[robenkleene]

I agree with this so much, in particular I want to highlight these tools from the list, just because I love them so much:

# `rg` / Ripgrep (`grep` replacement)

`rg` uses `ack`-semantics (i.e., automatically searches files recursively).

Here's what my search workflow looks like, this is the main way I program:

1. `rg something`

2. Too many hits? `rg -l something` to just list matching filenames

3. Hopefully based on that we can narrow enough using a glob: `rg something -g "*.m"`. Otherwise write a regular expression to get more specific matches.

4. After I have exactly the set of matches I'm interested in, I pipe the results to a text editor that can interpret grep-style output (e.g., quickly jump between results, I usually use Vim).

The key here is that the command-line excels at iteratively refining a command based on output, and that's exactly what we're looking for to use search effectively. `rg` provides a more ergonomic UI than `grep` (recursive, automatically ignoring version control files, including ignored), which is really important if this is the main command that you're running all-day, which it is for me.

# `fd` (`find` replacement)

This advantages here are the similar as for `rg`, quickly being able to recursively find a file by name, a problem that similarly benefits from iteratively refining a command.

# `bat` (`cat` replacement)

`bat` is just the best way I've found to quickly view a file from the command-line, it adds syntax highlighting and line numbers, which are both invaluable.*

[jedisct1]

ugrep is better than rg.

[karottenreibe]

It would help if you added why it's better to your comment

[pdimitar]

Agreed, plus some of them replace Python CLIs which are awfully slow to start (400 to 1500ms in my experience). Having those start in 3ms is a huge win in terms of ergonomics.

[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.