The problem#

When writing a shell script that starts background jobs, sometimes running those jobs past the lifetime of the script doesn't make sense. (Of course, sometimes background jobs really should keeping going after the script completes, but that's not the case this post is concerned with.) In the case that either the background jobs are used to do some background computation relevant to the script or the script can conceptually be thought of as a collection of processes, it makes sense for killing the script to also kill any background jobs it started.

The solution#

At the start of the script, add

cleanup() {
    # kill all processes whose parent is this process
    pkill -P $$
}

for sig in INT QUIT HUP TERM; do
  trap "
    cleanup
    trap - $sig EXIT
    kill -s $sig "'"$$"' "$sig"
done
trap cleanup EXIT

If you really want to kill only jobs and not all child processes, use the kill_child_jobs() function from all.sh or look at the other versions in the kill-child-jobs repository.

The details#

The problem#

My existing script for publishing my blog has Pelican run on the web server and generate the static site directly into the directory served by nginx. This has the effect that while the blog is being published, it is inaccessible or some of the pages or styles are missing. The publish takes well under a minute, so this isn't a big issue, but there's no reason for any downtime at all.

The solution#

Instead of serving the output/ directory, instead generate it and then copy it over by changing the make publish line in schedule_publish.sh to the following:

make publish || exit 1
if [ -L output_dir ]
then
    cp -r output output_dir/
    rm -rf output_dir/html.old
    mv output_dir/html output_dir/html.old
    mv output_dir/output output_dir/html
fi

where output_dir/ is a symbolic link to the parent of the directory actually being served and html/ is the directory actually being served (which output/ previously was a symbolic link to).

The details#

The problem#

My system for automatically posting future-dated blog posts mysteriously stopped working recently. The posts would appear if I manually published the blog, but not with the automatic scheduling mechanism.

The solution#

In schedule_publish.sh, I changed the line

echo "$0" | at -q g $time

to

if [ "$(date -d "$time PST" +'%s')" -ge "$now" ]
then
    echo "$0" | at -q g -t "$(date +'%Y%m%d%H%M' -d "$time PST")"
fi

(where "PST" is the timezone of this blog; adjust as appropriate for your blog). $now is initialized with

now="$(date +'%s')"

before the call to make publish to avoid a race condition.

The details#

Too many input devices#

On a modern computer there are often many input devices,

$ ls /dev/input/event* | wc -l
28

They are just identified by numbers, so it can be difficult to choose the right one and trial-and-error can get tiresome with so many. There is some help from the by-id and by-path listings:

$ ls -go --time-style=+ /dev/input/by-id/
...
lrwxrwxrwx 1 10  usb-045e_0291-if06-event-joystick -> ../event26
lrwxrwxrwx 1  6  usb-045e_0291-if06-joystick -> ../js6
lrwxrwxrwx 1 10  usb-0b43_0003-event-if00 -> ../event20
lrwxrwxrwx 1 10  usb-0b43_0003-event-joystick -> ../event19
lrwxrwxrwx 1  6  usb-0b43_0003-joystick -> ../js1
lrwxrwxrwx 1  9  usb-BTC_USB_Multimedia_Keyboard-event-if01 -> ../event2
lrwxrwxrwx 1  9  usb-BTC_USB_Multimedia_Keyboard-event-kbd -> ../event1
...

$ ls -go --time-style=+ /dev/input/by-path/
...
lrwxrwxrwx 1  9  pci-0000:00:1a.2-usb-0:2:1.0-event-kbd -> ../event1
lrwxrwxrwx 1  9  pci-0000:00:1a.2-usb-0:2:1.1-event -> ../event2
...
lrwxrwxrwx 1 10  pci-0000:00:1d.0-usb-0:1:1.6-event-joystick -> ../event26
lrwxrwxrwx 1  6  pci-0000:00:1d.0-usb-0:1:1.6-joystick -> ../js6
lrwxrwxrwx 1 10  pci-0000:00:1d.0-usb-0:2:1.0-event -> ../event20
lrwxrwxrwx 1 10  pci-0000:00:1d.0-usb-0:2:1.0-event-joystick -> ../event19
...

But, for the most part, those names aren't very helpful, especially since many joystick devices support 2 or 4 joysticks connected to the same device.

identify_evdev.py#

Enter identify_evdev.py:

$ identify_evdev.py
/dev/input/event22

