When running shell commands, sometimes errors require interaction like:
if file already exists in the destination, then we see the error asking for replacing "Yes(Y), No(N), Skip(S) etc
I can get the error displayed in a dialog box but by that time the shell would have finished executing the command and any “Y”, “N” or “S” will not reach the shell. How to send it to shell before the shell exits so that it continues to execute the command after taking our answer? Ofcourse, such situations can be got rid of by anticipating them and changing applescript itself but I would like to know if this can be done?
Thanks
The short answer is “no”. do shell script offers only one chance to send data to a program (when it is launched), and only one chance to gather data from a program (the result of do shell script, either error and the text from ˜stderr’, or the text from ˜stdout’).
A longer answer is that it depends on the program, and on how much effort you are willing to spend.
If the program is willing to send questions to stdout/stderr that are attached to regular files and read input from stdin that is attached to something like a named pipe, it could be possible to launch a process in one do shell script, monitor its output with read, and give it further input with write. But this can get complicated. Not only is the initial shell code a bit more complicated (setting up the stdio redirections and launching the process “in the background”), but the processes of checking the output, recognizing when the program needs more input, and providing that input all complicate the AppleScript code, too. If you also want to capture the exit code from such a detached process, the shell code to launch it gets even more complicated.
Also, there are some classes of programs that will never “ask questions” unless they are connected to a terminal (pseudo-tty). The authors of these kinds of programs reason that if the stdout and stdin are not connected to a terminal there will be no one there to answer, so there is no point in asking (they either abort or go ahead with some kind of default). To interact with such a process “behind the scenes”, you pretty much have to resort to something like Expect (a Tcl-based library/language designed to interact with processes). An alternative would be to direct Terminal to launch the program and then send requests to Terminal to see what the current output looks like, decide if the program has asked a question, and decide what to send to the program (through Terminal). Using Terminal would also mean that the user could interfere or intercede, which could be good or bad, depending on what you are trying to do.
Hi chrys,
Thanks for the reply. Using the Terminal may be worth trying for my scripts but it seems I will have to live with the short answer “no”.