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.
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).
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: 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.
> 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.
[0] https://github.com/larkery/zsh-histdb
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
(https://media.ccc.de/v/froscon2024-3125-moderne_linux_komman...)
- 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.
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:
A simple case: A case with multiple substrings: 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.
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...
edit: added; I already had a note on it, just wasn't in this list