This script generates a report against your command-line history and suggests workflow improvements. Its opinion is that most commands should be simple and require minimal typing. The report contains:
- comprehensive lists of commands you use, with and without arguments
- suggestions for ways to shorten commands (aliases, alternative syntax)
- a subset of lints from Shellcheck, if installed; many of these can warn against dangerous habits
The script does not use the network, and it doesn’t move or store your command history anywhere. It should be fairly portable, running on Python 2.7 or 3.4+ and requiring “only” the standard library.
This is an early prototype and primarily supports bash, sh, and zsh.
Download command_line_lint.py and run it:
python command_line_lint.py <history_file> # python 2 or 3 is fine
<history_file> argument is optional. If omitted, a determination is
made based on the value of the
SHELL environment variable:
zshuses the value of
Not all shells have support for saving a history file (fish, dash, etc.)
Command-Line Lint gives better results when the following hold (it will tell you about these, too):
HISTSIZEenvironment variable should be large enough to produce useful usage summaries. The defaults tend to be too small – try 5000.
- Retaining duplicate entries is important for being able to determine what
you do the most, so variables/options like
histignorealldupsshould be set appropriately.
- If you use
shopt histappendshould be set so that multiple concurrent shell sessions can all add to your
.bash_history. If you use
setopt appendhistoryshould be set likewise.
If you’re linting a history file that comes from a different shell than the one you’re using, you can let the script know. For example, .history comes from a zsh session but you’re using bash, you can write:
SHELL=zsh python command_line_lint.py /path/to/.zsh_history
This script supports the use of NO_COLOR to disable color output:
NO_COLOR=1 python command_line_lint.py
Because those who do not learn from history are doomed to
additional reporting around some of the following would be useful:
- Command fingerprinting to sort out common typos (
shopt dirspell, if it exists, can be used to fix typos in
- Security checks in addition to readability of history file (for example warnings about plaintext passwords, etc.)
- Analyzing sequences of commands for improvements (e.g., sometimes
dry-running a command like
rm -rf ./*with
ls ./*is a good idea; switching back and forth between directories can use
cd -and switching back and forth between git branches can use
git checkout -; etc.)