Osascript and AppleEvents

applescriptcommand lineterminal

I logged the AppleEvents that get sent from a Terminal window. The event that the osascript command sends to the AppleScript compiler/interpreter wasn't logged. How come?

In greater detail, the following argument consists of three hypotheses followed by their logical conclusion. However, experiment shows that the conclusion is false. Hence the argument is faulty. Unfortunately, I don't know why it is faulty. Where does it break?

Hypotheses

  1. macOS comes with a built-in AppleScript compiler/interpreter that is installed as an OSA component.

  2. The Terminal command osascript does not "know" AppleScript. When passed a line of AppleScript code, it passes it on to the AppleScript compiler/interpreter via the OSA architecture by sending out an AppleEvent.

  3. The following line of code, when run in the Terminal, will cause all AppleEvents sent by commands that are executed from the same Terminal window afterwards to be printed out in the Terminal:

    export AEDebugSends=1
    

Conclusion

After running the following two commands in a Terminal window:

export AEDebugSends=1
osascript -e 'tell application "Finder" to activate'

two AppleEvents should be printed out:

  1. One directed from osascript to the AppleScript compiler/interpreter to compile and run the command 'tell application "Finder" to activate'.
  2. One directed from the AppleScript compiler/interpreter to Finder to activate itself.

Actual output

Only one AppleEvent gets printed out, the one sent to Finder:

AE2000 (4085 ): Sending an event:
——oo start of event oo——
aevt('misc'\'actv' transactionID=0 sourcePSN=[0x0,e00e "Finder"] timeout=7200 eventSource=3 { &'subj':null(), &'csig':magn(65536) })
——oo end of event oo——

Best Answer

tl;dr : Language components are just dependencies used by the executable and can be accessed through the shell without Apple events.

A: Your argument breaks at a couple of points made in number 2.

a. "The Terminal command osascript does not "know" AppleScript."

Agreed, it does not have all of the languages it supports self contained in one executable. However, that's where dependencies come in, and when you think of it that way; it's not too troubling that it can access dependencies through your shell like any other application can.

b. "it passes it on to the AppleScript compiler/interpreter via the OSA architecture by sending out an AppleEvent."

"When a scripting component executes a script, statements in the script may result in Apple events being sent to applications (developer.apple.com)".

The executable is not limited to only using either code within itself or an Apple event call. Similar to almost every process or application on your machine, it relies on various core libraries and specifically it uses the osa language components installed on your system. It does not use Apple events for passing your script to the language component.

see supported languages:
❯ osalang 
these language components live here:
❯ ls /System/Library/Components/


Since osascript can access your system's language components directly through the shell, you'll never seen an Apple event triggered just to process/interpret the script input.

for example compare these two commands where the first uses the AppleScript language but does not interact with any other applications:
❯ osascript -e 'set myVar to "hello" & "world"'
helloworld
and the second where we tell terminal to do something:
❯ osascript -e 'tell application "Terminal" to do script ("echo helloworld;")'
AE2000 (63917 ): Sending an event:
------oo start of event oo------
aevt('core'\'dosc' transactionID=0 sourcePSN=[0x0,dd7dd7 "Terminal"] timeout=7200 eventSource=3 { '----':utxt('utxt'(TEXT("echo helloworld;"))), &'subj':null(), &'csig':magn(65536) })
------oo  end of event  oo------
tab 1 of window id 32644

Only the one that interacted with an application, not just the AppleScript language itself, triggered an Apple event.

Read over this article again and you will see how this explination fits now. OSA Architecture implemented via Apple events is the powerful construct allowing for automating between applications; but interpretation of the input script itself is just done by your system's compatible language component behind the scenes.