TCL(Tool Command Language) Scripting :: utter newbie expect question


	Home \| .Net Programming \| cSharp Home \| Sql Server Home \| Javascript / Client Side Development \| Ajax Programming Ruby on Rails Development \| Perl Programming \| C Programming Language \| C++ Programming \| IT Jobs Python Programming Language \| Laptop Suggestions? \| TCL Scripting \| Fortran Programming \| Scheme Programming Language

Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0


	TCL(Tool Command Language) Scripting


	utter newbie expect question Let me start by declaring that had I access to the Exploring book, I would not be here posting this, I'd be figuring it out for myself and leaving you to more interesting problems. Thanks for your patience and any help you can offer. My problem is that the application I want to control could generate, at one point in its execution, any number (from 0 to 1000) "Press <Space> to Continue" prompts, and I cannot for the life of me figure out how to write an expect script that will deal with this. I need it to send " " when this prompt appears, then check to see if it gets that prompt again before it moves on, until it no longer gets that prompt. So it looks like this: expect "(A, B, C" send -- "c" # at this point, we can get any number of "Press <Space>" prompts, to which we need to send " " after capturing the response each time. expect "(X, Y, Z" send -- "y" etc. Thanks! On May 29, 5:43 pm, Artis Gripemore <wealthe@yahoo.com> wrote: - Hide quoted text - > Let me start by declaring that had I access to the Exploring book, I > would not be here posting this, I'd be figuring it out for myself and > leaving you to more interesting problems. Thanks for your patience > and any help you can offer. > My problem is that the application I want to control could generate, > at one point in its execution, any number (from 0 to 1000) "Press > <Space> to Continue" prompts, and I cannot for the life of me figure > out how to write an expect script that will deal with this. I need it > to send " " when this prompt appears, then check to see if it gets > that prompt again before it moves on, until it no longer gets that > prompt. > So it looks like this: > expect "(A, B, C" > send -- "c" > # at this point, we can get any number of "Press <Space>" prompts, to > which we need to send " " after capturing the response each time. > expect "(X, Y, Z" > send -- "y" > etc. > Thanks! Something like: expect { "<Space> to Continue" {send " " ; exp_continue} "(X, Y, Z" {send -- "y"} } Should do the trick. This will wait for either "(X, Y, Z" and send yes or wait for the <Space> line and send a space in response and then wait for either a <Space> line or a X, Y, Z line again. Mark Thanks very much! I suppose if I put a ;return after the send -- "y" that I could break out of this, if I had more script to run after the match on X, Y, Z? "(X, Y, Z" {send -- "y" ;return} Otherwise, it would continue with the next expect statement anyway, once it timed out, correct? Thanks again! On May 29, 1:11 pm, Mark Janssen <mpc.jans@gmail.com> wrote: - Hide quoted text - > On May 29, 5:43 pm, Artis Gripemore <wealthe@yahoo.com> wrote: > > Let me start by declaring that had I access to the Exploring book, I > > would not be here posting this, I'd be figuring it out for myself and > > leaving you to more interesting problems. Thanks for your patience > > and any help you can offer. > > My problem is that the application I want to control could generate, > > at one point in its execution, any number (from 0 to 1000) "Press > > <Space> to Continue" prompts, and I cannot for the life of me figure > > out how to write an expect script that will deal with this. I need it > > to send " " when this prompt appears, then check to see if it gets > > that prompt again before it moves on, until it no longer gets that > > prompt. > > So it looks like this: > > expect "(A, B, C" > > send -- "c" > > # at this point, we can get any number of "Press <Space>" prompts, to > > which we need to send " " after capturing the response each time. > > expect "(X, Y, Z" > > send -- "y" > > etc. > > Thanks! > Something like: > expect { > "<Space> to Continue" {send " " ; exp_continue} > "(X, Y, Z" {send -- "y"} > } > Should do the trick. This will wait for either "(X, Y, Z" and send yes > or wait for the <Space> line and send a space in response and then > wait for either a <Space> line or a X, Y, Z line again. > Mark- Hide quoted text - > On May 29, 8:40 pm, Artis Gripemore <wealthe@yahoo.com> wrote: > Thanks very much! I suppose if I put a ;return after the send -- "y" > that I could break out of this, if I had more script to run after the > match on X, Y, Z? > "(X, Y, Z" {send -- "y" ;return} > Otherwise, it would continue with the next expect statement anyway, > once it timed out, correct? No, by default the expect command will normally return after a match, a timeout or a eof has occured. It's the exp_continue in the other case that will keep on running the expect command so a return is not necessary. See also http://www.tcl.tk/man/expect5.31/expect.1.html Mark On May 29, 1:40 pm, Artis Gripemore <wealthe@yahoo.com> wrote: - Hide quoted text - > Thanks very much! I suppose if I put a ;return after the send -- "y" > that I could break out of this, if I had more script to run after the > match on X, Y, Z? > "(X, Y, Z" {send -- "y" ;return} > Otherwise, it would continue with the next expect statement anyway, > once it timed out, correct? > Thanks again! > On May 29, 1:11 pm, Mark Janssen <mpc.jans@gmail.com> wrote: > > On May 29, 5:43 pm, Artis Gripemore <wealthe@yahoo.com> wrote: > > > Let me start by declaring that had I access to the Exploring book, I > > > would not be here posting this, I'd be figuring it out for myself and > > > leaving you to more interesting problems. Thanks for your patience > > > and any help you can offer. > > > My problem is that the application I want to control could generate, > > > at one point in its execution, any number (from 0 to 1000) "Press > > > <Space> to Continue" prompts, and I cannot for the life of me figure > > > out how to write an expect script that will deal with this. I need it > > > to send " " when this prompt appears, then check to see if it gets > > > that prompt again before it moves on, until it no longer gets that > > > prompt. > > > So it looks like this: > > > expect "(A, B, C" > > > send -- "c" > > > # at this point, we can get any number of "Press <Space>" prompts, to > > > which we need to send " " after capturing the response each time. > > > expect "(X, Y, Z" > > > send -- "y" > > > etc. > > > Thanks! > > Something like: > > expect { > > "<Space> to Continue" {send " " ; exp_continue} > > "(X, Y, Z" {send -- "y"} > > } > > Should do the trick. This will wait for either "(X, Y, Z" and send yes > > or wait for the <Space> line and send a space in response and then > > wait for either a <Space> line or a X, Y, Z line again. > > Mark- Hide quoted text - > > Actually the way the script is written the first time you send "y" you will leave the script no return needed. You will only do the send once. By default expect does not loop unless you have exp_continue. Carl This is the error message I get. I don't see the typo, but I assume that it is there. Any ideas? Thanks again. wrong # args: should be "send ignore arg" while executing "send " " " invoked from within "expect -nobrace {<SPACE> to continue} {send " " ; exp_continue} {Choose one (X,Y,Z} {send -- "y"}" invoked from within "expect { "<SPACE> to continue" {send " " ; exp_continue} "Choose one (X,Y,Z" {send -- "y"} }" On May 29, 2:51 pm, Mark Janssen <mpc.jans@gmail.com> wrote: - Hide quoted text - > On May 29, 8:40 pm, Artis Gripemore <wealthe@yahoo.com> wrote: > > Thanks very much! I suppose if I put a ;return after the send -- "y" > > that I could break out of this, if I had more script to run after the > > match on X, Y, Z? > > "(X, Y, Z" {send -- "y" ;return} > > Otherwise, it would continue with the next expect statement anyway, > > once it timed out, correct? > No, by default the expect command will normally return after a match, > a timeout or a eof has occured. It's the exp_continue in the other > case that will keep on running the expect command so a return is not > necessary. See alsohttp://www.tcl.tk/man/expect5.31/expect.1.html > Mark On May 29, 9:44 pm, Artis Gripemore <wealthe@yahoo.com> wrote: - Hide quoted text - > This is the error message I get. I don't see the typo, but I assume > that it is there. Any ideas? Thanks again. > wrong # args: should be "send ignore arg" > while executing > "send " " " > invoked from within > "expect -nobrace {<SPACE> to continue} {send " " ; exp_continue} > {Choose one (X,Y,Z} {send -- "y"}" > invoked from within > "expect { > "<SPACE> to continue" {send " " ; exp_continue} > "Choose one (X,Y,Z" {send -- "y"} > }" > On May 29, 2:51 pm, Mark Janssen <mpc.jans@gmail.com> wrote: > > On May 29, 8:40 pm, Artis Gripemore <wealthe@yahoo.com> wrote: > > > Thanks very much! I suppose if I put a ;return after the send -- "y" > > > that I could break out of this, if I had more script to run after the > > > match on X, Y, Z? > > > "(X, Y, Z" {send -- "y" ;return} > > > Otherwise, it would continue with the next expect statement anyway, > > > once it timed out, correct? > > No, by default the expect command will normally return after a match, > > a timeout or a eof has occured. It's the exp_continue in the other > > case that will keep on running the expect command so a return is not > > necessary. See alsohttp://www.tcl.tk/man/expect5.31/expect.1.html > > Mark It might be that you are having a name collistion with the standard Tk command send (I cannot test as I am on windows). To prevent the collision use exp_send instead (which is a good habit to get into anyway). If that doesn't work, try exp_send -- " ". Additionally, what is your Expect and Tcl version? result of: info patchlevel and of: package require Expect Or are you using the expect binary to run the script? Then what does expect -v say? Mark It would appear to be working now. I did change all the sends to exp_sends, but then the script would not run at all, but that helped me debug a bit. The problem seemed to be that I had it in conservative mode. Does that make sense? So now I have exp_sends, conservative mode off, and a load of sleeps inserted, and it seems to work in limited testing. Thanks again; I was completely lost! On May 29, 4:17 pm, Mark Janssen <mpc.jans@gmail.com> wrote: - Hide quoted text - > On May 29, 9:44 pm, Artis Gripemore <wealthe@yahoo.com> wrote: > > This is the error message I get. I don't see the typo, but I assume > > that it is there. Any ideas? Thanks again. > > wrong # args: should be "send ignore arg" > > while executing > > "send " " " > > invoked from within > > "expect -nobrace {<SPACE> to continue} {send " " ; exp_continue} > > {Choose one (X,Y,Z} {send -- "y"}" > > invoked from within > > "expect { > > "<SPACE> to continue" {send " " ; exp_continue} > > "Choose one (X,Y,Z" {send -- "y"} > > }" > > On May 29, 2:51 pm, Mark Janssen <mpc.jans@gmail.com> wrote: > > > On May 29, 8:40 pm, Artis Gripemore <wealthe@yahoo.com> wrote: > > > > Thanks very much! I suppose if I put a ;return after the send -- "y" > > > > that I could break out of this, if I had more script to run after the > > > > match on X, Y, Z? > > > > "(X, Y, Z" {send -- "y" ;return} > > > > Otherwise, it would continue with the next expect statement anyway, > > > > once it timed out, correct? > > > No, by default the expect command will normally return after a match, > > > a timeout or a eof has occured. It's the exp_continue in the other > > > case that will keep on running the expect command so a return is not > > > necessary. See alsohttp://www.tcl.tk/man/expect5.31/expect.1.html > > > Mark > It might be that you are having a name collistion with the standard Tk > command send (I cannot test as I am on windows). To prevent the > collision use exp_send instead (which is a good habit to get into > anyway). If that doesn't work, try exp_send -- " ". > Additionally, what is your Expect and Tcl version? > result of: info patchlevel > and of: package require Expect > Or are you using the expect binary to run the script? > Then what does expect -v say? > Mark- Hide quoted text - > On May 29, 11:03 pm, Artis Gripemore <wealthe@yahoo.com> wrote: - Hide quoted text - > It would appear to be working now. I did change all the sends to > exp_sends, but then the script would not run at all, but that helped > me debug a bit. The problem seemed to be that I had it in > conservative mode. Does that make sense? > So now I have exp_sends, conservative mode off, and a load of sleeps > inserted, and it seems to work in limited testing. > Thanks again; I was completely lost! > On May 29, 4:17 pm, Mark Janssen <mpc.jans@gmail.com> wrote: > > On May 29, 9:44 pm, Artis Gripemore <wealthe@yahoo.com> wrote: > > > This is the error message I get. I don't see the typo, but I assume > > > that it is there. Any ideas? Thanks again. > > > wrong # args: should be "send ignore arg" > > > while executing > > > "send " " " > > > invoked from within > > > "expect -nobrace {<SPACE> to continue} {send " " ; exp_continue} > > > {Choose one (X,Y,Z} {send -- "y"}" > > > invoked from within > > > "expect { > > > "<SPACE> to continue" {send " " ; exp_continue} > > > "Choose one (X,Y,Z" {send -- "y"} > > > }" > > > On May 29, 2:51 pm, Mark Janssen <mpc.jans@gmail.com> wrote: > > > > On May 29, 8:40 pm, Artis Gripemore <wealthe@yahoo.com> wrote: > > > > > Thanks very much! I suppose if I put a ;return after the send -- "y" > > > > > that I could break out of this, if I had more script to run after the > > > > > match on X, Y, Z? > > > > > "(X, Y, Z" {send -- "y" ;return} > > > > > Otherwise, it would continue with the next expect statement anyway, > > > > > once it timed out, correct? > > > > No, by default the expect command will normally return after a match, > > > > a timeout or a eof has occured. It's the exp_continue in the other > > > > case that will keep on running the expect command so a return is not > > > > necessary. See alsohttp://www.tcl.tk/man/expect5.31/expect.1.html > > > > Mark > > It might be that you are having a name collistion with the standard Tk > > command send (I cannot test as I am on windows). To prevent the > > collision use exp_send instead (which is a good habit to get into > > anyway). If that doesn't work, try exp_send -- " ". > > Additionally, what is your Expect and Tcl version? > > result of: info patchlevel > > and of: package require Expect > > Or are you using the expect binary to run the script? > > Then what does expect -v say? > > Mark- Hide quoted text - > > Are you using autoexpect by any chance? In that case conservative mode makes sense. Mark In article <1180472623.821578.15@u30g2000hsc.googlegroups.com>, Artis Gripemore <wealthe@yahoo.com> wrote: >It would appear to be working now. I did change all the sends to >exp_sends, but then the script would not run at all, but that helped >me debug a bit. The problem seemed to be that I had it in >conservative mode. Does that make sense? >So now I have exp_sends, conservative mode off, and a load of sleeps >inserted, and it seems to work in limited testing. . . . The sleeps are generally a symptom that there's a better coding available. It's unlikely they're helping in other than a super- ficial way. On May 29, 5:30 pm, Mark Janssen <mpc.jans@gmail.com> wrote: - Hide quoted text - > On May 29, 11:03 pm, Artis Gripemore <wealthe@yahoo.com> wrote: > > It would appear to be working now. I did change all the sends to > > exp_sends, but then the script would not run at all, but that helped > > me debug a bit. The problem seemed to be that I had it in > > conservative mode. Does that make sense? > > So now I have exp_sends, conservative mode off, and a load of sleeps > > inserted, and it seems to work in limited testing. > > Thanks again; I was completely lost! > > On May 29, 4:17 pm, Mark Janssen <mpc.jans@gmail.com> wrote: > > > On May 29, 9:44 pm, Artis Gripemore <wealthe@yahoo.com> wrote: > > > > This is the error message I get. I don't see the typo, but I assume > > > > that it is there. Any ideas? Thanks again. > > > > wrong # args: should be "send ignore arg" > > > > while executing > > > > "send " " " > > > > invoked from within > > > > "expect -nobrace {<SPACE> to continue} {send " " ; exp_continue} > > > > {Choose one (X,Y,Z} {send -- "y"}" > > > > invoked from within > > > > "expect { > > > > "<SPACE> to continue" {send " " ; exp_continue} > > > > "Choose one (X,Y,Z" {send -- "y"} > > > > }" > > > > On May 29, 2:51 pm, Mark Janssen <mpc.jans@gmail.com> wrote: > > > > > On May 29, 8:40 pm, Artis Gripemore <wealthe@yahoo.com> wrote: > > > > > > Thanks very much! I suppose if I put a ;return after the send -- "y" > > > > > > that I could break out of this, if I had more script to run after the > > > > > > match on X, Y, Z? > > > > > > "(X, Y, Z" {send -- "y" ;return} > > > > > > Otherwise, it would continue with the next expect statement anyway, > > > > > > once it timed out, correct? > > > > > No, by default the expect command will normally return after a match, > > > > > a timeout or a eof has occured. It's the exp_continue in the other > > > > > case that will keep on running the expect command so a return is not > > > > > necessary. See alsohttp://www.tcl.tk/man/expect5.31/expect.1.html > > > > > Mark > > > It might be that you are having a name collistion with the standard Tk > > > command send (I cannot test as I am on windows). To prevent the > > > collision use exp_send instead (which is a good habit to get into > > > anyway). If that doesn't work, try exp_send -- " ". > > > Additionally, what is your Expect and Tcl version? > > > result of: info patchlevel > > > and of: package require Expect > > > Or are you using the expect binary to run the script? > > > Then what does expect -v say? > > > Mark- Hide quoted text - > > > > Are you using autoexpect by any chance? In that case conservative mode > makes sense. > Mark- Hide quoted text - > Yes, I did use autoexpect -p to build the original script. Lots of editing. Next time, by hand. The script outruns the application at one point, so I have simulated the delay by inserting sleeps. I know that there is some kind of "human typing" option, but I haven't looked into it yet. I'm just happy that the major stumbling blocks are overcome. One thing that looks interesting to try next -- have the script read the menu it has accessed, to ensure the correctness of the next exp_send. If the correct choice off a given menu, say foo, is 16 most of the time, but can be 17 some of the time, it would be cool to read in from the buffer and then use the number associated with foo in the corresponding exp_send. I gotta get that book. On May 29, 6:23 pm, cla@lairds.us (Cameron Laird) wrote: > In article <1180472623.821578.15@u30g2000hsc.googlegroups.com>, > Artis Gripemore <wealthe@yahoo.com> wrote:>It would appear to be working now. I did change all the sends to > >exp_sends, but then the script would not run at all, but that helped > >me debug a bit. The problem seemed to be that I had it in > >conservative mode. Does that make sense? > >So now I have exp_sends, conservative mode off, and a load of sleeps > >inserted, and it seems to work in limited testing. > . > . > . > The sleeps are generally a symptom that there's a better coding > available. It's unlikely they're helping in other than a super- > ficial way. I'm sure that you are right about that. The app does fail at one point with the script going full out, but I doubt that the delays are needed everywhere I put them. Thanks! In article <1180533175.419845.307@g4g2000hsf.googlegroups.com>, Artis Gripemore <wealthe@yahoo.com> wrote: - Hide quoted text - >On May 29, 6:23 pm, cla@lairds.us (Cameron Laird) wrote: >> In article <1180472623.821578.15@u30g2000hsc.googlegroups.com>, >> Artis Gripemore <wealthe@yahoo.com> wrote:>It would appear to be >working now. I did change all the sends to >> >exp_sends, but then the script would not run at all, but that helped >> >me debug a bit. The problem seemed to be that I had it in >> >conservative mode. Does that make sense? >> >So now I have exp_sends, conservative mode off, and a load of sleeps >> >inserted, and it seems to work in limited testing. >> . >> . >> . >> The sleeps are generally a symptom that there's a better coding >> available. It's unlikely they're helping in other than a super- >> ficial way. >I'm sure that you are right about that. The app does fail at one >point with the script going full out, but I doubt that the delays are >needed everywhere I put them. >Thanks! Are you using sleep ... in place of a sufficiently specific expect ... ? I urge you to reconsider the latter. On May 30, 10:37 am, cla@lairds.us (Cameron Laird) wrote: - Hide quoted text - > In article <1180533175.419845.307@g4g2000hsf.googlegroups.com>, > Artis Gripemore <wealthe@yahoo.com> wrote: > >On May 29, 6:23 pm, cla@lairds.us (Cameron Laird) wrote: > >> In article <1180472623.821578.15@u30g2000hsc.googlegroups.com>, > >> Artis Gripemore <wealthe@yahoo.com> wrote:>It would appear to be > >working now. I did change all the sends to > >> >exp_sends, but then the script would not run at all, but that helped > >> >me debug a bit. The problem seemed to be that I had it in > >> >conservative mode. Does that make sense? > >> >So now I have exp_sends, conservative mode off, and a load of sleeps > >> >inserted, and it seems to work in limited testing. > >> . > >> . > >> . > >> The sleeps are generally a symptom that there's a better coding > >> available. It's unlikely they're helping in other than a super- > >> ficial way. > >I'm sure that you are right about that. The app does fail at one > >point with the script going full out, but I doubt that the delays are > >needed everywhere I put them. > >Thanks! > Are you using > sleep ... > in place of a sufficiently specific > expect ... > ? I urge you to reconsider the latter.- Hide quoted text - > I will do so. I never stop trying to make these things better. Thanks again.


	Add to del.icio.us \| Digg this \| Stumble it \| Powered by Megasolutions Inc