I've written before (a long time before) that scripting something captures knowledge about how to do it, but recently I had a nice example of another advantage of turning things into scripts, which is that scripting things can encourage you to improve what you're doing.

We've recently started using Dovecot statistics to hunt for causes of IMAP slowness, including people who are still part of our backwards compatibility issue and would benefit from being migrated to our new way of dealing with this, both because their clients would often work much faster and because it helps the overall IMAP server. I wrote an initial script to post-process the raw Dovecot stats to produce some pretty general output and then found myself repeatedly running it by hand with a somewhat intricate command line that post-processed its output a bit to cut things down to what I really cared about, such as IMAP LIST commands with wildcards. Eventually I figured that I was running this command line often enough that I should turn it into a little script of its own.

The very first version of this script was just what I'd been running on the command line, but I'd hardly saved my editor buffer before I was adding small improvements; I switched to dynamically generating some data that had been stashed in a file before, and I filtered out a couple more things that weren't interesting to me. I could have done all of these in the command line version, but it would have pushed the command line well over the edge of complexity that I want to write (and re-write) by hand, at least these days (I once was more energetic here).

I think that there are at least two reasons why turning my command line into a script encouraged me to improve it. The first is that it was much easier to reuse my improvements because they're automatically permanent. An improved command line is an ephemeral thing (especially for me, as I don't keep command history across sessions); embodied in a script, it's forever. The second is that it's simply easier to do things in a script. A command line is edited on the fly and either is crammed all into one giant line or generally gives you relatively little or no ability to go back to improve a previous line. A shell script is editing in the editor of your choice, and you have the full power of the editor to move around, reconsider things, split things up into much more readable multi-line constructs, and so on. As part of this, it's simply far easier and more feasible to use more complex structures in a script than on the command line, things like case in the Bourne shell.

(I could in theory write a Bourne shell case as part of a command line, but in practice the idea is laughable. I'll use a case in even a small shell script without thinking twice about it.)

What this experience suggests to me is that I should consider being more aggressive about turning frequent command line things into scripts. Perhaps I don't want to have them on my $PATH, because it could get very cluttered that way, but I can at least make a habit of stashing them in a directory somewhere.