Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Programming Books Media Businesses Book Reviews Apple Technology

Beginning AppleScript 171

norburym writes "AppleScript: The Missing Manual by Adam Goldstein is part of the Missing Manual series of beginner/intermediate books published by Pogue Press/O'Reilly and Associates. This series focuses on computer products that have been released without adequate printed manuals (Mac OS X, iLife '04, Google, iPod and iTunes, Windows XP, Windows 2K, among others). I would venture that this also applies to most major software releases, which should keep Mr. Pogue, O'Reilly and their contributing authors busy for quite some time. Their newest release, AppleScript: The Missing Manual, is a welcome addition to their catalog of smart, funny and user-friendly books." Read on for the rest of Norbury-Glaser's review.
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.
This discussion has been archived. No new comments can be posted.

Beginning AppleScript

Comments Filter:
  • article title (Score:4, Interesting)

    by geoffspear ( 692508 ) * on Monday February 07, 2005 @03:32PM (#11600164) Homepage
    Umm, did the submitter change his mind about which AppleScript book he was reviewing after typing in the title for his submission?
  • Its about time (Score:5, Insightful)

    by Altus ( 1034 ) on Monday February 07, 2005 @03:35PM (#11600203) Homepage

    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)

      by TheRaven64 ( 641858 )
      Agreed. AppleScript is the only language I have ever used that is easier to read than it is to write - and the reason it's so hard to write is that the documentation is scattered and unintelligible. Next to the Cocoa documentation it looks even worse.
      • Re:Its about time (Score:3, Informative)

        by OECD ( 639690 )

        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)

      by Tsiangkun ( 746511 ) on Monday February 07, 2005 @03:44PM (#11600283) Homepage
      Apple script is so easy to read, almost like english. Too bad when I try to script something from scratch, my guess at the english word that is expected is never right. Hopefully this will make applescript as easy to write as it is to read. I do most of my apple scripting in bash and perl nowadays anyway.
      • Too bad when I try to script something from scratch, my guess at the english word that is expected is never right.

        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.

    • But I wonder -- is this a technology whose time has come -- and gone?

      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)

        by jlaxson ( 580785 )
        No, it has most certainly not come and gone. Automator is going to take applescript to new levels. In addition, AppleScript isn't a one-shot thing. It operates on top of apple's "Open Scripting Architecture." You can write OSA scripts in any language you have an interpreter/compiler plugin for. There's only one I know of, for javascript, but in theory you could write a plugin for any language. Python, F:Script, anything.
    • Re:Its about time (Score:3, Interesting)

      by tijnbraun ( 226978 )
      Wasn't Myst programmed in applescript?
      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)

        by Altus ( 1034 ) on Monday February 07, 2005 @03:52PM (#11600355) Homepage


        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)

          by zbrimhall ( 741562 )
          The original Myst was indeed a set of standalone HyperCard stack. I used to use a "cheat code" which consisted of typing 'Command-?' A dialogue box would appear, complaining that it couldn't find "HyperCard Help Stack," and giving asking you to find the help stack in an Open File... dialogue. Thing is, the different Myst Ages were just different stacks which, while normally hidden, were visible in the Open File... dialogue. Select your desired Age and voila--instant warp!

          Not that this exactly ruined th
      • Re:Its about time (Score:3, Informative)

        by Megane ( 129182 )
        While Hypertalk was esentially the predecessor of AppleScript, it was not the same thing. Hypertalk only worked in Hypercard (and Supercard) stacks. Myst used a Hypercard runtime with some xcmds (external command modules) added to it.
    • 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.



      • 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)

      by myov ( 177946 )
      Some of the Dictionaries have been really complicated. Really un-Apple of Apple. But, in many cases you can hit the Record button, and it will build the script as you perform the actions.
  • Scripting Cron? (Score:3, Interesting)

    by OECD ( 639690 ) on Monday February 07, 2005 @03:36PM (#11600206) Journal

    ...use an AppleScript to run cron every day,...

    Shouldn't that be the other way 'round? Or am I missing somethinig?

    • >...use an AppleScript to run cron every day,...

      Shouldn't that be the other way 'round? Or am I missing somethinig?


      Either way you want it, my friend. In MacOS X, you can integrate the gumdropesque beauty of GUI tools with the strange world of Unix under the hood. You can launch AppleScript from cron script or a shell script from AppleScript. To do the former all it takes is to place a command "open foo", where "foo" is your script written in AppleScript ("open foo" generally equals to double-click
      • Re:Scripting Cron? (Score:2, Informative)

        by Eravau ( 12435 )
        If you want to call an AppleScript command from a shell script, you don't need to open it (which will essentially call it from the Finder). You can run it from the shell with the osascript command. e.g.:

        osascript -e 'tell application "Stupid App" to quit'
        osascript /path/to/applescript_script_as_text

        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

      • 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 imagine he wrote an applescript with a little clickable icon so that he doesn't have to go to a terminal and type c-r-o-n. Perhaps a dubious achievement, but if it makes him happy...
      • Ok, but why would anyone be running cron from the terminal in the first place? If your cron process is dying often enough that you need a GUI icon to restart it, there's something seriously wrong with your machine.
      • Or maybe it performs a service something like anacron. My computer is seldom running when cron wants to do its magic, and if it is running, I'm usually using it and don't want a cron job running. What a predicament!
  • Scripty Goodness (Score:5, Interesting)

    by Stanistani ( 808333 ) on Monday February 07, 2005 @03:37PM (#11600217) Homepage Journal
    Not being a Mac person myself (although I am eyeing the Mini as a starter) I ask:
    are there AppleScript security vulnerabilites?
    • by kiwidefunkt ( 855968 ) on Monday February 07, 2005 @03:40PM (#11600239) Homepage
      No. If you read back a few stories, you'll see only .NET and JVM have security vulnerabilites.
    • Re:Scripty Goodness (Score:5, Informative)

      by NMerriam ( 15122 ) <NMerriam@artboy.org> on Monday February 07, 2005 @03:49PM (#11600333) Homepage
      Not in the sense of VBScript or similar Windows issues. Applescripts don't run automatically, you can't email them to somebody and have it delete their home directory without their participation, or put it on a web page and use an IE exploit to get root-level access to the system.

      But yes, it's a powerful scripting language, so it can do all the bad stuff your user account can do. OSX is so flexible on language that you can pretty much use anything you can think of (AppleScript, perl, python, [ba|c]sh, etc) in a single script, so all the stuff you can do with those languages and shells are possible in a script.

      There was a debate over on MacOSXhints.com a week or two ago debating whether Apple should somehow try to "protect" people from malicious scripts, but there doesn't seem to be any sensible way to have a functional scripting language that isn't capable of doing damage when used improperly.
      • Not in the sense of VBScript or similar Windows issues. Applescripts don't run automatically, you can't email them to somebody and have it delete their home directory without their participation, or put it on a web page and use an IE exploit to get root-level access to the system.

        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
        • by cowscows ( 103644 )
          Microsoft discontinued IE for macs. I don't think Apple would be dumb enough to add something like that to Safari.

          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)

            by Altus ( 1034 )


            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.
            • by Blamemyparents ( 730461 ) on Monday February 07, 2005 @05:12PM (#11601277)
              Applescripts don't have any better access privledges than any other OS X program. In order to seriously damage the system, you need the admin password for access to system folders. Unix kids should note that this is OSX's policy of 'sudo everything:' let the user do as they please, but if they're going somewhere they might not want to, get passwordy real fast. Even the 'administrator' account is not truly an administrator (though he can do a lot more than a 'normal user'), the root account is actually disabled on OS X (though it can be re-enabled with little work). OS X Server, on the other hand, tries to log you in as root by default, taking the fair guess that it's dealing with someone significantly wiser with the system.
          • I don't think Apple would be dumb enough to add something like that to Safari.

            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].

        • Yet. How long will it be before there's a 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 hasn't generated enough followers for it to be worth someone's while to abuse it.

          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
      • Back in OS 8/9, I had a setup script for new machines fresh from Apple (it didn't make sense to image my machines). Among other things, it would go around trashing extensions/leftovers/AOL, disable printers Apple hadn't shipped in years, rename the workstation, copy a bunch of default prefs, setup file sharing including owner name/pass etc.

        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
        • And that lousy security is part of why i left the Mac around OS 8 (went to NT, 2k, and BSD) and came back at 10.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.
      • Applescripts don't run automatically, you can't email them to somebody and have it delete their home directory without their participation

        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
        • Been a while since I used outlook, but I seem to remember at least some of those script viruses took advantage of a preview pane that would execute embedded material without requiring any action from the user.

          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.

    • 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.
  • Dear Linux: The Missing Manual,

    aka RTFM.

    Letter

  • A neat use (Score:5, Informative)

    by nate nice ( 672391 ) on Monday February 07, 2005 @03:45PM (#11600290) Journal
    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.
    • new NSAppleScript("get duration of current track").execute(new NSMutableDictionary());

      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

      • Feh, I meant to hit the preview button, went to edit the example script into something that actually works (Like "tell application itunes to get duration of current track"), and there was no edit field. Ah well.

        ~Lake
  • Syntax & Grammar (Score:5, Insightful)

    by bwcarty ( 660606 ) on Monday February 07, 2005 @03:47PM (#11600314)
    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?
    • Well enough to understand AppleScript, certainly. The genius and uniqueness of AppleScript becomes apparent when you actually look at code. tell application Finder, if (variable) is equal to (value) then, display dialog box "Hello World" buttons "OK", end if, end tell. End of argument.
    • Your [sic] right.

      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)

      by lokedhs ( 672255 ) on Monday February 07, 2005 @05:44PM (#11601627)
      Your post was modded +2 insightful by the time I wrote this. I sincerely hope it gets modded up higher.

      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:

      tell application "Terminal" to set background color of the first window to "green"
      In comparison, the Java version of the above code would look something like this:
      terminal.getWindows().get(0).setBackground("green" );
      The above assumes that .getWindows() returns a List of windows, and like all lists, .get(0) returns its first element.

      AppleScript 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:

      set itunesRunning to ((application processes whose name is equal to "iTunes") count) is greater than 0
      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:

      send message to user "jim" message text "hello, how are you"
      Or, it could be:
      send message to channel member whose nick is "jim" with text "hello, how do you feel this time?"
      Don't take me wrong, I really like AppleScript. I just wished the syntax was better.
      • Re:Let me explain (Score:3, Interesting)

        by Graff ( 532189 )

        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:

        set itunesRunning to ((application processes whose name is equal to "iTunes") count) is greater than 0

        Honestly the way you formatted the statement is what is confusing, you could also have done:

        set itunesRunning to false
        if (count of (application processes whose name is "iTunes")) is greater than 0 then set i

        • Re:Let me explain (Score:4, Informative)

          by lokedhs ( 672255 ) on Tuesday February 08, 2005 @02:58AM (#11604599)
          But that was my point exactly. There are a 100 different ways to write something, and getting it right can be frustratingly difficult. However, once it's written it's very easy to read.

          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.

    • Well, if you lack the ability to understand the syntax of a language, you probably wouldn't be programming a computer anyway, would you?
  • by dpbsmith ( 263124 ) on Monday February 07, 2005 @03:48PM (#11600318) Homepage
    ...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.

    • 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.
    • 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.

      • A wildly successful advanced computer book like 'The C Programming Language' or 'UNIX Network Programming' will take years to match the sales that a mildly successful book aimed at new users can make within months.

        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.

  • by jkujawa ( 56195 ) on Monday February 07, 2005 @03:50PM (#11600338) Homepage
    Fortunately, you don't have to use it to get the full functionality of the Open Scripting Architecture.

    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 /sw/lib/python2.3/plat-mac/gensuitemodule.py \
    --output iTunes --resource --creator hook \ /Applications/iTunes.app/Contents/Resources/iTunes .rsrc

    [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): ... trk = library.file_track(i) ... print app.get(trk.name)
  • by Biomechanical ( 829805 ) on Monday February 07, 2005 @03:51PM (#11600350) Homepage

    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.

    • I wish they did, too. Here's why I think they don't:

      1. Pages get lost and damaged due to the constant sliding of the holes as the pages are turned.
      2. The book becomes trivial to scan or photocopy.
      3. Providing "updated chapter(s)" means there's no incentive to buy the more expensive updated edition.
      4. Multiple page sizes would be a pain to keep in sync.
      • I wish they did, too. Here's why I think they don't:

        1. Pages get lost and damaged due to the constant sliding of the holes as the pages are turned.
        2. The book becomes trivial to scan or photocopy.
        3. Providing "updated chapter(s)" means there's no incentive to buy the more expensive updated edition.
        4. Multiple page sizes would be a pain to keep in sync.

        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

    • One of the Amiga releases did this (wow... that's going back). I can remember buying a system update and needing to go through the manual inserting/removing pages.

      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)

    by Doc Ruby ( 173196 ) on Monday February 07, 2005 @03:57PM (#11600404) Homepage Journal
    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.
  • by Durandal64 ( 658649 ) on Monday February 07, 2005 @04:01PM (#11600448)
    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 agree that the english-language syntax, while being great for beginners, is a huge hinderance when you're trying to write larger applications. I grew up with C-style languages, where you get visual clues for everything through its use of brackets, 'arrows', etc. None of that in AppleScript - just grokking the structure of the code takes a careful read-through where I'm used to being able to give it a glance because things like if-statements just physically look different from, say, a for loop.

      But reall
  • Python (Score:2, Insightful)

    by Anonymous Coward

    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

  • 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.
  • by Sophrosyne ( 630428 ) on Monday February 07, 2005 @05:21PM (#11601388) Homepage
    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
    • Normal Spacing: (Score:3, Informative)

      by Sophrosyne ( 630428 )
      (*
      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)

    by DaedalusLogic ( 449896 ) on Monday February 07, 2005 @05:23PM (#11601407)
    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...
  • Don't forget Xcode! (Score:3, Informative)

    by myov ( 177946 ) on Monday February 07, 2005 @06:23PM (#11601954)
    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.
  • Tiger is due out in a few months, so this book would be a bad buy if AppleScript changes a lot in Tiger.

    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...

  • 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

"The great question... which I have not been able to answer... is, `What does woman want?'" -- Sigmund Freud

Working...