Also, note that the above is not production-quality code. Whenever
one uses Runtime.exec one should always spawn two threads to drain
the stout and stderr streams, *especially* when calling
Process.waitFor. Failure to do so will result in a deadlock if the
process generates more than a couple of hundred bytes of output.
I think the draining thing might depend on ordering as well. If a
process does not deadlock without two threads it probably never will.
I have simple Runtime exec code and more complicated where the
deadlock is a concern. The simple can usually just be inserted as a
method in a the class...
You can also get more interactive with Runtime'd osascript if you
want. The following is from a java CLI GUI shell. It feeds osascript
the input through it's System.in and gets the output from the
appropriate stream as well.
osascript
set cd to (random number 100000) mod 52 + 1
return cd
18 Oct 2007 06:29:23,375 INFO - RuntimeExecutable: osascript
18 Oct 2007 06:29:23,379 INFO - -s
18 Oct 2007 06:29:23,379 INFO - s
18 Oct 2007 06:29:23,380 INFO - -e
18 Oct 2007 06:29:23,380 INFO - set cd to (random number
100000) mod 52 + 1
return cd
49
Since the parms get echoed I might be wrong on this feeding the
script to osascript through System.in. It probably accumulates them
and sends the entire script as a parameter. However, I think I have
entered scripts into Terminal using osascript's system in so that
should work.
The 49 is the returned result, so this is not completely async anyhow.
Also java alone, even if the process is async, should be able to wait
as long as you might want and check for the existence of files.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden