expectperl-discuss Mailing List for Expect.pm

Hello all,

Can you tell me why isn't the expect(1, '-re', $string) bellow matching
successfully?

I put in color RED the debug message showing that the pattern in $string is
exactly what expect has on it's accumulator.

So why isn't it matching? There are some "\n" in the pattern, can it be a
problem?


Starting EXPECT pattern matching...
        Expect::expect('Expect=GLOB(0x8064a020)',0,'-re','  PID TTY
TIME CMD\x{a} 9724 ?        00:00:00 bash\x{a} 988...') called at
/home/brunonz/Net-SSH-Expect/lib/Net/SSH/Expect.pm line 239
        Net::SSH::Expect::eat('Net::SSH::Expect=ARRAY(0x80173ce0)','  PID
TTY          TIME CMD\x{a} 9724 ?        00:00:00 bash\x{a} 988...') called
at /home/brunonz/Net-SSH-Expect/lib/Net/SSH/Expect.pm line 270
        Net::SSH::Expect::readAll('Net::SSH::Expect=ARRAY(0x80173ce0)',1)
called at /home/brunonz/Net-SSH-Expect/lib/Net/SSH/Expect.pm line 289
        Net::SSH::Expect::exec('Net::SSH::Expect=ARRAY(0x80173ce0)','ps',1)
called at ./wshell line 66
        eval {...} called at ./wshell line 65
spawn id(3): list of patterns:
  #1: -re `  PID TTY          TIME CMD\n 9724 ?        00:00:00 bash\n 9888
?        00:00:00 bash\n12978 ?        00:00:00 bash\n13075 ?
00:00:00 ps\n'


spawn id(3): Does `  PID TTY          TIME CMD\n 9724 ?        00:00:00
bash\n 9888 ?        00:00:00 bash\n12978 ?        00:00:00 bash\n13075
?        00:00:00 ps\n'

match:
  pattern #1: -re `  PID TTY          TIME CMD\n 9724 ?        00:00:00
bash\n 9888 ?        00:00:00 bash\n12978 ?        00:00:00 bash\n13075
?        00:00:00 ps\n'? No.




Best regards,

bruno

On Thu, Jul 26, 2007 at 11:08:11AM -0400, Chuck Son wrote:
> It appears that whenever I use send(), the next expect() will read the
> previous line again and thus causing the send() to occur twice.  I read
> the FAQ and it appears this is a common problem?  Has anyone figured out
> a workaround?  Thanks.

Not sure I understand the question, but maybe you're referring to the
just-sent string appearing in the response? That would be the "echo" from
the application, which is normal for interactive applications. If you're
driving the application manually, each character you see in response to
what you type is coming back from the application, not from your local
terminal. When automating this, you just need to expect to see the same
string (usually) just sent, usually with the end-of-line character(s)
changed ("foo\r" is sent, "foo\n" or "foo\r\n" is seen in response).

The echo might be considered a confirmation that the app has gotten the
right command, or an indication of the state of the application. The
command's response should immediately follow the echo.

> my $exp = new Expect;
> $exp->raw_pty(1);
> $exp->spawn("randomApplication.pl");
> 
> while ($value != 3) {
> 	my $value = $exp->expect($timeout,
> 		[ qr/sender/],
> 		[ qr/receiver/],
> 		[ qr/whatever/]
> 		);
> 
> 	if ($value == 1) {
> 		$exp-send("Yes");
> 	}
> 	elsif ($value == 2) {
> 		$exp-send("No");
> 	}
> }

Or maybe you meant something else... I don't follow what the code snippet is
intended to demonstrate/illustrate.

Ken

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

It appears that whenever I use send(), the next expect() will read the
previous line again and thus causing the send() to occur twice.  I read
the FAQ and it appears this is a common problem?  Has anyone figured out
a workaround?  Thanks.

my $exp = new Expect;
$exp->raw_pty(1);
$exp->spawn("randomApplication.pl");

while ($value != 3) {
	my $value = $exp->expect($timeout,
		[ qr/sender/],
		[ qr/receiver/],
		[ qr/whatever/]
		);

	if ($value == 1) {
		$exp-send("Yes");
	}
	elsif ($value == 2) {
		$exp-send("No");
	}
}

> On 7/16/07, Bryan Bueter <br...@bu...> wrote:
>> I persued Net::SSH2 over a year ago for just this purpose.  You can read
>> the thread I had with the author here:
>>
>> http://sourceforge.net/mailarchive/message.php?msg_id=200601192208.43932.dbrobins%40cpan.org
>>
>> Basically David Robins stated this:
>>
>> Ah, then there's the problem. Fileno tries to get a real Unix filehandle
>> out
>> of the object; since it isn't a real Unix file, you won't get one.
>>
>> I could not get it to work, and David seemed to think that it should not
>> work.  In that thread there is very simple code that I wrote and even
>> that
>> doesnt work.
>
> I think all that would be needed is that Net::SSH2::Channel returns
> the fileno of the socket connection. Expect needs a real fileno to do
> a select() on it, but everything else is done via the object.
>
> Ideally, Net::SSH2 should be rewritten as an I/O filter ala
> PerlIO::gzip. Well, one may dream... :-)
>
>> However, all that aside, even without using Expect, Net::SSH2 was not
>> thread safe.  I sent emails regarding that as well, to no avail.  At
>> this
>> point in time, I really think Expect on top of a spawned ssh command is
>> the best way to do things (from a perl perspective).
>
> I browsed through the source and didn't notice anything obvious that
> could hinder thread-usage. Can you remember what it was that was not
> thread-safe?
>
> Yeah, let's stick to ssh for now, nothing wrong with that. But please,
> people, remember to not use password-authentication...
>
> Best regards, Roland
>

If I remember correctly, when i tried threading with Net::SSH2 in the past
(v0.06), it would connect to multiple sessions and then hang when reading
from those channels simultaneously.

However, now I cant even get the latest version (v0.10) to work in single
threaded mode.  So for the moment i'm not going to waste any more time on
it.

Thanks,


Bryan Bueter
http://sourceforge.net/projects/rover

On 7/16/07, Bryan Bueter <br...@bu...> wrote:
> I persued Net::SSH2 over a year ago for just this purpose.  You can read
> the thread I had with the author here:
>
> http://sourceforge.net/mailarchive/message.php?msg_id=200601192208.43932.dbrobins%40cpan.org
>
> Basically David Robins stated this:
>
> Ah, then there's the problem. Fileno tries to get a real Unix filehandle out
> of the object; since it isn't a real Unix file, you won't get one.
>
> I could not get it to work, and David seemed to think that it should not
> work.  In that thread there is very simple code that I wrote and even that
> doesnt work.

I think all that would be needed is that Net::SSH2::Channel returns
the fileno of the socket connection. Expect needs a real fileno to do
a select() on it, but everything else is done via the object.

Ideally, Net::SSH2 should be rewritten as an I/O filter ala
PerlIO::gzip. Well, one may dream... :-)

