I can’t any way to make Script Editor to save a script using an extension of .jxa, either for a “script” or for “text”.
I’ve also been using a script (well KM Macro actually) to open a file selected in the Finder or Path Finder in the appropriate app, like Script Editor for JXA scripts and SD6 for AppleScript scripts. Before I was relying on keywords in the name of the script file. But now I can use your above script to get the script language and take appropriate action.
Classic thinking mistake. The initial supplied solution works perfect. The only requirement: you need to run it in with the osascript runtime, not within Script Debugger or ScriptEditor 
I now have this and it works perfectly (osagetlang.sh):
#!/usr/bin/env osascript
use AppleScript version "2.4"
use framework "Foundation"
use framework "OSAKit"
use scripting additions
on print(line_text)
do shell script "echo " & quoted form of line_text
end print
on run(args)
if count of args is not 1 then error "usage: osagetlang.applescript path-to-script-file.scpt" number 1
set scpt_path to item 1 of args
set source_nsurl to current application's NSURL's fileURLWithPath:scpt_path
set the_script to current application's OSAScript's alloc()'s initWithContentsOfURL:source_nsurl |error|:(missing value)
if the_script is missing value then error "File or contained script is unreachable" number 2
set osa_lang to the_script's language()'s |name| as text
print(osa_lang)
end run
Come to think of it: it would be nice to switch runtime environments in Script Debugger, or is this already possible?
What I do is I have added Script Debugger to the toolbar of Finder. To open a file, I drag it to the Script Debugger icon:
If you automatically want to open an AppleScript .scpt file in Script Debugger and a JavaScript .scpt file in Script Editor, you could write an AppleScript Droplet application that determines the script engine used (as in code above), and launches the app you want via do shell script with the open command.
To bind this application to the .scpt extension, you need to edit the Info.plist. If you need it, I could look for the exact XML you need. I have it somewhere…
I’ve ran into another snag. When I run the above script on El Capitan, I get the error message:
./osagetlang.sh:390:415: execution error: nsurl doesn't understand the "fileURLWithPath_" message. (-1708)
When opening the file in Script Debugger, nsurl is converted to lowercase. It seems it doesn’t recognize the classname. And according to the documentation it’s available in the Foundation-framework since macOS 10.0.
Any tips?
I found it. The term nsurl is part of scripting additions on my El Capitan installation. This installation has multiple items below Scripting Additions in the Dictionary. These are: FITS.osax, Numerics.osax, Satimage.osax and XMLLib.osax. The former has a record-type namespace with a property nsurl that causes the problem.
I fixed this by removing the line use scripting additions and wrapping the line that needs this lib with using terms from scripting additions.
Where do osax-files come from? Did Apple stop distributing some of these osax-files with newer OS’s? My El Capitan computer started with OS X 10.5 Leopard installed. Could it be a remnant of that distribution?
This mechanism seems a compatibility nightmare issue. Does anyone has some info on this? And is there strategy how to cope with different standard additions installations?
That’s a third-party scripting addition, and the only way it got there is by someone installing it. Only Standard Additions is installed by Apple.
The best way to avoid this type of problem is to use Script Debugger’s code-completion. When you type NSU and hit the completion key (F5 or esc), you will see a list of terms. When you choose NSURL (or anything else), Script Debugger checks if there are any terminology conflicts like this, and if so it adds pipe characters around the term to escape it, like this: |NSURL|.
The only catch is if you are saving the scripts as text rather than compiled – you can get caught out when you open them on another computer. If that’s likely to be the case, then the process you described of removing the use scripting additions line is the only 100% reliable method.
FWIW, NSURL is the only class name conflict I’ve seen. But there are plenty of others with parts of method names, including with Apple defined terms like error. Script Debugger’s code-completion really is your friend.
I found the source of those osax-files. I once installed SmileLab on my El Capitan computer, and that software extends standard additions.
From the dictionary on my El Capitan computer:
And my new computer.
Do you know of more of those Scripting Additions-additions?
The code-completion suggestion only works if you have this software installed on your development machine. However, the |NSURL| solution works fine. So I have to remember this…
I don’t think there is a difference whether you save it as scpt or as text. It’s the runtime environment that is causing the problem. On my new computer, there was no terminology conflict. However, I did some testing, and it turns out when you save the script as a Run Only App, it worked on both computers…
The only solution is to know what stuff can be installed, and test this. And wrap NSURL with pipes 
Thanks for the info: I’m sure going to use autocompletion more often now 
If you had saved as a .scpt file on your development machine, when you opened it on the other machine, the AppleScript compiler would have recognised the clash when it decompiled it and added the pipes for you. This is standard behavior when a variable name conflicts with an AppleScript term.
