Modern Unix Tool List | Hacker News Reader

Modern Unix Tool List

notes.billmill.org

61 pointsspeckx11 comments

I strongly recommend storing your shell history in a database, but if you're more of a minimalist, you might want to look at zsh-histdb[0]. It only support zsh, and doesn't have cloud syncing, but its also written entirely in shell script, doesn't have "accounts" or rely on sponsors, and it is far simpler. I have been using it for years and it has been absolute bliss. Whenever I run a command, it is immediately available in the history for all of my shells, and I no longer have commands disappear from my history unexpectedly.

[0] https://github.com/larkery/zsh-histdb

FWIW, atuin has support for syncing to a server, but it's entirely optional. I've used it for quite some time without knowing that, and have never set up an account (since I didn't know I could and have no interest in doing so).

Seems like a pretty good collection of a lot of the tools I hear about these days, and also use myself sometimes.

I also like `fx`, which is like a combination of `jq` and `gdu`.

https://fx.wtf/

Oh, and also `gdu`, which is like `ndu` but faster:

https://github.com/dundee/gdu

I'm surprised no one has mentioned Nushell, which is a modern BASH replacement that can replace curl, jq, and other data processing tools, and not to mention ls, ps, and other core GNU programs.

fd is the tool I've wanted for so long

as seen on froscon this year :)

(https://media.ccc.de/v/froscon2024-3125-moderne_linux_komman...)

- fd: an improved find Depends on what you need to do, at least without constructing a pipeline like it's 1990 (modern..), probably on your age, and how much you suck at typing. I have it installed as well, but most of the time still use find and not just in scripts which hopefully is a no-brainer. Some rather weird decisions went into that iteration, or call it taste if you prefer. Even the name is a joke honestly. But what in and out of Rust isn't. Re-inventing the wheel, ok. But then why not, err, also improve on it?

- hexyl: a better xxd Like what?!

- ripgrep: a cornerstone of my workflow, an improved grep No, it's a by default recursive grep which grep emphatically isn't, wasn't and never aimed to be. It has many, many more features, is bigger, newer, shinier and (yes) a bit slower. But that's ok, I use it too where it makes sense, as usual. An improved silversearcher, maybe that!

I'm barely using anything of the mentioned. But then I hate colors, and when I want to see nice pictures I'm off to the movies. At least your definition of modern is actually funny.

For me, fd is as better than find as ripgrep is to grep

The main benefits are:

- it skips ignored and hidden files by default

- it uses modern regular expressions

- it has a more sane UI (`find . -iname '*.txt'` -> `fd -g '*.txt'`)

I do use it in scripts as long as I know they're going to run in a context where it's available, ex: https://github.com/llimllib/personal_code/blob/c3d33b4d95f89...

> It has many, many more features, is bigger, newer, shinier and (yes) a bit slower.

Can you show a common case where ripgrep is meaningfully slower than grep?

Here are a few common cases where ripgrep is meaningfully faster than GNU grep 3.11 on Linux.

The setup:

    $ cd /dev/shm
    $ curl -LO 'https://burntsushi.net/stuff/OpenSubtitles2018.raw.sample.en.gz'
    $ gunzip OpenSubtitles2018.raw.sample.en.gz

A simple case:

    $ time rg -c 'Sherlock Holmes' OpenSubtitles2018.raw.sample.en
    502

    real    0.102
    user    0.056
    sys     0.046
    maxmem  903 MB
    faults  0

    $ time LC_ALL=C grep -c 'Sherlock Holmes' OpenSubtitles2018.raw.sample.en
    502

    real    0.378
    user    0.255
    sys     0.122
    maxmem  21 MB
    faults  0

A case with multiple substrings:

    $ time rg -c -e 'Sherlock Holmes' -e 'John Watson' -e 'Irene Adler' -e 'Professor Moriarty' OpenSubtitles2018.raw.sample.en
    628

    real    0.128
    user    0.077
    sys     0.050
    maxmem  903 MB
    faults  0

    $ time LC_ALL=C grep -c -e 'Sherlock Holmes' -e 'John Watson' -e 'Irene Adler' -e 'Professor Moriarty' OpenSubtitles2018.raw.sample.en
    628

    real    0.580
    user    0.516
    sys     0.063
    maxmem  21 MB
    faults  0

You can run the `rg` commands with `--no-mmap` to get slightly slower but roughly similar times but using standard `read` syscalls instead of file-backed memory maps.

I chose these cases because they represent common and simple queries. And, specifically, it's searching a single text file. There isn't anything involving parallelism or skipping files or recursive search or whatever.

jless - good companion to jq

oh yeah I love jless, I should add it

edit: added; I already had a note on it, just wasn't in this list

Reply on news.ycombinator.com