Shell History Is Your Best Productivity Tool(martinheinz.dev)
martinheinz.dev
Shell History Is Your Best Productivity Tool
https://martinheinz.dev/blog/110
19 comments
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.
I have sync disabled, though.
I have sync disabled, though.
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.
Sync is oversold as a feature, never used it.
Sync is oversold as a feature, never used it.
An alternative perspective for consideration:
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
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
Right now I use Makefiles for most everything.
I can always type make <tab> and see what commands are available in that repo.
If I'm using the shell in any nontrivial way after things are set up, that's an issue I need to fix.
If there's commands I don't want to fully hide, that people may want to customize, I put them in the readme and usually copy and paste from there.
I can always type make <tab> and see what commands are available in that repo.
If I'm using the shell in any nontrivial way after things are set up, that's an issue I need to fix.
If there's commands I don't want to fully hide, that people may want to customize, I put them in the readme and usually copy and paste from there.
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.
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 use SecureCRT which has a session logging feature: https://www.vandyke.com/products/securecrt/index.html
Yes, it includes both commands entered into the terminal and also all output or whatever gets put on the screen.
Yes, it includes both commands entered into the terminal and also all output or whatever gets put on the screen.
Wow, I didn't even know -r existed!
Last time I touched a crontab was a few years ago when I was migrating them to timer units.
The classic UNIXy stuff really does not try to hold your hand at all, so that level of logging seems pretty reasonable on systems like that.
Last time I touched a crontab was a few years ago when I was migrating them to timer units.
The classic UNIXy stuff really does not try to hold your hand at all, so that level of logging seems pretty reasonable on systems like that.
[deleted]
I agree with the author.
My shell has a lot of history:
For ZSH users, I would also recommend setting:
And
My shell has a lot of history:
$ history|wc -l
152298
For ZSH users, I would also recommend setting:
$ setopt EXTENDED_HISTORY
And
$ setopt INC_APPEND_HISTORY_TIME
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.
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.
I've become extraordinarily reliant on fzf's shell history integration.
Indeed. Zsh history + FZF is my second brain.
I tag some commands with #some-comment in the end so I can search easier.
I tag some commands with #some-comment in the end so I can search easier.
Comments on the end are useful. I do that for yt-dlp commands which don't get nice URLs so I can find them again later.
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.
> 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.
if you're going to bother syncing your shell history across machines, you probably also would strongly consider syncing your entire home directory.