#!/usr/bin/perl -w

use strict;
use Expect;

my $username = "admin";
my $password = "password\n";

##### flip this value to 0 to turn off stout and 1 to turn it on
$Expect::Log_Stdout=1;

# Lets see what expect is doing!
$Expect::Exp_Internal = 1;
#$Expect::Debug = 3;

my $terminal = new Expect;
$terminal->raw_pty(1);
$terminal = Expect->spawn("ssh -l $username hostname");

$terminal->log_file("test_err.txt");

unless ($terminal->expect(30,"passphrase")) {
   die "Error 01::Never got password prompt, ".$terminal->exp_error().
+"\n";
}
print "...recieved password prompt\n";

$terminal->send($password);
unless ($terminal->expect(30, '/# ')) {
   die "Error 02::Never got first prompt, ".$terminal->exp_error()."\n
+";
}

$terminal->send("sys hard\n");
unless ($terminal->expect(30, '/# ')) {
   die "Error 03::Never got sec prompt, ".$terminal->exp_error()."\n";
}

$terminal->send("exit\n");
$terminal->log_file(undef);
[download]

Yes the entire session always works via command line and tcl expect and python expect, so I would venture a guess that it is perl expect that has the issue. Yes I am talking to some shell type application, sorry if that was not clear in my original post. The remote server shell mimics that of a Cisco IOS type OS.

I have monitored the connection via ethereal but none of it really helps since ssh is an encrypted session I can not see what is being sent in the payload. Any other suggestions?

Yes. Since you do $terminal->raw_pty(1), did you test

$terminal->send("sys hard\r\n");
[download]

i.e. sending CRLF? The script looks ok, and re-opening filehandles is ok too. It must not be Expect's fault if there's nothing to read from the socket; if nothing was sent, that's perfectly ok. I guess the remote shell doesn't grok the input is terminated, so I'd play with various setings of CRLF translations.

HTH,
--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Yeah I have tried all combinations of the CRLF issue. I suspect that you are correct in saying that the remote system does not understand what is being sent which is why I was trying setting to raw and all sorts of other things but nothing seems to work.

What settings of CRLF translation are you refering to? I have tried nunerous combinations of CR LF and CRLF along with raw terminal and setting slave modes, etc..