![Programming Programming](http://a.fsdn.com/sd/topics/programming_64.png)
![Books Books](http://a.fsdn.com/sd/topics/books_64.png)
![Media Media](http://a.fsdn.com/sd/topics/media_64.png)
![Businesses Businesses](http://a.fsdn.com/sd/topics/business_64.png)
![Book Reviews Book Reviews](http://a.fsdn.com/sd/topics/bookreview_64.png)
![Apple Apple](http://a.fsdn.com/sd/topics/apple_64.png)
![Technology Technology](http://a.fsdn.com/sd/topics/technology_64.png)
Beginning AppleScript 171
AppleScript: The Missing Manual | |
author | Adam Goldstein |
pages | 304 |
publisher | Pogue Press/O'Reilly & Associates |
rating | 8 |
reviewer | Mary Norbury-Glaser |
ISBN | 0596008503 |
summary | AppleScript for the Beginning/Intermediate User |
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.
article title (Score:4, Interesting)
Re:article title (Score:3, Interesting)
"Goldstein's Missing Manual fills this gap with coverage of the current Mac OS 10.3 (Panther) release of AppleScript..."
So my guess is no, she did not change her mind, though I hear that is a woman's prerogative.
Re:article title (Score:2)
Re:article title (Score:2)
Re:Umm... (Score:4, Funny)
Re:Umm... (Score:3, Funny)
Re:Umm... (Score:4, Funny)
Re:Umm... (Score:4, Funny)
Re:Umm... (Score:2)
Re:Umm... (Score:2)
I won't, but shouldn't you be honest with him?
"I know all there is to know, about the crying game
I've had my share of the crying game"
Heh.
Its about time (Score:5, Insightful)
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.
Re:Its about time (Score:3, Informative)
Re:Its about time (Score:3, Informative)
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.
Re:Its about time (Score:4, Interesting)
Re:Its about time (Score:2, Funny)
Amen. I remember my first attempt, circa 1996. I wanted a task to repeat every few minutes, pausing between loops. But what on earth could the AppleScript command be? Pause? No. Wait? No. Hold? No. It's idle [applescrip...cebook.com]. Ah. So simple, and yet so obscure.
Re:Its about time (Score:2)
I did quite a bit of Applescripting back in the day. Letting scriptable apps loose on the internet makes me a bit nervous.
Also, I wonder if something like javascript/Dom might take the place of Applescript.
Re:Its about time (Score:3, Insightful)
Re:Its about time (Score:3, Interesting)
I clearly remember "the making of myst" that was included with a apple a roommate had bought (the game was included as well). The two bothers who made the game (forgot their names) talked about applescript or hypercards or something... I played the game wth my roommate and we really liked it... but i couldn't believe it was programmed in a scripting language.
Re:Its about time (Score:5, Informative)
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..
Re:Its about time (Score:2, Interesting)
Not that this exactly ruined th
Re:Its about time (Score:3, Informative)
Re:Its about time (Score:2)
its power and simplicity is only undermined by the near total lack of documentation.
....just like WebObjects.
Apple really doesn't know how to market and support developer tools. Often times the best way to learn about apple tools is to find the right non-apple listserv or message board.
Re:Its about time (Score:2)
I guess... I never really had much trouble with web objects... or any of the rest of apples dev tools...
sure the Cocoa API docs are a little weak... but so is MSDN if you ask me.... and I think apples code samples are much more useful than anything else I have found.
not that apple is without sin... their docs could all be much better... but only applescript stands out for me as the worst of the bunch...
even worse is the fact that its really a tool for non programmers... you just cant expect a non progra
Re:Its about time (Score:3, Interesting)
Scripting Cron? (Score:3, Interesting)
Shouldn't that be the other way 'round? Or am I missing somethinig?
Re:Scripting Cron? (Score:3, Informative)
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
Re:Scripting Cron? (Score:2, Informative)
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 AppleScr
Cocoa from Applescript (Score:2)
Re:Scripting Cron? (Score:2)
Re:Scripting Cron? (Score:2)
Re:Scripting Cron? (Score:2)
This means that for laptop users, often daily weekly and monthly cron tasks are sometimes not run for quite some time, degrading system performance.
That is a load of BS perpetuated by several authors of irrelevant and purposeless shareware to perform OSX maintenance.
The periodic subsystem jobs clear out and rotate old log files and rebuild the locate database. These have no impact on general system performance.
Equally silly is the advice to periodically removing cache files or dot files, or run scrip
Re:Scripting Cron? (Score:2)
Scripty Goodness (Score:5, Interesting)
are there AppleScript security vulnerabilites?
Re:Scripty Goodness (Score:5, Funny)
Re:Scripty Goodness (Score:5, Informative)
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.
Re:Scripty Goodness (Score:2)
Yet. How long will it be before there's a <SCRIPT LANGUAGE="AppleScript"> addition to the next version of IE for Macs? Welcome to the world of Windows issues. The only reason it hasn't been done yet is that the language
Re:Scripty Goodness (Score:3, Insightful)
Even if macs somehow gained 10-20% market share over the next few years, it wouldn't make much sense for websites to require it. Pages require such an operating system specific function will only occur when you've got 95%+ marketshare for a single browser, which we're unlikely to ever see again.
Re:Scripty Goodness (Score:3, Interesting)
In addition to your good points... Im not sure applescript can do as much damage as VB script even if apple did add this to safari.
i havent tried this, but doesnt applescript require an admin password to do any of the things that a user needs a password for? I mean, it could wipe out user data but not the system, at least without the user putting in the admin password?
I could be totally wrong here... like I said, I havnt tested it... but thats certainly the way it should work.
Yes, requires a password for serious damage (Score:4, Informative)
Re:Scripty Goodness (Score:2)
But wasn't there something using the help:// protocol that was fixed by a security update this fall or summer?
Ah, yes. Here it is [macslash.org].
Re:Scripty Goodness (Score:2)
Even if there were such web-enabled support, it would all still be limited by the BSD permissions. Windows runs the default user as root. Not only does OSX have root completely disabled by default, you'll be asked for the administrator pass
Re:Scripty Goodness (Score:2)
I always used the "move to trash" command rather than a complete delete in case it blew up, but there was nothing stopping me. If I ran something like "select folder "Sy
Re:Scripty Goodness (Score:2)
I do have a couple of scripts that delete stuff automatically, and of course have been bitten by the inadvertant wrongly-placed rm-r, so when I came (back) to the Mac I was happy to be able to mv ~/.trash in all my automated (and contextual) scripts.
Re:Scripty Goodness (Score:2)
You know, the famous ILOVEYOU.vbs and other script viruses didn't run automatically either -- one had to click on it and dimiss a warning. Furthermore, those viruses rarely required Administrator rights, they ususally just sent mail and copied themselves wilynily.
I see no difference between OS X and Windows in this department. EXECPT for the fact that people are scanni
Re:Scripty Goodness (Score:2)
I agree that run of the mill Mac users aren't any smarter than Windows users and that most users will click 'okay' to get rid of a dialogue without reading it. An 'always ask the user policy' is irresponsible, the user probably doesn't know and doesn't understand.
I've seen some good things so far. (Score:2)
Otherwise expect the operation run with whatever permissions the user which executed the script has.
Dear Linux: The Missing Manual (Score:2, Insightful)
aka RTFM.
Letter
A neat use (Score:5, Informative)
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.
Re:A neat use (Score:2)
That works when using Java against Cocoa (to mix even more languages). I happen to be working on an iPod-like interface to iTunes for touch screens today. It's for a car install. Link [umn.edu].
Though I have been having a weird issue where a script that compiled fine (it auto-compiles the script on execute if it isn't already) dozens of times 500ms apart, will spontaneously fail to compile. I was recompiling each time through the
Re:A neat use (Score:2)
~Lake
Syntax & Grammar (Score:5, Insightful)
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?
Re:Syntax & Grammar (Score:2)
Re:Syntax & Grammar (Score:2, Funny)
Most native English speakers cant[sic] even properly use there [sic] own language in proper context.
Its[sic] really depressing; not to mention annoying as hell.
I love Applescript though. It helps me to use my system real good [sic].
Let me explain (Score:5, Interesting)
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 [wikipedia.org]) 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.Re:Let me explain (Score:3, Interesting)
Honestly the way you formatted the statement is what is confusing, you could also have done:
Re:Let me explain (Score:4, Informative)
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.
Re:Syntax & Grammar (Score:2)
Yet another chatty beginner's guide? (Score:5, Insightful)
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.
Oh, all right, mod me down... (Score:2)
Re:Yet another chatty beginner's guide? (Score:2)
Yeah. I really wish that O'Reilly would get back to its roots and publish book geared for advanced users (and not users who think they are advanced). Even the Definitive Guide pales in comparison to the coverage in the original X series, or the other early books.
Re:Yet another chatty beginner's guide? (Score:2)
Also, when 'Programming Perl', 'Lex and Yacc', 'Sendmail: TDG' and the other classic O'Reilly books came out they were aimed at the accidental system admin/programmer. The new books are a little more mass market, but the audience is not much less technical than those first books.
Applescript is such an asstastic language ... (Score:3, Informative)
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 [stompstompstomp.com]]
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):
Re:Applescript is such an asstastic language ... (Score:2)
tell application "iTunes" to print the name of each item in the library
So what exactly are you saying is asstastic about it? The above seems to be an awful lot simpler, and clearer than your python.
Re:Applescript is such an asstastic language ... (Score:2)
Re:Applescript is such an asstastic language ... (Score:2)
Re:Applescript is such an asstastic language ... (Score:3, Insightful)
I've never used Applescript... (Score:4, Interesting)
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.
Re:I've never used Applescript... (Score:3, Informative)
I wish they did, too. Here's why I think they don't:
Re:I've never used Applescript... (Score:2, Insightful)
1. A thin but durable plastic strip stuck to one side of each page would easily add strength to the holes and help prevent breakage.
2
Re:I've never used Applescript... (Score:2)
It might have been workbench 2.0, although 2.1 shipped as a boxed set of 4 bound manuals. My first machine ran 1.3, but with either stickers or a smaller update book listing the sections to ignore in the 1.2 book.
tempting (Score:4, Interesting)
Yeah it's nice for beginners ... (Score:5, Insightful)
Re:Yeah it's nice for beginners ... (Score:2)
But reall
Re:Yeah it's nice for beginners ... (Score:2)
Python (Score:2, Insightful)
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 th
Re:Python (Score:2)
Re:Python (Score:2)
I have one question to those proficient in AS (Score:2)
Re:I have one question to those proficient in AS (Score:3, Informative)
There's a scripting component for Python called OSA Python [pacbell.net], and one for Javascript called Javascript OSA [latenightsw.com].
Frontier's UserTalk [userland.com] language is another implementation.
Thanks so much! (Score:2)
My Favorite Applescript (Score:3, Informative)
(* 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
Normal Spacing: (Score:3, Informative)
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 might buy this... (Score:3, Interesting)
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...
Don't forget Xcode! (Score:3, Informative)
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.
will AppleScript change a lot in Tiger? (Score:2)
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...
The book will not be irrelevant... (Score:2)
Synax and power (Score:2)
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
Re:Longest summary ever? (Score:2)
Re:Longest summary ever? (Score:2)
And admit why you want it, because you are too lazy to read a thorough review.
Wow (Score:2)
"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!"
Re:Ummm. (Score:5, Insightful)
Cool, I'm sure your pals will all love a book about how to use features that don't exist.
Re:Ummm. (Score:4, Funny)
Re:Ummm. (Score:5, Insightful)
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 [apple.com] 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.
Re:Ummm. (Score:2)
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 peo
"for the intermediate-to-advanced scripter" (Score:2)
Re:Ummm. (Score:2)
Applescript for graphic artists (Score:4, Interesting)
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.
Re:One way of thinking about AppleScript (Score:2)
No, that would be forth. Makes perl look like "See Spot Run."
Re:Can some one explain why AS is so slow (Score:2)
Re:Apple's development manuals (Score:3, Insightful)
CoreAudio and the Quicktime are quite possibly the two most worst-documented sets of Apple technologies out there. I don't understand how a company that builds nearly its entire bottom line on being a multimedia powerhouse can afford to make development of multimedia applications so problematic for some many people. If you want to write a simple application that records audio or lets you playback video in a custom way, you are so totally screwed.
You just don't know how bad it is