Why is this better than a shell's built-in history, possibly paired with fzf?
I'm not asking sarcastically, either. Is this something awesome I should be using? What about it is going to blow my mind?
I'm not asking sarcastically, either. Is this something awesome I should be using? What about it is going to blow my mind?
First, a bit more about my zsh+fzf use: I use `share_history` so that my history is available across shells, allowing me to quickly find and re-run commands. (https://zsh.sourceforge.io/Doc/Release/Options.html#index-SH...)
Sometimes I want to switch back to some terminal tab/window and find a command that I nkow I ran in that session, but now it's flooded with 1000+ commands that I've entered elsewhere, making it difficult to find what I'm looking for. So the shared history is both useful and a hindrance, depending on the scenario.
Compare with atuin: I can filter by commands entered specifically within the current shell, or across all shell sessions, and possibly even across other hosts (when using atuin's sync functionality -- haven't tried that yet).
Given the metadata that atuin collects (current working directory, start time, exit status, duration, etc) I'm sure there are some other clever things that can be done with my shell history now, vs the the "line per entry, with optional start timestamp" approach used by zsh's builtin history functionality. Actually, more on that first point: you can also filter by commands entered within the current directory.
I guess I’m looking for more of a personal experience anecdote, where someone could explain how its other features made it worth signing up for another sync service and learning a new thing. It may be the best thing since sliced bread but that page doesn’t say why I should try it.
- this matters because it's capturing not just what commands were run, but metadata about the commands as well. Of particular interest to me is that ot captures the start and end time for every history entry so you can get timing data even if you forget to use `time`
- it provides much more fine-grained control over what makes it into the database than shells provide for controlling what makes it into their built-in history. For example, it has built-in support for filtering out common kinds of secrets/tokens/etc.
It's also in active development with a friendly and helpful creator/project lead, an active community, and an ever growing feature set.
I'd recommend giving it a try; as far as I'm concerned, it's best-in-class for managing shell history
That’s potentially an incredible useful feature to integrate with all that metadata! Very very interesting.
I use it mainly because a) it stores data about command history in a proper database that's easy to query (what century is this? How do other tools justify dumping what should be structured information into some god-awful mess of semi-structured text files?) and b) it makes a clean separation between SESSION, DIRECTORY and GLOBAL scopes which means you can explicitly use a recency or a locality filter (I don't want irrelevant commands cluttering my history).
Even without sync, atuin is a gem.
- Filter by commands run within the current shell session
- Filter by commands run within the current working directory
- Filter by commands run across hosts (as opposed to filtering commands run on your local machine)
- Filter by commands run within the current shell session
- All of the above searching functionality, with nice fuzzy finding support, time stamps, etc.
Before atuin I used zsh's builtin history, with ctrl+r rebound to present that builtin history through the `fzf` fuzzy finding tool, and zsh configured to share history across shells. The deficiencies I found: I couldn't optionally filter by commands _only_ run in the current shell, I couldn't filter by commands run in the current directory (useful for quickly finding commands I often need to re-run for a given project), and I can't search for commands run across hosts.
If you don't find yourself valuing these things, you may find that you have little to gain from using atuin.
It syncs across devices. I’ve got a number of raspberry pi devices I use and I never remember what command I used. Also preserves history when I inevitably need to replace the SD card.
Atuin also preserves information about the exit code. So you can filter on commands that worked. Which is great.
And, you can still use fzf to search your history if you want. I’ve got ctrl-r bound to search Atuin with fzf and ctrl-t to use native Atuin search.
If you’ve got an extensive history already, Atuin easily imports it. So I didn’t miss anything.
And because I wrote an ansible playbook to install it everywhere, including provisioning my self-hosted Atuin server, it just works.
Biggest downside was compiling for Raspberry Pis - which may be running slightly different versions of Raspbian. The project doesn’t provide the arm7 binaries. Eventually I figured out how to do fully static compilation with rust and that solved my problems.
function hist() {
print -z $( ([ -n "$ZSH_NAME" ] && fc -l 1 || history) | fzf | sed -E 's/ *[0-9]*\*? *//' | sed -E 's/\\/\\\\/g')
}I think you mean "I have a one-liner zsh function that does a tiny subset". It's lacking:
- The ability to filter by current directory
- The ability to filter by current shell session, instead of across all shell sessions (that's assuming you use zsh's shared_history; if not, then the opposite is true: you can only search within the current shell session. See https://zsh.sourceforge.io/Doc/Release/Options.html#index-SH...)
- Search history across hosts
Until recently, I used zsh+fzf, with the default ctrl+r binding replacement provided by fzf. It's been great, but it has lacked functionality that I've wanted for a while now. Atuin fills in these gaps for me.
Atuin stores _everything_ it can about each command run, what you see when you press C-r is only a tiny subset. And even it gives you the duration and success/failure information immediately.
If you want to, try pressing C-r, select a command from history and press C-o. Normal shell history doesn't store any of that.