Slashdot Mirror
Beginning AppleScript
AppleScript mimics the syntax of English. As such, its grammar by intent should be easy for English speakers to grasp, which results in an intuitive and simple to use scripting language. However, this doesn't undermine its role as a very powerful tool for automation.
There are very few books on AppleScript, and certainly not many current volumes outside of Matt Neuburg's excellent AppleScript: The Definitive Guide (O'Reilly) for the intermediate-to-advanced scripter, and Hanaan Rosenthal's reference-type manual, Applescript: A Comprehensive Guide to Scripting and Automation on Mac OS X (Friends of Ed). But Neuburg's book is intended for the intermediate to advanced reader while Rosenthal's book is a bit extensive to be called a primer. Hence, there are few worthy contributions for the beginner. Goldstein's Missing Manual fills this gap with coverage of the current Mac OS 10.3 (Panther) release of AppleScript, including multimedia support, GUI scripting and AppleScript Studio. While the book is intended for the beginner and intermediate user, power-hounds will also find many tricks, tips and hidden tools.
The book is divided into four parts: "AppleScript Overview," "Everyday Scripting Tasks," "Power-User Features," and "Appendixes." Part One begins with the usual suspects: where to find the AppleScript folder in Mac OS X, and how to enable the script menu (and how to take advantage of the surprising number of useful scripts you'll find there). In just a few pages, Goldstein hands the reader a collection of valuable scripts that were hiding in OS X Panther all along (I particularly like the "ransom note" script). Chapter 2 introduces the Script Editor application and provides a comprehensive description of Script Editor properties, tools and preferences. After setting up the work environment and introducing the AppleScript tools to the reader, Goldstein begins hands-on scripting in Chapter 3: displaying dialog boxes, commands, commanding other programs, using tell statements and how to find and use the command dictionaries specific to the Finder and other scriptable applications. This author avoids the pitfall of overwhelming the reader with too much information, too many new concepts, and too many abstruse examples.
Part Two is the core of the book, and covers "Everyday Scripting Tasks." The seven chapters in this section run the gamut of increasing difficulty: manipulating text, controlling files, creating lists, organizing and editing graphics, playing sound and video, internet and network scripting, and organizing information in databases. The author quickly takes the reader through a series of simple scripts designed to illustrate AppleScript syntax. Chapter 4 covers variables, strings, dialog boxes, scripting applications and running scripts from text. Goldstein scripts TextEdit, the built-in Mac OS X word processor, by adding code to automatically add new text to a document, adding formatting and adding a word count. He then adapts this exercise to scripting Microsoft Word, which contains far more robust AppleScript support. The contrast is a good example of the range of AppleScript support between applications; some programs aren't AppleScriptable at all, while others offer varying degrees of support.
Chapter 5 includes a primer on file paths as an introduction to folder and file scripting (displaying and opening folders; moving, backing up, deleting and saving files). There are quite a few exercises here that train the reader in using the dictionary and becoming more adept with the AppleScript syntax.
Creating and manipulating lists is the subject of Chapter 6. It covers lists: nested lists, list commands and various ways of displaying lists. Goldstein creates a UNIX top-like/Activity Monitor AppleScript to display a simple list of running programs. This exercise leads into list processing and batch renaming which is the type of automation AppleScript excels at. Other list examples include joining, merging, inputting, and getting lists from other programs (TextEdit and MS Word are again the apps of choice). Lists are ubiquitous, and we spend an enormous amount of time organizing and sorting through them. Goldstein shows the reader how well AppleScript is suited to the task of manipulating lists quickly and efficiently.
The author moves on to another core application of AppleScript in Chapter 7: organizing and editing graphics. Graphics applications are highly scriptable, and Goldstein illustrates this with tutorials using iPhoto and Photoshop: creating new iPhoto albums, showing slideshows, color-correcting images automatically, filtering images, getting image dimensions and creating droplets. One of the most practical uses of AppleScript in this category is batch conversion of images from one format to another using Image Events. (You don't have to be a graphics professional to see how often anyone with a digital camera would make use of this script.)
Scripting sound and video apps is discussed in Chapter 8: manipulating tracks, converting song files, making your Mac speak to you and listen to you, showing full-screen QuickTime movies, rotating movies and embedding movies within scripts. For those with DVD-drive equipped Mac, Goldstein also unveils the AppleScript menu within the DVD Player app. For so many people who rely in iTunes to catalog their extensive music collection, there are very good scripts here for streamlining playing tracks, creating song ratings and performing song file conversions. The best video tip is using AppleScript to enable full-screen video within QuickTime Player, a feature normally available only if you upgrade to the Pro version.
Chapter 9, "Internet and Network Scripting," is chock-full of fun and useful scripts for Internet Connect, Safari, Address Book, Mail, iChat and Keychain. Goldstein shows the reader how to automate dial up an ISP, show Airport signal-strength fluctuations, view Web page source code, run AppleScripts from a Web page using Safari Services, use AppleScripts right in the Safari address bar, save scripts in the favorites bar, find contacts in Address Book, check for new and unread messages in Mail, create iChat controls, download and upload files, and recall passwords. The Power Users' Clinic aside is particularly interesting as it deals with using AppleScript to interact with Web Services using call soap or call xmlrpc. Goldstein provides resources and references for pursuing this advanced topic.
The final chapter in Part Two involves database scripting, including creating simple AppleScript databases and scripting FileMaker Pro databases using AppleScript to enter and sort data. Goldstein includes a nice FAQ on FileMaker's built-in ScriptMaker option.
Once the reader whips through the example scripts in Parts One and Two, it's time to get down and geeky. Part Three, titled "Power-User Features", is the section of the book for geeks and wanna-be geeks. Goldstein shoves enough advanced techniques in five chapters to make these alone worth the price of the book. Chapter 11 introduces folder actions to the AppleScript repertoire of advanced features. The reader learns how to enable folder actions, attach built-in folder actions to specific folders, view and edit these built-in folder actions and run his or her own actions. Folder actions always bring to mind Sal Soghoian's (AppleScript Product Manager and Evangelist) lectures on AppleScript and some tricks to play on unsuspecting co-workers with folder actions. For example, a clueless user double-clicks a folder to open it and it opens and immediately closes ... If you're an IT manager, sometimes you just need to break up the monotony once in a while!
Dictionaries are revisited in Chapter 12 and the author addresses the unfortunate situation when an app doesn't have a dictionary, or has such a limited dictionary that it's effectively useless. Goldstein explains how to control these programs with Mac OS X's GUI Scripting feature, System Events (to automate the clicking of buttons or typing of keys instead of using commands) and Apple's UIElementInspector to discover an object's hierarchy (a download available from http://www.apple.com/applescript/uiscripting).
My favorite chapter in this section is Chapter 13, "Mixing AppleScript and Unix." Goldstein gives a quick terminal lesson followed by a neat trick to display the Expose button ("the blob"). Other helpful actions: use do shell script to run Unix programs straight from AppleScript, run shell scripts with admin privileges, run AppleScripts from Unix thus saving time by bypassing the Script Editor and schedule commands (use an AppleScript to run cron every day, use iCal to schedule scripts). Even users who normally shy away from the terminal will want to try some of these.
Chapter 14 is titled "Testing and Debugging Scripts," and offers some advice and tools to handle errors that show up when you compile a script. Goldstein offers a handy table of common compiler errors and likely causes, error handling tricks (using a display dialog command and the log command) and tips on avoiding typical scripting errors like infinite loops, coercions and nonexistent items.
The author closes this chapter with a brief introduction to Xcode: how to download it, install it and use it to debug your scripts. Xcode is a much more powerful tool than Script Editor and therefore has better features and options for debugging. The reader should probably choose to revisit this section after the chapter that follows, on AppleScript Studio, where Xcode is handled with a bit more depth.
The final chapter in the book is "AppleScript Studio," where Goldstein creates a simple "SpeakToMe" project that contains a dialog box for typing in text, a pop-menu menu with Mac OS X system voices and a button labeled "Speak." This chapter is a very brief nod to AppleScript Studio (Xcode and Interface Builder) but gives the reader a taste for what application building with control over the GUI is all about. This is enough to pique the reader's interest and provides enough hands-on experience to engender confidence in using these tools.
Part Four contains the Appendix A through C: "AppleScript Support in Common Programs" (a very useful set of tables of applications, their level of AppleScript support, price and where to get them), "Moving from Hypercard to AppleScript" (options and advice for converting Hypercard stacks to AppleScript and major syntax differences between HyperTalk and AppleScript), and "Where to Go from Here" (AppleScript sources: Web sites, discussion lists and books).
The Missing Manual series uses a nice layout style with a "soft" look; the pages have black tabs on light gray margins that identify the chapter topic and dark gray sidebars. Screenshots are enhanced with a shadow effect that raise the graphic off the page in a visually appealing manner. The notes, tips and boxed asides (Gem In The Rough, Workaround Workshop, Power Users' Clinic, etc.) are relevant, concise and often contain an element of humor; they don't detract at all from the flow of reading the main text. Each chapter has a gentle reminder that example scripts can be found on the Examples CD disk image that can be downloaded from the Missing Manual web site (http://www.missingmanual.com). References to definitions, tips, hints and other topics are indicated with a page number, not the usual "somewhere in the depths of chapter x". The Web site for the Missing Manual series (http://www.missingmanual.com) contains a link to "Missing CD-ROMs" where readers can download free and shareware applications described in the book series. For this particular book, the author has made a disk image available containing all the sample scripts used in the text examples. Errata can be found at O'Reilly's site (http://www.oreilly.com/catalog/applescripttmm/ind ex.html).
This book is eminently satisfying on many levels: the writing style is conversational and humorous (I would imagine this is a pre-requisite for writing for David Pogue), the style of this book series is consistently pleasant to read and the level of technical difficulty satisfies the range of readers from beginner through power-user. The "valuable information:price" ratio is, hands-down, in the buyer's favor.
A final note about Adam Goldstein, the author of Applescript: The Missing Manual: he is the teenage founder of GoldfishSoft (http://www.goldfishsoft.com), a Mac OS X games and utilities software company (my 7 year-old son loves AlgeKalk and FrakKalk, geek that he is). By "teenage," I mean Adam Golstein is 17-ish. He began contributing to this Pogue/O'Reilly series several years ago by writing a few sections of Mac OS X Panther Edition: The Missing Manual (FileVault, journaling and Disk Restore). I suspect we'll be hearing a lot more from Mr. Goldstein, and I'm looking forward to it.
Mary Norbury-Glaser is an IT Director at a University of Colorado Health Sciences affiliate center in Denver. Working in a multi-platform academic environment dominated by Windows boxes, she sometimes feels like the Mac Maytag Lady. You can purchase Applescript: The Missing Manual from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Umm, did the submitter change his mind about which AppleScript book he was reviewing after typing in the title for his submission?
Don't blame me; I'm never given mod points.
Applescript is one of the best things that apple ever produced... its power and simplicity is only undermined by the near total lack of documentation.
I have always found it to be quite a shame that for all the effort apple is willing to put into applescript... that they have kept it from being as powerful a tool as it could be by keeping the learning curve so high for such an english like scripting language.
Of course by the look of Tiger and the inclusion of Automator (which looks like it might just be an easy to use shell on top of applescript) this book might not be as necessary in a few months... look forward to Automator: The Missing Manual.
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
Not being a Mac person myself (although I am eyeing the Mini as a starter) I ask:
are there AppleScript security vulnerabilites?
You can't talk about Wikipedia's flaws on Wikipedia
IS to use Applescripts embedded in a Cocoa program. I forget the exact syntax but it's similar to using the system() in a C program. It's also easy to make your program scriptable by making available certain variables and then allowing your Cocoa program to read in an Applescript and execute it on the variable(s)the scripter wants to manipulate.
I remember years back writing a simple Cocoa program that would automate things, stop and start programs, etc using nothing but Applescripts inside the program.
These are things you can do with typical ANSI C in your program to, forking off process', killing process', etc but it's a lot easier to have a script that says something like:
tell Application 'Finder' to quit PROGRAM
instead of checking if a program is running by asking the system, using a grep fork with a regex to see if it is running and then telling the system to quit it or start it if it isn't running, etc.
Hell, you could even make a variable PROGRAM and then have users simply enter the programs they want to start/stop and at what time and then have your program run via Applescript at the correct times to start/stop a program based on the string PROGRAM.
Personally I'd use cron, but hey, this is why we make nice little GUI programs for the other people.
"If you are a dreamer, a wisher, a liar, A hope-er, a pray-er, a magic bean buyer
AppleScript mimics the syntax of English. As such, its grammar by intent should be easy for English speakers to grasp
The key word here is should. How many English speakers truly understand the grammar and syntax rules of their own language, particularly the written version?
...I already have Ethan Wilde's "AppleScript for the Internet" and Matt Neuberg's "AppleScript: The Definitive Guide" (an O'Reilly, with a Boston Terrier on the cover). And a couple of Apple PDFs.
What we really need is a fully grown-up guide that is truly definitive, with proper descriptions of the never-quite-explained object model behind AppleScript that is rigorous and complete--and that includes the functionality provided in Apple-supplied AppleScript extensions and in the Finder.
I want something at an Inside Macintosh level, or a Harbison and Steele level; not a Danny Goodman level or even a man-page level.
Neuberg's book is the best I've seen so far. He makes the right promise, but doesn't quite deliver. It is all too obvious that he is charting his personal voyage of discovery.
I know I should not comment on Goldstein's book without at least having browsed through it in a bookstore, but it sounds as if it is just one of another AppleScript books that will be full of magic snippets I can use, never quite understanding why they work, or why they fail... exactly what all the quoting rules are... and so forth.
"How to Do Nothing," kids activities, back in print!
tell MaryNorburyGlaser set its gender to "male" end tell
I'm not a Troll, it's reverse psychology.
Having never owned a Mac, but I'd like to comment on the books, the "missing manuals", and the literature that you can find online.
Owning a detailed, well laid out reference manual to scripting, programming, your OS of choice, and other parts of your computer is always a handy thing, but why don't they ever publish manuals in a three or four ring binder, or unbound with the holes punched for readily inserting into a binder?
Not all aspects of computing change as rapidly as others. A manual explaining how a transistor works and how to build one would still be as valid today as it was when transistors were first created, even if only to the hobbiest electrician, but my two books on Debian GNU/Linux are now rather dated in areas.
What I'd like to see publishers do is provide people with the option to order "binder format" - "Would you like that in 3 or 4 ring? A4, Letter, or A5?" - editions of books, so that when the subject matter changed, the publisher could provide the updated chapter(s) all nicely prepared to simply insert in your binder, or you could even download/rewrite the chapters yourself.
It's not such a stretch to see that in this information age as much as we need readily upgradeable software and hardware, we should also have readily upgradeable manuals to go with it.
His name is Robert Paulsen...
AppleScript is poorly documented, incompletely implemented, and unevenly supported by developer tools. But even its basics are extremely powerful. Along with Apple's required "File" and "Edit" menus (and their command items) for all apps, is their corresponding AppleEvents, supported by a generic enough AppleScript interface that other languages can bind to them. So Apple apps have a reliable, even if often rudimentary, IPC mechanism. Even though Mac apps are known for their GUI, the AppleEvent interface means that they can be chained together as tools, with a wrapper, or just a network (or other IPC) API. Linux has some competing technologies, but it really could benefit from as simple, predictable and consistently available IPC interface as AppleEvents.
--
make install -not war
Cool, I'm sure your pals will all love a book about how to use features that don't exist.
But honestly, you never know how much you hate AppleScript until you learn it. The problem with English-language syntax is that good code will be unambiguous. Writing AppleScript is one of the single worst things you can imagine. Sometimes a `the' keyword is required; other times it is not. It can be utterly infuriating. Take it from someone who has written an AppleScript Studio application that was eventually successfully deployed ... it's not fun. I did the same thing in Cocoa in about 1/6 the time.
I never took Marketing in college, but I'm guessing a book titled Applescript: The Unnecessary Manual would sell even fewer copies.
It's obviously a pseudonym. Everyone knows there are no women on slashdot.
Don't blame me; I'm never given mod points.
Wrong. True, Apple has a smaller market share, but that's when you look at the whole computing market. In the home market (where Applescript was intended to be used, btw), the percentage of users is higher.
Most Mac users don't use AppleScript.
Wrong. Most Mac users don't program Applescript. There are lots of Applescripts out there that can be downloaded and used as-is. (Apple supplies a bunch of their own with the default OS X install.) I know lots of people who have used Applescript without knowing a thing about it. Also, Applescript was designed to be a programming language for non-programmers. I've known people who have figured out how to get things done with Applescripts without knowing much about how to use it. There isn't a huge learning curve involved for very basic stuff. In fact, there is a "record" button on the Applescript compiler interface that will write out a script from actions you're doing.
Also, you might want to check out the future of Applescripting which is going to make non-programmer usage a lot easier.
Most of those who use it don't really need a manual.
Wrong. Despite its power, Applescript is woefully underdocumented. This is because Applescript has been on the chopping block more than once. It was supposed to have been tossed out with the advent of OS X, but users (did you catch that? Users) were upset by this and Apple relented to complaints and put it back in.
There are two good manuals out there already anyway.
Hey, you got something right.
--Rick "If it isn't broken, take it apart and find out why."
Don't tell my boyfriend that.
Applescripts don't have any better access privledges than any other OS X program. In order to seriously damage the system, you need the admin password for access to system folders. Unix kids should note that this is OSX's policy of 'sudo everything:' let the user do as they please, but if they're going somewhere they might not want to, get passwordy real fast. Even the 'administrator' account is not truly an administrator (though he can do a lot more than a 'normal user'), the root account is actually disabled on OS X (though it can be re-enabled with little work). OS X Server, on the other hand, tries to log you in as root by default, taking the fair guess that it's dealing with someone significantly wiser with the system.
I have been writing some AppleScript, and it's definately one of the few "read only" languages out there. There are languages which are "read write", such as Java which are both easy to read and reasy to write. Then there are languages such as Perl (or why not TECO) which are "write only", i.e. very hard to read. However, as I mentioned, AppleScript is one of the very few "read only" languages.
There are quite horrible subtle details that you have to pay attention to. Things like wether your list of files is actually a list of files or a list of file names. The automatic conversion makes the difference irrelevant most of the time, except when things just break and you have no idea what you did wrong.
How about some examples. Here's the command to set the background colour of the topmost terminal window to green:
In comparison, the Java version of the above code would look something like this:The above assumes thatAppleScript is object oriented, and as you can see, the "of" keyword behaves like the "." operator in Java, except that the arguments are swapped. The "the" keyword is always ignored, and plural words are lists (for example, the "windows" member of the Terminal application class. "first window" (i.e. "first" followed by the singular form of the list member) returns the first element in that list. Simple, right?
It gets worse. Here's a line from a script I wrote (although I believe this particular line was copy-pasted from some others script). It sets a variable itunesRunning to true if iTunes is running:
I'll leave it as an excersice to the reader to figure out exactly why you have to write it like that.The problem is that you constantly have to look in the manual to figure out exactly how you are supposed to pass your command arguments. Suppose you have a command "send message" that sends a message to a user on IRC. Now, how do I figure out how to pass the user name and the message to send as arguments? Depending on the developer it might be:
Or, it could be:Don't take me wrong, I really like AppleScript. I just wished the syntax was better.I work as a production artist in a Flag shop and at a screenprinter and find applescript to save sometimes up to 100 mouseclicks in a single task.
I've got one script that iterates through an illustrator file and creates a list of spot colors that are used in a file. (illustrator 10/CS is fully scriptable... 9 might even be, too).
I wrote another script that exports my illustrator files to a jpeg, opens it in photoshop, crops it, resizes it, and emails it to my customer for a proof (we don't do pdf proofs since clients could use them for production).
Another script for when we outsource our files that dupes them, opens them, converts fonts to outlines, waits for me to doublecheck that everything's ok, then when I click OK, closes, and iterates through all the files. Then, when it's done, asks which company I'm sending to, figures out if the file is small enough to email, and if so, stuffs and emails the file to the correct email address with a list of included files, types, and sizes, or if too large to email, either stuffs and FTPs (using transmit) or launches toast, creates a new CD, and ejects the CD Tray waiting to burn.
I've also written several scripts for creating job folders and for general file management and preflighting (opening files in photoshop and printing with info about size, resolution, file format and color mode).
There's a very good book on Illustrator 10 applescripting and VBA scripting on amazon that got me started with scripting for illustrator, although CS works differently than 10 and requires a rewrite of the scripts.
...spike
Ewwwwww, coconut...