Shell History Is Your Best Productivity Tool

https://martinheinz.dev/blog/110

by nalgeon • 2 years ago

47 18 2 years ago

martinheinz.dev

klooney• 2 years ago

I've become extraordinarily reliant on fzf's shell history integration.

reddit_clone• 2 years ago

Indeed. Zsh history + FZF is my second brain.

I tag some commands with #some-comment in the end so I can search easier.

Am4TIfIsER0ppos• 2 years ago

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.

jmholla• 2 years ago

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.

jeffwiederkehr• 2 years ago

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.

pricci• 2 years ago

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.

perrygeo• 2 years ago

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.

mdaniel• 2 years ago

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

  N=echo
  for i in ...; do
    $N something destructive "$i"
  done

eyeball the output, then N="" and run it for reals

eternityforest2• 2 years ago

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.

silverquiet• 2 years ago

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.

add-sub-mul-div2• 2 years ago

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.

Gerlo• 2 years ago

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?

add-sub-mul-div2• 2 years ago

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.

eternityforest2• 2 years ago

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.

charlieok• 2 years ago

if you're going to bother syncing your shell history across machines, you probably also would strongly consider syncing your entire home directory.

qweqwe14• 2 years ago

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.

mmh0000• 2 years ago

I agree with the author.

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.

aninuth• 2 years ago

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.

Shell History Is Your Best Productivity Tool

Related Stories