I researched the topic before posting here: it turns out the issue used to be widespread since 10.6 but the problem is there’re many references but no ultimate solution.
I have a third-party standard addition which development was quite expectedly stopped with the premiere of Mojave. I can run the code containing statements from its dictionary in Script Editor, Script Debugger and Automator but as soon as I put it together as a part of an Automator Service (known by the name of Quick Action since Mojave) or Script Menu item that runs by choosing from the global script menu it stalls. I see the workflow gear spinning but the actions from the script addition’s commands that are supposed to kick in do not. I can stop it only by killing Automator Runner in Terminal.
If I run a script containing this scripting addition from the global script menu the part that contains the addition simply blanks.
Speaking of Terminal, as a test, I executed the automator utility on the troubled service with verbose logging. It returned the message I encountered a lot in the past when running shell scripts involving osascript without any degrading effect. Here it is as seen on the command line:
automator -v /Path/To/Services/MyService.workflow
Get Selected Mail Items is running
Get Selected Mail Items is finished
Run AppleScript is running
Automator Runner: OpenScripting.framework - scripting addition "/Library/ScriptingAdditions/QXPScriptingAdditions.osax" cannot be used with the current OS because it has no OSAXHandlers entry in its Info.plist
It’s the Run AppleScript point where everything halts. The most interesting thing is that it’s not QXPScriptingAdditions.osax that I call in my script. Furthermore, the scripting addition I use resides in my home folder, not a volume library.
Permissions are OK.
In another, an iteration older system:
When I run the bit in Automator it throws an error to the effect that it “doesn’t understand the command” although it compiles seamlessly
When I run it as an executable AppleScript script from the target application’s script menu Console shows error -10004 which is a privilege violation error. What does make it raise such an error when I run it as a legitimate user and the owner of both the script and the processes?
What’s wrong then? Does a possibility of reconciling the issue exist?
I presume you are using a pre-Mojave version of macOS. WIth Mojave and later versions of macOS, Scripting Additions are no longer supported due to increased security restrictions.
I think this error tells you why commands from the scripting addition fail to run:
There are many ways to configure a scripting addition, and in this instance the OSAXHandlers plist entry is required. It may be that somehow this plist entry got stripped along the way - I can only speculate.
Moving on to why you are able to compile scripts, but not run them. The AppleScript compiler only requires the scripting additions dictionary meta-data (‘aete’) to compile your script and convert the commands and other identifiers defined by the scripting addition into their internal coded form. The AppleScript runtime, which must load and execute code from the scripting addition, does not participate in the compilation process.
Later, when the script executes, the AppleScript runtime will fail to load the scripting addition at startup (issuing the error you quote), but will execute your script. Later when the script attempts to call a scripting addition command, there will be a event not handled failure.
Error reporting will very depending on the run-time environment (script menus, automator, terminal, etc.). The bottom line is that attempts to invoke missing commands from the scripting addition will fail, and cause an AppleScript exception. If this exception is not handled, the script will abort. If the exception is handled incorrectly, you may experience endless loops that appear to be hangs.
I’m at a loss to explain why you are able to successfully run your script from the Script Editor. By ‘home’ folder, are your referring to ~/Library/ScriptingAdditions? If not, then you’ll need to make sure you place the scripting addition in this folder.
Yes, I talked about ~/Library/ScriptingAdditions/. Since I left off the thread I did a couple of analogous tests on the same Automator service running the shell automator command with the verbose mode turned on in the other older macOS I mentioned briefly at the bottom of my original message and got the following even more detailed response:
Starting Automator…
Get Selected Mail Items is running
Get Selected Mail Items is finished
Run AppleScript is running
Automator Runner[12486:707] Error loading /Users/home/Library/ScriptingAdditions/24U Appearance OSAX.osax/Contents/MacOS/24U Appearance OSAX: dlopen(/Users/home/Library/ScriptingAdditions/24U Appearance OSAX.osax/Contents/MacOS/24U Appearance OSAX, 262): no suitable image found. Did find:
/Users/home/Library/ScriptingAdditions/24U Appearance OSAX.osax/Contents/MacOS/24U Appearance OSAX: GC capability mismatch
Automator Runner: OpenScripting.framework - can't find entry point AGUI_DisplayBetterDialog in scripting addition .
The action “Run AppleScript” encountered an error.
That, in fact, echoes what I said about the inability to run AppleScript scripts from outside Script Editor and Automator and in the latter case it fails even in Automator. On the GUI level this corresponds to the
Choose a contact from the pop-up menu to add the E-mail address to." doesn’t understand the display better dialog message.
error followed by the termination of the workflow. 24U Appearance OSAX is the standard addition in question and better dialog message belongs to its commands. By default, it was installed in /Library/ScriptingAdditions with somewhat erroneous permissions (those of my user). Both elevating them to system:wheel and moving to the same folder of my home library with my:staff didn’t change anything.
Running a AppleScript script containing 24U Appearance OSAX on the command line with osascript -so /Path/To/Scripts/Applications/MyScript.scpt bears no actions and produces no standard output at all.
Today, I saw this when I tried to execute a script, containing the same osax, from Firefox. I can swear I used to run it without a hitch. I cannot trace back to the event that caused this mess but I know it used to work as I wanted it to (click to view the screenshot because Imgur won’t allow previews).
I finally found the solution. Since commands of this OSAX worked only outside the tell block regardless of whether the script was saved as a compiled script or an applet, the only logical choice was to put these commands in a script object calling that script object from the tell block.
The formal code:
script Do3rdPartyOSAXCommand
3rdPartyOSAXCommand
end script
tell application "CoolApp"
[code]
run script Do3rdPartyOSAXCommand
[code]
end tell
This issue is still not cured by applying the same logic when you add this OSAX to the code of the Run AppleScript action in Automator both as a workflow or Automator application. It is with AppleScript applets and ScriptMenu scripts.
I think though it’s best that you accept that third-party OSAXen are (rightly!) dead and gone†, and that any kludges to keep them limping along for a bit were always fragile and liable to fail with zero warnings, and were only ever intended to buy you some time while you updated your scripts to use something else.
If you can rewrite your code to eliminate its reliance on those old OSAXen, that would be by far the easiest and most sensible solution.
Your only other option would be to beg/bribe the OSAX’s original author to rebuild it as a faceless background application, or give/sell you the code so you can do it yourself. I suspect, however, if any OSAX developers were willing to do this they would already have done so years ago. There just isn’t much of a market nowadays to justify them doing new work.
† Because OSAXen load their Apple event handlers into the target application (i.e. tell app "NAME" to SOME_OSAX_COMMAND) instead to the app that’s running the script, they allowed any application/script to inject arbitrary, potentially dangerous code directly into any other application running on the user’s computer. Thus a malicious OSAX could bypass the target application’s sandbox and other security measures, to steal its data and perform other operations not normally allowed.
Apple’s only mistakes are 1. not killing OSAXen a decade sooner, 2. not eliminating StandardAdditions.osax too by making its commands part of AppleScript itself. That an AppleScript can still send Standard Additions dialog commands to other apps so that unwary users will mistake them for genuine—e.g. tell app "Music" to display alert "Please enter your iTunes Store password to log in:"…—remains a real problem.
The subject of the topic contains the word «pre-Mojave». I’m not using the OSAX in question in Mojave. The macOS of choice is an earlier system. I don’t think nor do I care about security implications as I’m not distributing my code (on a side note, adhering to the what-could-happen approach as a determinant is akin to nourishing paranoia; the preoccupation with security on later macOS has grown to such an exuberant extent and beyond any practical reason that I prefer older systems with more freedom to tweak this and that to my liking). I figured out workarounds by adapting my code to the irks (or perceived as such) of this OSAX and other pieces of software and am now more or less content with the result. I’m not inclined to complain that something isn’t perfect. I prefer to analyze and get to the bottom which is how we gain more knowledge and hone our skills.
I got that. However, you’re saying it doesn’t fully work on your older, pre-10.14 OS either. And Mark’s post suggests the OSAX itself is far older still.
I appreciate the need to keep an old system to run old software (e.g. I keep a 10.14 box around to run an old, unsupported 32-bit only app†), but if it ain’t working it ain’t working. And there probably isn’t anything more you can do about this as it is all extremely obsolete software that’s no longer supported by vendors. Fallacy of sunk costs.
Accept your ancient fragile OSAX will only work in some apps and not in others on your fairly old OS, and stick to using it only in apps where it does work. Or, heck, find yourself an old white-top Mac mini on ebay and run a really old OS like Snow Leopard. I do not remember when OSAXHandlers plists were introduced, but I’d feel pretty confident that SL will happily uses OSAXen that don’t have them.
I doubt you can get any more useful info here as very few will remember the exact foibles of using AppleScript on 10.13 or earlier, never mind still work with that obsolete combination themselves. Therefore, to re-answer your original query:
“Does a possibility of reconciling the issue exist?”
Maybe, if you go back to running Snow Leopard; otherwise:
No.
–
† My old Ship of Theseus, aka tangerine toilet seat, is also tucked somewhere in the junk pile should I ever hanker for an original DM-Deck 16 botmatch every few years. Heck, there might even be a working Timex Sinclair 1000 in there too! 3D Monster Maze, anyone? Good times…
I wasn’t talking about Mojave. The semantics of the topic’s title makes that crystal clear and I emphasized that beyond the title in a post, so «doesn’t work on older systems, either» isn’t there at all. I found a way to make it work. It works and I’m content with the result. You saw it in operation. Are you trying to convince me I’m hallucinating or that I’ve arrived at it wrongly?