Blog Archives

Script Editor battle

Here’s a short video showing some of the differences between Apple’s own Script Editor and my DisplayDroid.

If you haven’t got 5 minutes, the highlights include:

DisplayDroid shows result of each line of the script
DisplayDroid offers more informative error messages
DisplayDroid has automatic language detection (between AppleScript and JavaScript)
DisplayDroid allows you to set a breakpoint on any line in your script
DisplayDroid lets you step through the script line by line


applescript: toggle Notification Centre (Yosemite)

Notifications Center

Ever since Apple introduced Notification Centre, scripting it has been anything but easy.

I’ve seen brutal shell scripts and a variety of GUI scripts that variously work in Mountain Lion and Mavericks to turn ‘Do Not Disturb’ on and off. With Yosemite, Apple made yet another change to the ui process that controls Notification Centre, which means scripts like this one will choke.

If you’re wondering how to simply toggle whether Notification Centre is enabled or not with AppleScript on Yosemite, here’s the trick (whether this will continue to work in 10.11 is anyone’s guess** — see the comments below for the El Capitan version).

Enjoy it while it lasts! 🙂

tell application "System Events"
    tell application process "SystemUIServer"
            if exists menu bar item "NotificationCenter, Do Not Disturb enabled" of menu bar 2 then
                key down option
                click menu bar item "NotificationCenter, Do Not Disturb enabled" of menu bar 2
                key up option
                key down option
                click menu bar item "Notification Center" of menu bar 2
                key up option
            end if
        on error
            key up option
        end try
    end tell
end tell

applescript: make your own battery health meter

A couple of weeks ago, I posted about how to extract numbers from strings. That led one reader to wonder what use they could make of such a handler. That sounded like an invitation for a little AppleScript tutorial, so in this post we’re going to build our own, colourful and highly useful battery health meter. In the process we’ll not only use the numbersInString handler I posted last time, but learn how to make our AppleScript displays a little more colourful by adding images, and we’ll take a quick look at some very useful Bash utilities that will do some of the heavy lifting for our little app. So, open up your AppleScript editor and let’s get started!

Step 1. Grab the returnNumbersInString(inputString) handler I posted here, and paste the code into a new, blank AppleScript editor window. Hit ‘cmd-K’ to turn it into ‘pretty text’ and check that it compiles OK.

Step 2. Underneath that, hit return a couple of times to create some white space, and define a new handler like this:

on powerstats()
set iconAC to ""
display dialog iconAC & "Power Source: " with icon 1
end powerstats

Hit ‘Cmd-K’ again to compile, then underneath our new powerstats handler, hit return to make some space again and type


Hit ‘cmd-R’ this time, which will build and run our code at the same time, and you should get the nice if not terribly useful result as so:


Believe it or not, that’s all it takes to get the core of our app, and all that remains now is to fill out the powerstats() handler and the display dialog command with the details.

Step 3: You might have been wondering what that ‘iconAC’ variable at the beginning of the display dialog command was doing, since all we did was set it to an empty string with “”. That was a placeholder. Let’s put something in it.

First, place the cursor between the two quote marks in the line that reads

set iconAC to ""

Now, either use the keyboard shortcut control+command+spacebar, or open the Character Viewer from the Keyboard menu bar (check the System Preferences > Keyboard | Keyboard: Show Keyboard & Character Viewers in menu bar item if necessary). Pick an image you like to represent AC Power. You can find the same image as I used by typing plug in the search/filter bar, but feel free to choose any image you like.

When you find the image you want, double-click it, and you should see it inserted between the quotation marks in your AppleScript. With the cursor placed immediately after the plug character but before the final quotation mark, hit the space bar three times. That’ll position it just nicely with our ‘Power Source:’ text:


OK, we’re going to set the other images we need in the same way. So, now place the cursor after the quote marks on the ‘set iconAC ‘ line, and hit return to create a space between that line and the display dialog line.

Now add the following lines, but do not include the words in orange like #battery after each set of quote marks. I’ve included those here just as search tips to help you find appropriate characters in the Character Viewer. As before, put the cursor between each set of quote marks and use the suggested orange words to find the images. Of course, you can use any image you like, but don’t forget to add the three spaces after the ASCII image.

