in reply to Re: Expect.pm early termination?
in thread Expect.pm early termination?

Well if the source code will help then I will be glad to post it.
#!/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);
I do not however believe there is an issue with it since it is so basic and have already troubleshot down to the Expect.pm module but if it helps you help me, there it is.

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?

Replies are listed 'Best First'.
Re^3: Expect.pm early termination?
by shmem (Chancellor) on Jul 25, 2006 at 16:26 UTC
    Yes. Since you do $terminal->raw_pty(1), did you test
    $terminal->send("sys hard\r\n");

    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..