"expect" problem

[nergal]

Hi,

I got a problem with expect. When the output from the spawned program
is comming to fast, expect fails to match patterns in the pipe.

I made a csh script that prints random stuff and a specific string in
the middle of the random output, like follows:
echo "yeah"
echo "rajraj"
echo" my:match here"
echo "more stuff"

Then I spawn this script from a expect (tcl) script and match the
middle line "my:match here". When I have as above it never match but
when I add a "sleep 2" between each row in the csh script the expect
script matches the line I look for.

How come it is so time sensitive? Any workaround? Any tips?

Best Regards,
Nergal

[Uwe Klein]

nergal wrote:
> Hi,
>
> I got a problem with expect. When the output from the spawned program
> is comming to fast, expect fails to match patterns in the pipe.
>
> I made a csh script that prints random stuff and a specific string in
> the middle of the random output, like follows:

#sprudel#####################################
#!/bin/bash

while true ; do

echo "yeah"
echo "rajraj"
echo "my:match here"
echo "more stuff"

done
#end##########################################

#!/usr/bin/expect

spawn sprudel

expect \
"my:match here" {
puts MATCHED
exp_continue
} eof {
puts EOF
}

this works for me like mad.

What platform are you on and which expect version?

could you post your script?

uwe

[nergal]

It kinda works now, but I got another related problem. If I match the
above line "my:match here" with regexp instead and add another row in
the sh script (e.g "my:matchTEXThere"). It matches the first correct
match but not the second even though I have exp_continue.

I got the following script:

set p "my"
set i "match"
set s "here"
set regExp "($process):($instance).*($state)"

expect {
-regexp $regExp {
puts "*** MATCH *** $expect_out(1,string)
$expect_out(2,string) $expect_out(3,string)"
exp_continue
}
}

Why does it only match one of the two sentences in the shell script?
Even more strange (at least to me) is that if I run the script a lot
of times it matches sometimes the first and sometimes the second
sentence.

[Uwe Klein]

If you change the RE to

set regExp "($process):($instance)(.*)($state)"

and print out the relevant expect_out(..,string) pattern
you will see why. ( the match spans both occurences )

if you convert your RE part from greedy ".*" to nongreedy ".*?"
you will imho see your match working properly:

set regExp "($process):($instance)(.*?)($state)"

uwe

[Cameron Laird]

In article <g41pg4-...@robert.houseofmax.de>,
Uwe Klein <uwe_klein_...@t-online.de> wrote:
.
.
.

>> It kinda works now, but I got another related problem. If I match the
>> above line "my:match here" with regexp instead and add another row in
>> the sh script (e.g "my:matchTEXThere"). It matches the first correct

.
.
.

>> Why does it only match one of the two sentences in the shell script?
>> Even more strange (at least to me) is that if I run the script a lot
>> of times it matches sometimes the first and sometimes the second
>> sentence.
>>
>If you change the RE to
>
> set regExp "($process):($instance)(.*)($state)"

.
.
.
Let me make a tangent: I'm noticing that several reports with a
symptom of the "sometimes Expect works, and sometimes it doesn't"
hide misunderstandings of RE matching. If an RE matches more
than the developer realizes, he might match on command output
(for example) long before the prompt which one typically [expect]s.
Poorly-reproducible results ensue, and Expect gets a reputation for
being hard.

[Uwe Klein]

Well, yes.
If the fat lady can't swim this will certainly be due to her inferior bathing suit.

These seem to be the major issues people hit:

1. expecting less than is advisable and too much in other places:

"Funny Users Password:" in contrast to "assword: "

2. underestimating the greediness of REs

".*" in contrast to ".*?"
or building really brilliant and convoluted REs
that break in really brilliant and convoluted ways.

3. using spawn where exp_send would be the proper command:

spawn telnet
.. login stuff ..
exp_send "MySuperDuperRemoteScript with some args\r"

4. being too optimistic and constructing scripts that continue unfazed due
to not handling "timeout" and "eof"

X. Would making un"expect"ed timeout or eof a catchable error help?

uwe