set iconBatt to ""    #battery
set iconCharge to ""    #voltage
set iconTime to ""    #clock
set iconHealth to ""    #clover
set iconCycles to ""    #cyclone
set iconWarning to ""    #warning

Now we’re going to update our Display Dialog command so that we get the images at the beginning of a new line. We do that by adding

& return &

between each variable. Also, we don’t need all the images (iconBatt and iconAC are alternatives, and the warning sign appears elsewhere), so we’ll just add the ones we know will always be displayed. Finally, we’ll add an extra

return &

between iconTime and iconHealth to create some space. Update your Display Dialog command so that it now looks like this:

display dialog iconAC & "Power Source: " & return & iconCharge & return & iconTime & return & return & iconHealth & return & iconCycles with icon 1

When you hit ‘cmd-R’ it should now give you this:


Step 4: Ok, we’re done with the images, but not quite with the Display Dialog command. We need some more static text in there, so edit the command to look like the following:

display dialog iconAC & "Power Source: " & return & iconCharge & "Current Charge: " & return & iconTime & return & return & iconHealth & "Battery Health: " & return & iconCycles & "Cycles: " with icon 1

Be careful to ensure you close every quote and add an ampersand between every term and every return, or your code won’t compile correctly. Feel free to cut and paste it from above if necessary, but you should now have something like this:

add static text

This is all the ‘static text’ — text that will appear every time we run the script. As you can see, there’s some parts missing, as they will need to be added depending on the state of our battery.

Step 5: Coding time! We need to get our data for the battery before we can do much else, and for that we’re going to use a couple of unix utilities. Rather than messing around in Terminal, though, we’re going to let AppleScript manage them for us using the ‘do shell script’ command. First, we’ll ask pmset for a load of information about the machines power management settings, then we’ll ask grep to narrow it down to just the bits we’re interested in. To do all that, we’ll add the following short but powerful command to our powerstats() handler. Place the cursor on a new line after all the set icon commands, but before the Display Dialog command. Then type the following:

do shell script "pmset -g everything | grep Cycles"

Now run the script again and hit the “OK” button. The dialog will look the same as before, but this time we’re interested in what is in the ‘Replies’ (not ‘Result’) panel in the lower half of the AppleScript editor:


Note you won’t see this until after you hit the “OK” button on the dialog panel. What we need to do now is capture this result in a variable so that we can start extracting some of those useful numbers, so immediately underneath this line, add:

set x to the result

set x to the result

Step 6: In order to understand what follows, temporarily add the following two log lines:

log word 1 of x

Now run the script. Run it once with the power supply connected, then again with the machine running on battery power and compare the output in the ‘Replies’ field after you’ve hit the “OK” button.

The output of the log lines is shown in the Replies field between

(* *)

and they tell you the values of the variables. “Word 1” is the first text item in the result (exactly what delimits text items in a script depends on a built-in AppleScript variable called text item delimiters, which you can read about here).

If the AC Power is connected, word 1 should be “AC”, otherwise, it should be “No”. Similarly, word 2 should be either “charging” or “not” (sometimes the battery doesn’t charge due to a poor connection or if its more than 95% full). If AC is not connected, Word 2 should be “AC” (Word 1 and 2 together, in this case read “No AC”). However, different macs may have different power management options, so do some tests and check that you get the same results. If you don’t, you’ll need to experiment logging different words to find out which words correspond to my ‘word 1′ and word 2’. Here’s a summary again of the word numbers you need to determine for each of the values, with those on my machine given in brackets:

AC connected: word (1)? = “AC”; word (2)? = “charging” or “Not”
On battery power: word (1)? = “No”; word (2)? = “AC”

If your machine gave different results, make a note of which word number corresponds to my word 1 and word 2, and wherever I mention ‘word 1’ and ‘word 2’ in the scripting below, substitute those for the correct word numbers you found in your tests.

That these words always appear in the same position on the same machine is a very handy fact that makes it easy for us to determine whether the mac is running on battery or mains power, and in the latter case whether the battery is charging or not.

