Long-Running Command Alerts

If you’re a developer or power-user, then you probably have to run commands that take a reasonably long time to complete fairly frequently. Too long to comfortably stare at your screen waiting for it to complete in any case. I like to be able to be alerted to the fact that one of these long-running commands has finished, so that I can do something else while it’s running, but then get right back to it once it’s done. In this post I outline the two ways I do this: aurally, and visually (via desktop notifications).

Everything in this post runs on Linux - I don’t believe the approaches outlined here would work for macOS, Windows, or most other operating systems. At the time of writing this I’m uses these commands on Linux Mint with Bash as my shell.

Aurally #

I define a shell function tone like so:

tone() {
    timeout -k ${2} ${2} speaker-test --frequency ${1} --test sine;
    return 0
} > /dev/null 2>&1

It takes 2 arguments: frequency, and duration. It uses the command speaker-test provided by ALSA, which plays a sine wave with the specified frequency until the process is killed. To kill the process so that we aren’t subjected to an endless pure tone we use the command timeout provided by the GNU Core Utilities. We use > /dev/null 2>&1 to discard the text output.

I then define an alias named beep:

alias beep='tone 523.25 0.35'

When run, this plays a nice C₅ for 0.35 seconds. Feel free to experiment with different frequencies/notes, and durations. Note that speaker-test will only play sine waves with a frequency between 30 Hz and 8000 Hz by default, but you probably want to stay without that range anyway.

If you want to have a different tone play for success versus failure, you can do so like so:

alias beep='tone `[ $? = 0 ] && echo 523.25 || echo 261.63` 0.35'

We get the exit code of the last executed command with $?, and check if it was 0 (success) with [ $? = 0 ]. If it was a success, the frequency argument is set to C₅ (523.25 Hz). If it was a failure (i.e. a non-zero exit code), the frequency argument is set to C₄ (261.63 Hz).

To hear the difference, set the alias, then run the following:

true; beep

false; beep

If you’re unfamiliar with the true and false commands, they’re a fun little part of the GNU Core Utilities. Their docs sum them up nicely:

true - do nothing, successfully

false - do nothing, unsuccessfully

Visually #

Sometimes I’m not wearing my headphones, or otherwise can’t hear audio from my computer. Or sometimes I want to run multiple long-running commands, and have them all alert me when they’re done, but not be subjected to a cacophony of pure tones. In these cases I use desktop notifications. They don’t grab my attention quite as well as audio usually does, but are better than nothing.

For this, Bash comes with the alert alias defined like so:

notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$(history|tail -n1|sed -e 's/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//')"

Let’s unpack this:

• notify-send is a neat little program that can send desktop notifications from the command line.
• --urgency=low means exactly what it says, but as for what it does, that can vary depending on the notification server and desktop environment. The options are documented in the desktop notification sepc. In practice it probably will result in the notification not appearing over full-screened content, and it’ll probably be shown after any higher urgency notifications in the queue, if there are any. If a notification cannot be shown immediately, it is not lost - rather it’ll either appear later, or will be minimized to a notification tray.
• -i "$([ $? = 0 ] && echo terminal || echo error)" sets the icon used in the notification to a terminal icon if the previous command succeeded (i.e. returned an exit code of 0), or an error icon (a red circle with a white horizontal line in it for me) if the previous command failed (i.e. returned a non-zero exit code). This is done just like how the beep alias chooses which tone to play depending on the exit code of the previous command, which was explained above.
• "$(history|tail -n1|sed -e 's/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//')" forms the title and body of the notification:
  • history|tail -n1 gets the last command run, which will probably be of the form <command>; alert.
  • sed -e 's/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//' the text of the last command run is piped into sed:
    • s/^\s*[0-9]\+\s*// removes all whitespace from the front and back, and all digits from the front
    • s/[;&|]\s*alert$//'\' removes any ;, &, or | characters from the front, and any whitespace from the back, as well as the word alert.

With this, we can use it in much the same way as beep:

true; alert

false; alert

We can also include a custom message:

true; alert '`true` exited with exit code 1, unsurprisingly'

Concerns About Long-Running Commands #

It’s all well and good that we can alert ourselves with these methods that a long-running command has terminated, but there’s something to be said for switching tasks while a command runs. It’s well known that we humans are rubbish at switching tasks - especially mentally demanding ones. When a command takes a very long time to run, this isn’t much of a problem, as you can fully switch away from your task involving the command to immerse yourself in something else. It becomes more of an issue when a command takes long enough that just waiting for it to finish while doing nothing else is unpleasant, i.e. long enough to warrant using one of the methods discussed here to alert yourself that it’s done so that you can do something else. You don’t have enough time with these commands to fully switch over to another demanding task, and what’s worse, by switching away from the mental state you were in when you issued the command you’ll have a hard time coming back to it. There have been many times where I’ve had to wait for around 3-10 minutes for some command (.e.g a compilation command) to complete, then switch back to a mental state suitable to work on whatever I was working on before, then run the command again. Repeat all day long. It’s exhausting, and difficult to get much good work done like this.

I find that listening to music can help make sitting through the long-running commands easier. By intentionally not engaging in anything else, and keeping my mind from wandering to other topics, I can re-engage with the task at hand much more quickly after the command terminates. What kind of music you use matters, as music does impose a cognitive load. I find that lyricless music has a lesser cognitive load than music with lyrics in a language that I do not understand, and music with lyrics in a language that I do not understand has a lesser cognitive load than music with lyrics in a language I do understand.

An excellent option for maximizing productivity and mental wellbeing is to meditate while the command runs. I do this sometimes, but have trouble bringing myself to do it regularly, even though I’ve observed it’s great at keeping my mind prepared to get back to the task I was just working on, and results in other benefits.

If you are going to do something else with the time taken by the long-running command, try to do something that isn’t very mentally demanding or stimulating - or at least uses different parts of the brain. Exercise is a good option, as well as certain monotonous chores, such as washing dishes.

Whatever you do, try to avoid sites like Reddit, Hacker News, Twitter, and anything else that can effectively grab your attention. Phones can be pretty bad about this too, as can message boards, chatrooms, and chatting with friends in-person. Reflect on what has a tendency to grab and hold onto your attention, and then try to avoid all of those things if you want to stay on-task through a long-running command.