> However, all that aside, even without using Expect, Net::SSH2 was not
> thread safe.  I sent emails regarding that as well, to no avail.  At this
> point in time, I really think Expect on top of a spawned ssh command is
> the best way to do things (from a perl perspective).

I browsed through the source and didn't notice anything obvious that
could hinder thread-usage. Can you remember what it was that was not
thread-safe?

Yeah, let's stick to ssh for now, nothing wrong with that. But please,
people, remember to not use password-authentication...

Best regards, Roland

On Mon, Jul 16, 2007 at 12:38:24PM +0200, Roland Giersig wrote:
> Hmm, could be the wait delay in soft/hard_close which is trying to
> send signals to the spawned process via "kill". Maybe that also
> doesn't work in a thread (like fork()). Could you try closing the
> Expect objects in the main thread? Maybe that gets rid of the delay...
> 


	soft_close (e.g.) will read from the process until it returns EOF,
then wait on the process until it dies. This is typically considered
responsible behavior because it reduces the possibility of leaving zombies
around. My question would be "what is ssh doing instead of exiting?" Maybe
truss/strace would answer that question.


	Austin

> Hmm, could be the wait delay in soft/hard_close which is trying to
> send signals to the spawned process via "kill". Maybe that also
> doesn't work in a thread (like fork()). Could you try closing the
> Expect objects in the main thread? Maybe that gets rid of the delay...
>
> Seems a sensible rule to me: "Create and destroy Expect objects only
> in the main thread."
>

Actually its the other way around.  If i soft/hard close the object in the
thread it takes a reasonable amount of time.  If I soft/hard close it in
the main thread it takes longer.  The actual delay is in the join
function, then closing the objects works normally.  I re-wrote the last
script to output the number of seconds elapsed and here is the output:

Getting expect object for mythtv: 0 seconds
Getting expect object for valhalla: 0 seconds
Getting expect object for eldorado: 0 seconds
Spawning thread: 1 seconds
Spawning thread: 1 seconds
Spawning thread: 1 seconds
Joining thread 0 (mythtv): 1 seconds
Completed joining thread 0 (mythtv): 16 seconds
Closing expect object: 16 seconds
Joining thread 1 (eldorado): 16 seconds
Completed joining thread 1 (eldorado): 16 seconds
Closing expect object: 16 seconds
Joining thread 2 (valhalla): 16 seconds
Completed joining thread 2 (valhalla): 16 seconds
Closing expect object: 16 seconds

You can see it takes about 15 seconds to join the first thread and then
things progress normally.

>
> BTW, anybody tried to use Net::SSH2 instead of spawning ssh? Net::SSH2
> objects are tied filehandles, so they should be usable via
> exp_init()...
>
> Cheers!
> Roland
>

I persued Net::SSH2 over a year ago for just this purpose.  You can read
the thread I had with the author here:

http://sourceforge.net/mailarchive/message.php?msg_id=200601192208.43932.dbrobins%40cpan.org

Basically David Robins stated this:

Ah, then there's the problem. Fileno tries to get a real Unix filehandle out
of the object; since it isn't a real Unix file, you won't get one.

I could not get it to work, and David seemed to think that it should not
work.  In that thread there is very simple code that I wrote and even that
doesnt work.

However, all that aside, even without using Expect, Net::SSH2 was not
thread safe.  I sent emails regarding that as well, to no avail.  At this
point in time, I really think Expect on top of a spawned ssh command is
the best way to do things (from a perl perspective).

