Shell History Is Your Best Productivity Tool
martinheinz.dev
martinheinz.dev
I have sync disabled, though.
Sync is oversold as a feature, never used it.
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 realsI 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.
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.
Yes, it includes both commands entered into the terminal and also all output or whatever gets put on the screen.
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.
My shell has a lot of history:
$ history|wc -l
152298
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.Not having (persistent) history in a shell actually forces you to think about your workflow, which is a good thing.
> 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.
I tag some commands with #some-comment in the end so I can search easier.