At 2007-12-12 12:32PM, "geoffhazel" wrote: > I have an application that is perfect for expect. It replays a console > log (binary file) and is controlled by hitting return to get to the > next screen. > > Sometimes it needs to get two returns to get to the next page. > > When you are all done, return doesn't produce any output, and you send > ctrl-C to exit. > > The output you get from each "return" is highly variable, and may not > even include a newline. > > I want to write an expect script that will spawn the command, > "pbreplay" with an argument (the filename), and then keep sending \n > until the output stops, in which case send ctrl-C. > > It sounds pretty simple but I'm having a dickens of a time getting it > to work. > > Here's what I tried -- it just spawns and exits immediately: > > #!/usr/local/bin/expect > spawn /var/tmp/pbreplay $argv > send "\n" > expect { > timeout {exit} > * ( send \n } > } You spawn, send \n, expect anything, send another \n and then your program ends. First, to send a "return", use \r Next, if you want to loop in your expect command, use exp_continue. Expecting "*" will probably result in an infinite loop. Is there prompt to the user to clue them to hit return? If yes, that's what you should expect. Using "exp_internal 1" while testing your script can be helpful. spawn ... send -- "\r" expect { timeout { puts "timed out!" exit } * { send -- "\r" exp_continue } } -- Glenn Jackman "You can only be young once. But you can always be immature." -- Dave Barry

At 2007-12-12 01:31PM, "geoffhazel" wrote: > The problem is that there is no prompt to continue - you just get the > next screen of data in the log, and have to KNOW to hit return. So > what you're getting is impossible to pattern except for "*". Perhaps > if I could do a "not nothing" expect that would work? Unless at each expect, you remember what you saw previously and compare it to what you just saw. -- Glenn Jackman "You can only be young once. But you can always be immature." -- Dave Barry