Thanks


Bryan Bueter
http://sourceforge.net/projects/rover

Hmm, could be the wait delay in soft/hard_close which is trying to
send signals to the spawned process via "kill". Maybe that also
doesn't work in a thread (like fork()). Could you try closing the
Expect objects in the main thread? Maybe that gets rid of the delay...

Seems a sensible rule to me: "Create and destroy Expect objects only
in the main thread."

BTW, anybody tried to use Net::SSH2 instead of spawning ssh? Net::SSH2
objects are tied filehandles, so they should be usable via
exp_init()...

Cheers!
Roland

On 7/16/07, Bryan Bueter <br...@bu...> wrote:
> > Austin/Roland,
> >
> > Ok, there have been a few threads lately about threading so I thought i
> > would re-visit the issue.  I wrote a script that seems to work, but I
> > would like your opinions on if it really should be working, and/or any
> > snafu's i may run into if I continue doing it this way.
> >
>
> Ok, responding to my own thread...  I've been playing with this because
> even though the login portion is single threaded, it still outperforms
> forking and running in parallel.  However, I think i ran into one bug that
> I am consistently able to re-produce.
>
> My previous script works fine and is pretty quick to spawn and join the
> threads.  However, it seems that if I exit and soft_close()/hard_close()
> the expect object after the thread is joined, it hangs for a couple of
> seconds before joining the first thread.
>
> Here is the script that causes the join() delay.  You can compare this to
> my previous script to demonstrate what I'm talking about.
>
> --- start --->
> #!/usr/bin/perl -w
>
> use strict;
> use threads;
>
> use Expect;
> $Expect::Log_Stdout = 0;
>
> our $prompt = '[>#\$] $';
> my @hosts = ("mythtv", "valhalla", "eldorado" );
> my %hosts_exp;
>
> foreach my $host (@hosts) {
>   print "Getting expect object for $host\n";
>   $hosts_exp{$host} = new Expect;
>
>   $hosts_exp{$host}->log_file("$host.log");
>   $hosts_exp{$host}->spawn("ssh -x $host");
>   $hosts_exp{$host}->expect(5, '-re', $prompt);
> }
>
> my $thread_id = 0;
> my @thread_ids = ();
> my @thread_hosts;
> my @commands = ("uptime", "who", "who am i", "pwd");
> foreach my $host ( keys %hosts_exp ) {
>   $thread_ids[$thread_id] = threads->new("run_threaded",
> $hosts_exp{$host}, $host, @commands);
>   $thread_hosts[$thread_id] = $host;
>
>   $thread_id++;
> }
>
> for (my $t=0; $t<$thread_id; $t++) {
>   print "Joining thread $t (". $thread_hosts[$t] .")\n";
>   my $result = $thread_ids[$t]->join();
>   print "Completed joining thread $t (". $thread_hosts[$t] .")\n";
>
>   if ($result) {
>     $hosts_exp{$thread_hosts[$t]}->send("exit;\n exit;\n exit;\n");
>     $hosts_exp{$thread_hosts[$t]}->soft_close();
>   } else {
>     print "Thread $t returned bad result\n";
>     $hosts_exp{$thread_hosts[$t]}->hard_close();
>   }
>
> }
>
> sub run_threaded {
>   my $exp = shift;
>   my $hostname = shift;
>   my @commands = @_;
>
>   my $result = 0;
>   foreach my $command (@commands) {
>     print "Executing on $hostname: $command\n";
>     $exp->send("$command \n");
>     $result = $exp->expect(5, '-re', $prompt);
>     last if ! $result;
>   }
>
>   return($result);
> }
> <--- end ---
>
> Thanks, please let me know what you think.
>
>
> Bryan Bueter
> http://sourceforge.net/projects/rover
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
>

> Austin/Roland,
>
> Ok, there have been a few threads lately about threading so I thought i
> would re-visit the issue.  I wrote a script that seems to work, but I
> would like your opinions on if it really should be working, and/or any
> snafu's i may run into if I continue doing it this way.
>

Ok, responding to my own thread...  I've been playing with this because
even though the login portion is single threaded, it still outperforms
forking and running in parallel.  However, I think i ran into one bug that
I am consistently able to re-produce.

My previous script works fine and is pretty quick to spawn and join the
threads.  However, it seems that if I exit and soft_close()/hard_close()
the expect object after the thread is joined, it hangs for a couple of
seconds before joining the first thread.

Here is the script that causes the join() delay.  You can compare this to
my previous script to demonstrate what I'm talking about.

--- start --->
#!/usr/bin/perl -w

use strict;
use threads;

use Expect;
$Expect::Log_Stdout = 0;

our $prompt = '[>#\$] $';
my @hosts = ("mythtv", "valhalla", "eldorado" );
my %hosts_exp;

foreach my $host (@hosts) {
  print "Getting expect object for $host\n";
  $hosts_exp{$host} = new Expect;

  $hosts_exp{$host}->log_file("$host.log");
  $hosts_exp{$host}->spawn("ssh -x $host");
  $hosts_exp{$host}->expect(5, '-re', $prompt);
}

