I’m using this in a little utility I’ve written for others. They’ll have the choice of either downloading the utility as an .app with MT v1.0.6 in the bundle, or they’ll be able to download my source script and follow directions to install MT themselves locally from the macosxautomation site.

In the latter case, will my source script work without changes in the future if they download a later version of MT (e.g. a hypothetical v1.0.7)

My script’s import statement is

use script "Myriad Tables Lib" version "1.0.6"

Does the MT source code allow the stated version or higher, or is it strict to the actual version stated?

It’ll show the backup of the source disk without the shell script, which it gets from CCC’s Task History, but it won’t show when any of your connected disks were last backed up until they’ve been backed up with the shell script.

BTW, the postRun.sh script is now included in the bundle’s Resources/Scripts folder in v1.1 (and so is the Myriad Tables Lib, which I forgot to add in v1 and didn’t notice as it was running from my own installed version. ).

Also the applet isn’t saved as ‘run only’ so all can marvel at my bad coding practices; resist the temptation to “improve” it though, as that’ll break the codesigning.

Thanks, I’ll try to add such niceties in v1.3. Right now I’m having nightmares with codesigning. The earlier versions passed on the latest beta of 10.12, but now I can’t get either SD or SE to codesign the bundle correctly. One and the same signed bundle gives me different results depending on what I try to download it onto:

The problem was that signing the app in 10.11.6 would pass Gatekeeper on 10.11.6 but not 10.12.2. (by which I mean downloading it to my own machine externally from the aws host threw the ‘unidentified developer’ dialog in the latter but not the former).

For reasons I haven’t yet determined, that didn’t occur with v1 or v1.1 built only a few hours earlier on the same machine and install.

I encounted a few other problems at the same time with SD and autosave and with copying resources into the bundle (is there any way to stop SD autosaving?); my impression was that the corruption was something to do with the order in which SD was autosaving and signing the current state of the app, but tbh, I was more concerned with fixing the problem ASAP than analysing the cause. I’ll be able to take a more leisurely approach when I do the 1.3 update (forewarned, forearmed an’ all that).

According to RB App Checker Lite, the problem was the Info.plist was not signed or had been altered after signing. That’s what led me to think it was something to do with the order of the save/signing process.

It occurred to me earlier today that I should turn code signing off until the final build / save. As SD code signs on each and every compile, run and save, perhaps the whole signing signature had become corrupted in some way.

Anyways, if it occurs again I’ll take the trouble to document some reproducible steps and we can take it from there.

I strongly recommend keeping all but the simplest of script libraries out of bundles during development, and adding them only when ready to export deployment versions. There’s a script in that article that can be adapted to make it a simple process.

I strongly recommend keeping all but the simplest of script libraries out of bundles during development, and adding them only when ready to export deployment versions. There’s a script in that article that can be adapted to make it a simple process.

Can I suggest you use the “Open in script debugger” for quoted scripts on the SD web page?