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:
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:
say “Greetings, Professor Falken.”
delay 1
say “How about a nice game of chess?”
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:
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.
Note: When you purchase something after clicking links in our articles, we may earn a small commission. Read our affiliate link policy for more details.