Shell History Control

⊕I miss Minesweeper.

Say you execute the following commands in your terminal,If you try this yourself, type each line individually. Don’t copy and paste the entire block – it won’t work.

bash  # Create a new bash session
echo "SECRET_API_TOKEN_1" > /dev/null
echo "SECRET_API_TOKEN_2" > /dev/null
exit  # Exit it

followed by,

bash
tail -n 3 ~/.bash_history | grep SECRET_API_TOKEN_1 # <= grep_1
tail -n 3 ~/.bash_history | grep SECRET_API_TOKEN_2 # <= grep_2

What do you think the output for grep_1 and grep_2 would be?

The answer,

echo "SECRET_API_TOKEN_1" > /dev/null               # <= grep_1

The second tail|grep invocation (grep_2) doesn’t print anything because it fails to find SECRET_API_TOKEN_2 in your history because it isn’t there. The extra space before the second echo statement wasn’t an accident. bash looks at the HISTCONTROL environmental variable. If it is set to ignorespace (or ignoreboth, which also ignores duplicate lines), it won’t write any command with a space prefix to the history.h/t Yevgeniy Brikman in Terraform: Up Running: Writing Infrastructure as Code, at least for me. Or, if you use zsh (as you should) make sure to put setopt HIST_IGNORE_SPACE in your .zshrc.

This is useful.

Granted, It is not useful in the way I sketched above. There are probably other good reasons for not putting secrets in command line scripts. Plus, you have to be sure the space is there, which seems like asking for trouble.

But it is useful for TAB-UP mistakes – those accidents where you press TAB-UP-RETURN too quickly and do something painful. Think rm -rf . or an accidental deploy. Your fast-moving developer auto-pilot brain is prone to stepping on old landmines. HISTCONTROL disarms them.