my $thread_id = 0;
my @thread_ids = ();
my @thread_hosts;
my @commands = ("uptime", "who", "who am i", "pwd");
foreach my $host ( keys %hosts_exp ) {
  $thread_ids[$thread_id] = threads->new("run_threaded",
$hosts_exp{$host}, $host, @commands);
  $thread_hosts[$thread_id] = $host;

  $thread_id++;
}

for (my $t=0; $t<$thread_id; $t++) {
  print "Joining thread $t (". $thread_hosts[$t] .")\n";
  my $result = $thread_ids[$t]->join();
  print "Completed joining thread $t (". $thread_hosts[$t] .")\n";

  if ($result) {
    $hosts_exp{$thread_hosts[$t]}->send("exit;\n exit;\n exit;\n");
    $hosts_exp{$thread_hosts[$t]}->soft_close();
  } else {
    print "Thread $t returned bad result\n";
    $hosts_exp{$thread_hosts[$t]}->hard_close();
  }

}

sub run_threaded {
  my $exp = shift;
  my $hostname = shift;
  my @commands = @_;

  my $result = 0;
  foreach my $command (@commands) {
    print "Executing on $hostname: $command\n";
    $exp->send("$command \n");
    $result = $exp->expect(5, '-re', $prompt);
    last if ! $result;
  }

  return($result);
}
<--- end ---

Thanks, please let me know what you think.


Bryan Bueter
http://sourceforge.net/projects/rover

More info.


    I just tested that the extra \n after the ps command is only
needed when the SSH server is an AIX system, the same thing doesn't
hapen when the SSH server is a zLinux OS...

    :-(

    Why????!!!!

    Best regards,

    bruno

Hello guys,

I'm developing a perl module to login and execute commands via ssh using
Expect. It's already on CPAN:
http://search.cpan.org/~bnegrao/Net-SSH-Expect-0.08/lib/Net/SSH/Expect.pm<http://search.cpan.org/%7Ebnegrao/Net-SSH-Expect-0.08/lib/Net/SSH/Expect.pm>

I'm facing some problems that i don't understand. Now i have a case where i
need to send an extra "\n" character to make the prompt reapear after
sending a some specific commands, not all.

I did a simple script that exemplifies this behaviour.

The script bellow is called ssh.pl. The usage is
     ssh.pl host username password

It will login via ssh on host and execute the same four commands 100 times.

The problem is shown in the line:
    $spawn->send("ps\n\n");  # NEEDS TWO \N\N HERE OR THE PROMPT DOESN'T
RETURN!! WHY????

I simply don't understand why after sending a "ps\n" the prompt on the
remote server doesn't appear, what makes it unavailable for the next command
in the loop.

But, for example, after sending a "who am i\n", one \n is enough to make the
prompt reapear.

Can you explain this phenomenon for me?

Regards,

bruno



#!/usr/bin/perl
# ssh.pl
# ssh to a server and execute 4 commands in a loop, only to test Expect.
# usage
# ssh.pl host username password

if( ! defined $ARGV[0] ) {
    print "Usage: ssh.pl <host> <username> <password> \n";
    exit;
}

my ($host, $username, $password) = @ARGV;
$username = $ENV{USER} if $username eq "";

#!/usr/bin/perl
# ssh to a server and execute 4 commands in a loop, only to test Expect.
#

if( ! defined $ARGV[0] ) {
    print "Usage: ssh.pl <host> <username> <password> \n";
    exit;
}

my ($host, $username, $password) = @ARGV;
$username = $ENV{USER} if $username eq "";

use Expect;
#use IO::Pty;

my $spawn = new Expect;
$spawn->raw_pty(1);
$spawn->exp_internal(0);


$spawn->spawn("ssh $username\@$host") or die $!;

$spawn->log_stdout(0);

my $ret = $spawn->expect(10,
    [ qr/\(yes\/no\)\?\s*$/ => sub { $spawn->send("yes\n"); exp_continue; }
],
    [ qr/assword:\s*$/      => sub { $spawn->send("$password\n") if defined
$password;  } ],
    [ qr/ogin:\s*$/         => sub { $spawn->send("$username\n");
exp_continue; } ],
    [ qr/REMOTE HOST IDEN/  => sub { print "FIX: .ssh/known_hosts\n";
exp_continue; } ],
);
while ($spawn->expect(1, '-re', qr/[\s\S]+/)){
    #swallow any output the server throws after loging in
}
my $PROMPT = 'SSH_PROMPT>> ';
$spawn->send("PS1='$PROMPT'\n");


for (my $i = 100; $i > 0; $i--) {
    if ($spawn->expect(3, -re, qr/$PROMPT$/)) {
        print $spawn->before();
        $spawn->send("df -m /\n");
    } else {
        exit $i;
    }

    if ($spawn->expect(3, $PROMPT)) {
        print $spawn->before();
        $spawn->send("ls -l /bin/ls\n");
    } else {
        exit $i;
    }
    if ($spawn->expect(3, $PROMPT)) {
        print $spawn->before();
        $spawn->send("who am i\n");
    } else {
        exit $i;
    }
    if ($spawn->expect(3, $PROMPT)) {
        print $spawn->before();
        $spawn->send("ps\n\n");  # NEEDS TWO \N\N HERE OR THE PROMPT DOESN'T
RETURN!! WHY????
    } else {
        exit $i;
    }
    print ("\n\n$i $i $i $i $i $i $i $i $i $i $i\n\n");
}

exit;

>
>Hi All,
>
>I am using the Expect to give responses to the questions asked while
>installation. Here is a problem I am facing.
>
>This is the question I am expecting to be asked and I am waiting for the
>same question
>Do you want to start Veritas Storage Foundation for DB2 processes now?
>[y,n,q] (y)
>
>But, the problem is on some terminals the question appears as
>Do you want to start Veritas Storage Foundation for DB2 processes now?
>[y,n,q] (y)
>
>or even as
>Do you want to start Veritas Storage Foundation for
>DB2 processes now? [y,n,q] (y)
>
>How to handle such things? Please help.
>
>Thanks and Regards,
>Prasad.

Some problems like this are caused by the  setup of the  shell started  using the
spawn command. If the default line width is shorter than the ouput line  from the
program the line is wrapped on to the next line.

What I often do is to wait for the  first prompt and  send a
   stty  columns 200
so that output lines  are not wrapped.
Ian W Moor                    Department of Computing,
iw...@do...           Imperial College.
                                    180 Queensgate
                                     London SW7 2AZ UK.

>From the perlthrtut:
"Thinking of mixing fork() and threads?  Please lie down and wait
until the feeling passes."
;-)

