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.
Agreed. AppleScript is the only language I have ever used that is easier to read than it is to write - and the reason it's so hard to write is that the documentation is scattered and unintelligible. Next to the Cocoa documentation it looks even worse.
I am TheRaven on Soylent News
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
Not in the sense of VBScript or similar Windows issues. Applescripts don't run automatically, you can't email them to somebody and have it delete their home directory without their participation, or put it on a web page and use an IE exploit to get root-level access to the system.
But yes, it's a powerful scripting language, so it can do all the bad stuff your user account can do. OSX is so flexible on language that you can pretty much use anything you can think of (AppleScript, perl, python, [ba|c]sh, etc) in a single script, so all the stuff you can do with those languages and shells are possible in a script.
There was a debate over on MacOSXhints.com a week or two ago debating whether Apple should somehow try to "protect" people from malicious scripts, but there doesn't seem to be any sensible way to have a functional scripting language that isn't capable of doing damage when used improperly.
Recursive: Adj. See Recursive.
Fortunately, you don't have to use it to get the full functionality of the Open Scripting Architecture.
/sw/lib/python2.3/plat-mac/gensuitemodule.py \ /Applications/iTunes.app/Contents/Resources/iTunes .rsrc
... trk = library.file_track(i) ... print app.get(trk.name)
You can use it from python, for instance. You need to generate an interface object from the AppleScript dictionary of anything you want to use, but then it's pretty straightforward.
For iTunes (and using a fink-provided python, but the shipped one will work as well):
pythonw
--output iTunes --resource --creator hook \
[Source]
This makes a module called iTunes.
Then you can use it trivially. You have to use the pythonw instead of the python executable (due to some interaction with the OS X window manager):
>>> import iTunes
>>> app = iTunes.iTunes()
>>> library = iTunes.library_playlist(1)
>>> num = app.count(library, each=iTunes.track)
>>> num
9365
>>> for i in range(1, num+1):
I believe the original myst was a hypercard stack (or at least that was the proof of concept) decked out with nice graphics.
It is pretty unbelievable that something so successfull can come from something so simple... but thats why I have always liked applescript..
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
AppleScript is the only language I have ever used that is easier to read than it is to write
I think they're ALL easier to read than write, but I know what you mean. It's easy to write a perfectly understandable statement that the interpreter can't handle. Personally, I think the problem is a lack of consistancy more than anything else. Scripting InDesign is VERY different than scripting Quark. That's not going to change, either, since so much depends on the way the application 'understands' the data.
What's really missing is an easy front end, like HyperCard used to provide. AppleScript Studio (unfortunate abbreviation, that) is a bit more complex than necessary.
One man's -1 Flamebait is another man's +5 Funny.
>...use an AppleScript to run cron every day,...
Shouldn't that be the other way 'round? Or am I missing somethinig?
Either way you want it, my friend. In MacOS X, you can integrate the gumdropesque beauty of GUI tools with the strange world of Unix under the hood. You can launch AppleScript from cron script or a shell script from AppleScript. To do the former all it takes is to place a command "open foo", where "foo" is your script written in AppleScript ("open foo" generally equals to double-click on foo's icon). To do the latter just include "Tell application Terminal to do script with command bar" in your AppleScript (this would equal to typing bar in your Terminal window).
While Hypertalk was esentially the predecessor of AppleScript, it was not the same thing. Hypertalk only worked in Hypercard (and Supercard) stacks. Myst used a Hypercard runtime with some xcmds (external command modules) added to it.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
I wish they did, too. Here's why I think they don't:
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.
Used in conjunction with the Mail.app Rule: "if message is junk mail run applescript:"
(* Bounce Mail Messages AppleScript Copyright © 2004 Michael Brewer Brewing Designs - http://www.brewingdesigns.com/ *)
using terms from application "Mail" on perform mail action with messages theMessages for rule theRule tell application "Mail" repeat with eachMessage in theMessages bounce eachMessage (* Mail automatically deletes bounced messages in the GUI, but not in AppleScript, so we... *) delete eachMessage end repeat end tell end perform mail action with messages end using terms from
Quickly bouncing your junk is the key to getting rid of it
(*
Bounce Mail Messages AppleScript
Copyright © 2004 Michael Brewer
Brewing Designs - http://www.brewingdesigns.com/
*)
using terms from application "Mail"
on perform mail action with messages theMessages for rule
theRule
tell application "Mail"
repeat with eachMessage in theMessages
bounce eachMessage
(* Mail automatically deletes bounced messages in the GUI,
but not in AppleScript, so we... *)
delete eachMessage
end repeat
end tell
end perform mail action with messages
end using terms from
There's a scripting component for Python called OSA Python, and one for Javascript called Javascript OSA.
Frontier's UserTalk language is another implementation.
I hold it, that a little rebellion, now and then, is a good thing. -- Thomas Jefferson
http://www.spiderworks.com/books/ashandbook.php
a nd book_Preview.pdf
Great book, PDF, and only $14.95, online immediately.
Sample:
http://www.spiderworks.com/samples/AppleScriptH
Go SpiderWorks!
You can pass data back to the shell by including a return statement in your AppleScript code (something like a subroutine in some languages). In the same way, you can call a shell command/script from AppleScript without having to invoke the Terminal app (or ever even seeing from the user perspective that anything but AppleScript was ever used). Use the do shell script command. e.g.:And it'll display the results of the uptime command in a typical GUI dialog box without the user ever seeing a CLI.
Seamlessly passing data back and forth between AppleScript and shell processes is a beautiful and useful thing for writing scripts to adjust CLI parameters for users that are CLI-phobic.
Xcode now lets you create a standard GUI with the regular tools (InterfaceBuilder). You would never know it's an Applescript unless you're looking around in the compiled package. I put together a quick app for a client to script InDesign and you would never know it was Applescript.
Applescript is about the closest I've seen to ARexx on the Amiga., and that language could do anything. Just about every app shipped had some sort of arexx functionality. The parse command was the easiest way I've ever seen to separate out a string. I remember hearing people who would have a single script dial in to CompuServe, navigate to stock quotes, grab and parse teh info, paste it in a spread sheet, build a chart, export the chart into another app, etc. I could use one app as a front end and use arexx to hit any number of back ends.
I use Macs to up my productivity, so up yours Microsoft!
In my opinion, that is the completely opposite compared to what you want from a quick one-shot scripting language. Those should be easy to write and it really doesn't matter if it's hard to read or not. Perl and TECO are good examples of this.