Conceptually:
- the
run
command launches and runs an application hidden
- the
activate
command launches, runs, and activates the application (makes it the frontmost application)
launch
, according to Apple, "Launches an application, if it is not already running, but does not send it a run command."
- for AppleScript-based applications this should mean that they're loaded, but not executed (i.e., their - implicit or explicit -
on run
handler is NOT invoked), but in practice that is not true up to 10.9 - see below.
- it is unclear (to me) what exactly that means for non-AppleScript-based applications
A script can send commands to a script application just as it can to other applications. To launch a non-stay-open application and run its script, use a launch command followed by a run command, like this:
launch application "NonStayOpen"
run application "NonStayOpen"
The launch command launches the script application without sending it an implicit run command. When the run command is sent to the script application, it processes the command, sends back a reply if necessary, and quits.
Broken behavior on OSX 10.8, 10.9 (fixed in OSX 10.10):
launch
by itself is enough to run the application and is indeed the only command that works with AppleScript-based applications.
Any attempt to execute run
or activate
(whether in addition to launch
or not) runs the application - even twice when run from AppleScript editor(!; just once with osascript
) - but reports failure <appName> got an error: Connection is invalid
.
This strikes me as bug.
Not sure how OSX versions <= 10.7 behave.
Note: I've witnessed the non-executing behavior with launch
once, but every non-stay-open AppleScript-based test app I've created from scratch on OS X 10.9.2 and OS X 10.8.5 also executes the script with launch
- contradicting what the documentation says.
Please let me know if your system behaves differently and/or how older versions behave. On what OSX version was the app that doesn't execute with launch
created?
On OSX 10.10, behavior is consistent with the documentation, with one thing worth noting:
- If the intent is to launch and run in one step,
run application
is sufficient - no need for a separate launch application
command first.
Options
- @user309603's pragmatic solution simply uses
do shell script
with the standard open
utility to bypass the problem - this should work, regardless of whether the application is AppleScript-based or not:
do shell script "open " & ¬
quoted form of POSIX path of ¬
alias ":path:to:applescript:apps:shell-script-launcher.app"
run script file ":path:to:applescript:apps:shell-script-launcher.app"
Note: There's also load script file
, which indeed lets you merely load script code without executing it right away.
- to run non-AppleScript apps: use
run
/ activate
to run the app hidden / frontmost:
run application ":path:to:applescript:apps:shell-script-launcher.app"
- You could use
run
even with AppleScript-based applications and simply ignore errors with try ... end try
, as @atonus suggests - the downside is that you won't be able to detect actual failure to invoke the application.
You can mitigate this by selectively ignoring only the specific Connection invalid
error (which assumes this error would not legitimately occur) [no longer needed on OSX 10.10]:
try
run application "Macintosh HD:Applications:_Sandbox-AppleScript0.app"
on error number -609 # 'Connection is invalid' error that is spuriously reported
# simply ignore
end try
- Finally, on OSX <= 10.9, you could try to simply use the
launch
command (though that didn't work for the OP, possibly due to working on a <= 10.7 OSX version):
launch application ":path:to:applescript:apps:shell-script-launcher.app"
However, that is not advisable for two reasons:
- In OSX 10.10, Apple has fixed the
launch
behavior to no longer execute also, so your code will break when run there.
- While non-AppleScript apps typically do run (hidden) when invoked with
launch
, the documentation says that AppleScript "does not send it a run command" and "allows you to open an application without performing its usual startup procedures, such as opening a new window" - what that exactly means is not clear and different applications seem to handle this differently.