Applescript is the under-rated yet very wonky (and sometimes not endearingly so) scripting language created by Apple. Apple downplays Applescript quite a bit these days, but it still very much has its uses. It is also where I got my start in programming, and this page is here as a resource to non-developers-turned-developers in my position of not finding enough “rubber meets the road” snippets to at least get the project on its way. Here I dispense with the usual “here is a variable and here is a subroutine” content because there are already enough resources out there like that, though I may add that content at a later date. But almost all of the basics can be gleaned from the snippets provided.
I’ve done a lot of programming in my time, but I have clocked more hours with Applescript than anything else.
- Applescript Language Guide: The definitive guide from Apple. Unless there is a question about scripting an application, all queries should start here.
- Mac OS X Automation: This used to be part of the Apple website but has since been made independent of Apple.com.
- MacScripter: I have yet to have a question that either hasn’t been asked already or not been able to get some kind of clue to do what I want to do.
- Script Debugger: There are two good Applescript-native code editors out there that I know of, Apple’s and Late Night Software’s. If anyone intends to do anything even remotely serious in Applescript, Script Debugger is invaluable. It picks up where Apple’s Script Editor leaves off and offers some tools found in higher end IDE/RADs.
About the Snippets
The code snippets on the right are a supplement to the snippets given in Apple’s Script Editor, Script Debugger, the Applescript Language Guide, and on the Mac OS X Automation Website. However, some of their code might have made it into this site unintentionally. All code is available under the MIT license, though some code is copyright their respective owners, and every effort has been made to exclude their code from this site.
Every attempt has been made to keep the formatting of scripts and their snippets as consistent as possible, but this sight was created from my own “private stash” collected and curated over many years of working in Applescript.
Wherever reasonable snippets are displayed in subroutines with the following formatting:
my SubroutineName(InputArgument) -- if no value is returned set theReturnedValue to SubroutineName(InputArgument) of me-- if a value is returned on SubroutineName(InputArgument1[, InputArgument2, ...]) -- (datatype) as datatype -- subroutine code end SubroutineName
This is done largely to make the snippet as useful as possible without having to regard surrounding context; in other words to make it as modular as Applescript will allow it to be. Otherwise, as much information will be given, if needed, to integrate the code into a script. Sometimes, this means that the snippet will look like a complete script with properties, globals, and the like.
My vs. Me with Subroutines
Applescript is unique in its requirement to use the
my keywords so much. The purpose of the keywords is to direct the given command to the appropriate script object, for example a script that is linked to another. But this isn’t immediately obvious when writing a self-contained script, but the error comes up when needing to call a subroutine multiple times and it isn’t immediately obvious to the beginning scripter that this is required. I use either the
my keywords on every subroutine every time I call it, even if I know I’m going to use it only once.
One Last Note About Style
I prefer readability and self-documenting code over all else. There are few things I do that require any real hard optimization of processes and functions so longevity of the code takes precedence; I want to be able to read what I did five years just as well as what I did yesterday, and I have been able to do exactly that (for the most part, my earliest code was pretty bad).