Great article! I had a similar set up using zsh and fzf but recently switched to https://atuin.sh/ and can't recommended it enough. It just works and I love the default built in search by current directory vs global.
Search by current directory is the killer feature IMO. Was initially recluctant to use atuin, thinking that fish's history was enough, but now I'm sold.
For me, having history in a structured sqlite database is the killer feature. You can build useful reports ("histogram of run times for all pytest calls from the current directory that exited zero") in a single sql query.
The very act of remembering something embeds it deeper into memory versus control-r "something", oh yeah that, enter. I'm cognizant that this is roughly the same argument as "google is making us dumber" which it's just "for your consideration" and not an axiom
And shell is one of those DSLs folks speak so highly of, in that one can build up a vocabulary that is meaningful to you, or your team, or your line of business in ways that "here's my .bash_history good luck" type sharing doesn't. Most good unix-y tools support hooks based on the script name to extend common systems with other verbs: brew, git, kubectl, and likely more
So, if one needs to remember the 5 distinct commands to cut a release, why not put them in .gitlab/scripts/run-release versus "oh, I think Jane runs that, ask her to look in her shell history"
Merely as a bit of ancedata, I have two forms of shell history suppression: $(ln -sf /dev/null .bash_history) and the almighty $(export HISTIGNORE=both) which allows me to prefix commands with a space in order to keep them out of even the local shell session's history. I am pretty disciplined about doing it for destructive commands so the inadvertent up-arrow+enter doesn't go off the rails
I've also had great luck with "poor person's dry run" as in
N=echo
for i in ...; do
$N something destructive "$i"
done
eyeball the output, then N="" and run it for reals
I do the same thing. In fact I was telling a colleague that I've always thought it was a good idea, but I always do it since I watched a bad bash loop end a person's employment. I felt like that was the kind of war story that has me well on my way to being a greybeard.
I go so far as to log all sessions, everything that comes across the screen. Sometimes it's a lifesaver or just convenient to be able to grep through everything to find a specific command, sql query, their output, etc.
One time long ago I wiped out a long crontab by using -r instead -e and got a perfect recent copy from my terminal history, so no harm done.
Can you elaborate on what you mean by "everything that comes across the screen?" Does this include the outputs from your commands? If so, what do you use to do this?
I'm usually not typing in new commands, but rather, using ctrl+r and searching for things I remember that I've done.
For ZSH users, I would also recommend setting:
$ setopt EXTENDED_HISTORY
Which saves history in the format Format : [beginning time]:[elapsed seconds];[command]
And
$ setopt INC_APPEND_HISTORY_TIME
man page says: This option is a variant of INC_APPEND_HISTORY in which, where possible, the history entry is written out to the file after
the command is finished, so that the time taken by the command is recorded correctly in the history file in EXTENDED_HIS‐
TORY format. This means that the history entry will not be available immediately from other instances of the shell that
are using the same history file.
Personally I just disable history in everything I use, including the shell and the browser. If something is potentially worth remembering, just save it into a script/make a bookmark.
Not having (persistent) history in a shell actually forces you to think about your workflow, which is a good thing.
I've recently started using Atuin (https://atuin.sh/), and can't get enough. Now it's one of the first things I install on any new machine/environment I work with, and it's been an absolute game-changer.
My biggest problem with it is it breaks operate-and-get-next (Ctrl+O). So I still have to manually walk back in my history if I want to rerun a sequence of commands.
> operate-and-get-next (C-o)
> Accept the current line for execution and fetch the next line relative to the current line from the history for editing. A numeric argument, if supplied, specifies the history entry to use instead of the current line.