Beefy Boxes and Bandwidth Generously Provided by pair Networks chromatic writing perl on a camel
laziness, impatience, and hubris
 
PerlMonks  

A few questions regarding Expect.pm and possible alternatives

by Anonymous Monk
on May 23, 2013 at 13:01 UTC ( #1034942=perlquestion: print w/ replies, xml ) Need Help??
Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Good morning Monks!

I have a few questions for you guys, so not really too sure how to title this one... I am using Expect to automate some things over here. Some of these things are simple commands, so Expect is not really necessary per se (i.e., I won't be using expect/send functionality). Others are interactive, so I will be needing Expect.

My first question is: Expect is a rather old Perl module that has not been updated in quite some time. Is this still the go-to module for automating interactive tasks via ssh, or is there something better?

Second, since I am running some commands that I only care to get the output from, and others that are interactive (i.e., where I am using expect/send), do you think it makes sense to use Net::SSH::Perl for the tasks where I need output, and Expect for those tasks that are interactive?

Finally, the commands I am running share output, have their own output, and have quite a bit of output. I could do this:

$exp->expect($timeout, [ qr /pattern/ => sub { do things; } ] );

For each and every pattern... However, say with commandA I am expecting 40 or so different possible patterns, and with commandB I am expecting 30 or so possible patterns, 20 of which I am also expecting from commandA (i.e., shared possible patterns, union). Is there an easier way to do this then? Say something like a dispatch table where output is mapped to what to do, then I could do something like:

$exp->expect($timeout, \$dispatch_table );

Or, maybe I could even have an XML file with all the possible outputs and what to dos defined? Just wondering how some of you would tackle this one, because my mind is drawing a blank.

Thank you Monks!

Comment on A few questions regarding Expect.pm and possible alternatives
Select or Download Code
Re: A few questions regarding Expect.pm and possible alternatives
by 5mi11er (Deacon) on May 23, 2013 at 20:37 UTC
    I would recommend you use the expect methods for most everything. Switching back and forth, wondering which method would be better means that it will become more difficult down the road to tweak things to add a smidgen more functionality if you didn't start out using expect for that task.

    Expect is pretty mature, as such, there isn't a need to add features all the time, and there are apparently not many bugs that need squashed, so it's age could be considered a good thing. It works, and works well.

    Update: (I didn't answer other questions)

    If the expect script parts are complicated enough, you might find that writing actual expect scripts rather than embedding them in perl, and calling those scripts from perl may simplify the tasks. This is typically what I've done with my scripts. Without actual or simulated examples, it's difficult to point you in a direction or suggest improvements.

    -Scott

Re: A few questions regarding Expect.pm and possible alternatives
by salva (Monsignor) on May 24, 2013 at 08:05 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1034942]
Approved by ww
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (15)
As of 2014-04-18 19:37 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (471 votes), past polls