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
Shouldn't that be the other way 'round? Or am I missing somethinig?
One man's -1 Flamebait is another man's +5 Funny.
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
aka RTFM.
Letter
Umm, did the submitter change his mind about which AppleScript book he was reviewing after typing in the title for his submission?
reviewer: Mary Norbury-Glaser
...
she sometimes feels like the Mac Maytag Lady
Umm, did the poster read the review or summary before using inappropriate pronouns?
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!
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):
Yeah... I shouldn't knock it for being a self-acknowledged beginner's level. And, yes, I need to take a look at the Hanaan Rosenthal book the reviewer mentions.
"How to Do Nothing," kids activities, back in print!
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...
in a more systematic volume that just explained Applescript the way that most programming languages are explained. I've only found one free PDF download made by a 3rd party that came close to explaining an Applescript pre-written routine and how to call one. Also developers ought to be doing more to hook Applescript into their applications - so many times I've been thwarted by a lack of scriptability. Overall Applescript rocks, in spite of the absence of decent documentation. However I'm going to hold judgment on whether this book is worth spending my money on - it doesn't really seem like that kind of documentation I'm looking for.
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
Do you even read Slashdot? This isn't a summary, it's a book review. Have a look at past book reviews, and you'll see that they're all about this length...
Take off every sig. For great justice.
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.
I'd much prefer to use Python to script my Mac applications. Apple has done a good job of integrating Python into the Mac OS X system and made it possible to build Cocoa applications with it, but unfortunately the same cannot be said for Python's integration into the messaging/windowing system.
The last time I attempted to write a Python script to interact with iPhoto, I ended up downloading about eight or nine seperate components, and it ended up not working due to an incompatibility with Panther (I think).
It would be nice to see Python treated as a first-class scripting language under Mac OS X, with the same capabilities as AppleScript. About the only thing I like about Windows is that Windows Scripting Host lets you use pretty much any language (VBScript, JScript, ActiveState PerlScript, etc) to interact with objects from other languages and the system through COM (or whatever the hell Microsoft calls it this week).
And admit why you want it, because you are too lazy to read a thorough review.
"Sorry, Mary. You weren't superficial enough in your review. I was looking for the soundbite version, and I didn't want to use that silly scrolling thing on the side of my browser to skip to the end. You suck!"
Read the EFF's Fair Use FAQ
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."
http://www.spiderworks.com/books/ashandbook.php
For Safari and Firefox, which are what everyone uses anyway, I think it's going to be a while before any serious problems crop up.
Security problems *have* been found in these programs. They've also been fixed without Apple or the Firefox group trying to save face. They just released the patch when they could.
Internet Explorer is a browser which was a) developed in a race with Netscape, b) developmentally discontinued at the end of the race, and c) hooked into every part of the operating system.
None of these things apply to the most popular Mac browsers. The Finder isn't based on Safari. Apple isn't trying to put other broswer makers out of business by adding features as fast as possible. Safari is still very much in active development.
Microsoft has so completely stopped developing IE that it offers a toolbar to fix some of the glaring problems with the browser. It developed a whole separate program to fix its own program, rather than just updating the code. That's hardcore ductape.
So yes. There probably will be vulnerabilities on the Mac. The question is whether it will be so full of thousands of vulnerabilities that you can plug a brand-new install into the net and have the machine completely crippled within twenty minutes. It isn't likely, because Apple isn't really competing with anybody but itself.
Someone at MacHack/ADHOC 2004 yelled out that AppleScript is "the world's only read-only computer language"
Then someone replied that perl is the only write-only language.
However, people who use AppleScript tend to use it a lot. Once you discover how much you can do with it, you start to see all sorts of places that its useful.
Is it possible to use something else to drive AppleScript-enabled apps? Say, Javascript or Python? For some reason AppleScript just looks foreign to me, so I'd like to use the languages that I already know. Windows supports this, Mac, it seems, does not. I'd be glad to be wrong.
As a graphic designer, I've always found AppleScript kind of neat, but never really found anything that applied to me or my work that did anything more than save a click or two.
I took another look at it about a year ago. After some very short trial and error, I wrote a script that provides mail merge capability to Adobe's InDesign, a program that does not have such functionality natively.
I'm currently working on another script that will go through an Address Book subfolder and email a PDF newsletter to those contacts that have an email address, or print an addressed newsletter to those contacts with only a physical mail address.
It's fun stuff!
I'm sorry, but your opinion seems to be wrong.
but my two books on Debian GNU/Linux are now rather dated in areas.
You aren't by any chance talking about O'Reilly's "Running Debian GNU Linux", are you? I bought the second edition a couple of years ago, and the nuts and bolts stuff was great, and most of it was still very usefull. However, it was somewhat amusing to read how 16 megs was a *lot* of memory, and how OS2/Warp was gaining in populatrity.
Of course, just a couple weeks after I bought it (and spilled Dew on part of the cover) they came out with the 3rd edition. Poo.
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
I started playing around with AppleScript the other day and realized how simple it is to use it with xCode to create Cocoa GUI apps for Mac... I've already written a couple tools to run some command line tools for clients who are GUI centric.
The only complaint I have is that for a programmer AppleScript looks horrible when you first start working with it... The "Plain English" format of do and tell and "set x to y" seems a little laborious at first when you're used to x = y;
But that's why I'm buying the book...
(*
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
I've an apple for about a year, and have been programming on it. It is very fun. However I can't seem to wrap my mind around their development manuals.
I guess I'm completely used to reading man-pages, and it probably has something to do with, me, being dyslectic.
Anyway I found that some of their header files, such as for their CoreAudio API is documented very clearly. After trying to read the manuals for weeks, I could read the documentation that was left their by a programmer in one go, and finally understand why they did what they did (the API's themself are also pretty foreign).
And the CoreAudio API development manual is not the only one I have problems with, neither can I understand the whole QuickTime API. So I am left wondering, who is writing these development manuals. And am I the only one with the problem reading these manuals.
One thing I did read last night is that you can specify to run applications as root in your AppleScript. If the password isn't supplied in the script it automatically give you the dialog box...
Otherwise expect the operation run with whatever permissions the user which executed the script has.
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.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!
How pointless. I've never run across any products with that problem.
</sarcasm>
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!
Like probably everyone reading /. I've made lots of bad purchases of computing books. I don't mind it if I have to chuck the book after a couple of years, but a couple of months...
You can even access the Cocoa API via Applescript and create an actual app with it. It's a great little tool. Looking forward to Automator to speed things up for newbies.
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...
Man, I've been struggling with AS like you wouldn't believe.
I have writen the same program in AS studio then Realbasic and finally in Cocoa and saw at least a magnitude increase in performance each time and almost a magnitude increase in time taken to write each program. I am still learning to write cocoa so it fairly reasonable to take longer to write.
But I am curious as to whether there is a proven inverse relationship between ease of programming and execution speed. It seems that the faster a language the harder it is to program, must this be so
Good Lord, it's like walking on egg shells with you people.
I'm not saying AppleScript is bad or Macs are bad. I'm saying that we Mac users are 5% of computer users at best, that most of us never utilize AppleSript (I tend to do a lot of my scripting with Perl... YMMV), and that AppleScript is such an amazingly easy scripting language that anybody capable enough to learn a scripting language can pick up AppleScript just by skimming web sites on the subject and/or stealing code from other scripts.
Most people don't use Macs.
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.
Holy crap, you gotta be kidding me.
"Most people don't use Mac's" is a true statement. I didn't say "only four in 100 use Macs." I said "most don't."
As in, "less than half of computer users are Mac users."
You would have to be a complete idiot to disagree with that basic fact.
Sheesh!
For the record: I'm a total Mac zealot, and recently jettisoned the last of my non-Mac systems from my home network (a Linux web server and a game PC, both made redundant by my new media-room Mac mini, which hosts my web pages and plays World of Warcraft just fine.)
Information wants to be anthropomorphized.
Personally, I find the syntax of AppleScript so godawful that I can barely use it. I guess that's because I'm experienced with more conventional languages, and tend to think in terms of scopes and operator precedence. I often find it very difficult to figure out what parts of an AppleScript command apply to what, when.
On the other hand, the power of the tool is just incredible. It's the consistent, simple and flexible out-of-process scripting system every other OS would kill for. Yes, I know about Windows Scripting Host (and DCOP, but it's very limited and hardly system-wide).
If I find myself doing more mac work again, I'll be looking at the Python AppleScript interface *very* closely.
only incomplete. Like every other major upgrade to the Mac OS, Tiger will only add 'must have' new features to AppleScript.
...it's probably more expensive to publish a book in 3 ring binder form than traditional paperback production.
I believe paperpack books only cost a few bucks per unit (US$) to produce in volume. 3 ring binder plus all that manual insertion probably is more, and would take up more space for shipping.
My guess is that it's basic economics, and we're getting what's cheapest to produce.
Sleep is for the Weak
I have to disagree here. Your problem isn't AppleScript. Your problem is AppleScript Studio. There is a huge difference. I tried Studio when it was first released. I gave up in frustration. It was simply too buggy. A broken subroutine could be 'fixed' by adding
log "I'm breaking here"
Needless to say, that should have zero effect on the script's execution, but it made all the difference in the world in one case. In others, I had to wire things up in Interface Builder in a very specific, mystical order. Check off three check boxes in one case, broken studio app. Check off the *same three check boxes* in reverse order, everything is peachy. Then there's the fact that there is no reasonable way to pass data and objects between multiple script files. It's off limits. Every once in a while I return to it to try something new, but... while Studio has made some progress, I still find it quite useless for anything marginally complex.
AppleScript itself on the other hand is quite nice. Just pop open Script Editor and give it a whirl. The resulting script's interface might not be as purty, but it works rather well. In short, AppleScript sucks for application development, but that really isn't what AppleScript was meant to do. It is a scripting language. When it comes to automating applications, it is a truly wonderful technology. I find the biggest limitations of the language to be the memory usage (scripts that need lots of memory start to magically break) and its single threaded-ness.
Actually there are a number of useful online resources http://www.apple.com/applescript/developers/ http://www.apple.com/applescript/studio/ http://www.macscripter.net/ and several very helpful lists at http://lists.apple.com/archives I've used Applescript Studio to build a couple of applications very quickly.
a-ahem.
Although Automator works in the same niche as AppleScript and integrates nicely with it, it's something completely separate (i.e. an app could provide Automator support but no AS scripting dictionary).
That was kind of my point.
Securing XP is something that lots of people need to do, and requires vast amounts of arcane knowledge, hence a book which explained it would make a great Christmas gift for the poor saps who need it.
On the other hand, if such a volume was sufficiently expensive, maybe it would make more sense to just give away Mac minis.
Information wants to be anthropomorphized.
A useful little thing that was in beta for a while (and seems to have gone mainstream very quietly) is at Apple's GUI scripting page - As might be expected, it's a bit unweildy (check out the lovely example on page 3) and a bit pitfally to write, but when it's done right it works like a dream. You can script Powerpoint actions, for once. Hooray!
Browsing with +2 to insightful posts and a higher threshold makes the average post seen seem a lot more ingenious
repeating the entire post at "2", since it most certainly was not "Flamebait", but my actual honest opinion:
"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)."
So, this relatively obscure yet incredibly easy scripting language which only runs on one platform which is only used by a small percentage of computer users out there had only two complete, up-to-date, and comprehensive volumes of documentation, and therefore the world was crying out for the publication of a "missing manual."
Uh-huh.
Let's go over this again:
Most people don't use Macs.
Most Mac users don't use AppleScript.
Most of those who use it don't really need a manual.
There are two good manuals out there already anyway.
Wow. This thing has "best seller" written all over it.
Mac manuals are not "missing." They are "not needed."
Let me know when "Windows XP Security Administration: The Missing Manual" gets published. I'll buy twenty copies and have my Christmas shopping for next year done (for my PC-owning friends and relatives, anyway.)
Information wants to be anthropomorphized.
Yeah, but he got you on mac-users utilizing Applescripts without neccessarily programming with it! I was going to point this out but decided the effort to post an lengthy explanation wasn't worthwhile. Maybe you ought to buy the book and check it out for yourself.
Thanks for the tip!