Category Archives: AppleScript
At our house, giving visitors the wifi password is always an exercise in frustration. Can’t remember? Oh, then I’ve got to either go trawling through Keychain Access or log in to the router, neither of which are particularly appealing.
Here’s an easier way. It’ll require an admin password (and you’ll need to supply it for as many passwords as you’re looking for – no ‘with administrator privileges’ will help here I’m afraid), but otherwise requires nothing more than a quick double-click of this saved script, once you’ve added your own SSID names in place of the dummy ones.
Just to be clear, you do NOT need to add the passwords to the script. So long as the mac that you run this script on already knows the Wifi password, the script will retrieve it.
One of the things I find intrusive are the constant Swift Compiler warnings while I’m actually in the middle of writing a block of code (e.g, ‘…value was never used consider replacing…’). Well, yeah, it’s not been used *yet* …grrr!
However, turning off compiler warnings isn’t something I want to do either. It’s too easy to go into the build settings, turn them off, do a bit of coding, take a break, do a bit more coding…oh, three thousand lines later and I suddenly realize why Xcode hasn’t been correcting my mistakes all afternoon!
This script allows you to quickly and easily toggle the warnings from a hotkey, and just gives you a gentle reminder as to what you’ve done. Of course that won’t stop you forgetting, but assigning a hotkey for this script makes it painless to just turn warnings off and back on again as soon as you’ve got past whatever bit of code the compiler was complaining about.
Xcode unfortunately doesn’t have its own scripts menu, so in order to assign the script a hotkey, you’ll need to either make it into a Service with Automator or use a script runner like Red Sweater’s FastScripts.
display notification "Suppress Warnings was set to " & aVal with title "Swift Compiler - Warnings Policies"
tell application id "com.apple.dt.Xcode"
tell its front document
tell its front project
tell its front target
tell its build configuration "Debug"
set b to build setting "SWIFT_SUPPRESS_WARNINGS"
if b's value is "NO" then
set b's value to "YES"
set b's value to "NO"
my sendNotification(b's value)
do shell script "SD=~/.spindump.txt; rm $SD; spindump 1 1 -file $SD; grep 'Fan speed' $SD; rm $SD" with administrator privileges
Copy and paste the above into your (Apple)Script Editor and run it. You’ll need an Adminstrator password.
However, that doesn’t really tell you what you want to know: is my mac too hot or not? Should I do something about it?
Fortunately, we can get a better idea of the mac’s thermal state (and we don’t need admin privs to do it!), with this script:
The script not only reports the mac’s thermal state, but prints out Apple’s recommended advice, if any. Uncomment the last line of the script to get the result in a display dialog box; otherwise, you can just read the result in the results pane of your script editor.
Featured Image: Flicker
The idea behind BackupCam is to keep a continuous, rolling video of the last few minutes of activity on your mac, in just the same way as dash cams in cars work.
There’s a couple of scenarios where this might be useful. If you’re working on a project where ‘undo’ doesn’t always work reliably or when you most need it to – Xcode, for example, can often let you get your project in a mess without offering you a clear path as to how you got there or how to get back, short of discarding all changes in a particular file – with BackupCam you’ll be able to see exactly how you got to where you are.
Similarly, BackupCam can also help you to review changes that you may not have noticed at the time – perhaps if you were distracted by something else happening, either on screen or off. This can help both as a security and a troubleshooting tool
BackupCam can record up to the previous 30 minutes activity, so may help you recover something that is missed even by Time Machine or other traditional file backup mechanism.
More details are over on the BackupCam webpage, but I’ll just note here that BackupCam can also be controlled by AppleScript, with all the flexibility that that offers. Here’s a sample script that checks whether the last recording was longer ago than the time interval set in BackupCam. If it is, it kicks off a new recording session:
BackupCam is still in the early stages of development (we’re calling v1 a beta), so please feel free to report any bugs or enhancments you’d like to see. At the moment, it requires 10.11.6 or higher and only records the main display. I plan to add support for multiple displays in a future update.
Is it me, or is AppleScript experiencing something of an Indian Summer? It seems everywhere I go, people are talking more about macOS automation, AppleScript and even Apple’s curious hybrid syntax AppleScriptObjC (ASObjC).
Of course, some people have suffered miserably at the hands of AppleScript in the past, and even though the thought of scripting with access to Cocoa APIs through Objective-C is tempting, they fear the AppleScript side of it.
If that’s you, bear in mind that AppleScriptObjC isn’t really “AppleScript + Objective-C” at all. It is actually just a dialect of Objective-C that will be accepted in the (Apple)Script Editor and can be run by an instance of the AppleScript component. In plainer English, you can use Objective-C in an AppleScript without any AppleScript whatsoever!
The point of doing so would be that one could package Objective-C code in a .scpt file (or scptd bundle or AppleScript .app), and also mix whatever scripting language you prefer with calls to Cocoa’s APIs.*
The problem that using ASObjC presents anyone familiar with Objective-C is how to translate ‘pure’ Objective-C into the dialect that Script Editor (and other applescript runners like FastScripts, Keyboard Maestro, Automator, etc) can understand. If you use LateNight Software’s Script Debugger for scripting, you’ll already know that the work is done for you by the app’s built-in code completion. If you’re battling on in Apple’s default Script Editor, you’ll need to do the translation manually.
By way of example, then, here’s some original Objective-C, and below it, a translation that would work in Script Editor:
NSString *aString = @"hello";
NSString *bString = @" world";
aString = [aString stringByAppendingString:bString];
NSUserNotification *notif = [[NSUserNotification alloc] init];
notif.informativeText = aString;
[[NSUserNotificationCenter defaultUserNotificationCenter] deliverNotification:notif];
set aString to NSString's stringWithString:"hello"
set bString to NSString's stringWithString:" world"
set aString to aString's stringByAppendingString:bString
set notif to NSUserNotification's alloc's init
set notif's informativeText to aString
NSUserNotificationCenter's defaultUserNotificationCenter()'s deliverNotification:notif
As you can see, there’s a direct 1-to-1 correspondence, with the 6 statements in Objective-C paralleled by the 6 statements in AppleScriptObjC.
The main peculiarity is the use of possessive word forms and that variable attribution is done by using
"set X to Y" rather than
"X = Y". Type declaration is done via the idiom
'set <var> to <NSObject>'s <class init method>', which returns an instance of the object just as it would normally. You call instance methods by putting the instance in front of the method just as you would in regular Objective-C (e.g, see line 3 of the examples).
As you can see in the screenshot below showing Xcode and Script Editor, they work in the same way. You’ll notice in Script Editor there is a
'use' statement (equivalent to Objective-C’s ‘import’), and there’s also a whole load of property statements. These latter are peculiar to the ASObjC translation, and don’t have a counterpart in pure Objective-C. All you need to know about these is for each kind of Objective-C object you want to use (NSString, NSArray, whatever*), you’ll want a property statement for it at the beginning of the script. The statement always has the same form:
property <NSObject> : a reference to current application's < NSObject>
I think the best way to think of ASObjC was recently summed up by Sal Saghoian, when he said that ASObjC is “…the ultimate duct tape. You can do anything you want with ASObjC. You own the computer.”
*not all Cocoa frameworks nor all Objective-C objects can be bridged to, but pretty much all the most useful ones are available.
I recently discovered a neat little extra automation tool on top of the familiar ones of AppleScript, Automator, and script runners like FastScripts and Keyboard Maestro. Meet Hammerspoon, which differs significantly in not using Apple Events to do many of its automation tasks. Instead, Hammerspoon bridges directly to Apple APIs using the lua scripting language, and that allows you to do some interesting things.
Here’s a good example. One of the ‘danger zones’ on your mac – by which I mean one of the favourite places for adware, malware and other assorted badwares to infect – is your LaunchAgents folders. Apps like my DetectX and FastTasks 2 keep an eye on these areas by design, warning you in the Changes and History logs when files have been added or removed from them – but Hammerspoon can add an extra little ‘canary’ warning for you too. With only a few lines of code in Hammerspoon’s config file, you can set up an alert that will fire whenever the LaunchAgents folder is modified.
It has been possible to rig up something similar for a long time with Apple’s built-in Folder Actions, but there’s a couple of reasons why I prefer Hammerspoon for this task. One, despite Apple’s attempt to improve Folder Actions’ reliability, I’m still not convinced. I get inconsistent reports when asking System Events to check whether Folder Actions is enabled even on 10.11 and 10.12. Second, Folder Actions is limited in what it will respond to. By default, only if an item is added. With a bit of effort, you can rig it up to watch for items deleted, too, but that’s pretty much it. With Hammerspoon, it’ll alert you whenever the folder or its contents are modified in any way whatsoever. The final reason for preferring Hammerspoon for this particular task is ease of use. It really is as simple as pasting this code into the config file:
hs.alert.show("Launch Agents folder was modified")
hs.alert.show("Canary folder was modified")
local aWatcher = hs.pathwatcher.new(os.getenv("HOME") .. "/Library/LaunchAgents/", myFolderWatch):start()
local bWatcher = hs.pathwatcher.new(os.getenv("HOME") .. "/_Acanary/", canaryFolderWatch):start()
And what’s the config file you ask? Nothing complicated! Just launch Hammerspoon, click its icon and choose ‘open config’.
That will launch your default text editor, and all you do is paste your code into there, save it (no need to tell it where, Hammerspoon already knows) and then go back to the Hammerspoon icon and click ‘Reload config’. That’s it. Less than a minute’s work!
There’s a lot, lot more you can do with Hammerspoon, so if you’re interested head off and check out the Getting Started guide. One of the nice things is that you can even call AppleScripts with it, so you really do have a world of automation options to choose from!
I tend to work on the iMac at home, then take an MBP to work. Several times I’ve thought iCloud had uploaded what I had been working on at home before I left, only to find that when I got to work, the old version was still the latest one on iCloud. Of course, I checked for the spinning little progress indicator, but apparently I either missed it or it didn’t appear.
To mitigate this problem, I came up with this script to tell me what iCloud daemon is doing. If files are pending update or being updated, it will indicate which ones. It will also tell me if the iCloud daemon is either idle or busy / not responding.
The recent update to Script Debugger 6 added a subtle, but much-needed new feature.
Now, scripters can take advantage of the same kind of navigation markers familiar to users of Xcode (pragma marks) to quickly navigate to user-defined sections of the script.
Scripters can now create a marker with a double-dash and double arrow marker, followed by whatever label they choose.
-->> myMarker here!
For me, this is a great boon, and I’ve changed all the section headings in my templates to the new navigation marker syntax, meaning I can easily jump to the various sections from the Navigation bar at the top of the script.
Script Debugger 6: The Complete Review
One of the things I’m often finding myself doing is trying to remove characters from strings, particularly
html codes and other markdown clutter. Rather than laboriously messing around with offsets and the like, we can make our lives simpler by making a quick handler that leverages Cocoa’s
For example, suppose you’ve got a
sourceString containing something like this
We can strip all the tags out by calling our handler like this, once for the opening tags and again for the closing tags. Note how the variable names have changed in the second call:
The beauty of this is it doesn’t just remove one instance of the tag, it removes all occurrences of them, so this handler is a real life-saver when you’ve got a whole page of markdown to clean.
To achieve this you’ll need to add a couple of declarations to the top of your script, as well as the handler:
Here’s the declarations you’ll need:
use scripting additions
use framework "Foundation"
property NSString : a reference to current application's NSString
Here’s the code for the handler:
on remove:remove_string fromString:source_string
set s_String to NSString's stringWithString:source_string
set r_String to NSString's stringWithString:remove_string
return s_String's stringByReplacingOccurrencesOfString:r_String withString:""
For those participating in Apple’s public beta program or developer program, here’s a script that will make a bootable flash drive installer of Sierra for you. Of course, you’ll need to have downloaded and saved the original installer before running it on your mac for this to work.
When an installer is made available to you from Apple, the first thing to do after downloading it is to quit the installer if it auto runs. Insert your blank USB thumb drive, and make sure it’s at least 8GB (16GB recommended).
You can either run the script immediately with the installer app still in your /Applications or /Downloads folder, or you can move the installer first to your preferred location. It doesn’t make any difference to the script since it’ll ask you for the location of both the Installer and the USB drive before doing its thing. It’ll also give you an option to cancel out if you made any mistake in specifying the location or you just change your mind. The script will ask you for an administrator password as it needs elevated privileges to run the
Note the script continues to run in the background until the installer has been created. It sleeps for an interval of 10 secs between checking the job status. Since it takes around ten minutes for the createInstallMedia routine to finish its work, you could comfortably increase that sleep time 30 secs or more if you desire. The script will present you a dialog when it detects all is done:
To use the bootable installer, just pop it into a mac, reboot holding down the ‘option’ key and choose the USB drive to kick off the installation process on a partition of your choice.