In the next step we’ll now put this information to good use in our script. First, however, remove all the log messages from the script.

Step 7: It’s time to add some more code to our powerstats() handler. Add this conditional test to your script, remembering to substitute any differences in word number you found in your logging tests:


This code assumes the AC is connected and sets the variable ‘charger’ to display whether the battery is charging or not. However, we need to set that variable to an empty string if the mac is running on battery power, so immediately underneath add another conditional:


In the Display Dialog command, replace iconAC with pwrSource as indicated in the image above. This will allow the Display to change the image accordingly. At this point, compile and test your script, both with the power supply connected and disconnected, ensuring that the icon changes accordingly.

If that’s working as expected, add the variable _t to the Display Dialog command immediately after the iconTime variable. Don’t forget to add another ampersand along with it as shown:

Again, compile and test your script, both on battery and AC Power.

Step 8: Time to do some math. You may remember we started the script by adding the returnNumbersInString(inputString) method, and now it’s time to use it. We want to extract all those numbers returned by the do shell script command, and currently stored as a text string in our variable, x. We’re going to need some of them as numbers because we’re going to perform some math on them to get the battery percentage health.

Start by adding the following line, which calls the handler and gets the numbers back as a list of integers:

Item 1 of nums should be the battery’s current charge. Test this by adding a temporary log statement immediately after the set nums line:

log "item 1 of nums is " & item 1 of nums

Run the script, hit “OK”, and examine the Replies panel. Compare the output of the do shell script statements, and it should be clear whether you’ve got back the battery percentage or not. If not, continue logging till you hit the right item number. I’m going to assume that you got item 1 (if you didn’t, replace my mention of ‘item 1’ with whatever yours was in the following lines), so let’s remove the log statement, and replace it with this:

set percentage to item 1 of nums & "%".

Now, down in the Display Dialog command, add the variable ‘percentage’ and another ampersand in the place shown:

Screen Shot 2014-08-25 at 21.24.08
Run the script and hopefully you should now see that your battery percentage is correctly shown:

show battery percentage
Looking at the display reveals we haven’t added in the Power Source variables to the Display Dialog which we defined earlier, so do that now:

pwr & charger

Step 9: The next step is to add the time, but this is tricky on several counts. First, if you examine the number returned by do shell script in the Replies panel, you’ll note the hours and minutes are colon-separated. As far as our list is concerned, that makes them two different items, so we have to get the hours and minutes separately (items 5 & 6 on my machine; use logging to check what they are on yours).

Secondly, if the minutes are between “00” and “09”, AppleScript will just return a single-digit between 1-9, cutting of the “0”. That’ll mean we’ll end up with a weird display for say “1:05” as “1:5”. To counter that, we’ll have to test whether the minutes is less than 10 and add a “0” back in to the string if so. Also, we’ll have to add “hr”, “hrs” or “mins” depending on how much time is remaining or left to fill the charge.

As if that wasn’t enough, there’s a problem with the power manager: if you use Apple’s battery/power icon in the menu bar, you’ll notice that if you click on it straight after changing the power source, you’ll get a “Calculating Time till Full” or “Calculating Time Remaining…” message. That’s because it takes a minute or so for the power manager to update. The menu bar icon will update live, but we don’t have that luxury. Instead, we’ll add a warning later to alert users to this and ask them to run the script again after a short delay.

Woah. That’s a lot of conditions, so here goes. Add the following immediately above the Display Dialog command:

if item 5 of nums = 0 then
set hrmins to " mins"
else if item 5 of nums = 1 then
set hrmins to " hr"
set hrmins to " hrs"
end if
if item 5 of nums is greater than 4 then

if pwr is "AC" then
set t to "Calculating...try refresh in 2 mins"

end if

if item 6 of nums is less than 10 then
set theMins to item 6 of nums as string
set theMins to "0" & theMins as string
set theMins to item 6 of nums as integer
end if
set t to item 5 of nums & ":" & theMins & hrmins
end if

And for all that code, we only need to add one variable and an ampersand to our Display Dialog:

Step 9 v2