Where /dev/input/event22 is the device of the joystick I touched after running identify_evdev.py.

Dice in shell#

Today I was borrowing a board game from the lending library at Emerald City Comicon and it was missing its dice. We could have gotten some physical dice somewhere, but instead we decided to use the materials we had on hand. The people I was playing with agreed that we did not want to drain our phone batteries by using a dice app on our phones, but I had a laptop with me. So I wrote a dice app for the shell:

while true
do
    reset
    seq 1 6 | shuf -n1
    seq 1 6 | shuf -n1
    read
done

This rolls two six-sided dice every time you hit enter and clears the screen before showing the result using reset.

X clipboard#

The X Window System, the basis for the GUI on most desktop Linux systems, defines how the clipboard works for copying and pasting between applications in Linux. One notable quark of X clipboard is that there's actually two clipboards in common use: the one you expect explicitly accessed via Copy and Paste menu items or key shortcuts called the CLIPBOARD and another one where you copy by selecting text and paste by pressing the middle mouse button called the PRIMARY selection.

X clipboard utilities#

Occasionally it is useful to be able to read or write the clipboard at the command-line. For most uses, your terminal emulator's copy and paste options are probably enough. The primary use case I have for using a command-line program to interact with the clipboard is when I am uploading a file as a Gist:

<file xclip

The xclip utility will copy the contents of the file onto the clipboard (PRIMARY, not CLIPBOARD, by default) and then I can paste it on the Gist website.

My system also has xsel which is very similar to xclip. Wikipedia actually lists several such programs, including the unfortunately named xcopy, not to be confused with XCOPY.

GNU Screen copy mode#

GNU Screen provides its own clipboard for copying information between the different windows of a screen session. ctrl+a, [ enters copy mode. In copy mode you can move the cursor using the arrow keys and page up/page down keys. Screen keeps a history (of configurable size), so you can scroll back pretty far. In fact, I use Screen's copy mode far more often for viewing the history in a terminal than for actually copying anything. You can exit copy mode either by using esc to cancel or enter once to mark the start of the selection and again to mark the end of it. Once you have copied something, ctrl+a, ] pastes the contents of the clipboard.

The problem#

$ ls > file

doesn't do what you expect:

$ touch foo
$ touch bar
$ ls > filelist
$ cat filelist
bar
filelist
foo

You probably didn't expect, or want, filelist to be listed in filelist.

The solution#

$ filelist=$(ls); echo "$filelist" >filelist

The goal#

Given a series of images, present them in a video with a blend effect between the images. The frames between the input frames should gradually transition between the previous and next image. This, and other transition effects, could likely be implemented using a slideshow generator, but it can also be done quite easily using a shell script.

The script#

The final script I wrote is blend.sh. The following commands fetch and run it:

$ wget https://gist.githubusercontent.com/dperelman/2b4b86233aa13d13c0ab/raw/91c7988e27288af8aeb25ade11d0cab90355702f/blend.sh
$ chmod +x blend.sh
$ ./blend.sh slideshow.mkv first.png second.jpg third.gif
$ mplayer slideshow.mkv

The input images may be in any format. The extension of slideshow.mkv will be used by FFmpeg to guess the desired video format (H.264 in a Matroska Multimedia Container for .mkv).

The problem#

While trying to develop a modification to the Pelican source, I was unexpectedly having my installed version of Pelican get run instead of the local version:

$ which pelican
/usr/local/bin/pelican
$ command -v pelican
/usr/bin/pelican

For some reason, which was pointing to the executable I was expecting bash to run, but the Bash builtin command was telling me that bash was running the installed version instead.

The solution#

Use the hash builtin to clear bash's cache of the location of pelican:

$ hash -d pelican
$ command -v pelican
/usr/local/bin/pelican

The problem#

If you take the word wizard, reverse the order of the letters and reverse the alphabet:

From: abcdefghijklmnopqrstuvwxyz
To:   ZYXWVUTSRQPONMLKJIHGFEDCBA

then you get the word wizard back, an observation made at least as early as 1972.

Now let's write a shell script to verify this so we can find other words with similar interesting properties. The obvious shell script to verify this

echo wizard | tr a-z z-a | rev

unfortunately fails with the error

tr: range-endpoints of 'z-a' are in reverse collating sequence order

The error is by design: it's not clear what a sequence in reverse order should mean, so POSIX actually requires that it not work.