Re: [Expectperl-discuss] Accumalation behaviour differs on different systems.

[KhAoZ <xk...@gm...>]

Yeah, I was expecting such an answer, just hoped I might get lucky
with a quick hack. I'll show you my problems, but its really an ugly
problem that I have to deal with since so much of the code base was
written like this from my predecessor.

What I'm doing right now is using expect to spawn a telnet connection
to a remote server, and executing a bunch of tests. Because this is a
telnet process, when I run commands, the only way to really see if the
command has ended is to try and parse the shell output (Ie, looking
for a "> "). Previously, most of the code looked for those special
shell characters implying a command has finished, but that ended up
being very unreliable, so I simply ran commands like this "command;
echo RESULT $?", and I knew the command was finished when I saw RESULT
\d+.

Thus, my code was like this:

$console->expect($timeout,
     [qr/RESULT (\d+)/ , sub { .. finished .. } ],
     .. command related expects ..

This worked fine when RESULT would only appear at the end, but now the
entire output of the command matched immediately, and the RESULT
pattern would simply match right away and prevent any of the other
expect patterns to match anything. The obvious solution here would be
to put the RESULT pattern at the end. However, that breaks a lot of
existing code base because a bunch of the patterns end up matching
RESULT (Ie. ^(.+)$).

I am only now thinking of making trying to change the whole
expect<->telnet thing. I've looked at Net::SSH::Perl, but that seems
like more for interaction with a user. Anyways, any ideas you have
would be very helpful.

Thanks for your help.

Note: The two servers actually have identical specs, and have the
exact same jumpstart images as well. There is probably something
running on one of them that may be slowing it down a notch, but I am
honestly amazed that each server can so reliably produce different
behaviors.


On Tue, Apr 21, 2009 at 11:55 AM, Roland Giersig <rgi...@cp...> wrote:
> Hi,
>
> let me guess: the new machine is much faster than the old one? :-)
>
> Sorry, both behaviours are perfectly valid, you must not make any
> assumptions about how fast the lines will arrive and when matching will
> occur. And no, there is no way to force any line-reading behaviour upon
> Expect, it always reads in chunks the way it gets them from the OS.
>
> So I'm afraid it really means going over the match-logic again and figure
> out a way that works in any way. BTW, what problem did you have to "work
> around"? Maybe you can post the relevant matching code so I can point out
> problems? Maybe the solution is to split and/or combine expect()
> statements...
>
> Best regards,
> Roland
>
> KhAoZ wrote:
>>
>> I've been developing with Expect on this one system, and I have a huge
>> code base that works perfectly fine on that server. However, I just
>> tried moving to another server (of the exact spec and OS), and I'm
>> getting a different behavior with the pattern matching with respect to
>> the command accumulation.
>>
>> On the server that works, when I run a command, the pattern matching
>> behavior is as follows:
>>
>> output line #1
>>  -> try all patterns
>> output line #1
>> output line #2
>> -> try all patterns
>> output line #1
>> outline line #2
>> output line #3
>> -> try all patterns
>> -> found a match
>> output line #4
>> ... etc...
>>
>> However, on this other server, the following happens:
>>
>> output line #1
>> output line #2
>> output line #3
>> output line #4
>> output line #5
>> -> try all patterns
>>
>> All the output from the command is accumulated immediately, and then
>> matched against the pattern, rather than matching every time a new
>> line is echoed from the command.
>>
>> When I was developing on my original server, I built around the first
>> scenario, and now a lot of my code is breaking because I seriously
>> though thats how Expect worked: add one line to the accumulator each
>> time, and try the patterns. I really don't want to rewrite and retest
>> all the code so that it can work in both scenarios, is there anyway to
>> force the behavior of scenario one? Does anyone have an idea why the
>> behavior is different, is it maybe a system setting that can be
>> changed (Perl 5.8.3 on Solaris 10 for both servers, except the first
>> one is using an ActivePerl distribution).
>>
>> I tried seeing if turning Multi-line off would help remedy the
>> situation, but that breaks a lot of code that makes use of $ and ^ in
>> the patterns. I can provide debug logs or clarify exactly how this is
>> breaking my code if anyone wishes.
>>
>> Any help is appreciated.
>>
>>
>> ------------------------------------------------------------------------------
>> Stay on top of everything new and different, both inside and around Java
>> (TM) technology - register by April 22, and save
>> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
>> 300 plus technical and hands-on sessions. Register today. Use priority
>> code J9JMT32. http://p.sf.net/sfu/p
>> _______________________________________________
>> Expectperl-discuss mailing list
>> Exp...@li...
>> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
>>
>