expectperl-discuss — Discussions about Perl modules Expect.pm, IO::Tty and IO::Stty

[Expectperl-discuss] parse interface output from CLI

[Noah <ad...@en...>]

Hi there,

okay i am trying to figure out how to incorporate Matt's and Ken's 
advice and fit it in with the current way I've been interacting with the tot

here is what I am doing.  I am trying to collect all the output after 
sending the command 'show interfaces $interface' and stop the collection 
whent eh prompt has been reached.

There is no need to check for 'more' or screen scrolling as I've turned 
that option off.

A good portion of the script is shown below.  The output of the command 
is  even further below.



Cheers,

Noah



#--- START SSH LOGIN SEQUENCE ! 
----------------------------------------------#
#

my $command = Expect->spawn("$cmd");
$command->log_stdout(0);
$command->expect($timeout, -re => "Password:") or die("Failed to get 
password prompt");
print $command "$password\r";


my $prompt = "$user\@[^>]+>";

$exp->expect($timeout, [ qr/$prompt/ => sub { $_[0]->send("set cli 
screen-length 0\n"); } ]);
$exp->expect($timeout, [ qr/$prompt/ => sub { $_[0]->send("show 
interfaces $interface\n");  } ]);



$command->expect(1, [ qr/$prompt/ => sub { my $exp = shift; 
exp_continue; } ] );


$exp->expect($timeout, [ qr/$prompt/ => sub { $exp->send("exit\n");  } ]);

exit 0;



----- output from the command  -----


Physical interface: t1-1/1/0, Enabled, Physical link is Down
   Interface index: 141, SNMP ifIndex: 38
   Link-level type: Frame-Relay, MTU: 1504, Clocking: Internal, Speed: 
T1, Loopback: None, FCS: 16, Framing: ESF
   Device flags   : Present Running Down
   Interface flags: Hardware-Down Link-Layer-Down Point-To-Point 
SNMP-Traps Internal: 0x4000
   Link flags     : Keepalives DTE
   ANSI LMI settings: n391dte 6, n392dte 3, n393dte 4, t391dte 10 seconds
   LMI: Input: 0 (never), Output: 4081 (00:00:04 ago)
   DTE statistics:
     Enquiries sent                       : 3409
     Full enquiries sent                  : 672
     Enquiry responses received           : 0
     Full enquiry responses received      : 0
   DCE statistics:
     Enquiries received                   : 0
     Full enquiries received              : 0
     Enquiry responses sent               : 0
     Full enquiry responses sent          : 0
   Common statistics:
     Unknown messages received            : 0
     Asynchronous updates received        : 0
     Out-of-sequence packets received     : 0
     Keepalive responses timedout         : 1
   CoS queues     : 4 supported, 4 maximum usable queues
   Last flapped   : 2007-10-19 20:11:51 UTC (3w5d 05:19 ago)
   Input rate     : 0 bps (0 pps)
   Output rate    : 0 bps (0 pps)
   DS1   alarms   : LOF, LOS
   DS1   defects  : LOF, LOS

   Logical interface t1-1/1/0.1 (Index 72) (SNMP ifIndex 5946)
     Description: globbers1
     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
     Input packets : 0
     Output packets: 0
     Protocol inet, MTU: 1500
       Flags: None
       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
         Destination: 10.10.10/24, Local: 10.10.10.1, Broadcast: 
10.10.10.255
       Addresses, Flags: Dest-route-down Is-Preferred
         Destination: 192.168.1.0/30, Local: 192.168.1.1, Broadcast: 
192.168.1.3
     DLCI 1
       Flags: Down, DCE-Unconfigured
       Total down time: 11:14:59 sec, Last down: 11:14:59 ago
         Input packets : 0
         Output packets: 0

   Logical interface t1-1/1/0.2 (Index 73) (SNMP ifIndex 5947)
     Description: globbers2
     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
     Input packets : 0
     Output packets: 0
     Protocol inet, MTU: 1500
       Flags: None
       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
         Destination: 192.168.1.4/30, Local: 192.168.1.5, Broadcast: 
192.168.1.7
     DLCI 2
       Flags: Active
       Total down time: 0 sec, Last down: Never
         Input packets : 0
         Output packets: 0

   Logical interface t1-1/1/0.3 (Index 74) (SNMP ifIndex 5948)
     Description: globbers3
     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
     Input packets : 0
     Output packets: 0
     Protocol inet, MTU: 1500
       Flags: None
       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
         Destination: 192.168.1.8/30, Local: 192.168.1.9, Broadcast: 
192.168.1.11
     DLCI 3
       Flags: Active
       Total down time: 0 sec, Last down: Never
         Input packets : 0
         Output packets: 0

   Logical interface t1-1/1/0.4 (Index 75) (SNMP ifIndex 5949)
     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
     Input packets : 0
     Output packets: 0
     Protocol inet, MTU: 1500
       Flags: None
       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
         Destination: 192.168.1.12/30, Local: 192.168.1.13, Broadcast: 
192.168.1.15
     DLCI 4
       Flags: Active
       Total down time: 0 sec, Last down: Never
         Input packets : 0
         Output packets: 0

   Logical interface t1-1/1/0.5 (Index 76) (SNMP ifIndex 5950)
     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
     Input packets : 0
     Output packets: 0
     Protocol inet, MTU: 1500
       Flags: None
       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
         Destination: 192.168.1.16/30, Local: 192.168.1.17, Broadcast: 
192.168.1.19
     DLCI 5
       Flags: Active
       Total down time: 0 sec, Last down: Never
         Input packets : 0
         Output packets: 0

   Logical interface t1-1/1/0.6 (Index 77) (SNMP ifIndex 5951)
     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
     Input packets : 0
     Output packets: 0
     Protocol inet, MTU: 1500
       Flags: None
       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
         Destination: 192.168.1.20/30, Local: 192.168.1.21, Broadcast: 
192.168.1.23
     DLCI 6
       Flags: Active
       Total down time: 0 sec, Last down: Never
         Input packets : 0
         Output packets: 0

   Logical interface t1-1/1/0.7 (Index 78) (SNMP ifIndex 5952)
     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
     Input packets : 0
     Output packets: 0
     Protocol inet, MTU: 1500
       Flags: None
       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
         Destination: 192.168.1.24/30, Local: 192.168.1.25, Broadcast: 
192.168.1.27
     DLCI 7
       Flags: Active
       Total down time: 0 sec, Last down: Never
         Input packets : 0
         Output packets: 0

   Logical interface t1-1/1/0.8 (Index 79) (SNMP ifIndex 5953)
     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
     Input packets : 0
     Output packets: 0
     Protocol inet, MTU: 1500
       Flags: None
       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
         Destination: 192.168.1.28/30, Local: 192.168.1.29, Broadcast: 
192.168.1.31
     DLCI 8
       Flags: Active
       Total down time: 0 sec, Last down: Never
         Input packets : 0
         Output packets: 0

   Logical interface t1-1/1/0.9 (Index 80) (SNMP ifIndex 5954)
     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
     Input packets : 0
     Output packets: 0
     Protocol inet, MTU: 1500
       Flags: None
       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
         Destination: 192.168.1.32/30, Local: 192.168.1.33, Broadcast: 
192.168.1.35
     DLCI 9
       Flags: Active
       Total down time: 0 sec, Last down: Never
         Input packets : 0
         Output packets: 0
   DLCI statistics:
     Active DLCI  :8  Inactive DLCI  :1

Re: [Expectperl-discuss] trying to capture multiple matches across many lines

[Noah <ad...@en...>]

Matt,

I am not doing something correct here.

I run my script and get the following:
"Can't call method "put" on an undefined value at ./maintenance.check.pl 
line 96."

Cheers,

Noah


Matt Zagrabelny wrote:
> On Wed, 2007-11-14 at 15:39 -0600, Noah wrote:
> 
> [...]
> 
>> is there a way to capture the output with perl-expect into an array?
> 
> Here are some snippets of what I have done in the past, though I do
> things a little differently now, you will get the idea... hopefully. ;)
> 
> Subroutine to send a command to Cisco devices and capture the output in
> the scalar reference $receive_buffer.
> 
> sub send_and_receive {
>   my $configs = shift;
>   my $send_string = shift;
>   my $receive_buffer = shift;
>   my $command = shift;
>   my $wait_for_found = (@_) ? shift : undef;
>   my $more_output = (@_) ? shift : '--More--';
>   my $continue_command = (@_) ? shift : " "; 
>   my $wait_for = (@_) ? shift : '>$';
>   
>   # send whatever it is we are to send
>   $command->put($send_string);
> 
>   # now wait for the "wait_for" meanwhile saving
>   # all the output into receive_buffer
>   my $done = undef;
>   until ($done) {
>     my ($prematch, $match) = (undef, undef);
>     ($prematch, $match) =
>       $command->waitfor(Match => '/'.$more_output.'/i',
>                         Match => '/'.$wait_for.'/i',
>                         Match => '/\\[X\\] Exit.*:/ism',
>                         Timeout => $configs->{management_timeout});
> 
>     if ($receive_buffer ne undef) {
>       $$receive_buffer .= $prematch.$match;
>     }    
> 
>     if ($match =~ /$more_output/i) {
>       $command->put($continue_command);
>     } elsif ($match =~ /$wait_for/) {
>       $$wait_for_found = 1 if ($wait_for_found);
>       $done = 1; 
>     } elsif ($match =~ /\[X\] Exit.*:/ism) {
>       $$wait_for_found = 1 if ($wait_for_found);
>       $done = 1; 
>     }    
>   }
> }
> 
> $text_io = '';
> &send_and_receive($configs,
>                   "show interface status\n",
>                   \$text_io,
>                   $connection,
>                   \$found_prompt);
> 
> my @lines = split /\n/, $text_io;
> for (@lines) {
>   $_ = &trim($_);
> }
> 
> sub trim {
>   my $s = shift;
>   $s =~ s/^\s*//;
>   $s =~ s/\s*$//;
>   return $s;
> }  
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss

Re: [Expectperl-discuss] trying to capture multiple matches across many lines

[Noah <ad...@en...>]

thanks Matt.

this is exactly what I am looking fer.

cheers,

Noah


Matt Zagrabelny wrote:
> On Wed, 2007-11-14 at 15:39 -0600, Noah wrote:
> 
> [...]
> 
>> is there a way to capture the output with perl-expect into an array?
> 
> Here are some snippets of what I have done in the past, though I do
> things a little differently now, you will get the idea... hopefully. ;)
> 
> Subroutine to send a command to Cisco devices and capture the output in
> the scalar reference $receive_buffer.
> 
> sub send_and_receive {
>   my $configs = shift;
>   my $send_string = shift;
>   my $receive_buffer = shift;
>   my $command = shift;
>   my $wait_for_found = (@_) ? shift : undef;
>   my $more_output = (@_) ? shift : '--More--';
>   my $continue_command = (@_) ? shift : " "; 
>   my $wait_for = (@_) ? shift : '>$';
>   
>   # send whatever it is we are to send
>   $command->put($send_string);
> 
>   # now wait for the "wait_for" meanwhile saving
>   # all the output into receive_buffer
>   my $done = undef;
>   until ($done) {
>     my ($prematch, $match) = (undef, undef);
>     ($prematch, $match) =
>       $command->waitfor(Match => '/'.$more_output.'/i',
>                         Match => '/'.$wait_for.'/i',
>                         Match => '/\\[X\\] Exit.*:/ism',
>                         Timeout => $configs->{management_timeout});
> 
>     if ($receive_buffer ne undef) {
>       $$receive_buffer .= $prematch.$match;
>     }    
> 
>     if ($match =~ /$more_output/i) {
>       $command->put($continue_command);
>     } elsif ($match =~ /$wait_for/) {
>       $$wait_for_found = 1 if ($wait_for_found);
>       $done = 1; 
>     } elsif ($match =~ /\[X\] Exit.*:/ism) {
>       $$wait_for_found = 1 if ($wait_for_found);
>       $done = 1; 
>     }    
>   }
> }
> 
> $text_io = '';
> &send_and_receive($configs,
>                   "show interface status\n",
>                   \$text_io,
>                   $connection,
>                   \$found_prompt);
> 
> my @lines = split /\n/, $text_io;
> for (@lines) {
>   $_ = &trim($_);
> }
> 
> sub trim {
>   my $s = shift;
>   $s =~ s/^\s*//;
>   $s =~ s/\s*$//;
>   return $s;
> }  
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss

Re: [Expectperl-discuss] trying to capture multiple matches across many lines

[Matt Z. <mzagrabe@d.umn.edu>]

On Wed, 2007-11-14 at 15:39 -0600, Noah wrote:

[...]

> is there a way to capture the output with perl-expect into an array?

Here are some snippets of what I have done in the past, though I do
things a little differently now, you will get the idea... hopefully. ;)

Subroutine to send a command to Cisco devices and capture the output in
the scalar reference $receive_buffer.

sub send_and_receive {
  my $configs =3D shift;
  my $send_string =3D shift;
  my $receive_buffer =3D shift;
  my $command =3D shift;
  my $wait_for_found =3D (@_) ? shift : undef;
  my $more_output =3D (@_) ? shift : '--More--';
  my $continue_command =3D (@_) ? shift : " ";=20
  my $wait_for =3D (@_) ? shift : '>$';
 =20
  # send whatever it is we are to send
  $command->put($send_string);

  # now wait for the "wait_for" meanwhile saving
  # all the output into receive_buffer
  my $done =3D undef;
  until ($done) {
    my ($prematch, $match) =3D (undef, undef);
    ($prematch, $match) =3D
      $command->waitfor(Match =3D> '/'.$more_output.'/i',
                        Match =3D> '/'.$wait_for.'/i',
                        Match =3D> '/\\[X\\] Exit.*:/ism',
                        Timeout =3D> $configs->{management_timeout});

    if ($receive_buffer ne undef) {
      $$receive_buffer .=3D $prematch.$match;
    }   =20

    if ($match =3D~ /$more_output/i) {
      $command->put($continue_command);
    } elsif ($match =3D~ /$wait_for/) {
      $$wait_for_found =3D 1 if ($wait_for_found);
      $done =3D 1;=20
    } elsif ($match =3D~ /\[X\] Exit.*:/ism) {
      $$wait_for_found =3D 1 if ($wait_for_found);
      $done =3D 1;=20
    }   =20
  }
}

$text_io =3D '';
&send_and_receive($configs,
                  "show interface status\n",
                  \$text_io,
                  $connection,
                  \$found_prompt);

my @lines =3D split /\n/, $text_io;
for (@lines) {
  $_ =3D &trim($_);
}

sub trim {
  my $s =3D shift;
  $s =3D~ s/^\s*//;
  $s =3D~ s/\s*$//;
  return $s;
} =20

--=20
Matt Zagrabelny - mzagrabe@d.umn.edu - (218) 726 8844
University of Minnesota Duluth
Information Technology Systems & Services
PGP key 1024D/84E22DA2 2005-11-07
Fingerprint: 78F9 18B3 EF58 56F5 FC85  C5CA 53E7 887F 84E2 2DA2

He is not a fool who gives up what he cannot keep to gain what he cannot
lose.
-Jim Elliot

Re: [Expectperl-discuss] trying to capture multiple matches across many lines

[Ken I. <fn...@ua...>]

On Wed, Nov 14, 2007 at 03:39:45PM -0600, Noah wrote:
>
> Bradford Ritchie wrote:
>> On Nov 14, 2007 3:46 PM, Noah <ad...@en... 
>> <mailto:ad...@en...>> wrote:
>>      >
>>      > I'm assuming the output is coming from a remote connection to something,
>>      > not a command run at the shell...  I'm pretty sure expect can do that,
>>      > but I would need more details.  Can you give some sample output and an
>>      > example of what you consider a "match" that you want to save?  You'll
>>      > probably end up calling expect over and over again to get each match, so
>>      > that means you may also need to look for something that tells you when
>>      > to stop looking.
>>      >
>>     Hi,
>>     okay I am attempting to grab the interface and Unit number like
>>     t1-1/1/0.0 for each logical interface to t1-1/1/0.9, the Input rate,
>>     Output rate, and the remote IP address out of the following output:
>>     sample output - yup the results from a JUNOS CLI command.
>> *Sounds like you really only need expect to do the remote connection/login 
>> part.  If it were me, I would do the minimum with expect to just send the 
>> command and capture all of the output to an array (ie. one call to expect, 
>> using the prompt as the "match" string), and then parse the output the way 
>> you would normally parse an input stream, like with a foreach loop or 
>> something.
>
> is there a way to capture the output with perl-expect into an array?

One way would be to receive a string and split it aftwards, e.g.,

    $foo->expect($timeout, 'regex', $some_terminating_pattern);
    my @results = split /\n/, $foo->match();
    ...

Ken

-- 
Ken Irving, fn...@ua...

Re: [Expectperl-discuss] trying to capture multiple matches across many lines

[Noah <ad...@en...>]

Bradford Ritchie wrote:
> 
> 
> On Nov 14, 2007 3:46 PM, Noah <ad...@en... 
> <mailto:ad...@en...>> wrote:
> 
> 
>      >
>      > I'm assuming the output is coming from a remote connection to
>     something,
>      > not a command run at the shell...  I'm pretty sure expect can do
>     that,
>      > but I would need more details.  Can you give some sample output
>     and an
>      > example of what you consider a "match" that you want to save?  You'll
>      > probably end up calling expect over and over again to get each
>     match, so
>      > that means you may also need to look for something that tells you
>     when
>      > to stop looking.
>      >
> 
> 
>     Hi,
> 
>     okay I am attempting to grab the interface and Unit number like
>     t1-1/1/0.0 for each logical interface to t1-1/1/0.9, the Input rate,
>     Output rate, and the remote IP address out of the following output:
> 
> 
> 
>     sample output - yup the results from a JUNOS CLI command.
> 
> 
> *Sounds like you really only need expect to do the remote 
> connection/login part.  If it were me, I would do the minimum with 
> expect to just send the command and capture all of the output to an 
> array (ie. one call to expect, using the prompt as the "match" string), 
> and then parse the output the way you would normally parse an input 
> stream, like with a foreach loop or something.
> 




is there a way to capture the output with perl-expect into an array?

Cheers,
noah

Re: [Expectperl-discuss] trying to capture multiple matches across many lines

[Bradford R. <bt...@po...>]

On Nov 14, 2007 3:46 PM, Noah <ad...@en...> wrote:

>
> >
> > I'm assuming the output is coming from a remote connection to something,
> > not a command run at the shell...  I'm pretty sure expect can do that,
> > but I would need more details.  Can you give some sample output and an
> > example of what you consider a "match" that you want to save?  You'll
> > probably end up calling expect over and over again to get each match, so
> > that means you may also need to look for something that tells you when
> > to stop looking.
> >
>
>
> Hi,
>
> okay I am attempting to grab the interface and Unit number like
> t1-1/1/0.0 for each logical interface to t1-1/1/0.9, the Input rate,
> Output rate, and the remote IP address out of the following output:
>
>
>
> sample output - yup the results from a JUNOS CLI command.


*Sounds like you really only need expect to do the remote connection/login
part.  If it were me, I would do the minimum with expect to just send the
command and capture all of the output to an array (ie. one call to expect,
using the prompt as the "match" string), and then parse the output the way
you would normally parse an input stream, like with a foreach loop or
something.

*

>
>
> Physical interface: t1-1/1/0, Enabled, Physical link is Down
>   Interface index: 141, SNMP ifIndex: 38
>   Link-level type: Frame-Relay, MTU: 1504, Clocking: Internal, Speed: T1,
>   Loopback: None, FCS: 16, Framing: ESF
>   Device flags   : Present Running Down
>   Interface flags: Hardware-Down Link-Layer-Down Point-To-Point
> SNMP-Traps Internal: 0x4000
>   Link flags     : Keepalives DTE
>   ANSI LMI settings: n391dte 6, n392dte 3, n393dte 4, t391dte 10 seconds
>   LMI: Input: 0 (never), Output: 2310 (00:00:08 ago)
>   DTE statistics:
>     Enquiries sent                       : 1930
>     Full enquiries sent                  : 380
>     Enquiry responses received           : 0
>     Full enquiry responses received      : 0
>   DCE statistics:
>     Enquiries received                   : 0
>     Full enquiries received              : 0
>     Enquiry responses sent               : 0
>     Full enquiry responses sent          : 0
>   Common statistics:
>     Unknown messages received            : 0
>     Asynchronous updates received        : 0
>     Out-of-sequence packets received     : 0
>     Keepalive responses timedout         : 1
>   CoS queues     : 4 supported, 4 maximum usable queues
>   Last flapped   : 2007-10-19 20:11:51 UTC (3w5d 00:27 ago)
>   Input rate     : 0 bps (0 pps)
>   Output rate    : 0 bps (0 pps)
>   DS1   alarms   : LOF, LOS
>   DS1   defects  : LOF, LOS
>
>   Logical interface t1-1/1/0.1 (Index 72) (SNMP ifIndex 5946)
>     Description: globbers1
>     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
>     Input packets : 0
>     Output packets: 0
>     Protocol inet, MTU: 1500
>       Flags: None
>       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
>         Destination: 10.10.10/24, Local: 10.10.10.1, Broadcast:
> 10.10.10.255
>       Addresses, Flags: Dest-route-down Is-Preferred
>         Destination: 192.168.1.0/30, Local: 192.168.1.1, Broadcast:
> 192.168.1.3
>     DLCI 1
>       Flags: Down, DCE-Unconfigured
>       Total down time: 06:22:08 sec, Last down: 06:22:08 ago
>         Input packets : 0
>         Output packets: 0
>
>   Logical interface t1-1/1/0.2 (Index 73) (SNMP ifIndex 5947)
>     Description: globbers2
>     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
>     Input packets : 0
>     Output packets: 0
>     Protocol inet, MTU: 1500
>       Flags: None
>       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
>         Destination: 192.168.1.4/30, Local: 192.168.1.5, Broadcast:
> 192.168.1.7
>     DLCI 2
>       Flags: Active
>       Total down time: 0 sec, Last down: Never
>         Input packets : 0
>         Output packets: 0
>
>   Logical interface t1-1/1/0.3 (Index 74) (SNMP ifIndex 5948)
>     Description: globbers3
>     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
>     Input packets : 0
>     Output packets: 0
>     Protocol inet, MTU: 1500
>       Flags: None
>       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
>         Destination: 192.168.1.8/30, Local: 192.168.1.9, Broadcast:
> 192.168.1.11
>     DLCI 3
>       Flags: Active
>       Total down time: 0 sec, Last down: Never
>         Input packets : 0
>         Output packets: 0
>
>   Logical interface t1-1/1/0.4 (Index 75) (SNMP ifIndex 5949)
>     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
>     Input packets : 0
>     Output packets: 0
>     Protocol inet, MTU: 1500
>       Flags: None
>       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
>         Destination: 192.168.1.12/30, Local: 192.168.1.13, Broadcast:
> 192.168.1.15
>     DLCI 4
>       Flags: Active
>       Total down time: 0 sec, Last down: Never
>         Input packets : 0
>         Output packets: 0
>
>   Logical interface t1-1/1/0.5 (Index 76) (SNMP ifIndex 5950)
>     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
>     Input packets : 0
>     Output packets: 0
>     Protocol inet, MTU: 1500
>       Flags: None
>       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
>         Destination: 192.168.1.16/30, Local: 192.168.1.17, Broadcast:
> 192.168.1.19
>     DLCI 5
>       Flags: Active
>       Total down time: 0 sec, Last down: Never
>         Input packets : 0
>         Output packets: 0
>
>   Logical interface t1-1/1/0.6 (Index 77) (SNMP ifIndex 5951)
>     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
>     Input packets : 0
>     Output packets: 0
>     Protocol inet, MTU: 1500
>       Flags: None
>       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
>         Destination: 192.168.1.20/30, Local: 192.168.1.21, Broadcast:
> 192.168.1.23
>     DLCI 6
>       Flags: Active
>       Total down time: 0 sec, Last down: Never
>         Input packets : 0
>         Output packets: 0
>
>   Logical interface t1-1/1/0.7 (Index 78) (SNMP ifIndex 5952)
>     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
>     Input packets : 0
>     Output packets: 0
>     Protocol inet, MTU: 1500
>       Flags: None
>       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
>         Destination: 192.168.1.24/30, Local: 192.168.1.25, Broadcast:
> 192.168.1.27
>     DLCI 7
>       Flags: Active
>       Total down time: 0 sec, Last down: Never
>         Input packets : 0
>         Output packets: 0
>
>   Logical interface t1-1/1/0.8 (Index 79) (SNMP ifIndex 5953)
>     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
>     Input packets : 0
>     Output packets: 0
>     Protocol inet, MTU: 1500
>       Flags: None
>       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
>         Destination: 192.168.1.28/30, Local: 192.168.1.29, Broadcast:
> 192.168.1.31
>     DLCI 8
>       Flags: Active
>       Total down time: 0 sec, Last down: Never
>         Input packets : 0
>         Output packets: 0
>
>   Logical interface t1-1/1/0.9 (Index 80) (SNMP ifIndex 5954)
>     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
>     Input packets : 0
>     Output packets: 0
>     Protocol inet, MTU: 1500
>       Flags: None
>       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
>         Destination: 192.168.1.32/30, Local: 192.168.1.33, Broadcast:
> 192.168.1.35
>     DLCI 9
>       Flags: Active
>       Total down time: 0 sec, Last down: Never
>         Input packets : 0
>         Output packets: 0
>   DLCI statistics:
>     Active DLCI  :8  Inactive DLCI  :1
>
>
>
>

Re: [Expectperl-discuss] trying to capture multiple matches across many lines

[Noah <ad...@en...>]

> 
> I'm assuming the output is coming from a remote connection to something, 
> not a command run at the shell...  I'm pretty sure expect can do that, 
> but I would need more details.  Can you give some sample output and an 
> example of what you consider a "match" that you want to save?  You'll 
> probably end up calling expect over and over again to get each match, so 
> that means you may also need to look for something that tells you when 
> to stop looking.
> 


Hi,

okay I am attempting to grab the interface and Unit number like 
t1-1/1/0.0 for each logical interface to t1-1/1/0.9, the Input rate, 
Output rate, and the remote IP address out of the following output:



sample output - yup the results from a JUNOS CLI command.

Physical interface: t1-1/1/0, Enabled, Physical link is Down
   Interface index: 141, SNMP ifIndex: 38
   Link-level type: Frame-Relay, MTU: 1504, Clocking: Internal, Speed: T1,
   Loopback: None, FCS: 16, Framing: ESF
   Device flags   : Present Running Down
   Interface flags: Hardware-Down Link-Layer-Down Point-To-Point 
SNMP-Traps Internal: 0x4000
   Link flags     : Keepalives DTE
   ANSI LMI settings: n391dte 6, n392dte 3, n393dte 4, t391dte 10 seconds
   LMI: Input: 0 (never), Output: 2310 (00:00:08 ago)
   DTE statistics:
     Enquiries sent                       : 1930
     Full enquiries sent                  : 380
     Enquiry responses received           : 0
     Full enquiry responses received      : 0
   DCE statistics:
     Enquiries received                   : 0
     Full enquiries received              : 0
     Enquiry responses sent               : 0
     Full enquiry responses sent          : 0
   Common statistics:
     Unknown messages received            : 0
     Asynchronous updates received        : 0
     Out-of-sequence packets received     : 0
     Keepalive responses timedout         : 1
   CoS queues     : 4 supported, 4 maximum usable queues
   Last flapped   : 2007-10-19 20:11:51 UTC (3w5d 00:27 ago)
   Input rate     : 0 bps (0 pps)
   Output rate    : 0 bps (0 pps)
   DS1   alarms   : LOF, LOS
   DS1   defects  : LOF, LOS

   Logical interface t1-1/1/0.1 (Index 72) (SNMP ifIndex 5946)
     Description: globbers1
     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
     Input packets : 0
     Output packets: 0
     Protocol inet, MTU: 1500
       Flags: None
       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
         Destination: 10.10.10/24, Local: 10.10.10.1, Broadcast: 
10.10.10.255
       Addresses, Flags: Dest-route-down Is-Preferred
         Destination: 192.168.1.0/30, Local: 192.168.1.1, Broadcast: 
192.168.1.3
     DLCI 1
       Flags: Down, DCE-Unconfigured
       Total down time: 06:22:08 sec, Last down: 06:22:08 ago
         Input packets : 0
         Output packets: 0

   Logical interface t1-1/1/0.2 (Index 73) (SNMP ifIndex 5947)
     Description: globbers2
     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
     Input packets : 0
     Output packets: 0
     Protocol inet, MTU: 1500
       Flags: None
       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
         Destination: 192.168.1.4/30, Local: 192.168.1.5, Broadcast: 
192.168.1.7
     DLCI 2
       Flags: Active
       Total down time: 0 sec, Last down: Never
         Input packets : 0
         Output packets: 0

   Logical interface t1-1/1/0.3 (Index 74) (SNMP ifIndex 5948)
     Description: globbers3
     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
     Input packets : 0
     Output packets: 0
     Protocol inet, MTU: 1500
       Flags: None
       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
         Destination: 192.168.1.8/30, Local: 192.168.1.9, Broadcast: 
192.168.1.11
     DLCI 3
       Flags: Active
       Total down time: 0 sec, Last down: Never
         Input packets : 0
         Output packets: 0

   Logical interface t1-1/1/0.4 (Index 75) (SNMP ifIndex 5949)
     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
     Input packets : 0
     Output packets: 0
     Protocol inet, MTU: 1500
       Flags: None
       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
         Destination: 192.168.1.12/30, Local: 192.168.1.13, Broadcast: 
192.168.1.15
     DLCI 4
       Flags: Active
       Total down time: 0 sec, Last down: Never
         Input packets : 0
         Output packets: 0

   Logical interface t1-1/1/0.5 (Index 76) (SNMP ifIndex 5950)
     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
     Input packets : 0
     Output packets: 0
     Protocol inet, MTU: 1500
       Flags: None
       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
         Destination: 192.168.1.16/30, Local: 192.168.1.17, Broadcast: 
192.168.1.19
     DLCI 5
       Flags: Active
       Total down time: 0 sec, Last down: Never
         Input packets : 0
         Output packets: 0

   Logical interface t1-1/1/0.6 (Index 77) (SNMP ifIndex 5951)
     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
     Input packets : 0
     Output packets: 0
     Protocol inet, MTU: 1500
       Flags: None
       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
         Destination: 192.168.1.20/30, Local: 192.168.1.21, Broadcast: 
192.168.1.23
     DLCI 6
       Flags: Active
       Total down time: 0 sec, Last down: Never
         Input packets : 0
         Output packets: 0

   Logical interface t1-1/1/0.7 (Index 78) (SNMP ifIndex 5952)
     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
     Input packets : 0
     Output packets: 0
     Protocol inet, MTU: 1500
       Flags: None
       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
         Destination: 192.168.1.24/30, Local: 192.168.1.25, Broadcast: 
192.168.1.27
     DLCI 7
       Flags: Active
       Total down time: 0 sec, Last down: Never
         Input packets : 0
         Output packets: 0

   Logical interface t1-1/1/0.8 (Index 79) (SNMP ifIndex 5953)
     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
     Input packets : 0
     Output packets: 0
     Protocol inet, MTU: 1500
       Flags: None
       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
         Destination: 192.168.1.28/30, Local: 192.168.1.29, Broadcast: 
192.168.1.31
     DLCI 8
       Flags: Active
       Total down time: 0 sec, Last down: Never
         Input packets : 0
         Output packets: 0

   Logical interface t1-1/1/0.9 (Index 80) (SNMP ifIndex 5954)
     Flags: Device-Down Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
     Input packets : 0
     Output packets: 0
     Protocol inet, MTU: 1500
       Flags: None
       Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
         Destination: 192.168.1.32/30, Local: 192.168.1.33, Broadcast: 
192.168.1.35
     DLCI 9
       Flags: Active
       Total down time: 0 sec, Last down: Never
         Input packets : 0
         Output packets: 0
   DLCI statistics:
     Active DLCI  :8  Inactive DLCI  :1

Re: [Expectperl-discuss] trying to capture multiple matches across many lines

[Noah <ad...@en...>]

Ken Irving wrote:
> On Wed, Nov 14, 2007 at 02:01:28PM -0600, Noah wrote:
>> Hi there,
>>
>> I have multi-line output that I am hoping to capture repetitive output 
>> and hoping to dump the collected matches to a data file.
>>
>> Is there an example of how to use perl expect module to do this?
> 
>>From this description there's no need for expect; just pipe or otherwise
> save the output into a file.



no its an interactive with a CLI expect is required.  plus I am not 
capturing all the output only matched regexp.




cheers,

Noah

Re: [Expectperl-discuss] trying to capture multiple matches across many lines

[Bradford R. <bt...@po...>]

On Nov 14, 2007 3:14 PM, Ken Irving <fn...@ua...> wrote:

> On Wed, Nov 14, 2007 at 02:01:28PM -0600, Noah wrote:
> > Hi there,
> >
> > I have multi-line output that I am hoping to capture repetitive output
> > and hoping to dump the collected matches to a data file.
> >
> > Is there an example of how to use perl expect module to do this?
>
> From this description there's no need for expect; just pipe or otherwise
> save the output into a file.

I'm assuming the output is coming from a remote connection to something, not
a command run at the shell...  I'm pretty sure expect can do that, but I
would need more details.  Can you give some sample output and an example of
what you consider a "match" that you want to save?  You'll probably end up
calling expect over and over again to get each match, so that means you may
also need to look for something that tells you when to stop looking.


>
> > Let me know if I need more details to make things make more sense.
>
> I don't know; it sounds simple enough as it is.  ;-)
>
> Expect is useful if you need to send commands to a process to get it
> to send anything, more particularly if there's a need for automated
> interaction with the process.
>
> >
> > Cheers,
> >
> > Noah
>
> Good luck!
>
> Ken
> --
> Ken Irving, fn...@ua...
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
>

Re: [Expectperl-discuss] trying to capture multiple matches across many lines

[Ken I. <fn...@ua...>]

On Wed, Nov 14, 2007 at 02:01:28PM -0600, Noah wrote:
> Hi there,
> 
> I have multi-line output that I am hoping to capture repetitive output 
> and hoping to dump the collected matches to a data file.
> 
> Is there an example of how to use perl expect module to do this?

>From this description there's no need for expect; just pipe or otherwise
save the output into a file.

> Let me know if I need more details to make things make more sense.

I don't know; it sounds simple enough as it is.  ;-)

Expect is useful if you need to send commands to a process to get it
to send anything, more particularly if there's a need for automated
interaction with the process.

> 
> Cheers,
> 
> Noah

Good luck!

Ken
-- 
Ken Irving, fn...@ua...

[Expectperl-discuss] trying to capture multiple matches across many lines

[Noah <ad...@en...>]

Hi there,

I have multi-line output that I am hoping to capture repetitive output 
and hoping to dump the collected matches to a data file.

Is there an example of how to use perl expect module to do this?

Let me know if I need more details to make things make more sense.

Cheers,

Noah

Re: [Expectperl-discuss] IO:tty errors

[Ken I. <fn...@ua...>]

On Wed, Nov 07, 2007 at 04:29:52PM -0500, sp...@nc... wrote:
> Hey all,
> 
> I've inherited some code that i need to fix up. There is a shell script
> that calls a perl program. The shell script is suid to a non-root user. In
> the perl script they did a set real id to effective id. With this setup
> all works, but it's a gapping security hole. the perl script uses expect
> to spawn a telnet session, and you can ctrl-] out of the telnet and
> ! to get a shell script as the suid user. I took out the set real id =
> to effective id and everything seems to work ok, but i get the following
> errors on spawing the telnet:
> 
> IO::Tty::open_slave(nonfatal): open(/dev/pts/2): Permission denied at /tools/perl/lib/IO/Pty.pm line 24.
> pty_allocate(nonfatal): open(/dev/ptmx): Permission denied at /tools/perl/lib/IO/Pty.pm line 24.
> IO::Tty::pty_allocate(nonfatal): grantpt(): Permission denied at /tools/perl/lib/IO/Pty.pm line 24.
> IO::Tty::pty_allocate(nonfatal): unlockpt(): Inappropriate ioctl for device at /tools/perl/lib/IO/Pty.pm line 24.
> 
> It makes sense to me, seems to be non-fatal, but my users will freak
> at seeing this output. Is there a quick and easy way to turn off these
> error messages?
> 
> Thanks
> -S

  $ perldoc -q warnings
  Found in /usr/share/perl/5.8/pod/perlfaq7.pod
       How do I temporarily block warnings?

       If you are running Perl 5.6.0 or better, the "use warnings" pragma allows fine
       control of what warning are produced.  See perllexwarn for more details.

           {
               no warnings;          # temporarily turn off warnings
               $a = $b + $c;         # I know these might be undef
           }

       If you have an older version of Perl, the $^W variable (documented in perlvar)
       controls runtime warnings for a block:

           {
               local $^W = 0;        # temporarily turn off warnings
               $a = $b + $c;         # I know these might be undef
           }

       Note that like all the punctuation variables, you cannot currently use my() on
       $^W, only local().

-- 
Ken Irving, fn...@ua...

[Expectperl-discuss] IO:tty errors

[<sp...@nc...>]

Hey all,

I've inherited some code that i need to fix up. There is a shell script that calls a perl program. The shell script is suid to a non-root user. In the perl script they did a set real id to effective id. With this setup all works, but it's a gapping security hole. the perl script uses expect to spawn a telnet session, and you can ctrl-] out of the telnet and ! to get a shell script as the suid user. I took out the set real id = to effective id and everything seems to work ok, but i get the following errors on spawing the telnet:

IO::Tty::open_slave(nonfatal): open(/dev/pts/2): Permission denied at /tools/perl/lib/IO/Pty.pm line 24.
pty_allocate(nonfatal): open(/dev/ptmx): Permission denied at /tools/perl/lib/IO/Pty.pm line 24.
IO::Tty::pty_allocate(nonfatal): grantpt(): Permission denied at /tools/perl/lib/IO/Pty.pm line 24.
IO::Tty::pty_allocate(nonfatal): unlockpt(): Inappropriate ioctl for device at /tools/perl/lib/IO/Pty.pm line 24.

It makes sense to me, seems to be non-fatal, but my users will freak at seeing this output. Is there a quick and easy way to turn off these error messages?

Thanks
-S

Re: [Expectperl-discuss] Having problems with prompt

[Ian M. <iw...@do...>]

>
>
>Hi guys,
>
>I am new to perl and expect.  I started putting a script together that
>telnets into desired devices one at a time and runs specified commands. 
>Problem I have is, that the prompt on this hosts does not follow a certain
>norm.  Some prompts are in caps, some are in lower caps.  Normally, prompts
>are device names, but in some case our device names exceeds the number of
>characters allowed in the hostname, so it cuts of the exceeded letters.  So
>having the following doesn't really work at times:
>
>$telnet->expect($timeout, "$HostName");
>
>Is there anyway, I can do this.  That once I spawn the telnet session and
>log in.  The prompt that it gets, it stores it into a variable and than I
>can leverage that variable throughout my script wherever it expects a
>prompt.
>
>Also, these devices are all cisco devices.  Is there a recommended timeout
>values? I have $telnet->exp_internal(1) in my script.  So In middle of the
>output after a command is run, I see several /r's.  Thanks in advance for
>your help.
>
>Amit.
>-- 
>View this message in context: http://www.nabble.com/Having-problems-with-prompt-tf4737304.html#a13547267
>Sent from the Perl - Expectperl-Discuss mailing list archive at Nabble.com.
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems?  Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >> http://get.splunk.com/
>_______________________________________________
>Expectperl-discuss mailing list
>Exp...@li...
>https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
>

I have found when  using expect with a   linux shell that various characters but mostly carriage return
are inserted in output lines. I realised that the shell was wrapping long lines and was in  edit mode,
where some input characters cause extra output as part of the line editing.

Perhaps if you could tell your telnet and  cisco shell to use as long a line as possible  and use
what my telnet manual calls old telnet line by line, where only complete lines are to the the remote host
then no extra characters are returned.

    Ian W Moor                  Department of Computing,
iw...@do...           Imperial College.
                                    180 Queensgate
                                     London SW7 2AZ UK.
 
 

Re: [Expectperl-discuss] Having problems with prompt

[Bradford R. <bt...@po...>]

I spent a long time (longer than I should have) trying to come up with the
perfect solution for this, but it's a tough one because there are lots of
unexpected situations that can get in the way and leave your script hanging
becuase it either missed something that didn't fit your regexp or
misinterpreted some extra output as a prompt.

In general, I found the easiest and most reliable solution was to try to
have your script autodetect the prompt under the assumption that it would be
the last line of text after you enter your password.  If you can manage to
autodetect it reliably, then you can use in subsequent expect() calls rather
than a regular expression.

You just have to make sure your script waits long enough after sending the
password before it tries to detect the prompt... sometimes there's a hiccup
during login and the prompt takes a half-second or so to be sent, and if
there's any preceeding output such as a motd/banner the script might grab
that instead.

It's a good thing that these are all cisco devices, so the output should be
more consistent and predictable than on unix boxes.

Good luck.
-- Brad


On 11/2/07, amit1017 <gos...@ho...> wrote:
>
>
> Hi guys,
>
> I am new to perl and expect.  I started putting a script together that
> telnets into desired devices one at a time and runs specified commands.
> Problem I have is, that the prompt on this hosts does not follow a certain
> norm.  Some prompts are in caps, some are in lower caps.  Normally,
> prompts
> are device names, but in some case our device names exceeds the number of
> characters allowed in the hostname, so it cuts of the exceeded
> letters.  So
> having the following doesn't really work at times:
>
> $telnet->expect($timeout, "$HostName");
>
> Is there anyway, I can do this.  That once I spawn the telnet session and
> log in.  The prompt that it gets, it stores it into a variable and than I
> can leverage that variable throughout my script wherever it expects a
> prompt.
>
> Also, these devices are all cisco devices.  Is there a recommended timeout
> values? I have $telnet->exp_internal(1) in my script.  So In middle of the
> output after a command is run, I see several /r's.  Thanks in advance for
> your help.
>
> Amit.
> --
> View this message in context:
> http://www.nabble.com/Having-problems-with-prompt-tf4737304.html#a13547267
> Sent from the Perl - Expectperl-Discuss mailing list archive at Nabble.com
> .
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
>

Re: [Expectperl-discuss] Having problems with prompt

[Bradford R. <bri...@po...>]

I spent a long time (longer than I should have) trying to come up with the
perfect solution for this, but it's a tough one because there are lots of
unexpected situations that can get in the way and leave your script hanging
becuase it either missed something that didn't fit your regexp or
misinterpreted some extra output as a prompt.

In general, I found the easiest and most reliable solution was to try to
have your script autodetect the prompt under the assumption that it would be
the last line of text after you enter your password.  If you can manage to
autodetect it reliably, then you can use in subsequent expect() calls rather
than a regular expression.

You just have to make sure your script waits long enough after sending the
password before it tries to detect the prompt... sometimes there's a hiccup
during login and the prompt takes a half-second or so to be sent, and if
there's any preceeding output such as a motd/banner the script might grab
that instead.

It's a good thing that these are all cisco devices, so the output should be
more consistent and predictable than on unix boxes.

Good luck.
-- Brad

On 11/2/07, amit1017 <gos...@ho...> wrote:
>
>
> Hi guys,
>
> I am new to perl and expect.  I started putting a script together that
> telnets into desired devices one at a time and runs specified commands.
> Problem I have is, that the prompt on this hosts does not follow a certain
> norm.  Some prompts are in caps, some are in lower caps.  Normally,
> prompts
> are device names, but in some case our device names exceeds the number of
> characters allowed in the hostname, so it cuts of the exceeded
> letters.  So
> having the following doesn't really work at times:
>
> $telnet->expect($timeout, "$HostName");
>
> Is there anyway, I can do this.  That once I spawn the telnet session and
> log in.  The prompt that it gets, it stores it into a variable and than I
> can leverage that variable throughout my script wherever it expects a
> prompt.
>
> Also, these devices are all cisco devices.  Is there a recommended timeout
> values? I have $telnet->exp_internal(1) in my script.  So In middle of the
> output after a command is run, I see several /r's.  Thanks in advance for
> your help.
>
> Amit.
> --
> View this message in context:
> http://www.nabble.com/Having-problems-with-prompt-tf4737304.html#a13547267
> Sent from the Perl - Expectperl-Discuss mailing list archive at Nabble.com
> .
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
>

[Expectperl-discuss] Having problems with prompt

[amit1017 <gos...@ho...>]

Hi guys,

I am new to perl and expect.  I started putting a script together that
telnets into desired devices one at a time and runs specified commands. 
Problem I have is, that the prompt on this hosts does not follow a certain
norm.  Some prompts are in caps, some are in lower caps.  Normally, prompts
are device names, but in some case our device names exceeds the number of
characters allowed in the hostname, so it cuts of the exceeded letters.  So
having the following doesn't really work at times:

$telnet->expect($timeout, "$HostName");

Is there anyway, I can do this.  That once I spawn the telnet session and
log in.  The prompt that it gets, it stores it into a variable and than I
can leverage that variable throughout my script wherever it expects a
prompt.

Also, these devices are all cisco devices.  Is there a recommended timeout
values? I have $telnet->exp_internal(1) in my script.  So In middle of the
output after a command is run, I see several /r's.  Thanks in advance for
your help.

Amit.
-- 
View this message in context: http://www.nabble.com/Having-problems-with-prompt-tf4737304.html#a13547267
Sent from the Perl - Expectperl-Discuss mailing list archive at Nabble.com.

Re: [Expectperl-discuss] Checking accumulator without a second expect

[<li...@jo...>]

Hi all,<br /><br />Sorry this is so long and vague (I'll try to code up a s=
mall example because my little project uses a back-end database and I'd lik=
e to split the Expect piece out - this will take a while). For anyone who's=
 interested have a look at the March 2007 thread to see the solution to my =
original problem.<br /><br />My new code (below) no longer works (I've done=
 a lot of code changes and need to backtrack to see what exactly broke it).=
 In the meantime I'm wondering if there's a better way.<br /><br />Here's w=
hat I'm trying to do...<br /><br />1. Match and capture a prompt at the sta=
rt of a line.<br />&nbsp;&nbsp; This works perfectly (March 2007 code)<br /=
>2. Look up the matched prompt and see if it...<br />&nbsp;&nbsp; (a) needs=
 a response,<br />&nbsp;&nbsp; (b) can be ignored, or,<br />&nbsp;&nbsp; (c=
) needs special handling..<br />&nbsp;&nbsp; Always works.<br />3a. For &qu=
ot;normal&quot; prompt send response + &quot;\r&quot; and exp_continue for =
next prompt.<br />3b. For &quot;ignored&quot; prompt just exp_continue.<br =
/>3c. For a &quot;special&quot; prompt sleep 3 seconds then check if there'=
s any more output, if there is the script shouldn't send a response because=
 the remote system is showing the status of this setting as opposed to aski=
ng for input. It will then present the next prompt (i.e. treat this prompt =
as in case 3b above). But if there's no further output it's a request for i=
nput and so a response must be given (even if just &quot;\r&quot;) as in 3b=
.<br /><br /><br />Case 3c isn't working. When I do it manually I get this.=
..<br /><br />NORMAL_PROMPT_1 (I send response + &quot;\r&quot;)<br />NORMA=
L_PROMPT_2 (I send response + &quot;\r&quot;)<br />SPECIAL_PROMPT_1 NO (I s=
ee &quot;NO&quot; straight away and do nothing)<br />SPECIAL_PROMPT_2 (I se=
nd response + &quot;\r&quot; as input required)<br />NORMAL_PROMPT_3 (I sen=
d response + &quot;\r&quot;)<br />...<br /><br /><br />When scripted this h=
appens...<br /><br />NORMAL_PROMPT_1&nbsp; (script sends response + &quot;\=
r&quot;)<br />NORMAL_PROMPT_2&nbsp; (script sends response + &quot;\r&quot;=
)<br />SPECIAL_PROMPT_1 (sleep 3 seconds)<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (don't=
 see further output so send response + \r)<br />&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; print=
 debug message to terminal &quot;*sending*&quot;<br />&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Then I get NO from the remote printed on the screen<br /><br />So it looks=
 like....<br /><br />NORMAL_PROMPT_1 RESPONSE_1\r<br />NORMAL_PROMPT_2 RESP=
ONSE_2\r<br />SPECIAL_PROMPT_1 RESPONSE_3\r *sending*<br />NO (the \r sent =
above forces a newline here even if response is &quot;&quot;)<br />NORMAL_P=
ROMPT_3 remote assumes RESPONSE_3 + \r is for this.<br /><br />Wrong :-(<br=
 /><br /><br />It seems that after sending &quot;response\r&quot; the accum=
ulator suddenly gets the NO from the remote system but that's after the scr=
ipt thinks it has to send a response. Kermit may be the problem as it's dri=
ving the link (either serial or via telnet) and it may be buffering (I don'=
t think so as it works OK manually)<br /><br /><br />Is there a way to chec=
k if I need to send a response without having to actually send it?<br /><br=
 />I've tried combinations of<br />&nbsp; buffer =3D exp-&gt;after()<br />a=
nd<br />&nbsp; buffer =3D clear_accum(); set_accum($buffer)<br />but no joy=
.<br /><br />Is there a way to check for further characters without absorbi=
ng them (because that text could be my next prompt and I need to keep that =
in the accumulator for the next pass of expect)<br /><br />Thanks,<br />Joh=
n.<br /><br /><BR>

[Expectperl-discuss] Checking accumulator without a second expect

[<li...@jo...>]

<p><br />Hi all,<br /><br />Sorry this is so long and vague (I'll try to co=
de up a small example because my little project uses a back-end database an=
d I'd like to split the Expect piece out - this will take a while).&nbsp; F=
or anyone who's interested have a look at the March 2007 thread to see the =
solution to my original problem.<br /><br />My new code (below) no longer w=
orks (I've done a lot of code changes and need to backtrack to see what exa=
ctly broke it).&nbsp; In the meantime I'm wondering if there's a better way=
.<br /><br />Here's what I'm trying to do...<br />1. Match and capture a pr=
ompt at the start of a line.<br />&nbsp;&nbsp; This works perfectly (March =
2007 code)<br />2. Look up the matched prompt and see if it...<br />&nbsp;&=
nbsp;&nbsp;&nbsp; (a) needs a response,<br />&nbsp;&nbsp;&nbsp;&nbsp; (b) c=
an be ignored, or,<br />&nbsp;&nbsp;&nbsp;&nbsp; (c) needs special handling=
.<br />&nbsp;&nbsp; Always works.<br />3a. For &quot;normal&quot; prompt se=
nd response + &quot;\r&quot; and exp_continue for next prompt.<br />3b. For=
 &quot;ignored&quot; prompt just exp_continue.<br />3c. For a &quot;special=
&quot; prompt sleep 3 seconds then check if there's any more output, if the=
re is the script&nbsp; shouldn't send a response because the remote system =
is showing the status of this setting as opposed to asking for input.&nbsp;=
 It will then present the next prompt (i.e. treat this prompt as in case 3b=
 above). But if there's no further output it's a request for input and so a=
 response must be given (even if just &quot;\r&quot;) as in 3b.<br /><br />=
<br />Case 3c isn't working.&nbsp; When I do it manually I get this...<br /=
><br />NORMAL_PROMPT_1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (I send response=
 + &quot;\r&quot;)<br />NORMAL_PROMPT_2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 (I send response + &quot;\r&quot;)<br />SPECIAL_PROMPT_1&nbsp; NO&nbsp; (I=
 see &quot;NO&quot; straight away and do nothing)<br />SPECIAL_PROMPT_2&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; (I send response + &quot;\r&quot; as input requi=
red)<br />NORMAL_PROMPT_3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (I send respo=
nse + &quot;\r&quot;)<br />...<br /><br /><br />When scripted this&nbsp; ha=
ppens...<br /><br />NORMAL_PROMPT_1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (script s=
ends response + &quot;\r&quot;)<br />NORMAL_PROMPT_2&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; (script sends response + &quot;\r&quot;)<br />SPECIAL_PROMPT_1&nbsp=
;&nbsp;&nbsp;&nbsp; (sleep 3 seconds)<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; (don't see further output so send response + \r)<br />&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; print debug message to terminal &quo=
t;*sending*&quot;<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Then I=
 get NO from the remote printed on the screen<br /><br />So it looks like..=
.<br /><br />NORMAL_PROMPT_1&nbsp;&nbsp;&nbsp; RESPONSE_1\r<br />NORMAL_PRO=
MPT_2&nbsp;&nbsp;&nbsp; RESPONSE_2\r<br />SPECIAL_PROMPT_1&nbsp;&nbsp; RESP=
ONSE_3\r *sending*<br />NO&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (the \r sent above fo=
rces a newline here even if response is &quot;&quot;)<br />NORMAL_PROMPT_3&=
nbsp;&nbsp;&nbsp; remote assumes RESPONSE_3 + \r is for this.<br />&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; Wrong :-(<br /><br /><br />It seems that after se=
nding &quot;response\r&quot; the accumulator suddenly gets the NO from the =
remote system but that's after the script thinks it has to send a response.=
&nbsp; Kermit may be the problem as it's driving the link (either serial or=
 via telnet) and it may be buffering (I don't think so as it works OK manua=
lly)<br /><br /><br />Is there a way to check if I need to send a response =
without having to actually send it?<br /><br />I've tried combinations of<b=
r />buffer =3D exp-&gt;after()<br />and<br />buffer =3D clear_accum(); set_=
accum($buffer)<br />but no joy.</p><p>&nbsp;</p><p>Is there a way to check =
for further characters without absorbing them (because that text could be m=
y next prompt and I need to keep that in the accumulator for the next pass =
of expect)<br /><br />Thanks,<br />John.<br /><br /> =0D
</p><BR>

[Expectperl-discuss] Checking accumulator without a second expect

[John B. (Lists) <li...@jo...>]

Hi all,

Sorry this is so long and vague (I'll try to code up a small example
because my little project uses a back-end database and I'd like to split
the Expect piece out - this will take a while).  For anyone who's
interested have a look at the March 2007 thread to see Roland's very
elegant solution to my original problem.

My new code (below) no longer works (I've done a lot of code changes and
need to backtrack to see what broke it).  In the meantime I'm wondering
if there's a better way.

Here's what I'm trying to do...
1. Match and capture a prompt at the start of a line.
   This works perfectly (March 2007 code)
2. Look up the matched prompt and see if it...
     (a) needs a response,
     (b) can be ignored, or,
     (c) needs special handling.
   Always works.
3a. For "normal" prompt send response + "\r" and exp_continue for next
prompt.
3b. For "ignored" prompt just exp_continue.
3c. For a "special" prompt sleep 3 seconds then check if there's any
more output, if there is the script shouldn't send a response because
the remote system is showing the status of this setting as opposed to
asking for input.  It will then present the next prompt (i.e. treat this
prompt as in case 3b
above). But if there's no further output it's a request for input and so
a response must be given (even if just "\r") as in 3b.


Case 3c isn't working.  When I do it manually I get this...

NORMAL_PROMPT_1       (I send response + "\r")
NORMAL_PROMPT_2       (I send response + "\r")
SPECIAL_PROMPT_1  NO  (I see "NO" straight away and do nothing)
SPECIAL_PROMPT_2      (I send response + "\r" as input required)
NORMAL_PROMPT_3       (I send response + "\r")
...



When I script it here's what happens...

NORMAL_PROMPT_1      (script sends response + "\r")
NORMAL_PROMPT_2      (script sends response + "\r")
SPECIAL_PROMPT_1     (sleep 3 seconds)
                     (don't see further output so send response + \r)
                     print debug message to terminal "*sending*"
                     Then I get NO from the remote printed on the screen

So it looks like...

NORMAL_PROMPT_1    RESPONSE_1\r
NORMAL_PROMPT_2    RESPONSE_2\r
SPECIAL_PROMPT_1   RESPONSE_3\r *sending*
NO                  (not the \r sent above forces a newline here)
NORMAL_PROMPT_3    remote assumes RESPONSE_3 + \r is for this.
                   Wrong :-(


What seems to be happening is after sending response + "\r" the
accumulator suddenly gets the NO from the remote system but that's after
I check if I need a response.


Is there a way to check if I need to send a response without having to
actually send it?

I've tried combinations of exp->after() and clear_accum()/set_accum()
but no joy.  Is there a way to check for further characters without
absorbing them (because that text could be my next prompt and I need to
keep that in the accumulator for the next pass of expect)

Thanks,
John.

[Expectperl-discuss] Checking accumulator without a second expect

[John B. (Lists) <li...@jo...>]

Hi all,

Sorry this is so long and vague (I'll try to code up a small example
because my little project uses a variable regexp and matchlist to
extract the matched prompt).  For anyone who's interested have a look at
the mailing list for March 2007 for Roland's very elegant solution.


My workaround for the new problem below no longer works (I've done a lot
of code changes and need to backtrack to see what broke it).  In the
meantime I'm wondering if there's a better way.

Here's what I'm trying to do...
1. Match a prompt at the start of a line and capture it and any trailing
spaces - this works perfectly (March 2007 code)
2. Look up the matched prompt and see if it needs a response, can be
ignored or needs special handling. Always works.
3a. For "normal" prompt send response + "\r" and exp_continue for next
prompt
3b. For "ignored" prompt just exp_continue (remote system displays next
prompt automatically so pick it up on the next pass of expect)
3c. For a "special" prompt sleep 3 seconds then check if there's any
more output, if there is the script shouldn't send a response because
the remote system is telling me the status of this setting as opposed to
asking for input.  If will then present the next prompt (i.e. case 3b
above). But if there's no further output it's a request for input and so
a response must be given (even if just "\r").


Case 3c isn't working.  When I do it manually I get this...

NORMAL_PROMPT_1       (I send response + "\r")
NORMAL_PROMPT_2       (I send response + "\r")
SPECIAL_PROMPT_1     NO   (I see "NO" straight away and do nothing)
SPECIAL_PROMPT_2          (I send response + "\r" as input required)
NORMAL_PROMPT_3       (I send response + "\r")
...



When I script it here's what happens...

NORMAL_PROMPT_1      (script sends response + "\r")
NORMAL_PROMPT_2      (script sends response + "\r")
SPECIAL_PROMPT_1     (sleep 3 seconds)
                     (don't see further output so send response + \r)
                     print debug message to terminal "*sending*"
                     Then I get NO to the screen from the remote

So it looks like...

NORMAL_PROMPT_1    RESPONSE_1\r
NORMAL_PROMPT_2    RESPONSE_2\r
SPECIAL_PROMPT_1   RESPONSE_3\r *sending*
NO                  (not the \r sent above forces a newline here)
NORMAL_PROMPT_3    remote assumes RESPONSE_3 + \r is for this.
                   Wrong :-(


What seems to be happening is after sending response + "\r" the
accumulator suddenly gets the NO from the remote system but that's after
I check if I need a response.


Is there a way to check if I need to send a response without having to
actually send it?

I've tried combinations of exp->after() and clear_accum()/set_accum()
but no joy.  Is there a way to check for further characters without
absorbing them (because that text could be my next prompt and I need to
keep that in the accumulator for the next pass of expect)

Thanks,
John.

Re: [Expectperl-discuss] expect aint slowing down

[Austin S. <te...@of...>]

On Wed, Oct 24, 2007 at 03:07:15PM -0700, Noah wrote:
> >>What am I doing wrong?
> >>
> >	Not using the debugging capabilities of the tool you are using.
> >Look for debug and exp_internal in the Expect docs.
> >
> >	Austin
> 
> 
> will do - thanks Austin.
> 

	No problem! If you are unable to figure out what's wrong after
some observation, feel free to report back with the output from a session.

	Austin

Re: [Expectperl-discuss] expect aint slowing down

[Noah <ad...@en...>]

Austin Schutz wrote:
> On Wed, Oct 24, 2007 at 10:22:51AM -0700, Noah wrote:
>> Hi there,
>>
>> It's been a while since I've coded in perl/expect.
>>
>> I am finding that when sending the "request snmp spoof-trap $trap" in 
>> the for loop that the command is sent without waiting for the prompt. 
>> In fact they are sent as fast as they can be.
>>
>> I am trying to figure out why that is happening.  since expect is not 
>> waiting for the prompt the commands get truncated and CLI errors result, 
>> etc.
>>
>> What am I doing wrong?
>>
> 	Not using the debugging capabilities of the tool you are using.
> Look for debug and exp_internal in the Expect docs.
> 
> 	Austin


will do - thanks Austin.

Re: [Expectperl-discuss] expect aint slowing down

[Austin S. <te...@of...>]

On Wed, Oct 24, 2007 at 10:22:51AM -0700, Noah wrote:
> Hi there,
> 
> It's been a while since I've coded in perl/expect.
> 
> I am finding that when sending the "request snmp spoof-trap $trap" in 
> the for loop that the command is sent without waiting for the prompt. 
> In fact they are sent as fast as they can be.
> 
> I am trying to figure out why that is happening.  since expect is not 
> waiting for the prompt the commands get truncated and CLI errors result, 
> etc.
> 
> What am I doing wrong?
> 
	Not using the debugging capabilities of the tool you are using.
Look for debug and exp_internal in the Expect docs.

	Austin