Split Brain

If you try the presented programs right away, you might wonder why the history you see depends on the terminal window instance where you're currently located.

Bash has the questionable habit of creating separate histories for separate terminal windows opened by the same user. If you type a command in one window, the history in another window will not know about it. But if you shut down the shell in a terminal window (e.g., by closing the window), the running shell sends its history to the .bash_history file in your home directory. Every newly started shell then has access to the newly added data moving onward.

If you want to keep the global history up to date, you can use the command sequence shown in Listing 5. If you store it in the PROMPT_COMMAND environment variable, the shell will trigger it after each command you type.

export PROMPT_COMMAND="history -a; history -c; history -r; $PROMPT_COMMAND"

The three history commands in Listing 5 write the command trail of the current Bash session to the global file (-a for "append"), delete the local history (-c for "clear"), and load the global history into the local session (-r for "reload"). This setting, however, means accessing the hard disk for each command; depending on the number of typed commands, this may result in a loss of speed.

Furthermore, Bash limits the number of commands created in the history to 500 by default. If you want to resort to older commands, set the variables in Listing 6 to the values shown [2].

export HISTSIZE=100000
export HISTFILESIZE=100000

The first value sets the maximum number of entries Bash can remember in a running session. The second value specifies the maximum number of lines in the global history file. In any case, access and analysis of history data offer the opportunity to discover shell commands that you type too often. This analysis might help you to develop better, as in more efficient, methods. The histWalk() function presented here will hopefully animate readers to try out further practical applications.

The Author

Mike Schilli works as a software engineer in the San Francisco Bay area, California. Each month in his column, which has been running since 1997, he researches practical applications of various programming languages. If you email him at mailto:mschilli@perlmeister.com he will gladly answer any questions.