Note that spawn() does a fork. So this can only work if you spawn()
all SSH connections in the main thread and then pass the Expect
objects to the threads for handling. Bryan Bueter has provided a
working example for using Expect/SSH/threads on the mailing list.

Hope this helps,

Roland
PS: Net::SSH2 looks promising because it's objects are tied
filehandles and thus should work with Expect via exp_init(). But I
haven't had the time to try that yet. Hopefully any day soon...

On 7/11/07, schlum <jsc...@bo...> wrote:
>
> Hi,
>
> I spent few days on this one, but couldn't get it working...
>
> I am working under sunOS
> bt1wxxxx#uname -a
> SunOS bt1wxxxx 5.6 Generic_105181-23 sun4u sparc SUNW,Ultra-60
>
> I can run the following script without any problem :
>
> #!/usr/bin/perl
> use strict;
> use Expect;
> my $exp = Expect->new;
> $exp->raw_pty(1);
> my $test = $exp->spawn('/usr/local/bin/ssh', -l => 'my_user', 'my_host') or
> die "Cannot spawn command: $!\n";
> my @test1 = $exp->expect(5,'-re','password:');
> $exp->clear_accum();
> my @test2 = $exp->send("my_pass\r\n");
> my @test3 = $exp->expect(15,'-re','my_host');
> my @test4 = $exp->send("sh privilege\r\n");
>
> The last command is exectuted successfuly.
>
> But if I try this :
>
> #!/usr/bin/perl
> use strict;
> use Expect;
> use threads;
> use threads::shared;
> use Thread::Queue::Any;
>
> my $thread = threads->new(\&threadJob,);
> $thread->join;
>
> sub threadJob{
>     my $exp = Expect->new;
>     $exp->raw_pty(1);
>     my $test = $exp->spawn('/usr/local/bin/ssh', -l => 'my_user', 'my_host')
> or die "Cannot spawn command: $!\n";
>     my @test1 = $exp->expect(5,'-re','password:');
>     $exp->clear_accum();
>     my @test2 = $exp->send("my_pass\r\n");
>     my @test3 = $exp->expect(15,'-re','my_host');
>     my @test4 = $exp->send("sh privilege\r\n");# On envoie le mdp
>         }
>
> I actually get connected, but Expect don't interact anymore with ssh after
> the logging. Instead, I can access the box, I telneted from STDIN ...
>
> Does anybody knows why I'm getting this strange behavior ?
>
> Btw, when I close the conection, the script finishes to run peacefully.
>
> --
> View this message in context: http://www.nabble.com/Trouble-with-Expect-working-with-Threads-tf4062209.html#a11541250
> Sent from the Perl - Expectperl-Discuss mailing list archive at Nabble.com.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
>

Austin/Roland,

Ok, there have been a few threads lately about threading so I thought i
would re-visit the issue.  I wrote a script that seems to work, but I
would like your opinions on if it really should be working, and/or any
snafu's i may run into if I continue doing it this way.

My script (which I will add to this e-mail) does the following steps in
order:

1. Initialize and store 1 expect object for each host, spawning an SSH
command
2. Get to a command prompt on each expect object, so we have some place to
start
3. Start one thread for each host, sending a list of commands, expecting
the prompt in between each command
4. Close the expect object and return, joining thread

I know it works with at least 5 hosts because i keep separate logs for
each expect session.  I'm using Expect v1.20, IO::Tty v1.07, and i've
tried this on two different hosts:

SunOS 5.10 Generic_125101-09 i86pc
Redhat Linux AS4 2.6.9-5.EL

And finally, here is the script:

--- start --->
#!/usr/bin/perl -w

use strict;
use threads;

use Expect;
$Expect::Log_Stdout = 0;

