Hello.
Err… I misplaced a parameter, or messed up the order it should be entered like this:
do shell script POSIX path of app_bin & " '" & POSIX path of input_script & "' >/dev/null 2>&1 & "
What happens at the end, is that we are implicitly telling the do shell script, that there will be no output:
We redirect stdout to /dev/null, then we redirect stderr to point to whatever file the file number stdout (1) points to. then we let the command be executed by a background shell, so that the do shell script returns immediately.
I’m sorry that I didn’t do it the right way the first time. I really thought that one way was as good as the other, and I didn’t test it with a command that was suitable the first time. Sorry.
Edit
I’ll toss in an explanation why the previous attempt didn’t work: 2>&1 >/dev/null & "
Here stderr, is redirected to stdout (file handle nr 1, which points to /dev/stdout), so that the terminal handling of the do shell script sees that it will be some output, because even if stdout is redirected afterwards, stderr, still points to /dev/stdout. Those filehandles, are more like variables with a value, than a pointer, so that later redirection, of one or the other of stderr, and stdout, doesn’t update the one that are set to point to the other.
Well. The do shell script, will poll for output, if there are any, and hang until a command is finished. So we need a two part trick to circumvent this trick, in order to use AppleScript to start up something, and then just return immediately. The first part of the trick is that when the output of a unix command are redirected to /dev/null, then the do shell script knows, that there isn’t any output to wait for, and will return immediately.
The second part of the trick is to put the ampersand, at the end of the commandline, which instructs the current shell, to execute the command in another shell in the background.
You need boths parts to make the trick work.
This can be exploited (in a good way) in circumstances like Joy’s, where you want to use AppleScript to start some other process in their own shell, and let the process run independently of the “originating AppleScript” from then onwards.