Fixing your terminal Unix History | Hacker News Reader

Fixing your terminal Unix History

htmlhive.com

27 pointsdedalus19 comments

I also log date/time with each command. Sensible bash provides this: https://github.com/mrzool/bash-sensible

This article erroneously conflates terminal and shell and then proceeds to talk about only one shell, the Bourne Again shell. (It is Windows NT where command history is a function of the console object rather than of the command interpreter.) Nor do "all software engineers use history". Some use the standard "fc" command. 93 Korn shell users can use "fc" or "hist" as well. The article's abuse of "legacy" to mean "undesirable" is almost a side-issue.

* http://pubs.opengroup.org/onlinepubs/9699919799/utilities/fc...

* http://jdebp.uk./FGA/legacy-is-not-a-pejorative.html

Of course, the idea that Unix, which was multi-user from 1st Edition onwards, "could only have one shell open at a time" is nonsense. And I can attest from personal experience that people cottoned on to having two terminals side-by-side before screen came to comp.sources.unix.

Interestingly, the manual page for the TENEX C shell points out that shell variables controlling history should be set in .tcshrc rather than in .login so that they affect the sourcing of $histfile which is done before the sourcing of .login. What it does not also point out is that this results in always setting them in all interactive shells without need to import them from the associated environment variables. If always set in this way, it is largely meaningless to export the shell variables into environment variables visible to other programs in child processes, as the headlined article has one do.

The same can be done with the Z shell, setting the history control shell variables in .zshrc or the $ENV file, the 93 Korn shell and PD Korn shell, setting the history control shell variables in the $ENV file, and the Watanabe shell, setting the history control shell variables in .yashrc or the $ENV file.

Thanks for posting this, this makes history so much better and I have only been using these changes for 20 minutes.

Is this an Apple problem? I've used a few different Linux distros over the decades, and all already had these improvements built into the default bashrc (well, maybe HISTSIZE and HISTFILESIZE could afford to be larger, but they're still larger than 500, the claim made in this post).

Apple bash is ancient.

I thought Mac os used zsh. Haven't used Mac in over 10 years so I don't remember

Ha no I think v3 bash is default. You would think zsh tho bc it kind of falls in line with the mac user experience goals.

What are some tips on effeciently searching through it? ctrl+r to search history and ctrl+r again for cycling backwards is an obvious one, but there doesn't seem to be an obvious way to cycle forwards (e.g. I accidentally passed a line in a search that I wanted).

Ctrl-S searches forward (but only if you run stty -ixon first).

ctrl+s will cycle forwards, but it's normally bound to turning flow-control off in the terminal (which means that it won't update the display in response to keystrokes).

If you are searching for something, you can always do something like this:

history | grep 'keyword' | less

This is usually more effective for me than C-r.

For quite a while now, I've been using fzf[1]. Among other things, it replaces Ctrl-R and allows you to fuzzy search your command history. I almost can't imagine not having it now...

[1] https://github.com/junegunn/fzf

Huh. I had no idea fzf did history too. I will have to give this tool another look.

edit: wow, this is GREAT. thank you!

Alt-C is another feature I like. Fuzzy find directories to cd into. I'm a bit of a fanboy at this point.

Oh! This is awesome, I've been doing ctrl+t, fuzzy finds files, then just erasing the file name at the end. This is so much much better.

Though, normally I use autojump to traverse around, this is really helpful when you're searching for a folder in somewhere you haven't been before or in a while (autojump uses your history).

Am I the only one who doesn't like their command history to be saved? I don't like the idea of that being recorded, even if it would save me time in some occasions.

in early internet days, I would either chmod 000 the .bash_history file, or symlink it to /dev/null, to signal to the sysadmin that i don't like being watched...

20 years later and I meticulously save all of my own history, even command output/terminal transcripts. It has become too rich of information and important for me to callback to, it makes me a more effective worker

Interesting.

Out of curiosity, how much history do you save? And do you sync it between machines (assuming you have more than one)?

I save millions of commands or megabytes of bash history, its customized for maximum values, and to persist often on both of my primary computers (workstation, laptop).

for the rest of the ~hundreds of computers I login to in a year I mostly just use default 1,000 maximum lines history of bash. I make no effort to synchronize across machines, it is helpful for me to keep them separate -- which computer it was executed on is also the computer to recall it from.

I have also considered full-time full-screen recording! I just wanted to express that using Linux professionally for 20 some years has turned me around to the opposite of extreme I began with, maybe you do not know that you are missing out on a fantastic "recall" skill :)

Reply on news.ycombinator.com