our $prompt = '[>#\$] $';
my @hosts = ("ravager", "jupiter", "europa", "firebee", "invader");
my %hosts_exp;

foreach my $host (@hosts) {
  print "Getting expect object for $host\n";
  $hosts_exp{$host} = new Expect;

  $hosts_exp{$host}->log_file("$host.log");
  $hosts_exp{$host}->spawn("ssh -x $host");
  $hosts_exp{$host}->expect(5, '-re', $prompt);
}

my $thread_id = 0;
my @thread_ids = ();
my @commands = ("uptime", "who", "who am i", "pwd");
foreach my $host ( keys %hosts_exp ) {
  $thread_ids[$thread_id] = threads->new("run_threaded",
$hosts_exp{$host}, $host, @commands);
  $thread_id++;
}

for (my $t=0; $t<$thread_id; $t++) {
  my $result = $thread_ids[$t]->join();
  if ( ! $result ) { print "Thread $t returned bad result\n"; }
}

sub run_threaded {
  my $exp = shift;
  my $hostname = shift;
  my @commands = @_;

  my $result = 0;
  foreach my $command (@commands) {
    print "Executing on $hostname: $command\n";
    $exp->send("$command \n");
    $result = $exp->expect(5, '-re', $prompt);
    last if ! $result;
  }

  if ($result) {
    $exp->send("exit;\n exit;\n exit;\n");
    $exp->soft_close();
  } else {
    $exp->hard_close();
  }

  return($result);
}
<--- end ---

Thanks,

Bryan Bueter
http://sourceforge.net/projects/rover

Matt Zagrabelny wrote:
> 
> On Wed, 2007-07-11 at 11:56 -0700, Austin Schutz wrote:
>> On Wed, Jul 11, 2007 at 10:50:32AM -0500, Matt Zagrabelny wrote:
>> > [...]
>> > 
>> > > Does anybody knows why I'm getting this strange behavior ?
>> > 
>> > Check the archives.
>> > 
>> > From [1] comes:
>> > 
>> > >>
>> > While Expect is supposed to be reasonably threadsafe, IO-Tty is *not*,
>> > that's where the problems come from. If you want to automate telnet,
>> > using Net::Telnet with Expect should be possible under threads.
>> > <<
>> > 
>> > I have had issues getting expect to use a spawned Net::Telnet object as
>> > well (which is "supposed to be" thread safe). After much gnashing of
>> > teeth, i have given up on Expect and been using Net::Telnet alone;
>> which
>> > is disappointing, because Expect is much more powerful and elegant than
>> > Net::Telnet, however many *many* hours were wasted trying to get them
>> to
>> > work together across a diverse population of Cisco gear.
>> > 
>> 
>> 	Have you tried using exp_init on a Net::Telnet object? That doesn't
>> use IO::Tty.
> 
> Yes, and by in large it worked. However, there were some Cisco switches
> that it did not work for. So... I emailed the list and a fellow gave me
> some good advice and my problems were solved, so I thought. There were
> still some anomalies that were not working correctly. So to recap:
> 
> * Expect worked with everything, but no threads
> 
> * Expect with Net::Telnet was threaded, but could not communicate to all
> switches
> 
> * Expect with Net::Telnet plus trick from mailing list was able to
> communicate to almost all switches, but not all
> 
> Hence...
> 
> I now use Net::Telnet by itself. It is not as elegant as Expect, but the
> thread speedup is *awesome*.
> 
> -- 
> 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
> 
> 

Hi !
Thank you for your answers.
Actually my need seems to be the same as you : I want to automatize some
operations on routers/switch/... I have about 2500 boxes to manage => I need
the multithreading in most cases.

For me everything worked fine with expect/telnet/threaded, as for
SNMP/threaded. But we are now desactivating the Telnet on the
infrastructure, so I really need to find a remplacement to Telnet. Most
Cisco equipments only support SSH V1, so the only way I found so far is to
use Expect.

You think there is no hope of getting Expect/SSH/threaded working ? What
struck me (and let me some hope) is that the trouble appear with only one
thread running... So far it's not a thread compatibily bug, no ?

I haven't try yet to use exp_init, but I am not sure what FILEHANDLE I am
suppose to feed it with. Is there a way to get a filehandle from a ssh
conection in Perl ?

Thank  you very much for your help.
Jerome
-- 
View this message in context: http://www.nabble.com/Trouble-with-Expect-working-with-Threads-tf4062209.html#a11557709
Sent from the Perl - Expectperl-Discuss mailing list archive at Nabble.com.

Hi All,

I am using the Expect to give responses to the questions asked while
installation. Here is a problem I am facing.

This is the question I am expecting to be asked and I am waiting for the
same question
Do you want to start Veritas Storage Foundation for DB2 processes now?
[y,n,q] (y)

But, the problem is on some terminals the question appears as
Do you want to start Veritas Storage Foundation for DB2 processes now?
[y,n,q] (y)

or even as
Do you want to start Veritas Storage Foundation for
DB2 processes now? [y,n,q] (y)

How to handle such things? Please help.

Thanks and Regards,
Prasad.

