On Sep 1, 2009, at 2:28 PM, Paul Scott wrote:
2009-09-01 14:21:54.152 osascript[1814:903] Error loading /Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types: dlopen(/Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types, 262): no suitable image found. Did find:
/Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types: no matching architecture in universal wrapper
osascript: OpenScripting.framework - scripting addition "/Library/ScriptingAdditions/Adobe Unit Types.osax" declares no loadable handlers.
I will explain why this message must be emitted at the time that it is, below.
However, the primary issue here is that it is incorrect to assume that osascript won't emit anything to stderr. Anything at all could be emitted to stderr now or in the future, if we decide there is important error or diagnostic information to communicate. This is the nature of command-line tools and stderr; this is not specific to osascript. Moreover, the libraries that programs use are free to emit messages to stderr, as well, meaning that even the developer of a given command-line tool cannot, generally, predict or control what messages will be written to stderr. In fact, in this particular case, the "dlopen" message is emitted by the dyld library, which is responsible for loading executables, and is not under osascript's control. This is the nature of stderr: It is where error and diagnostic information is communicated.
This addition is an old-style "initializer-based" addition, which means that OSA & AppleScript cannot know what event handlers it installs without loading its executable and calling its initializer function, which is responsible for installing its handlers. Since OSA cannot know in advance what handlers the addition provides, it logically cannot know whether your script uses them. Even the terminology used to compile a script is not sufficient for determining where an event will be handled at runtime; this is the dynamic nature of events and handlers. Terminology determines what events will be sent by a script, but it does not determine what handlers will be available when the script is run, nor who provides those handlers. The event handling mechanism enables you to install an addition to modify the behavior of existing scripts and applications; additions may even handle events for terminology provided by others. OSA must load all initializer-based additions before you compile or run any scripts, so that their event and coercion handlers will be available in case your script invokes them.
Modern (10.5 and later), Info.plist-based additions do not have initializer functions; instead, they declare their handlers and OSA is responsible for loading and installing them. For performance reasons, OSA arranges to lazily load the executables for these additions, so they won't emit these kinds of errors unless one of the handlers is actually invoked.
-- Chris Page
The other, other AppleScript Chris
|