1. 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 …

  2. 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 …