There is one remaining problem, which is that if you run the script immediately after changing the power source, although the message “Time to Full” or “Time Remaining” will change, the time itself may not. This is for the reason stated earlier: its inherent to the way the power manager works. We’ll do our best to help the user by adding a Refresh button later, but otherwise this is a shortcoming we’ll have to live with.

Step 10: It’s now time to get down to the real point of this script, which is to tell the user something that the battery meter in the status bar does not: the battery health and the battery cycles. The number of charge cycles the battery has been through is, naturally, given by the ‘Cycles’ figure. Battery health, however, is not data outputted natively by the power manager. Rather, it is a percentage of the Battery’s design capacity and its current ‘fully charged capacity’ or FCC. As you might expect, these two figures are represented in the do shell script output by “Design” and “FCC”, and it is largely because we need to do a mathematical operation on these that we needed the numbersInString handler.

To figure out the Battery health, we’ll divide the Design capacity by 100 to obtain 1%, then divide the FCC by this number to figure out how many percent it is of the Design capacity. That bit of math is represented by the function FCC/(design/100). In order to avoid a whole load of decimal places, we’ll also use AppleScript’s built-in round() handler to return a whole number. Finally, we’ll add the “%” sign to the string and add the ‘battHealth’ variable to the ‘Display Dialog’ command.

Here’s the code to be added, again after the last line and before the Display Dialog command (reminder: don’t forget to check using the logging technique I showed earlier that your item numbers are the same as mine, and to substitute your own for mine if they are different):

set FCC to item 3 of nums as integer
set designCap to item 4 of nums as integer
set battHealth to (FCC/(designCap/100))
set battHealth to round(battHealth)
set battHealth to battHealth & "%"


Don’t forget to add the battHealth and ampersand to the Display Dialog, as shown above.

Step 11: Almost there. Let’s add the Cycles, which is fortunately a simple one liner:

Does that say minus 3? Yes indeed it does! A little trick with AppleScript lists and strings is that you can count items backwards from the end using the minus sign,where -1 is the last item, -2 the item before it and so on (I thought I’d just throw that in as an extra since this command was so straightforward!). As always, check the position by using logging in your own script.

Step 12: If you run your script now you should find it’s complete. To wrap up, we want to go back to where we started, and that’s improving the look and functionality of our Display Dialog box. The first thing to do is fix the buttons. We don’t need a “Cancel” button, since the “OK” button does the job of dismissing the script, but we would like a “Refresh” button, so the user can run the script again from the dialog box. To add the the buttons, change the Display Dialog command and add a conditional statement after (not before this time) it. We’re also going to add a title for the box while we’re at it:

refresh button


Step 13: Your script is done, but to really finish it off, we should turn it into an app that we can run off the Dock, and to which we can add a custom icon. To create an app, choose “File > Export” and change the File Format to App. Give your script a name like “batteryPowerStat” and save it in your Applications folder.

Step 14: All you need now is an icon. You can either make your own, or you can download mine. Once you have an icns file, change its name to ‘applet.icns’ and add it to the Application bundle. To do that, control-click on your new app in the Finder, and choose ‘Show Package Contents’. Navigate to Contents > Resources, delete the file that currently exists there called ‘applet.icns’ and replace it with your custom icon.

You may need to log out and log in again before OS X flushes the old file from its memory and displays your new one.

Step 15: Only kidding! There is no step 15. 😀 I just wanted to stay “Congratulations”. If you made it this far, I hope you picked up a few AppleScript tricks along the way to creating your own battery health meter. If you need the complete code, you can find it on my Pastebin site here.

Enjoy! 🙂

how to save and print email attachments

I was recently asked for a script that would automatically save and print all the pdfs from one particular client’s emails. Since this is quite a common use case (think invoices from a particular supplier, for example) and involves a fair bit of complexity, I thought I’d share the answer for any others out there that have the same need.

We’re going to need to do three things; install a script, set up a mail rule, and set up folder actions. Here we go!

Part 1: Install Script

Copy and paste the script you see below from here:

save mail attachmentsSave this script with a name like ‘CopyAttachments’ in

~/Library/Application Scripts/

(note: ~/Library means your user library. You can find it by triple-clicking the path above, then control-click on the highlighted text and choose Services > Reveal in Finder)

