Problem with Expect...
nodeerforamonth
that's supposed to run several Informatica workflows. It's supposed to run
one, then wait for it to end, then run the next one, wait for it to end,
then run the next one... etc...
But instead it runs the first one, and then cuts right back to the UNIX
prompt! Any ideas? I thought Expect was supposed to wait for the expected
strings from the server, then run commands accordingly.
Here is the basics of the script (user/password information deleted.
everything works up to here): Forgive the crudeness. I've tried several
different ways to do this and it all has failed. This is just the current
way I'm using Expect:
The script telnets into the Informatica server.
.
.
.
expect "C:\>"
send "D:\r"
expect "D:\>"
send "cd InformaticaData\\bin\r"
expect -exact "D:\InformaticaData\bin>"
send "pmcmd startworkflow -u <username> -p <password> -s
informatica-server:9999 wf_BF_agg_all_cbs2csa\r"
#sleep 120
expect {
"Completed at" {
send "\r";
sleep 5;
send "pmcmd waitworkflow -u <username> -p <password> -s
informatica-server:9999 wf_BF_agg_all_cbs2csa\r";
}
timeout { exp_continue}
}
expect {
"Completed at" {
send "\r";
sleep 5;
send "pmcmd startworkflow -u <username> -p <password> -s
informatica-server:9999 wf_BF_agg_all_ctr2all\r"
}
timeout { exp_continue}
}
#sleep 120
expect {
"Completed at" {
send "\r";
sleep 5;
send "pmcmd waitworkflow -u <username> -p <password> -s
informatica-server:9999 wf_BF_agg_all_ctr2all\r";
}
timeout { exp_continue}
}
expect -exact "D:\InformaticaData\bin>"
send "exit\r"
expect eof
exit
And this is what I get:
Connected to Informatica Server at [informatica-server:9999]
Starting workflow [wf_BF_agg_all_cbs2csa]
INFO: Starting execution of workflow [wf_BF_agg_all_cbs2csa] in folder
[Dev_folderg_all_ctr2all\r";
] last saved by user [username]
Disconnecting from Informatica Server
Completed at Fri Sep 15 19:15:58 2006
D:\InformaticaData\bin>
D:\InformaticaData\bin>pmcmd waitworkflow -u username -p password -s
informatica-server:400
1 wf_BF_agg_all_cbs2csa
Informatica(tm) PMCMD, version [7.1.2], build [0127], 32-bit
Copyright (c) Informatica Corporation 1994 - 2005
All Rights Reserved.
Invoked at Fri Sep 15 19:16:04 2006
Connected to Informatica Server at [informatica-server:9999]
/var/users/sdradm/code/bf_summary/ksh>
It goes right to the UNIX prompt right after running the 2nd pmcmd! It's
supposed to wait until it finishes, but goes right into the prompt. This
works if I do it by hand, but not when put into an Expect script. Isn't
Expect supposed to wait until the telnet prompt appears?!?!
Uwe Klein
> expect {
> "Completed at" {
> send "\r";
> sleep 5;
> send "pmcmd startworkflow -u <username> -p <password> -s
> informatica-server:9999 wf_BF_agg_all_ctr2all\r"
> }
> timeout { puts stderr "TIMEOUT at $action ; exp_continue}
eof { puts stderr "EOF seen at $action " }
> }
could it be that you are kicked from the server?
enhance your [expect]s to notice "EOF" with some debugging output.
uwe
Ben C
Rather than timeout { exp_continue } just do
set timeout -1
at the start of your script. That means "wait as long as it takes".
The problem might be that you only expect "Completed at", and then start
sending the next bit of input. But "Completed at" is only the start of
the message-- "Completed at Fri Sep 15 19:15:58 2006" is the whole line,
and then the prompt. It may be that this pmcmd program doesn't tolerate
having its throat jumped down, and so is terminating prematurely.
Something like this might work better:
set prompt "D:\InformaticaData\bin>"
expect {
"Completed at" {set ok true; exp_continue}
-exact $prompt
}
# check value of $ok here and abort etc. if you want, then carry on:
send "\r"
expect -exact $prompt
send "pmcmd startworkflow -u <username> -p <password> -s \
informatica-server:9999 wf_BF_agg_all_ctr2all\r"
etc.
In other words, always wait for the full prompt before sending the next
bit.
> expect {
> "Completed at" {
> send "\r";
> sleep 5;
> send "pmcmd startworkflow -u <username> -p <password> -s
> informatica-server:9999 wf_BF_agg_all_ctr2all\r"
> }
> timeout { exp_continue}
> }
>
> #sleep 120
>
> expect {
> "Completed at" {
> send "\r";
> sleep 5;
> send "pmcmd waitworkflow -u <username> -p <password> -s
> informatica-server:9999 wf_BF_agg_all_ctr2all\r";
> }
> timeout { exp_continue}
> }
>
> expect -exact "D:\InformaticaData\bin>"
This expect _will_ timeout after the default (which is usually 10
seconds). But I don't think this is your actual problem since you don't
get this far.
> [...]
Uwe Klein
if he drops out of expect it is either eof
or some error.
He did not tell of any error messages.
uwe
Tom Conner
"nodeerforamonth" <nodeer_nosp...@hotmail.com> wrote in message
news:gahPg.2559$IA....@newssvr11.news.prodigy.com...
> Is there something I'm not understanding about Expect?
>
Probably. On one hand, Expect is a great program. On the other hand, you
need to read and reread the book to get Expect scripts working 100%. There
is always some little gotcha with Expect.
> expect {
> "Completed at" {
> send "\r";
> sleep 5;
> send "pmcmd waitworkflow -u <username> -p <password> -s
> informatica-server:9999 wf_BF_agg_all_cbs2csa\r";
> }
> timeout { exp_continue}
> }
Always have send/expect pairs. "send xxxx; send yyyy" has given me grief in
the past.
nodeerforamonth
> Rather than timeout { exp_continue } just do
>
> set timeout -1
>
> at the start of your script. That means "wait as long as it takes".
Tried that a few days ago. That makes the whole system just hang there
forever.
> The problem might be that you only expect "Completed at", and then start
> sending the next bit of input. But "Completed at" is only the start of
> the message-- "Completed at Fri Sep 15 19:15:58 2006" is the whole line,
> and then the prompt. It may be that this pmcmd program doesn't tolerate
> having its throat jumped down, and so is terminating prematurely.
>
> Something like this might work better:
>
> set prompt "D:\InformaticaData\bin>"
> expect {
> "Completed at" {set ok true; exp_continue}
> -exact $prompt
> }
Tried that first a couple weeks ago. Same thing happens: it just cuts out
to the UNIX prompt after awhile.
nodeerforamonth
to get the server prompt when running it by hand, I have to hit return
because it does not come up by itself. And I sleep it for 5 seconds because
it takes little while for the prompt to come up after hitting return.
This part does work though. What is supposed to happen is that the server
is not supposed to show it's prompt until the workflow is finish. What I
get is being kicked out of the server and I get the UNIX prompt after a few
seconds.
I'm thinking it's something with how the server is set up.
"Tom Conner" <tco...@olopha.net> wrote in message
news:sBjPg.13485$xQ1....@newsread3.news.pas.earthlink.net...
nodeerforamonth
If it's a problem with the server, I wonder how I'm going to relate that to
the IT department over there. That's problem for another time. :-)
Thanks.
"Uwe Klein" <uwe_klein_...@t-online.de> wrote in message
news:snl0u3-...@robert.houseofmax.de...
Cameron Laird
nodeerforamonth <nodeer_nosp...@hotmail.com> wrote:
>Is there something I'm not understanding about Expect? I have a script
>that's supposed to run several Informatica workflows. It's supposed to run
>one, then wait for it to end, then run the next one, wait for it to end,
>then run the next one... etc...
>
>But instead it runs the first one, and then cuts right back to the UNIX
>prompt! Any ideas? I thought Expect was supposed to wait for the expected
>strings from the server, then run commands accordingly.
>
>Here is the basics of the script (user/password information deleted.
>everything works up to here): Forgive the crudeness. I've tried several
>different ways to do this and it all has failed. This is just the current
>way I'm using Expect:
>
>The script telnets into the Informatica server.
>
>.
>.
>.
>expect "C:\>"
>send "D:\r"
>expect "D:\>"
>send "cd InformaticaData\\bin\r"
>
>expect -exact "D:\InformaticaData\bin>"
.
.
You all are working too hard.
The follow-ups have related many true facts. Apparently no one
has noticed what lines like
expect -exact "D:\InformaticaData\bin>"
really do.
Just for practice, start with
set prompt "D:\InformaticaData\bin>"
puts "The prompt is '$prompt'."
expect -exact $prompt
There are other problems in the script. That's a good starting
point, though.
Cameron Laird
Tom Conner <tco...@olopha.net> wrote:
.
.
.
>need to read and reread the book to get Expect scripts working 100%. There
>is always some little gotcha with Expect.
.
.
"There is always ..."--slander, or blasphemy? You decide.
Cameron Laird
nodeerforamonth <nodeer_nosp...@hotmail.com> wrote:
>Tried that too. The reason I put the first "send \r" in there is in order
>to get the server prompt when running it by hand, I have to hit return
>because it does not come up by itself. And I sleep it for 5 seconds because
.
.
>I'm thinking it's something with how the server is set up.
.
.
Nothing presented in this thread suggests to me a problem
with the server. Expect is up to all the challenges
described. You might like <URL: http://wiki.tcl.tk/3173 >.
Tom Conner
"Cameron Laird" <cla...@lairds.us> wrote in message
news:eb71u3-...@lairds.us...
Neither. Truth is the correct answer. :)
Ben C
> In article <gahPg.2559$IA....@newssvr11.news.prodigy.com>,
> nodeerforamonth <nodeer_nosp...@hotmail.com> wrote:
>>expect "C:\>"
>>send "D:\r"
>>expect "D:\>"
>>send "cd InformaticaData\\bin\r"
>>
>>expect -exact "D:\InformaticaData\bin>"
> .
> .
> .
> You all are working too hard.
>
> The follow-ups have related many true facts. Apparently no one
> has noticed what lines like
> expect -exact "D:\InformaticaData\bin>"
> really do.
>
> Just for practice, start with
>
> set prompt "D:\InformaticaData\bin>"
> puts "The prompt is '$prompt'."
> expect -exact $prompt
This was my suggestion. The problem I now see with it is that \I and \b
are "escaped" into I and the bell character.
Although the OP had:
expect -exect "D:\InformaticaData\bin>"
which suffers from the same problem.
set prompt {D:\InformaticaData\bin>}
seems like the way to go.
nodeerforamonth
"Ben C" <spam...@spam.eggs> wrote in message
news:slrnegsglq....@bowser.marioworld...
But expect -exect "D:\InformaticaData\bin>" works the first time around!
Not the second. expect "D:\" works too. Everything runs fine up until the
3rd pmcmd statement.
Do I have to clear a buffer that expect uses to search for incoming text?
Cameron Laird
.
.
>But expect -exect "D:\InformaticaData\bin>" works the first time around!
>Not the second. expect "D:\" works too. Everything runs fine up until the
>3rd pmcmd statement.
>
>Do I have to clear a buffer that expect uses to search for incoming text?
>
>
>
While I recognize you're sincere, I have *very* serious
doubts that
expect -exect "D:\InformaticaData\bin>"
and
expect "D:\"
do what you think they do. Again, I STRONGLY recommend you
use good debugging technique <URL: http://wiki.tcl.tk/3173 >.
Bezoar
Does the server have a timeout I think that you are timing out because
of the sleeps; since
you already exp_continue in the timeout you should set timeout to a
value and then set a limit that
way if the server comes back in 5 seconds you are not sitting there
waiting for 115 seconds. Also
using -exact is a good way to ensure that you will always have to
revisit your script to fix it. Use
either the glob or the regexp means of matching:
expect "C:\>"
send "D:\r"
expect "D:\>"
send "cd InformaticaData\bin\r"
# go to main expect loop below to expect the prompt
set timeout 5
set maxcount 24 ; # total number of timeouts to get before exiting
set count 0 ;
set cmdcount 0 ;
set ok 0 ;
# send each command twice ?
set cmd(0) "pmcmd startworkflow -u <username> -p <password> -s
informatica-server:9999 wf_BF_agg_all_cbs2csa"
set cmd(1) "pmcmd startworkflow -u <username> -p <password> -s
informatica-server:9999 wf_BF_agg_all_cbs2csa"
set cmd(2) "pmcmd startworkflow -u <username> -p <password> -s
informatica-server:9999 wf_BF_agg_all_ctr2all"
set cmd(3) "pmcmd startworkflow -u <username> -p <password> -s
informatica-server:9999 wf_BF_agg_all_ctr2all"
expect {
-exact {Completed At} {
# don't let user see behind seens
log_user 0
# if timeout is 5 then in 5 seconds if nothing else is
recieved timeout will send \r
set sendCR 1
exp_continue;
}
-re {.*[0-9]{2}:[0-9]{2}:[0-9]{2} 20[0-9]{2}} {
send_user "Completed At $expect_out(buffer)\n";
# got time now lets wait for prompt
set count 0 ; # reset the timeout
exp_continue;
}
-re {.*>} {
send_user "At prompt\n"
if { [info exists cmd($cmdcount) ] } {
exp_send "$cmd($cmdcount)\r"
# set up for next command
incr cmdcount
# let user see whats happenning
log_user 1
} else {
send_user "All commands processed\nExiting\n"
exp_send "exit\r"
set ok 1
}
exp_continue
}
timeout {
incr count
if { count < $maxcount } {
if { $sendCR } {
send "\r"
set sendCR 0
}
exp_continue;
} else {
# error message to include what expect has gotten so
far
send_user "TIMEOUT : $expect_out(buffer)"
}
}
eof {
if { !$ok } {
send_user "Oops suddenly cut off\n "
} else {
send_user "Done successfully at [clock format [clock
seconds ] ] "
}
}
# always get exit status
set exitstatus [ exp_wait -nowait -i $spawn_id ]
puts "exit status is : $exitstatus"
# always close with catch
catch { exp_close -i $spawn_id }
if { $ok } {
exit 0
} else {
# you can get spawn program exit status from [lindex $exitstatus 3 ]
otherwise do this
exit 1
}