On Wed, 2007-07-11 at 11:56 -0700, Austin Schutz wrote:
> On Wed, Jul 11, 2007 at 10:50:32AM -0500, Matt Zagrabelny wrote:
> > [...]
> >=20
> > > Does anybody knows why I'm getting this strange behavior ?
> >=20
> > Check the archives.
> >=20
> > From [1] comes:
> >=20
> > >>
> > While Expect is supposed to be reasonably threadsafe, IO-Tty is *not*,
> > that's where the problems come from. If you want to automate telnet,
> > using Net::Telnet with Expect should be possible under threads.
> > <<
> >=20
> > I have had issues getting expect to use a spawned Net::Telnet object as
> > well (which is "supposed to be" thread safe). After much gnashing of
> > teeth, i have given up on Expect and been using Net::Telnet alone; whic=
h
> > is disappointing, because Expect is much more powerful and elegant than
> > Net::Telnet, however many *many* hours were wasted trying to get them t=
o
> > work together across a diverse population of Cisco gear.
> >=20
>=20
> 	Have you tried using exp_init on a Net::Telnet object? That doesn't
> use IO::Tty.

Yes, and by in large it worked. However, there were some Cisco switches
that it did not work for. So... I emailed the list and a fellow gave me
some good advice and my problems were solved, so I thought. There were
still some anomalies that were not working correctly. So to recap:

* Expect worked with everything, but no threads

* Expect with Net::Telnet was threaded, but could not communicate to all
switches

* Expect with Net::Telnet plus trick from mailing list was able to
communicate to almost all switches, but not all

Hence...

I now use Net::Telnet by itself. It is not as elegant as Expect, but the
thread speedup is *awesome*.

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

On Wed, Jul 11, 2007 at 10:50:32AM -0500, Matt Zagrabelny wrote:
> [...]
> 
> > Does anybody knows why I'm getting this strange behavior ?
> 
> Check the archives.
> 
> From [1] comes:
> 
> >>
> While Expect is supposed to be reasonably threadsafe, IO-Tty is *not*,
> that's where the problems come from. If you want to automate telnet,
> using Net::Telnet with Expect should be possible under threads.
> <<
> 
> I have had issues getting expect to use a spawned Net::Telnet object as
> well (which is "supposed to be" thread safe). After much gnashing of
> teeth, i have given up on Expect and been using Net::Telnet alone; which
> is disappointing, because Expect is much more powerful and elegant than
> Net::Telnet, however many *many* hours were wasted trying to get them to
> work together across a diverse population of Cisco gear.
> 

	Have you tried using exp_init on a Net::Telnet object? That doesn't
use IO::Tty.

	Austin

[...]

> Does anybody knows why I'm getting this strange behavior ?

Check the archives.

=46rom [1] comes:

>>
While Expect is supposed to be reasonably threadsafe, IO-Tty is *not*,
that's where the problems come from. If you want to automate telnet,
using Net::Telnet with Expect should be possible under threads.
<<

I have had issues getting expect to use a spawned Net::Telnet object as
well (which is "supposed to be" thread safe). After much gnashing of
teeth, i have given up on Expect and been using Net::Telnet alone; which
is disappointing, because Expect is much more powerful and elegant than
Net::Telnet, however many *many* hours were wasted trying to get them to
work together across a diverse population of Cisco gear.

[1]

http://sourceforge.net/mailarchive/message.php?msg_id=3D3DE0EEDC.7060703%
40cpan.org

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

Hi,

I spent few days on this one, but couldn't get it working...

I am working under sunOS
bt1wxxxx#uname -a
SunOS bt1wxxxx 5.6 Generic_105181-23 sun4u sparc SUNW,Ultra-60

I can run the following script without any problem :

#!/usr/bin/perl
use strict;
use Expect;
my $exp = Expect->new;
$exp->raw_pty(1);
my $test = $exp->spawn('/usr/local/bin/ssh', -l => 'my_user', 'my_host') or
die "Cannot spawn command: $!\n";
my @test1 = $exp->expect(5,'-re','password:');
$exp->clear_accum();
my @test2 = $exp->send("my_pass\r\n");
my @test3 = $exp->expect(15,'-re','my_host');
my @test4 = $exp->send("sh privilege\r\n");

The last command is exectuted successfuly.

But if I try this : 

#!/usr/bin/perl
use strict;
use Expect;
use threads;
use threads::shared;
use Thread::Queue::Any;

my $thread = threads->new(\&threadJob,); 
$thread->join;

sub threadJob{
    my $exp = Expect->new;
    $exp->raw_pty(1);
    my $test = $exp->spawn('/usr/local/bin/ssh', -l => 'my_user', 'my_host')
or die "Cannot spawn command: $!\n";
    my @test1 = $exp->expect(5,'-re','password:');
    $exp->clear_accum();
    my @test2 = $exp->send("my_pass\r\n");
    my @test3 = $exp->expect(15,'-re','my_host');
    my @test4 = $exp->send("sh privilege\r\n");# On envoie le mdp   
	}

I actually get connected, but Expect don't interact anymore with ssh after
the logging. Instead, I can access the box, I telneted from STDIN ...

Does anybody knows why I'm getting this strange behavior ?

Btw, when I close the conection, the script finishes to run peacefully.