Part 2: Set up Mail Rule

Open Click on your Inbox in the sidebar. Click ‘Mail > Preferences… > Rules > Add Rule’

Under ‘Description’ give the rule a name (e.g., ‘Copy attachments’)

Set ‘If ANY of the following conditions are met’:


‘From contains’

and the email address of the person whose attachments you want to target.

(note: You can add more than one person’s email if you wish, but you do so by hitting the ‘+’ key and adding a new condition, not by adding more than one address in the text field. Each text field must contain only one condition, i.e., email address or keyword).

Next, set ‘Perform the following actions:’


‘Run AppleScript’

Click the ‘No Script Selected’ button and choose ‘CopyAttachments’

Click ‘OK” and in the following dialog click ‘Apply’.

3. Create & Set up a Folder Action

Open From the open panel choose ‘Folder Action’.

In the large, empty panel at the top you’ll see

‘Folder Action receives files and folders added to’ Choose folder

Click the Choose folder menu, choose Other. Select the folder you want the attachments to be saved in.

In the filter/search bar on the left of the Automator window, type ‘print images’. Drag the ‘Print Images’ selection from the results list into the middle of the empty workflow and release.

You can set some options here if you like (‘scale to fit’ might be useful).
You can choose either ‘Default Printer’ or click to select your actual printer. If your actual printer is the default, it won’t make any difference.

Press ‘command-S’ on your keyboard to save. Supply a name (e.g. Print PDFs) and hit ‘OK’. You do not choose a save location.

Quit Automator.

Open a Finder window and navigate to the folder where the attachments are going to be saved.

Hold down the ‘control’ key on your keyboard and click the attachments folder. From the contextual menu, go to Services > Folder Actions Setup… and click to open the dialog box.

Navigate down the list of scripts till you see the name of the Automator action you saved above and select it. Click ‘Attach’.

In the parent dialog box, check the box at the top that says ‘Enable Folder Actions’ and ensure that in the list on the left the attachments folder is listed and checked. Check that on the right, the ‘Print PDFs.workflow’ is checked.

If all is in order, close the dialog box. The procedure is complete and the workflow is installed.


It’d be wise to test the script as soon as possible. If it fails to work, double check that you’ve entered the correct path in the AppleScript as that’s the most likely point of failure. Let’s suppose your hard disk is called ‘Macintosh HD’, your user name is “Mack” and the folder you want to save the attachments in is “Invoices From Acme”, then the set attachmentsFolder line should look like this:

set attachmentsFolder to "Volumes:Macintosh HD:Users:Mack:Invoices From Acme:" as rich text

You must ensure you’ve already created the folder ‘Invoices From Acme’ before running the script. Also, be sure you don’t forget the trailing colon at the end of the path and that you have a matching pair of opening and closing quotes around the path name.

Any problems, drop me a comment below and I’ll try to help you out. Good luck and enjoy! 🙂

Contacts won’t launch

Screen Shot 2014-03-04 at 21.42.46
I’ve seen this problem crop up from time to time, and it seems to have reared its head again with the 10.9.2 update *.

Try running the following script in AppleScript editor:

tell contacts to activate

If you get an error message back from the AppleScript editor mentioning error number -10661 has occurred, then you’re going to need the following procedure.

The problem stems from the launch services database being out of sync and not knowing which app to launch when it gets passed “Contacts” as input. To solve that, we’re going to do a couple of things in Terminal (roll up your sleeves!).

First up, we’re going to ensure that the locate database is loaded. We’re going to need that to find the address of the Launch Services database, so

