I have a script, which downloads a zip file, then unpacks it, moves some files out of the unzipped folder and then moves the zip to an archive and removes the unzipped folder. And it works well. Most of the time...
Sometimes though, it fails and cancels. Claiming that a certain file can't be found, which (to my eyes) is clearly there... And sometimes it seems to skip one of the moving steps from the "Move mockups" action
I added the delays to see if that helps but I don't think they have improved the situation. Also wouldn't think that they should be necessary
Provided that the variables, that the shell scripts use, contains the right paths, is there even any room for error here? I mean, it's not something fuzzy like image recognition...
It also occasionally throws in an error
"osascript(87264,0x7fff7ccb3000) malloc: *** error for object 0x7fa02401fe08: incorrect checksum for freed object - object was probably modified after being freed."
I am not able to directly connect it to the failures from looking at the logs though
Here is that part of the macro, that is problematic
There should be no need for pauses in that macro. Except maybe after the open execution. In theory, the -W should keep the script from finishing until the application exits. In practice, it is possible that there is some level of asynchronicity in that.
There is no need to use shell scripts for moving files or removing files, you can use the Move a File action and the Delete a File action for that purpose, which would also give you clear errors.
And finally, there should be no use of osascript in that sequence unless the open uses osascript indirectly.
You could avoid that execute shell script as well by using the Keyboard Maestro Open a File action, however Keyboard Maestro has no option to not bring the application to the front (-g). It could then use a Pause Until action to pause until the application is not running, although there is some risk with that that the Open a File action could complete before the application is actually launched (launching and quitting applications is a very involved process with time on either spent when the application is partially launched).
Hey Peter, thanks for the reply and the background info!
I have investigated further. I have probably misinterpreted the logs earlier. Let's assume for now that the shell scripts do what they should. Btw: I am using them instead of the build in actions, because the target for the move might already exist. Seemed quicker to set up this way. In the beginning I had them all in one execute script statement, which I'll probably go back to if, we resolve this.
Turns out that the shell scripts are most likely fine, but the variables are not properly set. Which brings us to the osascript log entry. The variables are set with an execute apple script action. I have a use statement for a self made Excel library in the beginning and then uses the function in that library to get values from an Excel file. Something like
I have added some logging in that library as well and on the last fail it was clear, that above mentioned osascript error occured and that the apple script was not executed to the end. Thus the script returned nothing and thus the variable contains nothing and thus... all goes awry
Any ideas on how that might happen? As I mentioned the ExcelLib.scpt file is in the script libraries folder and I have not changed it during the execution of the macros (as the error message might suggest). Is this a Keyboard Maestro + Apple Script issue or might the Apple Script itself be the culprit?
Here is the log entry on the osascript issue again:
osascript(15503,0x7fff7ccb3000) malloc: *** error for object 0x7fad6205d008: incorrect checksum for freed object - object was probably modified after being freed.
I am using these retrieval functions a lot in what I am doing right now and as a rough estimate I would say that they fail 1% of the time at most. So most of the time it works as it should.
This error from osascript is a very low level error. It is talking about memory management, it has nothing to do with changing the script, this is a low level programming issue. My guess would be deep inside AppleScript/AppleEvents. This is causing the osascript tool to crash, which as you note means it returns nothing.
This sort of low level crash from AppleScript/AppleEvents is why Keyboard Maestro does almost all of its AppleScripting via the osascript tool, so that when AppleScript/AppleEvents crashes it does not take out Keyboard Maestro Engine.
It doesn't really have anything to do with Keyboard Maestro.
As for how you can work around it, I would try something as simple as looping the Execute AppleScript action if the result comes back as other than you expect.
That wont detect the case where the same error happens ten times in a row. If that happens then you will probably have to try a different solution. But it might be all that is required if the error only happens 1% of the time.
My guess is that the Apple Script error comes from Excel. Even the UI seems a bit buggy
Naturally I wanted encapsulate all this looping magic in a macro... I have dug around a little and finally learned how to access instance and local variables from Apple Script. Here is my solution that I can very well live with
The trigger value has the format value1|value2|value3 and contains name of the instance variable I want to store my results in after the last pipe.
Sidenote: the rest of the info is the worksheet and column to access and which column to retrieve, very specific to my case.
Then we loop over our problematic apple script until local__OutputValue is finally not empty.
Sidenote: That apple script retrieves the value from local__GetSetParameters, but that is again specific to my case.
Then we extract the name of the variable, that we actually want to store our value in, with a regex action into the variable local__TargetVariableName
And then we assign local__OutputValue to instance__%Variable%local__TargetVariableName%
Storing the entire name of the target variable didn't work. But prepending instance__ in that step, will save a few keystrokes anyway when calling the macro.
Looks good. Make sure you set a timeout abort on the While loop. Otherwise if something goes wrong so it keeps not working, that macro will be stuck in that loop for a long time, and then later when you open a new document in Excel or some such it will finally complete which will be an unwelcome surprise.
