Osascript evaluation environment vs Script Debugger & Script Editor?

I notice that the following code runs in Script Debugger
(and, as it happens, in Script Editor)

use framework "Foundation"

tell current application
    ((its (NSBundle's bundleWithIdentifier:"com.apple.Safari"))'s ¬
        objectForInfoDictionaryKey:"CFBundleDisplayName") as text
end tell

but it’s unusual in failing when passed to the osascript command, either directly at the command line, or in environments like Code Runner, Visual Studio Code, Keyboard Maestro Execute Applescript actions etc, which also pass source code to osascript.

Is anyone aware of a specific gap in osascript’s default evaluation context ?

Any frameworks that could be explicitly imported, beyond Foundation, to breath life into that NSBundle code ?


It there perhaps a clue in the phrase not yet loaded which is harvested in Script Debugger by evaluating the preliminary:

use framework "Foundation"

tell current application
    its (NSBundle's bundleWithIdentifier:"com.apple.Safari")
end tell

and getting the result:

NSBundle </Applications/Safari.app> (not yet loaded)

?

#!/usr/bin/python3

from Foundation import *

theBundle = NSBundle.bundleWithPath_('/Applications/Safari.app')
print(theBundle.objectForInfoDictionaryKey_('CFBundleDisplayName'))

You could try this… it works in PyObjC

And if you run this it will work

#!/usr/bin/osascript

use framework "Foundation"

set theBundle to current application's NSBundle's bundleWithPath:"/Applications/Safari.app"
return (theBundle's objectForInfoDictionaryKey:"CFBundleDisplayName") as string

Thanks, yes,

using bundleWithPath rather than bundleWithIdentifier is fine if we already know the installation path, and, as you demonstrate, there are a number of alternative routes for the bundIeIDDisplayName mapping, (tell application id "com.apple.Safari" to name, for example)

but what I am really trying to understand, is precisely what difference between osascript and the other evaluation environments is differentiating their behaviour here.


Perhaps there is some connection with the problem that a bundle id might be indeterminate – mapping to more than one different installation location for the same Application ?


(In which case we could take a dog-leg through an NSWorkspace method like URLForApplicationWithBundleIdentifier, but then the difference between osascript and other evaluation contexts still remains obscure)


Are Script Debugger and Script Editor, for example, looking up a table (lacked by osascript) of installed application locations ?

I would have thought that highly unlikely. Does it still fail if you ask for, say, bundlePath()?

Maybe this is what you are looking for…
NSBundle bundleWithIdentifier returning null for Static framework and resource bundle

And

NSBundle bundleWithIdentifier returning null for other application

1 Like

Yes, that does seem to be the same problem, i.e. in some contexts you can obtain an NSBundle reference with a path, but not with a bundle ID.

Why osascript is one of those contexts, but Script (Debugger | Editor) are not, I personally haven’t yet understood.


Yes – it inevitably still fails, because in osascript contexts, we obtain only missing value from evaluating:

use framework "Foundation"

tell current application
    its (NSBundle's bundleWithIdentifier:"com.apple.Safari")
end tell

The problem is that in osascript you can initialize an NSBundle reference from a path, but not from a bundle id.

(once you have initialized from a path, bundlePath(), does, of course, return a value, in osascript as easily as in (Script Debugger|Editor))