Mon 29 December 2014
By iturde
In misc .
tags: bash
Wouldn't it be great to remember every line ever typed at the bash prompt for
life? This article has instructions to configure the bash history just for
that.
Configuring bash to save every command line
Append the following lines to /etc/bash.bashrc:
HISTTIMEFORMAT='%F %T '
HISTFILESIZE=-1
HISTSIZE=-1
HISTCONTROL=ignoredups
HISTIGNORE=?:??
shopt -s histappend # append to history, don't overwrite it
# attempt to save all lines of a multiple-line command in the same history entry
shopt -s cmdhist
# save multi-line commands to the history with embedded newlines
shopt -s lithist
This configures bash to save every command line typed at the interactive shell
prompt (HISTFILESIZE) to ~/.bash_history (default), including a timestamp
(HISTTIMEFORMAT) and ignoring consecutive duplicate entries (HISTCONTROL).
By setting HISTSIZE to the same value as HISTFILESIZE, all saved commands
are read back to memory when a new interactive shell starts. The default value
for HISTSIZE (500) would load only a fraction of the saved history.
When saving the history at shell exit, history lines are appended to existing
ones, instead of replacing them (shopt -s histappend).
By setting HISTIGNORE=?:??, lines consisting of just one or two characters are
discarded from the history (e.g. ls commands).
These settings are a variation of some very useful discussion in this
debian administration article .
Removing duplicate history entries
We need to get rid of duplicate lines in the history file. For me an
appropiate point to do it is on each reboot of the machine. This can be
accomplished by adding the following crontab entry (add it with crontab -e):
@reboot $ HOME /bin/deduplicate-bash-history.sh
where deduplicate-bash-history.sh does the actual work:
# keep only the first occurrence of each duplicate entry in ~/.bash_history
#
# 1. Break records at points matching a timestap. Special case
# for the first and last lines in the history file (setting RS to a regexp is a
# GNU awk extension). This way the script matches multi-line commands in the file
# 2. Set the timestamp of the current record to the previous record separator,
# trim starting line break
# 3. Skip empty lines (e.g. the one produced while processing the first line)
out = $( mktemp)
gawk -vRS= '(^|\n)#[0-9]+\n' \
'{
sub(/\n$/, "")
if ($0 && cmds[$0]++ == 0)
print time $0
time = RT
sub(/^\n/, "", time)
}' < ~/.bash_history > $out
mv $out ~/.bash_history
The script is a bit tricky because, as explained in the comments, special care
must be taken on multi-line commands and the first and last file entries.
Running the script automatically on every reboot before even the user has
logged in ensures that nobody is using the history file, and avoids mangling
its contents.
Browsing the history
The Ctrl-R key is bound by default to reverse-search-history. Likewise, the
Ctrl-S key is bound to forward-search-history (man 3 readline), but this
clashes with the standard key assigned to terminal flow control. To fix that,
add the following to /etc/bash.bashrc:
# Instead of using control-s for flow control, pass it to readline to enable
# forward incremental search
stty stop ""
Having both keys available makes it easy to go back to the previous match if
you hit one key too many times.
There is another method to get to a specific history entry. As explained in
this hacker news comment , the
up and down keys can be used to jump to the previous/next history line matching
the current line. Add the following lines to /etc/inputrc to configure the
key bindings:
"\e[A": history-search-backward
"\e[B": history-search-forward
If you just made a typo in the last command you entered, you may want to remove
that entry from the history immediately. Here are some key bindings you can add
to /etc/inputrc for that:
$if Bash
# delete last command from history
Control-x: "history -d $(( HISTCMD-2)) "
# delete second to last command from history
Control-y: "history -d $(( HISTCMD-3)) "
$endif
Doesn't this slow down every bash startup? Does it turn bash in a memory hog?
After having this setup running for months, my history file has grown over a
couple of thousand lines. Now, every interactive shell must load and maintain
every history line into memory. I haven't meassured the startup time, but it
still feels immediate anyway. A quick check comparing the RSS field of ps u -C
bash indicates that, for each interactive bash shell, maintaining 20k history
lines in memory requires approximately 3 MiB of additional RAM. For me the
convenience of always having every command I ever typed on a shell at my
dispostion outweights this cost.