> 2. Being able to run another app from extendscript is so useful that Adobe has added an app method since this was written.
If adobe wanted to make "exec" a useful, standard part of the environment, making argulent passing and output
capturing part of the spec (and eliminating the need for kludges like this) would be step 1.
>3. Any script can be a security risk. You should only run scripts from trusted sources.
Being able to execute an existing executable is indeed useful, but being able to write your own script and execute it
is a major risk. The risk here is not that your installed javascripts are rogues, but that the random javascripts you
download via browsers will use the same capabilities, even though they're not supposed to be able to.
>I am unclear about how your approach works. Can you post an example? How do you call the app and pass it the env string? What if you need the called app >to pass something back and it doesn't support setting env stings?
AFAIK setting the env strings is a one-way street, you can set them and pass data in, but the target app can't use them to pass
results back. I pass the names of desired result files as one of the arguments.
in javascript, approximately:
$.setenv('arg1_name','arg1_value')
new File("appname").exec()
and in the app:
char *arg = getenv('arg1_name')