Quick follow-up to my earlier guide on using JavaScript for Automation.
There must be something in the air that put the topic of JXA on the minds of the Apple community. Armin Briegel shared a great roundup of recent JXA work, and the #scripting channel on the MacAdmins Slack team is full of folks discussing new and old discoveries.
Here are a handful of additional tips.
Excutable JXA scripts
You can run JXA directly by including the JavaScript language flag in a script's shebang, like this:
#!/usr/bin/osascript -l JavaScript
Save the file with a name and extension you like. I've been using .scpt
, which
is the convention suggested by Apple's own Script Editor application. Something
like cputype.scpt
will work just fine.
Mark the file as executable by running chmod +x cputype.scpt
. Then, you can
run it on your system by simply calling ./cputype.scpt
This will output the CPU architecture of the computer, for example ARM64E
or
Intel x86-64...
JXA in Jamf Pro Scripts
You can drop a JXA script directly in Jamf Pro without any modification. As long as you include the JavaScript shebang outlined above, you're good to go.
You do not necessarily need to wrap JXA in a shell script. It might make sense to "shell out" to a JXA function from a shell script for some use cases, but it is not a requirement.
Jamf supports non-compiled AppleScript files natively, and you can use them in your Policies like any other script.
JXA in Jamf Pro Extension Attributes
Same deal; specify the Script type for the Extension Attribute, and include the
JavaScript language flag shebang. Ensure your function returns the required
<result></result>
wrapper surrounding the output. You can do that with simple
string concatenation using the plus operator, like this:
#!/usr/bin/osascript -l JavaScript
This will output <result>ARM64E</result>
, for example, which will show up on
your computer's inventory record during the next device inventory.
--
That's it. Hopefully this helps you store and run JavaScript for Automation scripts.