1. Open (/Applications/Utilities/ and type

locate lsregister


You should get one of two possible results. Either you get a message telling you that the locate database doesn’t exist, and instructions on a command to run to create it:

sudo launchctl load -w /System/Library/LaunchDaemons/


or you get a path back that looks something like



In the first case, use the command suggested in the reply to create the database. The Terminal prompt will probably reappear almost instantaneously after you run that, but your database may not have finished creating yet. Wait a few minutes before running the ‘locate lsregister’ command again.

In the second case or once you’ve got your locate database loaded and working, copy the address returned to the clipboard by dragging across the whole thing to highlight it and hitting ‘command-C’ on your keyboard.

Still with Terminal active, hit ‘command-V’ to paste that address at the prompt. Hit the spacebar once, and then complete the command by adding

-kill -r -all l,s,u


So the whole thing should look something like this:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -all l,s,u


Finally, hit ‘return’ to enter the command. It’ll take a few seconds to return the prompt (it’s about 10 seconds on my machine, but your mileage may vary).

After the prompt returns, go test that AppleScript again. Hopefully, Contacts fires up without issue. 🙂

*Thanks go to Yvan and Deivy on the AppleScript users list for identifying and solving this problem.

the end of “tell”?


With all the excitement over Mavericks’ fancy new apps, memory compression and Finder enhancements, perhaps one of the most revolutionary changes to go largely unnoticed is to the venerable (yes, it’s 20 years old, this year!) programming language AppleScript.

Apple have quietly introduced a new command to the AppleScript language called ‘use’. In effect, ‘use’ replicates the preprocessor ‘import’ directive familiar to Objective C users or the ‘include’ directive known to C programmers. This is likely to have a radical effect on how people learn and write AppleScripts.

Although ‘use’ seems primarily intended as a means to turbo-boost AppleScript by making available Objective C methods to scripters, it can also be used to import the scripting language of any app on your system. With that power, the whole concept (and limitations) of the ‘tell’ block are done away with. To see how this works in practice, take a look at this short script for toggling Bluetooth depending on your power source that I wrote pre-Mavericks, using tell statements and blocks:

toggle bluetooth using tell

Compare that with how we will do it now in 10.9 with the ‘use’ statement*:

toggle bluetooth with 'use'

Not a ‘tell’ in sight! Note the three ‘use’ declarations at the beginning of the script. The first one tells the script editor to include terms from System Events scripting dictionary. The second one does something similar with terms from System Preferences, but you’ll notice the syntax is slightly different. In the second declaration, I’ve taken advantage of the optional means to define a global text substitution for the expression “application System Preferences”. If you’re familiar with the #define directive in Objective C, or with using global properties in AppleScript of old, you’ll understand how this works. If you’re not, the short version is that we’ve declared a global variable of the sort which allows us to use the expression SysPrefs wherever we would normally have used the string application "System Preferences".

Don’t overlook the third ‘use’ statement in my example script above. Using ‘use’ effectively disables scripting additions (that includes all your familiar ‘display dialog’, ‘clipboard’, ‘path to’ and other essential expressions). In short, if you include any ‘use’ statements, be sure to also add the ‘use scripting additions’ statement, too.

There’s a lot more to using ‘use’ (you can read the full documentation here), but overall I think this is a positive change. However, if you’re fond of ‘tell’ don’t despair. At least for now, there’s no sign that ‘tell’ is being deprecated and you can carry on using it just as before.


*Note that there are other changes in the Mavericks version of the Bluetooth toggle script (in the ‘if…else’ blocks) due to the fact that Mavericks has changed the Bluetooth system prefs pane.

get computer’s local & external IP address

Here’s an AppleScript you can save as a service that will show your router’s IP, your local network node and your external IP, if connected. Save it as a service and you can assign it a nice little hotkey. Pressing the ‘Copy’ button will display a menu that lets you choose which IP address you want to copy to the clipboard. If the connection request returns a timeout, hit the ‘Try Again’ button (or check your connection… 😉 ).

Tip: If you’re not familiar with using AppleScript yet, see my intro getting to grips with AppleScript for a guide to the basics! If AppleScript’s not your thing at all, download my free app FastTasks that will show you all your IP addresses and a whole lot more too!


Copy the entire code from Pastebin

copy the code from pastebin!

Related Posts:
FastTasks – download the free utility app from Applehelpwriter

search Safari Reading List

This is something I’ve been thinking about for a while. I have a pretty long Reading List and Spotlight often fails to find things in it. For that reason I came up with this little script which you might find useful.

1. Open up Automator by typing auto in Spotlight.

2.  Click on ‘Service’ (the big cog wheel) and then ‘Choose’.

Automator Service

3. Change the Service receives option to “No input” from the dropdown menu.

4. In the small filter bar to the left, type ‘run app’. You should see an action called ‘Run AppleScript’ in the second column. Drag it to the big pane on the right.


5. Select all the purple text inside the window and delete it. You don’t need any of it.

6. Command click on the image below, and copy the code from the pastebin page that opens up in another Safari tab. Paste the code into the Automator pane.


7. Hit ‘Command-S’ and give it a name like ‘Search Safari Reading List’. Click ‘Save’ (note: you do not specify a location for the save as it will automatically be saved in your ~/Library/Services folder).

8. Now click on the main menu for any app and have a look in the Services submenu. You should see your new service there (to add the keyboard shortcut, see Step 10 below).

9. Test it to make sure it works as expected. You should end up with something that looks like this:


10. If you want to assign a universal shortcut key like mine in the screenshot from Step 8, do so by going to  > System Preferences > Keyboard > Keyboard shortcuts. Look in Services for the name you gave it and add the shortcut by clicking in the empty space to the far right of the name.


A note on usage:
The reading list is really just a list of special bookmarks, with one difference: they contain short snippets or previews from each page. This has an impact on the way my script works in the following way: if the search string is in the preview snippet but isn’t in the URL, you’ll get back the line from the snippet but you won’t get the URL. It might be possible to code round that, but I haven’t had time to figure it out yet. If that’s a feature you want, send me a nag mail and I’ll put it on my list of things to do! ;). Otherwise it appears to function quite well as a workaround for the lack of a proper search facility.

