Re: [Expectperl-discuss] No match, but the pattern is there in debug output

[Ed R. <er...@pa...>]

Austin Schutz writes:
> <snip>
> > input none\r\012!\r\012!\r\012end\r\012
> > \r\012cs3mc-lab-e0a#'
> > match:
> >   pattern #1: -re `^cs3mc-lab-e0a(\\(\S+\))?#'? No.
>                                     ^^    ^
> 	Hmm, this is interesting. Two backslashes in one spot, one
> in the next.

Yes, that is odd.  Here's the code that sets that pattern (line 190):

        $router_prompt= '^' . $routername . '(\(\S+\))?#';

And there are no double backslashes.  There's definitely some
kind of artifact here with the way Perl displays stuff, although
I'm not sure whether this is relevant to the problem.  I think
the user must be running Perl 5.6.1 or thereabouts - I just installed
that on my home box and I see both the "\r\012" in the debug display
(instead of "\r\n" as Perl 5.005 does) and the unbalanced backslashes
(instead of `^routername(\\(\\S+\\))?#' which is how Perl 5.005
displays it).

It's a regexp to match the Cisco router prompt, which is of the form:

   "Router#"  or "Router(config-nacl-ext)#" or "Router(otherjunk)#"

So I want to match "Router(any junk between parens or no parens at all)#".
And it works for me, and since the user says it matches the first three
times when he runs the script, I can't see how anything could be wrong
with it.

> >   However, the big difference between the early commands
> > that matched and the one that failed is that the latter produces hundreds
> > of lines of output, while the successful commands produced either 30-40
> > lines (the "show term") or none at all (the two "set term" commands) except
> > for the router's prompt.
> > 
> 	This could be a problem if your timeout isn't set high enough.
> Occasionally slow devices can take a while to respond, particularly if they
> have large numbers of interfaces attached, e.g. heavily loaded  access router.
> Your 10 second timeout default may not be long enough in some cases, though it
> does seem to have gotten the correct data in this case.

Could there be a race condition in Expect.pm such that if the data
arrives just before or after the timeout, it might end up in the
accumulator (or at least in the debug output of the accumulator)
after the operation timed out?