------------------------------------------------------------------------------- Co-Processing using Expect programming ------------------------------------------------------------------------------- Hints and tips... http://www.linuxquestions.org/questions/showthread.php?p=5523296#post5523296 When using expect, recognising a prompt can be very difficult, especially if you don't want false positives. I don't use Tcl Expect. I prefer to use Perl Expect as it tends to give better control, but that is personal programming taste. And the major tip (learned from long experience): Don't try to search for everything in the one expect, search in stages, at which point you either fail (known error), proceed to next (or other stage), or time out for unknown reasons. --- Always include a timeout! The more stages (even very short, look for prompt) and you get better control and error condition handling. Typically when running a command with unknown output I wrap the command with 'start of data' and 'end of data' tags, and look for those. Only after seeing the end of data (at which point I grab the command output) then I look for a prompt for further processing (next stage). Example (perl expect) =======8<-------- # Data Wrapper Flags - to seperate actual output from other stuff my $SOD = "-----SoD-----"; my $EOD = "-----EoD-----"; my $SOD_echo = "-----\\SoD-----"; # so we do not match the typed command my $EOD_echo = "-----\\EoD-----"; $command = "echo $SOD_echo; $command; echo $EOD_echo;"; # Wrapper the command =======8<-------- At this time I use a subroutine structure, with each subroutine sending a command (or not), then looking for expected (and known unexpected) results. When one subrountine thinks it reaches the next stage it calls the next sub-routine handling the 'send-expect' cycle for the next stage, OR it calls a 'error' or 'finish' subroutine to note results, before just exiting the expect structure and the subroutine. Now at the final stage you will have a long chain of sub-routine calls. I am not keen on this, and I don't consider it a elegant solution, but so far it it has shown to be the most versitile, allowing me to skip stages, and handle errors simply. For example if a "ssh" command gets a 'terminal' prompt, instead of a 'password' prompt, I know a ssh key caused it to skip a stage, and I can skip the 'send ssh password' stage. That can be hard to do in a 'linear', one expect script after another, type of expect programming. ------------------------------------------------------------------------------- One of the simplest and more useful expect applications... expect -c " spawn mysql --host=localhost --user=$mySqlUser --password ... expect -nocase \"Enter password:\" {send \"$mySqlPassword\r\"; interact} " -------------------------------------------------------------------------------