Instant Scripting

February 16th, 2006  |  Published in old and busted

I really dig Automator , but it tells me something when its “Run Applescript” and “Run shell script” functionality are on the list of my top five favorite things about it.

The problem boils down to Automator being a workflow tool and not a programming tool. In other words, if you tend to do the same thing over and over and over, and it’s a very linear process, then Automator will probably be great. Applying specific transformations to specific files (like downsampling JPEGS and uploading them to flickr or importing them to iPhoto), or mass-renaming files, or doing some big file-object-level operation are all great for Automator.

What it can’t do is store a variable or flow control. If you want that stuff, then you’ll be reaching for the “Run Applescript” action and coding up a quick something and passing the results of that lump of code off to the next step in the workflow, with all the attendant hassles of figuring out how to hook up the input and output correctly.

The past few days have been an interesting exercise in learning when Automator is a good tool, and when Automator is going to force me to write so much Applescript to make up for its shortcomings that I might as well just put up with doing the whole thing in Applescript.

Some recent projects that taught me this:

  • Compose my weekly edit plan from an OmniOutliner document, save one copy in a date-labeled VoodooPad page and open another in e-mail for mailing off to my boss. It’s taken a 30 minute exercise in cutting, pasting and assembling stuff from several sources and turned it into a two second “open file, click button” procedure. If I take a minute a day to maintain the source document with all the information the edit plan needs, I get back 25 with this script. Perfect for AppleScript, but Automator couldn’t come close to doing this: No looping, no variables.

  • Extract the stats for my sites from a daily mailing of company-wide site statistics and paste the results into a VoodooPad page. This is done as a mail filter, so I don’t have to actively maintain it at all. When the mail arrives, the script fires as a filter action, writes the data then closes down. I started out with Automator on this one, but ended up writing two huge hunks of Applescript to make part of it happen. At that point I decided to just do what I wanted in Applescript and cut down on the number of moving parts.

  • Generate standard invoices for my authors and create mail messages with the information. Automator came close, but once again no variables, so no way to tell it how to get at saved chunks of author data needed to fill out a specific invoice.

  • Get the current page I’m looking at, download it, run it through a filter to remove the extraneous junk I don’t need in it, change some specific links to point from one site to another, then add an “article courtesy of {site I snarfed this article from}” tag to the end of the new file. Good for Automator. Turns the process of repurposing a story into a 15 second pause after clicking a button.

  • Send a “ping -o” (ping until comeback) to my hibernating Windows machine, wait for the ping to return, open the Apple Remote Desktop Client file for my Windows machine and log in from the iMac.

The last task is perfect for Automator. The two problems associated with using the RDC client are a.) turning on the Windows machine (it’s in a closet, not under my desk, to cut noise) and b.) knowing when the machine is awake enough to accept an RDC login. If I try to launch RDC too soon, it times out.

So to get the Windows machine to turn on without touching it, I have it set to Wake on LAN. Since a ping counts as a LAN activity, simply sending a ping -o to the Windows machine is enough to both wake it up and continue pinging it until it sends a ping back, at which point it’s either awake enough to take an RDC login, or will be soon enough to keep RDC from timing out.

The workflow in Automator is dead simple:

There’s a tiny bit of shell script: “ping -o”:

ping from Automator

Then a simple Finder operation to open the file for my RDC configuration, which is set to auto-launch:

Open an RDC file in Automator

I saved the workflow as a standard application, copied the RDC icon, then stuck it in my dock.

Windows RDC in the DockIt’s pleasing for the simple reason that it takes a stupid little task that involved getting up, opening a door, pressing a button, sitting back down, waiting until I guessed enough time had passed, opening a file and launching a program. Now it’s just “click a button, wait for Windows to launch.” Once I exit RDC, the Windows machine idles for five minutes, then it hibernates until pinged again. With the new iMac, that means there’s no noise in the office except my typing, the hard drive, and whatever’s on iTunes.

One other gripe about Automator. Any workflow over four or five actions, and Automator eventually grinds to a halt. You’ll wait 15 or 20 seconds to drag a new action into a workflow, and just as long if not longer for some buttons to respond after a 30 minute session in the Automator composer. That’s not a problem with workflow execution, mind, but composition. It can get frustrating when you’re doing a lot of trial and error.

Leave a Response

© Michael Hall, licensed under a Creative Commons Attribution-ShareAlike 3.0 United States license.