That looks like an annoying timing issue—was the hard drive asleep, perhaps? I saw this like three times during testing, but wasn't sure how to check/fix it. But maybe I can check the folder name at the end of the export, and if it's "Untitled Macros Folder," then change it.
That'll be tricky to test, though. But I think I'll probably do it anyway and then see if anyone has issues—the code would only execute if it sees that name, so should be safe for everyone in general.
Version 1.1 is out, and fixes a bad issue for anyone using 0.000,00 number formats: MBU wouldn't work. This boiled down to be a misunderstanding on my part as to how "Format With" works in Calculation fields, but I was led astray by what I found to be confusing wording on the wiki page. (Peter has now added a note there to help.)
This version also adds a check to make sure your backup folder isn't named Untitled Macros Folder, which KM sometimes does if there's a timing glitch when I try to insert the proper name. I think I've set it up so that this will always be caught and fixed before the macro proceeds.
I also added a bit of code to each AppleScript call to try to prevent some random (and not-the-macro's-fault) 600 errors that you may see—thanks, Chris!
My apologies to those with comma-separated decimals for the troubles; the thing ran perfectly with period-delimited decimals, and none of my testers used the alternative format.
Thanks! When I first started this thing, it was almost an afterthought, like "Oh, I could try to see how things have changed." Now it's one of my favorite parts of MBU, and I look at it when trying to figure out what stupid thing I might've done to some macro or group :).
I'll work on the feature list, as for the periodic option, it's how I have mine set. However, I don't like distributing macros that automatically run on a periodic basis; it somehow feels "wrong" to me to put something on someone's Mac that runs without their saying "yes please run this."
I do show a couple options in the help for users who want to add automatic usage—periodic or idle—for those who may not be familiar with those triggers.
That’s a good point. I’ll have to go read the documentation a little more thoroughly. I guess I just need a way to disable the final dialogue, but to be fair, I have not looked to see if such a thing is included yet. I only just tried it this morning. Thanks again
The answer lies in how diff works. When diff finds a difference between the two files, its exit code is 1. Nonzero exit codes typically indicate an error, so when Keyboard Maestro sees that exit code, it bails out. If you look through the Engine.log file, you'll see something like Task failed with status 1 which is true but not very helpful if you don't know diff's exit codes.
The workaround is to click on the gear icon in the upper left corner of your Execute Shell Script action and change the settings on "Failure Aborts Macro" and "Notify on Failure" from ✓ to ×. That should get you the output you expect.
So that's what I have to do whenever I use diff (and a couple other commands, as it turns out). But I don't know of any way to block the log entries for these things that aren't really errors.
Hi, @griffman. Thanks so much for your responsivenss to the issues that have been discovered during the roll-out of MBU! Considering the amazing functionality of MBU, it seems that the issues have been relatively minor. (Are you getting any sleep now? )
Coincidentally, I'm working on a macro (named: Engine.log Tool) that has some functionality that you might consider if/when implementing the above MBU enhancements.
Engine.log Tool that has three modes, one via direct trigger and two via calling macros that use the Execute a Macro action.
When Engine.log Tool is run via direct trigger (Mode 1) it displays a Prompt For User Input dialog with seven buttons.
For one of the buttons (Reduce) there are sub-options that are presented using a Prompt With List. (Coincidentally there are seven sub-options.)
When two of the five sub-options are selected, the macro does its respective task and then reports results.
For the other five sub-options, additional information is required and obtained via Prompt For User Input dialogs (customized to the particular sub-option). Like with the other two sub-options, the five sub-options complete a task and report results.
(This might sound complicated, but the macro is easier to use than to describe. )
With Modes 2 and 3, the information that would normally be supplied by the Mode 1 user responses (dialog+PWL or dialog+PWL+dialog) is supplied by the callers via the With Parameter. The only difference between these modes is that Mode 2 reports results and Mode 3 runs silently.
For example, one of the sub-options is delete. For Mode 2, the caller supplies delete in the With Parameter. For Mode 3, the caller supplies 0:delete in the With Parameter.
Engine.log Tool includes this simple set of actions to determine the mode of operation...
Version 1.2 is out now, with two Chris-requested features and some bug fixes :).
New feature #1 is the ability to control when (or if) the final onscreen summary dialog appears. You can set it to Always, Never, or Only if macro manually triggered. If you select the last option, you'll only see the dialog if you run MBU via its keyboard shortcut or directly from the KM editor.
New feature #2 is that MBU now tries to clean up the house before it leaves: It checks and saves the condition of the Keyboard Maestro app (running and visible, running and not visible, or not running), then restores that condition when the backup is done. So if you run MBU on a timer, you'll see KM open when it starts, but then (hopefully) also see it quit when the backup is done.
I also fixed a bug (thanks Chris!) in the update routine that was causing it to fail. So you won't be able to use the update manager this time, as it'll break. (If you want to fix it, just take out the call to launch the missing macro in the Update check macro.)