eject all your disks at once

script menu

Here’s a simple AppleScript one-liner that can be useful if, like me, you have several disks connected to your laptop at home or the office and you need to get up and go quickly.

1. Open the AppleScript by typing Apples in the Spotlight search bar and hitting ‘return’.

2. Copy the following code into the editor window:


3. Hit ‘Command-K’ to compile and ensure you didn’t make any mistakes. Fix any typos if it doesn’t compile and try again. Save the script to your Desktop as ‘EjectAll.scpt’

4. If you don’t already have the Scripts menubar icon visible in your menu bar, hit ‘command ,’ (that’s the Command key and the comma key) and check the ‘Show Script menu in menu bar’ item in the General pane of AppleScript’s Preferences window.

AS prefs
5. From the Scripts menu, choose ‘Open Scripts Folder > Open Computer Scripts Folder’ and drag ‘EjectAll.scpt’ from the Desktop to the Computer Scripts Folder. You’ll need to authenticate with an Admin password to complete the move.

And that’s it. Now whenever you want to eject every disk with one simple operation, just hit the Script menu icon and click on ‘EjectAll’. 🙂

getting to grips with AppleScript

Wall and paper stencil

Learning AppleScript is probably the second most productive thing you can do (the first is learning the Terminal) to improve your Mac experience. You know all those utilities that you see in the Mac App Store, on MacUpdate and so on, with developers charging anything from 99 cents to $20? Well, many of those are just doing simple jobs that you can actually script yourself for free with a little learning of OS X’s unique scripting language (and, indeed, some of those apps have been built in exactly this way).

To keep this post short and practical, I’m going to leave aside the wider discussion of what AppleScript is (and isn’t), what it can (and can’t) do and all manner of other interesting but theoretical things, and instead give you a taste of what you can do with it. I’ll give you some references at the end where you can find out more and learn everything you need.

Let’s get straight to it. Open up the AppleScript Editor by opening the Spotlight search bar and typing Apples. Hit ‘return’ and you’ll be faced with a new editor window. Let’s type something in it.

tell application "Finder"
display dialog "What's your name?" default answer "" with icon note
set myName to the text returned of the result
delay 0.5
display dialog "Hi there, " & myName & "! Welcome to AppleScript!" with icon note
end tell

You could just copy and paste this into the editor, but I’m going to recommend that you don’t. There’s a good reason to take the tedious route and type it in yourself. Like learning a human language, learning a computer language requires using it, and using it repetitively. As you type in the language, you’ll get a feel for its syntax that you won’t get if you just copy and paste. And, unlike a real human language, learning a computer language’s syntax is pretty much the whole battle of mastering it.

