Expect fails because of the printouts are too fast?
Why Tea
try again.
We use a same set of Expect scripts to test 3 versions of systems with
the same command handling front-end. The scripts run fine on the two
older versions and failed latest. The printouts from the latest system
are much faster than its predecessor. Could that cause a problem to
Expect?
This is how it fails.
1) We have two command prompts to deal with:
< and :
i.e. the less than sign and the colon
2) It also happens that colon is used in the commands,
e.g. print:ip=123.123.123,123;
The prompt is set as:
set prompt "^.*\[<:\]$"
In the fastest machine, the detection of prompt fails when it sees the
':' (colon) inside the command. But it's OK with the other older
machines.
Any help or suggestion is much appreciated.
/Why Tea
Patrick Finnegan
Are you running on Windows or *nix?
Why Tea
wrote:
Sorry, I should have mentioned. It was from Unix (Solaris).
Larry W. Virden
> The printouts from the latest system
> are much faster than its predecessor. Could that cause a problem to
> Expect?
I wouldn't think it would cause Expect a problem. However, it might
make a script bug appear that had been "masked" by the slower systems
previously.
> 1) We have two command prompts to deal with:
> < and :
> i.e. the less than sign and the colon
>
> 2) It also happens that colon is used in the commands,
> e.g. print:ip=123.123.123,123;
>
> The prompt is set as:
> set prompt "^.*\[<:\]$"
So each line is preceeded by
SomeKindOfText[<:]$
followed immediately by text - no spaces, tabs, etc.?
>
> In the fastest machine, the detection of prompt fails when it sees the
> ':' (colon) inside the command. But it's OK with the other older
> machines.
So, what does the code look like where you are using $prompt?
Why Tea
The prompts are always on their own, i.e. a single character on a
line, not followed by anything. Of course there could be many
printouts preceding the prompts (I use plural as there are two
different prompts). The code fragment:
...
set prompt "^.*\[<:\]$"
...
expect {
-re $expect_to_see {
# Got what we expected, continue loop to wait for prompt
exp_continue
}
-re $prompt {
# we see the prompt, we are done
}
timeout {
# bad, do timeout stuff
}
}
Why Tea
> On Jul 13, 6:02 am, Why Tea <ytl...@gmail.com> wrote:
>
> > The printouts from the latest system
> > are much faster than its predecessor. Could that cause a problem to
> > Expect?
>
> I wouldn't think it would cause Expect a problem. However, it might
> make a script bug appear that had been "masked" by the slower systems
> previously.
>
I have the same feeling. But I couldn't figure out why
expect -re $prompt ;# which "^.*\[<:\]$"
could detect the colon (:) in an output string such as
PRINT:IP=xx.xx.xx.xx.xx;
It fails 60-70% of the time.
Could it be a bug in Expect?
How does Expect handle -re "^.*:$"? How does it handle the '$'?
/Why Tea
wiede...@googlemail.com
Why Tea wrote:
> Could it be a bug in Expect?
Probably not.
>
> How does Expect handle -re "^.*:$"? How does it handle the '$'?
"^" matches from the start of the buffer not the start of a line!
"$" matches the end of buffer content ( both are not that usefull in
this context )
".*" matches all upto the _last_ possible match of the following RE
part.
a more fitting RE might be: ( does your device place a " " after the
":" ?)
"/n.*?: "
with your slower devices output to expect is probably checked after
every character.
>
> /Why Tea
uwe
Why Tea
> Why Tea wrote:
> > Could it be a bug in Expect?
> Probably not.
>
> > How does Expect handle -re "^.*:$"? How does it handle the '$'?
>
> "^" matches from the start of the buffer not the start of a line!
> "$" matches the end of buffer content ( both are not that usefull in
> this context )
>
I understood the "^" part, but how does Expect know when is "$" as
data can be filling the buffer at irregular intervals?
".*" matches all upto the _last_ possible match of the following RE
> part.
>
> a more fitting RE might be: ( does your device place a " " after the
> ":" ?)
>
> "/n.*?: "
I tried "\n.*:" (no trailing space) but it didn't work. Will try your
non-greedy method when I'm back to work.
wiede...@googlemail.com
Why Tea wrote:
> I understood the "^" part, but how does Expect know when is "$" as
> data can be filling the buffer at irregular intervals?
>
<cite: man expect>
Note that in many editors, the ^ and $ match the
beginning and
end of lines respectively. However, because expect is
not line
oriented, these characters match the beginning and
end of the
data (as opposed to lines) currently in the expect
matching
buffer. (Also, see the note below on "system
indigestion.")
</end>
> > a more fitting RE might be: ( does your device place a " " after the
> > ":" ?)
> >
> > "/n.*?: "
>
> I tried "\n.*:" (no trailing space) but it didn't work. Will try your
> non-greedy method when I'm back to work.
If there is a space sent as part of the expected prompt you will get
funny
results if you leave it out of your RE.
This is the most frequently made mistake with expect leading to
obscure
errors and unreliable behaviour.
For example when waiting for a password a process might do the
following:
<send "password: ">
<flush any input>
<change tty over to no echo>
<wait for user input>
<change back to echo mode> ...
your input will be trashed in part or completely if you start your
response
after receiving the ":"
see: . http://wiki.tcl.tk/18013
uwe
Why Tea
Thanks Uwe for the reply. The login works fine. The system prompt
doesn't have a trailing space.
The reason I knew Expect detected the ":" inside the command instead
of the debug prompt ":" because I do a printout right after detection
of the prompt. When the fault occurred, that was immediately after the
":" in the command. We have exactly the same front-end command
handling system and the scripts only fail towards the fastest machine.
I understood the concept described in the link, otherwise all our
scripts would have failed one way or another.
Perhaps I should re-phrase the problem, how does Expect differentiate
the ":" in the following data:
This is a possible command syntax,
PRINT:ERRORLOG; It contains a colon
and Expect is confused with the colon
used as the debug prompt below
:
I only want to detect the ":" prompt, i.e. the second one, but Expect
detects the first one instead.
set prompt "^.*\[<:\]$" -- doesn't work for all systems
Why Tea
Sorry, I forgot to mention, the systems needs to handle two prompts
":" and "<". Both appear alone right after a new line and no trailing
space(s).
wiede...@googlemail.com
Why Tea wrote:
> Sorry, I forgot to mention, the systems needs to handle two prompts
> ":" and "<". Both appear alone right after a new line and no trailing
> space(s).
Any difference between the two prompts?
try:
expect \
\n: {
puts stderr "seen : prompt"
} \n< {
puts stderr "seen < prompt"
} timeout {
puts stderr "aijj TIMEOUT"
}
uwe
Why Tea
> Why Tea wrote:
> > Sorry, I forgot to mention, the systems needs to handle two prompts
> > ":" and "<". Both appear alone right after a new line and no trailing
> > space(s).
>
> Any difference between the two prompts?
Sorry. Not too sure what you meant here. While doing testing, we can
use send the normal command and expect for "<". We can also get into
debug mode to get tracing info and the prompt is ":". The same Expect
loop is use to send command (be it system or debug) and expect for
output text patterns. With the $prompt we are using, more than half of
the time on one of the systems, Expect detects the ":" inside the
command instead of the ":" prompt. Since it works 100% of the time on
two systems, and fails more than 50% on one (the fastest system), why
is such an inconsistency?
> try:
> expect \
> \n: {
> puts stderr "seen : prompt"
> } \n< {
> puts stderr "seen < prompt"
> } timeout {
> puts stderr "aijj TIMEOUT"
> }
OK. I'll try - set prompt "^.*\n\[<:\]" - when I get back to work on
Monday.
/Why Tea
Why Tea
Thanks for the hint. I just realized that there is an additional
character (\003) in front of the prompt. Once I inserted it into the
original prompt and now the scripts work for all machines.
Now that we know what the problem is, those scripts should have failed
from the beginning on the older machines. Why didn't they fail?
Thanks for everyone who helped out.
/Y.T.