Command-Timing-Bash-Prompt
Tyler Cipriani Posted

A few years ago I was using ZSH with Sindre Sorhus’s Pure prompt and generally enjoying the experience. The big, dumb, obvious caveat of using ZSH is that it’s not Bash. As a result, when you SSH into production machines that only have bash installed, you feel a little off-balance. Off-balance is not a feeling you want during an emergency on a live application server. As a result, I switched back to using bash everywhere.

How I learned to stop worrying and love bash.

I never really missed fancy syntax highlighting, or the nice globbing features, or most of ZSH really. The one thing I missed immensely was not so much a feature of ZSH as it was a feature of the Pure prompt I had been using: execution time for long-running commands shown in the prompt.

The time(1) command is a command that I never think to run until it’s too late. The Pure prompt is fancy. By default, if a particular command takes longer than 5 seconds to run, Pure calculates the running time of that command, and renders a human-readable version just above your current prompt.

Bash it until it works

Command execution time in Pure uses the preexec and precmd feature of ZSH, which doesn’t exist in Bash. Instead Bash has the less intuitive trap command and the PROMPT_COMMAND shell variable.

PROMPT_COMMAND is a variable that can be set in your bash config file that, “is executed as a command prior to issuing each primary prompt.” [bash(1)]

trap [-lp] [arg] [sigspec] can be used to listen for the DEBUG signal. “If a sigspec is DEBUG, the command arg is executed before every simple command”

Using these two tools in conjunction, you can approximate preexec and precmd:

So now debug is executed before each “simple command” and prompt is executed before each issuing the primary prompt.

Timing each command is then pretty trivial:

Integrating that into the prompt and making it look pretty is just a little-bit of code away:

Motherfucking magic.

Jan 2016
S M T W T F S