After you’ve finished typing, press ‘Command-K’ on the keyboard. If you typed everything correctly, you see the script change into a multi-colored jamboree, like this:


If you weren’t so lucky, examine what you typed against what’s on the page here. Part of the frustration of any computer language is rooting out typos! Eventually, you get a feel for it and start to learn where to look first, based on the error messages you see. For now, you’ll have to peck and hunt (if you get really fed up, you can always go the cut-and-paste route!).

Assuming you’ve got your script to compile, now it’s time to run it and see what it does. Hit ‘Command-R’ (you can of course use the icons in the toolbar for compiling and running, too) and you should get this:

what's your name?

So go ahead, type your name!

OK, you’re getting the idea. Let’s try something different. Press Control-N to open up a clean editor window and enter this:

say "What's your name?" using "Vicki"
display dialog "My name is " default answer ""
set myName to the text returned of the result
say "His name is " & myName using "Vicki"
say "Welcome to AppleScript, " & myName using "Alex"

As before, press ‘Command-K’ to compile and ‘Command-R’ to run.

As you can see (or hear!), you can even have your computer continue a dialogue (with or without you!) using OS X’s many voices.

It’s worth noting that this feature is extremely useful if you’re learning a foreign language.

The Voices options in System Preferences > Dictation & Speech | Text to Speech | System Voice include many optional voices that you can download that will speak foreign text. You can paste the target text into a dialog box (like the ones you just created), and then listen and practice your language skills as repetitively as you desire. For those wanting to learn Thai, for example, download the voice “Narisa”. You can paste Thai script from the web or from the (if you have the Thai extension installed) into a dialog box and have “Narisa” say it in a very passable Thai accent. Great for learning!

One last one. How about your own screencapture program? Tired of remembering those shortcut keybindings, or having to fire up Preview or SnagIt for the occasional screen grab? Why not have your own app in the Dock that captures the screen with a single click? Here’s how:

Open a new editor window and enter this (in this case, you might want to copy and paste it, for reasons I’ll explain shortly):

do shell script "screencapture -x ~/Desktop/" & time string of (current date) & ".png"

Do the Command-K thing, but then this time do Command-S instead of Command-R. From the resulting save box, change the File Format near the bottom of the box from ‘Script’ to ‘Application’. Give it a fancy name (ScreenGrab, say?) and save it in your Applications folder.

applescript save as

Once that’s all done, go to your Apps folder, grab the and drag it to the Dock. Clicking on it puts a timestamped screenshot on your Desktop. If you’ve got multiple spaces open, flip between them clicking the ScreenGrab app. That’s one easy way to get a record of your entire set up! Cool, huh? (Don’t forget you can easily change the icon in the Dock for something more to your taste, as I explain here. Also, if you don’t like the / delimiters in the file name, use this version for your app.)

That last little script demonstrates one of AppleScript’s most powerful features: the ability to run other scripts (and apps). The command in the last script (and the reason why I suggested you paste it) was actually a Bash shell command (aka Terminal command), and we know those are very easy to mistype! AppleScript can actually run the commands of many apps from within its own scripts, putting the power of those apps at your disposal (and that includes some apps you’re very likely familiar with, like Word and Excel).

I hope this short intro has given you a taste for exploring AppleScript and finding out more. It’s an incredibly powerful language that you can use to enormous advantage, and profit. In order to do that, you’ll need to go on a learning adventure, but I promise, the following sources will make that relatively painless!

If you’re absolutely brand new to AppleScript, then the must-have starter’s book is

AppleScript 1-2-3

Once you’ve got through that you’ll be able to pretty much teach yourself the rest, picking it up from sources like

Other references you should consult once you’re up and running are

Learn AppleScript (Sanderson)

and don’t forget Apple’s own free guide:

AppleScript Language Guide which you can also download as a PDF for offline use.

Finally, my Mac OS X Technologies User Tip contains some of the above links as well as others that may be of interest.

Happy scripting! 🙂

Featured picture: wall and paper stencil by -endlesshate

%d bloggers like this: