💾 Archived View for thrig.me › blog › 2022 › 10 › 16 › shell-history.gmi captured on 2023-06-14 at 14:31:00. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Shell History: A Tale of Two Cities or at Least Two Very Small Opposing Camps in a Title that is Too Long, Whimsical, and Much in the Style of Don Quixote

It was the biggest of shell histories, it was the smallest of shell histories... most shell configurations probably lie somewhere between these two extremes, but a look at the extremes might help show the thinking that goes on in each of these camps.

small

First up, we have my current shell configuration,

    $ set | fgrep HIST
    HISTSIZE=64
    LESSHISTFILE=-

which is pretty minimal; the observant will note the lack of HISTFILE which means a shell history is not saved. This means anything important will be lost, or one must remember to put important things into a Makefile or script--quite possibly stored under version control--maybe also in a wiki or some other documentation store if one has coworkers. Some folks use shell functions instead of scripts, but I use both ksh and zsh and I typically do not want to write functions for both, and want to have things amenable to an execv(3) call, as I write a lot of C, and typically avoid the shell there when I can.

History support for other programs I tend to disable, as seen for less(1) above, or for other programs:

    $ readlink ~/.sqlite_history
    /dev/null

There is a reason for this; I use a program called feed(1) that feeds often repeated text into sqlite3 or really any REPL (which is then turned over to interactive use, after the feeding); if there were a history file, repeated feed(1) calls would spam it with too much data. Also, the data being fed is typically in a text file under version control; therefore, there is no reason to maintain a history file.

So much for the small history camp.

huge

I do not belong to this camp, so you may need to be one of these folks, or talk to them more. Their logic runs along the lines of:

< ectospasm> Mikachu: HISTSIZE=30000 when I noticed it, I recently increased it to 999999

< ectospasm> epony, thrig: I sometimes need to remember how I did something a long time ago. Without having it in my history, I tend to have to synthesize it again. Since the facility exists in zsh, I use it.

< ectospasm> And other times it's easier just to use !N to pull up the command and edit it. For seldom-used functions I may not remember how I set up the parameters, forcing me to `declare -f` to see how it was implemented. Most times it's just easier to edit a previous command.

Other complications here are possible; the history could be save to a database, put under version control, replicated across systems, etc. Go wild!

Do however note that fork(2) becomes less efficient in processes that use huge amounts of memory. Shells usually do not compete with the "heavyweight champion" browsers where this is a problem. Unless maybe your shell is an Electron app, in which case it is a heavyweight champion, plus some extra pounds. How much memory do your shells use? Is that a problem?

    $ ps auwwx | egrep '[k]sh|RSS'
    USER       PID %CPU %MEM   VSZ   RSS TT  STAT   STARTED       TIME COMMAND
    jmates   61273  0.0  0.0  1244  1000 p4  Ip      7Oct22    0:00.83 -ksh (ksh)
    ...

goldilocks

Now, if I were working for a company with problematic managers--the hypothetical ones who state "but you can multitask" after loading you up with 70+ hours of work on the week--I would save the shell history with epoch timestamps, plus keep a journal or worklog, etc. In less terrible work environments some of that extra state would be handy if a coworker needs to know when I did X which might have caused production issue Y, the context being that I am usually maintaining production systems which can break in amusing ways. Some extra history would help there.

If it's just me on my own laptop, and the history looks something like

    $ ./Build && prove t/100-gemini.t
    $ j
    $ nimi \^ | wc -l
    $ delve -C ~/var/log/irc 9999
    $ ps auwwx | grep ksh
    $ ps auwwx | sed 1q
    $ ps auwwx | egrep '[k]sh|RSS'

for me, that's really not worth saving. Actually the egrep can probably be improved to

    $ ps auwwx | sed -n '1p;/[k]sh/p'
    ...

to better capture the header line and processes matching ksh but not also the sed (or egrep) command.

tags #ksh #zsh

bphflog links

bphflog index

next: Software Portability