-- 
View this message in context: http://www.nabble.com/Trouble-with-Expect-working-with-Threads-tf4062209.html#a11541250
Sent from the Perl - Expectperl-Discuss mailing list archive at Nabble.com.

Hi,
   
  When I try to run a test script under windows cygwin environment, I got the following error:
   
  $ ./t193.pl
Can't load '/usr/bin/Tty' for module IO::Tty: No such file or directory at /usr/lib/perl5/5.8/cygwin
/DynaLoader.pm line 230.
 at /usr/lib/perl5/5.8/IO/Tty.pm line 30
Compilation failed in require at /usr/lib/perl5/5.8/IO/Pty.pm line 7.
BEGIN failed--compilation aborted at /usr/lib/perl5/5.8/IO/Pty.pm line 7.
Compilation failed in require at /usr/lib/perl5/5.8/Expect.pm line 22.
BEGIN failed--compilation aborted at /usr/lib/perl5/5.8/Expect.pm line 22.
Compilation failed in require at ./t193.pl line 8.
BEGIN failed--compilation aborted at ./t193.pl line 8.
   
  I check under /usr/bin and there is a tty.exe file:
  $ ls /usr/bin/tty.exe
/usr/bin/tty.exe
   
  Any help is appreciated.
   
  Sherry

       
---------------------------------
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.

Hi all,

I encoutered a problem using Expect version 1.20 but did not find any
information in the mailing list

The following code should display "failed" (the password is incorrect and
Net::SSH::Expect::connect method raised an exception) but displays
"succeeded"

################################

use strict;
use Net::SSH::Expect;

sub test
{
    my $ssh;
    $ssh = Net::SSH::Expect->new(host => 'my_machine',
                 prompt => 'my_prompt',
                 password => 'wrong_password',
                 user => 'titouan',
                 timeout => 4);
    $ssh->connect();
}

eval {
    test();
};
if ($@){
    print "failed\n";
}
else {
    print "succeeded\n";
}

################################


If I modify the code (by declaring the $ssh variable out of the test
function), the code displays failed
################################

use strict;
use Net::SSH::Expect;

my $ssh;

sub test
{
   $ssh = Net::SSH::Expect->new(host => 'my_machine',
                 prompt => 'my_prompt',
                 password => 'wrong_password',
                 user => 'titouan',
                 timeout => 4);
    $ssh->connect();
}

eval {
    test();
};
if ($@){
    print "failed\n";
}
else {
    print "succeeded\n";
}

################################

I tried to understand what happened in the first case
If I use the debugger, the $@ is correctly set with the Net::SSH::Expect
module, but when ssh variable is out of scope, the perl interpeter call the
Expect::DESTROY function. This last function undef $@ (when calling
$self->hard_close())

Is this a bug in Expect module ?
How can I prevent this behavior ?

Thanks

Austin Schutz wrote:
> 
>> This is a tool I'd like to interrupt.
>> 
>> $session->send("\cC") does not work, I suppose because the tool is not
>> waiting for input.
>> 
> 
> 	It should work anyway unless you have tweaked your term settings
> interrupt character. $session->slave->stty('intr', "\cC") should do it.
> 
> 
> 	Austin
> 

Thanks for advice, I'll try to understand it better (it di dnot work as I
expected). Actually, Ken's suggestion solved my problem.
-- 
View this message in context: http://www.nabble.com/Is-it-possible-to-interrupt-spawned-session-%28like-Ctrl-C%29-tf4028111.html#a11470791
Sent from the Perl - Expectperl-Discuss mailing list archive at Nabble.com.

Bruno Negrao-3 wrote:
> 
> Why don't you add a signal handler to your perl script that when it
> receives the CTRL-C
> it calls the
> 
>  $exp->hard_close();
> 
> on the spawned expect object?
> 
> regards,
> 
> bruno
> 
> 
Thanks for your response, but the situation is a bit different.
I'm testing someone's tool. I can't modify it. I actually need to kill some
of its sub-processes.
Ken's suggestion works fine.

-- 
View this message in context: http://www.nabble.com/Is-it-possible-to-interrupt-spawned-session-%28like-Ctrl-C%29-tf4028111.html#a11470788
Sent from the Perl - Expectperl-Discuss mailing list archive at Nabble.com.

Ken Irving wrote:
> 
> On Thu, Jul 05, 2007 at 12:26:20AM -0700, markgo wrote:
>> 
>> Hi,
>> 
>> In some script I'm sending the command that runs some tool that could
>> only
>> be stopped by pressing Ctrl-C. It does not wait for any input. Is there
>> any
>> way to simulate this Ctrl-C (that is SIGINT) except closing the session?
> Why not just send the signal directly to the process:
> 
>    kill SIGINT $tool_pid;
> 
> Ken
> 
> 

Indeed! Silly me. The tool printed out "press Ctrl-C" and I tried to send
Ctrl-C.
Thank you Ken, of course it works that way.
-- 
View this message in context: http://www.nabble.com/Is-it-possible-to-interrupt-spawned-session-%28like-Ctrl-C%29-tf4028111.html#a11470738
Sent from the Perl - Expectperl-Discuss mailing list archive at Nabble.com.