Today I’m announcing pwait, a little program I wrote to wait for another program to finish and return its exit code. Download it from Github and read on…

Why pwait?

Because I was procrastinating one day and felt like doing some systems programming.

Seriously though. Sometimes you need to run one program after another one finishes. For example, you might be running a calculation and then you need to run the data analysis script afterwards, but only if the calculation finished successfully. The easy way to do this is

run_calculation && analyze_data

(sorry to readers who don’t know UNIX shell syntax, but then again the program I’m introducing is useless to you anyway).

Which is fine if you plan for this before you run the calculation in the first place, but sometimes you already started the calculation, and it’s been running for 3 hours and you don’t want to stop it and lose all that progress. The easy way to do this is to hit Ctrl+Z (or some equivalent; it depends on your terminal) to suspend the calculation, and then run

fg && analyze_data

which will resume it and run the analysis script afterwards.

Which is …

While I was writing my last Mythbusters blog post, I realized that it’d be really useful to have a “quick and dirty” plotting program — one that just takes the output of another program and plots it, no questions asked. Actually, let me rephrase that: I knew it would be useful, it just never occurred to me that I don’t have one. Most of the common plotting programs people tend to use, like GNUplot, expect to be configured with the format and syntax and display options and all that junk that you don’t really care about when you just want to turn numbers into a picture.

If you have GNUplot installed, here’s a little script to do just that:

#!/bin/bash

using=""

shopt -s extglob
if [[ "$1" == +([[:digit:]])*(,+([[:digit:]])) ]]; then
        using="using ${1//,/:} "
        shift
fi
shopt -u extglob

plotopts=""

if [[ "$*" == *title* ]]; then
        next_is_title=""
        for word; do
                if [[ -n "$next_is_title" ]]; then
                        plotopts="$plotopts title '$word'"
                        next_is_title=""
                        continue
                fi
                if [[ "$word" == "title" ]]; then
                        next_is_title="1"
                else
                        plotopts="$plotopts $word"
                fi
        done
else
        plotopts="$* title 'STDIN'"
fi

gnuplot -p -e "plot '-' ${using}${plotopts}"

Save it as plot, make it executable, and put it in your $PATH, and then you can …

Bash, the shell commonly found on modern Linux systems, has a well-deserved reputation for being a tremendously complicated piece of software. The man page is more than three thousand lines long — what for most other programs would be the “pocket reference manual” is in this case more like a hundred-page book! But it’s everywhere, so if you want to do shell scripting, you have to know Bash. (To be fair, other shells can be even weirder) I’ve been working with this shell for a long time, and over the years I’ve come to terms with most of its wacky features: parameter expansion, quoting, variable substitution, job control, arrays, here strings, arithmetic evaluation, signal handling, and more. But I have never been able to understand I/O redirection.

Until now.

Now, I’m not talking about the basics. Of course I knew how to use the simple examples; for instance, I learned early on that

command >output.txt >errput.txt

means that anything the command prints to its standard output stream winds up in output.txt and anything it prints to its standard error winds up in errput.txt. I know that you can “merge” standard output and …

Since the beginning of version control, people have been using VCSs to manage websites. It works pretty well, because the process of web development is similar to the process of programming. Heck, with the advent of dynamic websites these days, often half of web development is programming. But web developers have one peculiar requirement that most other programmers do not: they have to maintain one particular copy of the site which gets continuously updated, but not always with the latest changes.

Typically, when you set up a version control system to handle your website, it works like this: you have a working copy on your computer, a repository on your server, and another “live” working copy on the web server which is the actual website content. Whenever you want to update the website, you push (or commit) changes from your computer to the repository, and have a hook script set up that makes the VCS update the live working copy with the latest changes. That’s the approach I found described in a couple of websites: http://danielmiessler.com/blog/using-git-to-maintain-your-website and http://toroid.org/ams/git-website-howto.

But once your site turns into a moderately complicated system, this doesn’t …