If you want to know all about AppleScript--the how, where, and why of using it--dig into AppleScript: The Definitive Guide. It doesn't make the mistake that other books do: it isn't about scripting this or that particular application, and it doesn't assume that learning AppleScript is easy or obvious. Instead, the book teaches and documents the language in a clear and rigorous manner, just as you'd expect with any programming or scripting language. AppleScript is a dynamic, object-oriented scripting system that allows Mac users--even novices who know nothing about programming--to directly control Macintosh applications, including the Mac OS itself. You can write scripts to automate repetitive tasks, customize applications, and even control complex workflows. AppleScript has always been useful, but with Mac OS X it's even more so. Nearly every application that comes with Mac OS X is scriptable. Even non-scriptable applications can often be driven with AppleScript, thanks to the new Accessibility API and GUI Scripting technologies. And now AppleScripters can put a true Aqua interface around their scripts! There's never been a more exciting time for AppleScript users. AppleScript: The Definitive Guide explores and teaches the language from the ground up. If you're a beginner and want to learn how to write your first script or just understand what the excitement is all about, you'll be able to do so after reading this book. AppleScript: The Definitive Guide is the quintessential guide to this important Mac tool. Regardless of their level of experience, AppleScripters everywhere will turn to this book again and again.

Amazon.com® Reader Reviews (Ranked by Helpfulness)

Average Amazon.com® Rating:  Based on 36 Ratings

