Yeah, I found subclassing Expect to be the easiest way to go (this was several years ago when SSH first started being supported across the board on our switches and routers). Too many of the dumber devices have cranky SSH support when it comes to keys and using multiple channels.

Read the source of Net::Telnet for hints and a good starting regexp to match the various prompts. Then subclass Expect and add login(), enable(), cmd() methods.

The reasons not to use a full-blown CPAN module are that once you get past real SSH hosts and into routers and then switches and access points the capabilities change so much that the modules don't work across them all. And when you submit bugs to vendors it goes much smoother if you can tell them that you're just using openssh.

Just start with Expect, enable the logging and spawn a ssh and work through the login() and cmd() steps using just the expect, send methods. Then factor that code out into a subclass of Expect.

You might want to look at Net::CLI::Interact which I just noticed a few weeks ago, it looks decently promising.

Subclassing external modules that are not designed for doing so is not a good idea. You could unintentionally give to some of your methods names already used on the base class (now, or in a future release) and break it.

Delegation is a better approach. You can use AUTOLOAD to proxy all the methods unknown to your class to the slave object.

package My::Expect;

use Expect;

sub new {
  my $class = shift;
  my $expect = Expect->new(@_);
  bless { expect => $expect }, $class;
}

sub login { ... }
sub enable { ... }
sub cmd { ... }

sub AUTOLOAD {
    my $method_name = $AUTOLOAD;
    $method_name =~ s/.*:://;

    my $sub = sub { shift->{expect}->$method_name(@_) }
    {
        no strict 'refs';
        *$method_name = $sub;
    }
    goto &$sub;
}
[download]