Monthly Archives: September 2016
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
Today I encountered a problem in which none of my files on iCloud could be opened. The issue (almost certainly self-inflicted after I’d been poking around in iCloud’s underbelly…) was peculiar in a couple of ways.
Although all files refused to open, Quick Look had no problem displaying every file’s contents (shame that we lost the ability to cut and paste from Quick Look in El Capitan, as that would have presented me with an option for recovery). Another oddity was that iCloud files that were currently open could still be saved to, but once closed, refused to open, showing the dialog above. Yet more worrying was that neither copying and pasting a file to another location outside of iCloud with the Finder nor trying to restore from Time Machine worked.
Logging out and logging back in again also did not resolve the problem, as I’d hoped. However, I was prevented from just trying a full restart as I had critical processes running elsewhere on the computer.
One option that I successfully employed was to use the ditto tool on the command line to copy a Pages document to another location (note that the Pages format is actually a directory rather than a single file, so ditto is a good tool for this). However, while this might be useful in an emergency, it’s hardly a practical solution to repairing the whole of the iCloud Drive.
Instead, I took the seemingly scary option of unlinking the mac from iCloud Drive in System Preferences > iCloud. You’ll get a warning like this:
I then re-enabled iCloud in the hope that this would refresh whatever it was that had become out-of-sorts. Unfortunately, that still didn’t work. I next tried unlinking again, logging out and re-linking after logging in. Still no dice, and by this time I was sufficiently worried that there was nothing for it but to halt all my other activities on the computer and try a restart. Possibly the system holds something in a memory cache that needs to be flushed, I’m not sure. In any case, I took the step of unlinking iCloud first, then restarting, then re-linking after reboot. Success (and relief)!
I don’t fancy trying to reproduce the issue to see if the reboot alone would have solved it, but that would be my first step if the issue occurs again. Otherwise, the unlink, reboot, and re-link method seems to do the trick.
With the release of the latest version of the Mac operating system, 10.12 macOS Sierra, it’s pleasing to see that Apple have fixed a bug I reported against El Capitan in October of last year, and wrote about on this blog here and here.
The TCC.db is now under SIP, which means hacking the Accessibility preferences is no longer possible.
The bug basically allowed anyone to circumvent the authorisation warning to place an app in the list of Accessibility apps in System Preferences > Security & Privacy. It still required
sudo, but an app (Dropbox being the most high profile offender) that got your admin credentials in other ways could insert itself into Accessibility and make it almost impossible for the user to remove.
Users can still alter Accessibility in the normal way (through Sys prefs GUI), but trying to hack the SQL database via Terminal now returns:
Error: attempt to write a readonly database.
xattr in Terminal for
/Library/Application\ Support/com.apple.TCC confirms this with the reply:
Hopefully, this fix will be ported to EC as well. At the moment, it’s still possible to run this hack in OS X 10.11.6.
One handy feature of Dock tiles is they work with Expose to let you easily see recent documents. For example, even without launching Scrivener, I can hover over its Dock tile, swipe down with four fingers on the trackpad and get a look at my recent Scrivs, as shown above.
The only problem is, sometimes Dock tiles get in a mess. Take a look at my Script Editor recents list:
Hmm, not a very helpful list. And yet, there isn’t an easy way to clear it either. You might think that using the ‘Clear menu’ option in the menu bar might do the trick, but on it’s own, it won’t. It’ll clear the list in the menu bar, but not in the Dock tile.
The trick is to kill the Dock process after using the menu command. So
1. Launch the app in question
2. Choose File > Open Recent > Clear menu
3. Quit the app.
4. Now launch the Terminal.app, and on the command line execute
And with that, you should have a nice clean Dock tile for that app:
Hope that helps! 🙂
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:""
With macOS 10.12 Sierra due out sometime this month, some will no doubt be wondering whether their current mac will make the cut.
First thing you’ll need to know is your model identifier. If you’re using DetectX or FastTasks 2, it’s displayed at the top of the Profile log. In FastTasks 2, you can also find it in the menu under ‘Model Overview’.
If you’re not using either of those, you can get your model identifier from > About This Mac > System Report… Look for ‘Model Identifier’ under the Hardware Overview section.
Barring any unlikely last minute changes from Apple, here’s the full list of models that are supported: