Using Tiger: Learning AppleScript

Automator truly is one of the most salivationary features of Tiger and proof positive that God loves us (if you believe in God) or we’re doing just fine without a Supreme Being around calling the shots, thank you very much (if you don’t believe in God).

Still, Automator has limitations. It’s marvelously well-suited for automating processes that are linear… ones that can be easily broken down into a list of predictable steps. The point where Automator falls down is when you throw it a problem that requires it to do some actual thinking . “If the file is smaller than 500K, I want you to e-mail it to my editor; if it’s larger, then upload it to my personal FTP server and send him an e-mail with instructions on how to download it.” You just can’t do that with Automator.

You also can’t do anything that requires the use of variables. Anyone who’s taken an introductory programming course knows what a variable is. Imagine that I’ve got an Automator workflow that’s 20 or 30 steps long. There are plenty of workflows in which it’d be helpful to say “OK: you remember 20 steps ago, way back in Step Three, when I told you to get a list of all of the pictures on the Astronomy Picture of the Day Web site? Here’s something else I want you to do with that same list:” But that’s way beyond Automator’s puny intellect. You can work around that limitation sometimes; in the preceding example, I could just tell Automator to go visit the Web site and build that list all over again.

But there are times when only a “real” programming language will do. And AppleScript is indeed a real language. It’s a really simple language, that’s really easy to learn and really tolerant of little mistakes. But it’s also one that has nearly every feature that a developer would wish for, short of the sort of tools you’d need to write a new challenger to Microsoft Office.

The bottom-line advice is to use Automator until you find yourself spending more time working around its limitations than taking advantage of its features. And that’s when you should start learning AppleScript.

Creating your own scripts

Nearly every app supports at least four basic AppleScript commands:

Run. Launches the app.

Open. Opens an item, typically a document file.

Print. Prints an item, again, typically a document.

Quit. Fold. Pack it in. Give up hope. Take your ball and go home. You know…Quit.

Anything above and beyond that is up to the ambition and commitment of the developer. It’s a crapshoot of delight and disappointment. It’s the good apps that keep you committed to AppleScript. Some apps are so script-happy that it almost seems like a waste to work with the user interface at all.

Script Editor

The Script Editor, with a simple script up on the lift so we can finally do something about those brake pads.

Script Editor is the app you use to record scripts, edit existing ones, write brand-new scripts of your own, and crack open your applications to see just how scriptable they are. You find it inside your AppleScript folder, which awaits you inside Applications. The figure on the right shows you a typical script-editing window. This is Script Editor’s entire interface, or near enough. Apart from Saves, Opens, and Prints, you never touch the menu bar at all. Here, give it a shot:

Create a new script by pressing Command-N. Alternatively, you can click File: New.

Type the following code into the editing window:
say “Greetings, Professor Falken.”
delay 1
say “How about a nice game of chess?”

Click the Run button.

There you go; you’re now a programmer. I bet your skin’s half a shade paler already.

If you were watching the window carefully when you clicked Run, you noticed that the Stop button enabled itself while your script was running. Clicking that sucker terminates the script in mid-run—a very useful feature when the script that you thought you told to automatically assemble a report on the status of the network actually winds up taking a folder full of boudoir photos that you posed for at the mall and e-mails them to everyone in your 1,100-person Address Book.

As you start to work with longer and more complicated scripts, you’ll probably start making regular use of the Compile button. Essentially, it double-checks your spelling and grammar. If something you’ve typed doesn’t make sense as AppleScript, it flags it for you and does its best to explain what the problem is. If everything’s flawless, it reformats the script with fancy nested indents and type styles to make it more readable.

Underneath the code section of the window exists a little pane of information. It can display three different things, depending on which of those three tabs underneath it has been clicked:

Description. It’s a good idea to describe your script and what it does. You’re going to start writing a lot of scripts (No, really, I’ve paid a large man $30 to come over to your house and beat the snot out of you if you don’t. So, I mean, time’s a-wasting), and without attaching notes to these things, it becomes really easy to forget why you bothered to write this particular script in the first place.

Result. That’s a debugging tool. When a script runs to the very end, the results of the last operation it performed are displayed in the Result tab.

Event Log. An even more sophisticated debugging resource. At the root of a gas engine is combustion. At the root of national-level politics are unresolved childhood inadequacy issues. And at the root of all Mac software are events. These are the molecules of what goes on behind the scenes—the actual activities that software has to carry out to make things happen. Script Editor can maintain an Event Log that keeps track of everything your script did during execution and what the immediate result was, step by step by step.

There’s a second set of resources for examining results and events: the Result Log and Event Log windows, which you can open from Script Editor’s Windows menu. They’re both frightfully useful; when a script fails to work the way you thought it did, they can act like the “black box” that gets pulled from the wreckage of a crashed airplane. They give you a detailed history of everything that your script did and what those intermediate results were, step by step along the way. By examining these logs, it’s easy to discover precisely which line of code caused One plus One to equal Twelve, and then make the necessary fixes.

Ah, yes, we seem to have overlooked the Record button. Well, let’s just clear that out of the way so we can move on.

Recording scripts

Like I said earlier, recording scripts can be a hit-or-miss proposition. There’s no way to tell whether or not an app is recordable—or exactly how useful its recording features are—until you give it a whirl. Let’s toss in a ringer for our example: the Finder. It’s eminently recordable and, as an environment for mind-numbing, repetitious behavior, it gives secondary education a real run for its money. I often organize my windows in a specific way that lets me reorganize my hard drive’s clutter quickly. Regardez-vous the screenshot below.

It’s a master column view of the whole hard drive up top, and three windows of subfolders arranged on the bottom. But it’s a pain to create and arrange these windows manually, so, on the next page, I’m going to record a script that does it for me.