1. 2014

    Introducing pwait

    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 …

  2. 2013

    Quick plotting

    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:

    shopt -s extglob
    if [[ "$1" == +([[:digit:]])*(,+([[:digit:]])) ]]; then
            using="using ${1//,/:} "
    shopt -u extglob
    if [[ "$*" == *title* ]]; then
            for word; do
                    if [[ -n "$next_is_title" ]]; then
                            plotopts="$plotopts title '$word'"
                    if [[ "$word" == "title" ]]; then
                            plotopts="$plotopts $word"
            plotopts="$* title 'STDIN'"
    gnuplot -p -e "plot '-' ${using}${plotopts}"

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

  3. 2011

    I/O redirection in bash

    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 …

  4. 2010

    Website maintenance with git, the pro way

    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 …