A book to be read again and again -- or not at all! - 2007-05-08
Reviewer Rating:
No, don't start with "AppleScript: The Definitive Guide." Although I was highly motivated, diligent, and intelligent (if I may say so), Neuburg's exigent, articulate, and idiosyncratic "guide" defeated me, and I had to buy and work all the exercises in another book (Kochan's "Beginning Applescript") to obtain the background needed to appreciate this one.
The highly praised chapter in the first edition about conquering FrameMaker has been moved to an Appendix in the 2nd Edition, but since Neuberg sends the reader there on page 75, it is still useful and timely. It would have been more useful had he chosen a scriptable application that is on every Macintosh, or one, at least, that is shipped with Tiger, so that readers could follow his adventure rather than simply read about it. The worst that would have happened is that a newer modification of the application might have come out, in which case, as with FrameMaker, the reader could read about, but not experience, the process.
'Introductory' books in the liberal arts ("The Discarded Image" by C.S. Lewis comes to mind) are larded with quotations in Greek, Latin, French, and German, not to mention others. In exactly the same spirit, Neuburg shifts shamelessly from AppleScript to Perl, especially, but also to Unix, Objective-C, Python, and JavaScript, not to mention others. If you can't follow such examples -- he tells you that is all right -- you get the point that AppleScript is compatible with these and more, and he has the chutzpah to mention his own JavaScript book if that is your deficiency.
The effectiveness of good programming books diminishes as you move away from the computer. Programming is learnt at the keyboard, not in the lecture hall. That said, this book has an astonishing amount to offer to someone perusing it in an easy chair and mulling things over, rather than trying a succession of incorrect guesses at the keyboard. Kochan's book taught me, quickly and easily, how to move a Finder window around the screen, but when I decided that the window I wanted to move was the one holding the AppleScript program, Kochan left me without a clue. The "Oh, yeah" that finally got it moving occurred to me over a sausage biscuit in a fast food place with Neuburg's book in front of me. He didn't tell me what to do, but his dictionary exposition got me to where I could figure it out for myself.
As other reviewers have pointed out, Neuburg's emphases are upon the obscure, the contradictory, and the difficult. To explain these, he has not bothered with the obvious, the consistent, and the easy. They do not interest him, and he pays us the high (too high) compliment of implying that the obvious, the easy, and the consistent need not be explained at all.
If you wish to learn AppleScript and must learn it on your own, begin with a book (Kochan's, for example) that will make you reasonably competent in a hurry (three months, in my case). Then, when you have discovered that AppleScript is not as easy as you thought, you are ready for Neuburg to confirm your worst suspicions about its intricacies, devastate your casual assumptions about obvious solutions, and give you pride in beginning to learn AppleScript.
If you buy this book, you must read it several times, or you will not learn much of what it has to say.

Excellent reference manual for a niche language - 2008-03-10
Reviewer Rating:
This is an exhaustive reference manual for AppleScript, a scripting language included with all Macintoshes. It is not a tutorial, but if you have some programming experience of any kind you will be able to use this manual to construct AppleScripts. The book was published in January 2006 and is up-to-date through Tiger (Mac OS X 10.4). It includes a little coverage of Automator. There is some description of other helpful tools such as Script Debugger, a third-party replacement for Apple's Script Editor that provides a lot of additional capability.

I did some work in AppleScript about ten years ago to automate a nightly build process. AppleScript was the right tool for the job, but getting it to work was a lot of aggravation and I didn't look at AppleScript again. Recently I was asked to prepare some AppleScript demos for my local computer user group, and I got this book as a reference. AppleScript is still as aggravating as ever, but I was able to answer all my questions and complete the demos by using this book and its wonderful index.

AppleScript has evolved a lot in the past ten years, in particular by adding a number of object-oriented ideas and by increasing its interoperability with other programming systems (for example, Python, JavaScript, Perl, Ruby, Carbon and Cocoa based applications). Neuburg does a good job of explaining all these features, and he is particularly good on strategy issues. AppleScript can be used by itself but hardly ever is; you should always be thinking of combining it with existing applications and systems to solve your problem.

The major challenge in AppleScript was and remains figuring out the data types and operations supported by a particular application. Neuburg is honest about this, and recommends extensive experimentation and test scripts to figure out how the applications work.

Is AppleScript worth knowing? Neuburg doesn't really make a strong case for this, although his Chapter 1 is a good try. He works through an impressive example in Appendix A, including all the roadblocks and wrong turns. But the example is to clean up a book manuscript prepared in FrameMaker to meet the publisher's standards before turning it in. I think this is a good job for AppleScript, but how many people would need to do this job? I think AppleScript is still a niche language, but if you work in that niche this is an excellent reference.

Pretty Good Book about a Problematical Language - 2009-01-26
Reviewer Rating:
I'm a big fan of scripting languages -- I've been scripting the UNIX shells since 1978, and I've done a lot of work with Perl since the early 1990s. About two years ago, I bought an iMac running MAC OS X Tiger, and have been delighted with the machine and the software bundled with it (which includes Perl, Python, PHP, Tcl, bash, and tcsh). I thought I'd take a stab at learning AppleScript in order to extend my knowledge of my new machine and "Apple's way of doing things." By and large, I like O'Reilly publications, so I picked up the second edition of Neuburg's book. I'm quite knowledgeable about operating systems and programming languages, and have designed and built several non-trivial applications.

The good news is that Mr. Neuburg seems highly knowledgeable about AppleScript and does an excellent job of communicating its bugs, design limitations, and other shortcomings. The bad news is that I have no intention of wasting my time trying to learn such a flawed tool. This should not be interpreted as a failing of Mr. Neuburg's book -- I am grateful to him for communicating so clearly the problems with AppleScript, and I owe him a debt of gratitude for saving me a lot of time. I had been considering doing some work with Automater, but I think I'll stick with cron(1) scripts.

The most salient section of Mr. Neuburg's book is Appendix A, a sort of case study of using AppleScript to rename illustration files used in the FrameMaker files of a book by chapter number and sequence number within each chapter. Mr. Neuburg says that this was a requirement of his publisher. As someone who has worked with scholarly and technical publications for most of my professional life, I can state emphatically that any publisher who embeds chapter-sequence data in filenames is making headaches for himself, but I suppose O'Reilly has their own way of doing things. The AppleScript process described by Mr. Neuburg looks like it must have taken hours, if not days, to develop. Having been faced with a similar problem for various FrameMaker projects, I can only compare Mr. Neuburg's AppleScript experience with my homebrow process, which was roughly as follows:

* convert the binary FrameMaker files to MIF with fmbatch
* extract the illustration names with egrep(1)
* create target filenames from the original filenames using awk(1)
* rename the illustration files using a shell script, possibly generated with awk(1)
* insert the revised illustration names into the MIF files with sed(1)
* compare the old MIF files with the new ones with diff(1) to make sure the proper changes were made

This process takes about fifteen minutes. And even for someone not familiar with the individual UNIX tools, the documentation is straightforward, and the tools, once learned, can be used in an infinite number of applications. Given the uncertainty about when or how AppleScript can (or can not) be used in any context, I'll stick with tools that have proven their worth.

the grammar book of AppleScript - 2007-11-11
Reviewer Rating:
We wouldn't know something, especially certain technology very well until we know its limitations (or exceptions).

The extensive explorations in this book chart out the boundaries of AppleScript.

If one needs to consult "dictionaries" to acquire AppleScript vocabulary, this book is definitely the grammar book for speaking the language correct-ly.

Excellent book, but even better with Amazon or O'Reilly "search" - 2007-04-08
Reviewer Rating:
Matt Neuburg's AppleScript book is an excellent overview of AppleScript. Alas, it is limited, as all such books are, by AppleScript's peculiar nature.

The problem is that AppleScript is primarily useful when it interacts with scriptable Applications; this means that many important commands one may think of as belonging to AppleScript belong to Applications instead [2]. If you working to extend an existing script, and decide to research a command in the excellent book index Matt built himself [1], you'll often be frustrated. The command, you see, belongs to the Application, not to AppleScript.

On the other hand, there's a good chance Matt used in the command in one or more examples. In the absence of a companion book entitled "AppleScript for Applications" [3] you'd like to find those examples. Alas, that's where you want a full text search engine.

The good news is, there are two. The even better news is that O'Reilly could make their engine much more visible and useful, with advantages for everyone.

Consider the case of the 'Duplicate' command, which is supported by iTunes (among others) and the Finder (in slightly different ways, no doubt). When I tried Amazon's "search within the book" I discovered several illuminating references. Similarly, O'Reilly allows one to search within the book as a promotion for its Safari eBook library.

The Safari search works well, but they don't want to give away too much for free. You can only read a snippet of information in the search results. A snippet that doesn't, currently, include the page or section number. If you click further you get to the 'buy safari' screen, but you also get to see the section number. Now, you can return to the book and read the information.

O'Reilly could make all of us (and themselves) happy by keeping Safari just as closed as it is today, but merely adding a section reference to the search results they freely expose already.

Here's the win-win for O'Reilly, Matt, Amazon and us:

1. Include the section reference in the initial search results screen.
2. Promote the search facility in every published O'Reilly book and explain how to use it on the O'Reilly book page.
3. If need be, request readers register to obtain this service. O'Reilly doesn't do spam, but they can suggest email subscriptions, RSS feeds, etc during the registration process.

Let us count the wins:

1. Matt's book is suddenly a better book. Readers get more value from it. They use it more. They like it and O'Reilly more.

2. O'Reilly gets ongoing visits from its customers.

3. O'Reilly gets free, regular, promotion of Safari services.

4. Amazon sells more books.

5. O'Reilly does not reduce the value of Safari, they enhance it by introducing users to it without giving it away.

It's a win-win for everyone. I just hope someone at O'Reilly can see the profit in it for them.

john

[1] In my real life I'm a knowledge representation/informatics geek. I have a lot of respect for the unrecognized intellectual labor that goes into producing a truly excellent index. In this case Matt did the work himself!

[2] Many applications may use the same string to refer to somewhat similar functions with slightly different syntax and semantics. This "ontologic dilemma" is a kind of uncontrolled overloading, and it makes AppleScript very challenging to use.

[3] If Matt decides to sell an "AppleScript for Applications" as a Tidbits eBook I'll pay for mine in advance!

Browse Similar Topics

Top Level Categories:
Operating Systems
Programming

Sub-Categories:
Operating Systems > Macintosh OS
Programming > Macintosh