|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
|
|
Expect.pm is built to either spawn a process or take an existing filehandle and interact with it such that normally interactive tasks can be done without operator assistance. This is a really great tool that can help to automate many mundane tasks. Please note that there are better alternatives to such common tasks as automation of telnet and SSH logins:
To install expect.pm (the latest version on CPAN is 1.21 dated Jul 20, 2006) you need to install IO::Tty first . There is also a Bundle::Expect available that installs everything for you. Here is a quote from README file
Expect requires the latest version of IO::Tty, also available from CPAN. IO::Stty has become optional but I'd suggest you also install it. If you use the highly recommended CPAN module, there is a Bundle::Expect available that installs everything for you.
If you prefer manual installation, the usual
perl Makefile.PL make make test make installshould work.
Note that IO::Tty is very system-dependent. It has been extensively reworked and tested, but there still may be systems that have problems.
Please be sure to read the FAQ section in the Expect pod manpage, especially the section about using Expect to control telnet/ssh etc.
There are other ways to work around password entry, you definitely don't need Expect for SSH automatisation!
The Perl Expect module was inspired more by the functionality of Tcl/Expect than any previous Expect-like tool such as Comm.pl or chat2.pl.
|
|
The Expect for Perl module was inspired more by the functionality the Tcl tool provides than any previous Expect-like tool such as Comm.pl or chat2.pl. I've had some comments that people may not have heard of the original Tcl version of Expect, or where documentation (book form) on Expect may be obtained. Here is the relevant "Recipe of the Day from The Perl Cookbook by Tom Christiansen and Nathan Torkington published by perl.com:
Each day, www.perl.com brings you one recipe from O'Reilly's The Perl Cookbook. If you prefer a digital version, a fully indexed, searchable HTML version of the Perl Cookbook is one of six O'Reilly Perl books in HTML format that are included in The Perl CD Bookshelf. If you like what you see, please purchase a copy of either the book or CD using the links to the right. (Please note that cross-references to other recipes in the book have been disabled on this page, but are fully functional in the CD version.)
Controlling Another Program with Expect Problem
You want to automate interaction with a full-screen program that expects to have a terminal behind STDIN and STDOUT.Solution
Use the Expect module from CPAN:use Expect; $command = Expect->spawn("program to run") or die "Couldn't start program: $!\n"; $command->log_stdout(0); unless ($command->expect(10, "Password")) { # timed out } unless ($command->expect(20, -re => '[lL]ogin: ?')) { # timed out } unless ($command->expect(undef, "invalid")) { # error occurred; the program probably went away } print $command "Hello, world\r"; $command->soft_close(); $command->hard_close();This module requires two other modules from CPAN: IO::Pty and IO::Stty. It sets up a pseudo-terminal to interact with programs that insist on using talking to the terminal device driver. People often use this for talking to passwd to change passwords. telnet (Net::Telnet, described in Recipe 18.6 , is probably more suitable and portable) and ftp are also programs that expect a real tty.
Start the program you want to run with
Expect->spawn, passing a program name and arguments either in a single string or as a list. Expect starts the program and returns an object representing that program, orundefif the program couldn't be started.To wait for the program to emit a particular string, use the
expectmethod. Its first argument is the number of seconds to wait for the string, orundefto wait forever. To wait for a string, give that string as the second argument toexpect. To wait for a regular expression, give"-re"as the second argument and a string containing the pattern as the third argument. You can give further strings or patterns to wait for:$which = $command->expect(30, "invalid", "succes", "error", "boom"); if ($which) { # found one of those strings }In scalar context,
expectreturns the number of arguments it matched. In the example above,expectwould return 1 if the program emitted"invalid", 2 if it emitted"succes", and so on. If none of the patterns or strings matches,expectreturns false.In list context,
expectreturns a five-element list. The first element is the number of the pattern or string that matched, the same as its return value in scalar context. The second argument is a string indicating whyexpectreturned. If there were no error, the second argument will beundef. Possible errors are"1:TIMEOUT","2:EOF","3:spawnid(...)died"and"4:...". (See the Expect (3) manpage for the precise meaning of these messages.) The third argument ofexpect's return list is the string matched. The fourth argument is text before the match, and the fifth argument is text after the match.Sending input to the program you're controlling with Expect is as simple as using
"\n"isn't taking place. We recommend trying"\r"at first. If that doesn't work, try"\n"and"\r\n".When you're finished with the spawned program, you have three options. One, you can continue with your main program, and the spawned program will be forcibly killed when the main program ends. This will accumulate processes, though. Two, if you know the spawned program will terminate normally either when it has finished sending you output or because you told it to stop - for example, telnet after you exit the remote shell - call the
soft_closemethod. If the spawned program could continue forever, like tail -f , then use thehard_closemethod; this kills the spawned program.The documentation for the Expect, IO::Pty, and IO::Stty modules from CPAN; Exploring Expect , by Don Libes, O'Reilly & Associates (1995).
The original implementation of expect was done in Tcl by Don Libes ([email protected]). The Tcl Expect home page is http://expect.nist.gov/. Don has written an excellent in-depth tutorial of the Tcl Expect, which is Exploring Expect. It is the O'Reilly book with the monkey on the front.
Exploring Expect A Tcl-Based Toolkit for Automating Interactive Programs (Nutshell Handbook)
by Don Libes
Price: $23.39
Paperback - 602 pages (December 1994)
Here is one of Amezon's customers reviews:
Steve WainsteadA completely different tool July 17, 2000Expect is completely unlike any other tool I have ever used. Think of any language you've used and how long it would take to: write a program that can update 1000 user passwords on 20 different machines; make two chess programs play each other; connect two users to the same shell program and type at the same time; allow you to rewrite the command arguments to any command line tool?
Expect really does make all these things trivial. It takes a lot of patience to master this tool though; Tcl is a very unforgiving and terse language. I've done things in Expect that I never thought were possible: I scripted Minicom (a modem term program that uses ncurses) to answer a phone after 7 seconds, and either: receive a zmodem file or send a login prompt. Then hang up the modem and wait again. Try that in a shell or systems language!
It's unfortunate that Expect is such a radically different beast and takes so long to understand; every person running regression tests or doing systems administration will benefit from this book. While it may not be great for just "looking up" things, search Usenet for all of the author's posts (comp.lang.tcl) and his answer is almost always, "This is on page XXX of the book." Because the book really does cover everything Expect does!
Don has several references on the Expect - Home Page web page. Here is a short history of Expect:
Expect was conceived of in September, 1987. The bulk of version 2 was designed and written between January and April, 1990. Minor evolution occurred after that until Tcl 6.0 was released. At that time (October, 1991) approximately half of Expect was rewritten for version 3. See the HISTORY file for more information. The HISTORY file is included with the Expect distribution.
Around January 1993, an alpha version of Expect 4 was introduced. This included Tk support as well as a large number of enhancements. A few changes were made to the user interface itself, which is why the major version number was changed. A production version of Expect 4 was released in August 1993.
In October 1993, an alpha version of Expect 5 was released to match Tcl 7.0. A large number of enhancements were made, including some changes to the user interface itself, which is why the major version number was changed (again). The production version of Expect 5 was released in March '94.
In the summer of 1999, substantial rewriting of Expect was done in order to support Tcl 8.2. (Expect was never ported to 8.1 as it contained fundamental deficiencies.) This included the creation of an exp-channel driver and object support in order to take advantage of the new regexp engine and UTF/Unicode. The user interface is highly but not entirely backward compatible. See the NEWS file in the distribution for more detail.
There are important differences between Expect 3, 4, and 5. See the CHANGES.* files in the distribution if you want to read about the differences. Expect 5.30 and earlier versions have ceased development and are not supported. However, the old code is available from http://expect.nist.gov/old.
The Expect book became available in January '95. It describes Expect 5 as it is today, rather than how Expect 5 was when it was originally released. Thus, if you have not upgraded Expect since before getting the book, you should upgrade now.
Historical notes on Tcl and Tk according to John Ousterhout
I got the idea for Tcl while on sabbatical leave at DEC's Western Research Laboratory in the fall of 1987. I started actually implementing it when I got back to Berkeley in the spring of 1988; by summer of that year it was in use in some internal applications of ours, but there was no Tk. The first external releases of Tcl were in 1989, I believe. I started implementing Tk in 1989, and the first release of Tk was in 1991.
Among other things Don Libes home page contains rscript 1.0 which is based upon Expect/Tcl and allows you to automate remote logins and execute remote commands, somewhat like rsh.
The site also contains many valuable examples. Among them are multixterm, kibitz, rftp (recursive ftp), passmass, autoexpect. Here are man pages for some of the examples:
There are many interesting papers about expect. Among them:
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
Expect (1.21)
This is a great module for manipulating a console application programmatically. It is useful for testing, automation and many other uses. Highly recommended.Shlomi Fish - 2008-08-30T12:39:08
Was this review helpful to you? Yes No5 out of 5 found this review helpful:
Expect (1.21)
I had to test over 200 legacy shell script when we converted them to use a more secure method for database connections. Without this module I could have never done such a thorough job of testing and making sure that everything ran correctly.I went through several iterations of my testing module and Expect was able to do whatever I needed. I created a driver file with all of the parameters needed to run each script and created a script to read the driver file and start, and then monitor each script for completion. The regular expressions available in pattern matching allowed me to cycle through repeatedly and watch for the completion messages of scripts. I was also able to monitor for signals indicating completion of scripts without completion messages. Expect was able to give all of the information I needed about each process, as well as logging all inputs and outputs of each script to both a master log and individual logs for each script.
Seth Fuller - 2008-08-15T07:53:35
Was this review helpful to you? Yes No5 out of 6 found this review helpful:
Expect (1.15)
I have used this module for about 7 years or so and I have little trouble with it. Both Austin and Roland have been very responsive to any issues that have been raised on the SF mailing list. They've taken care in how they're extended the interface, and the extensions have imporved the maintainability of the programs that I've written using Expect.And the best part is that I can avoid Tcl completely.
Mark Rogaski - 2005-11-01T14:22:05
Was this review helpful to you? Yes No2 out of 5 found this review helpful:
Expect (1.15)
This version builds on AIX 5.2.0.0, but it hangs up on the first test, which is a simple spawn of the perl -v command. I have communicated with the author about this problem and am hoping for a resolution.This is how it hangs up:
make test
PERL_DL_NONLAZY=1 /pcom/perl/perl-5.8.4/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl
1..36
Basic tests...
If you look at test.pl, you'll see that it's hanging up at this line:
my $exp = Expect->spawn("$Perl -v");
I debugged the module and found that it is hanging up at line 124 in
Expect.pm. This is the line of code:my $errstatus = sysread(STAT_RDR, $errno, 256);
I have seen other complaints about either test failures or hang ups
on bulletin boards. It seems a lot of people are having this problem, and not just on AIX.
|
|
|
An unreliable program can be controlled from a perl program using the Expect.pm module. A description of the unreliable program and the use of the Expect module is presented.I have a program that I need to run a large number of times. This program has a nasty bug in it. When you feed it bad data, it just sits there forever instead of providing a helpful error message. Bad Program!
I can't change the program, but I need to call this program inside a loop in my code. So I am using the perl Expect module to skip over the problem cases and continue with the rest of the runs of the program.
The Expect.pm module is capable of managing this process, so I wrote a few little test programs to help me understand how to accomplish this task. This document includes the tests along with a few words of explanation. For more documentation about the Expect module, search CPAN.
An Unreliable Program
Instead of using my real-world unreliable program, I used this program to simulate it instead. When it succeeds, this program just prints a simple message. When it fails, it just hangs. This matches the behavior of the program that I need to control.#!/usr/bin/perl # # Fri Dec 13 23:10:54 PST 2002 # # Copyright Tom Anderson 2002, All rights reserved. # This program may be copied under the same terms as Perl itself. # Please send modifications to [email protected] # # # unreliable.pl - Simulate a program that sometimes just hangs # my $VERSION=".01"; use strict; use warnings; use diagnostics; if (rand(10) > 8) { sleep 1 while 1 > 0; } else { print "--------------------------------\n", "It worked this time, no problems\n", "--------------------------------\n"; }Expect.pm Test Program One
The following test program runs the unreliable program twenty times. If the unreliable program takes longer than five seconds, the attempt to run it is terminated and the test program continues.#!/usr/bin/perl # # Fri Dec 13 23:10:54 PST 2002 # # Copyright Tom Anderson 2002, All rights reserved. # This program may be copied under the same terms as Perl itself. # Please send modifications to [email protected] # # timeout.pl - Expect Test Program # use strict; use warnings; use diagnostics; use Expect; my $timeout=5; foreach my $i (1..20) { my $exp = Expect->spawn("./unreliable.pl") or die "Cannot spawn unreliable process $!\n"; $exp->expect($timeout); }Expect.pm Test Program Two
The next version of the test program adds the feature that a message is printed for the cases when a timeout occurs.#!/usr/bin/perl # # Fri Dec 13 23:10:54 PST 2002 # # Copyright Tom Anderson 2002, All rights reserved. # This program may be copied under the same terms as Perl itself. # Please send modifications to [email protected] # # timemsg.pl - Expect Test Program # use strict; use warnings; use diagnostics; use Expect; my $timeout=5; foreach my $i (1..20) { my $exp = Expect->spawn("./unreliable.pl") or die "Cannot spawn unreliable process $!\n"; $exp->expect($timeout, [ timeout => sub { print "Process timed out.\n"; } ] ); }Expect.pm Test Program Three
The next version of the test program adds a check to see if the unreliable program prints "It worked" somewhere in its output. If the test program detects this string, it prints "Status: OK" after the unreliable program runs.#!/usr/bin/perl # # Fri Dec 13 23:10:54 PST 2002 # # Copyright Tom Anderson 2002, All rights reserved. # This program may be copied under the same terms as Perl itself. # Please send modifications to [email protected] # # timecheck.pl - Expect Test Program # my $VERSION=".01"; use strict; use warnings; use diagnostics; use Expect; my $timeout=5; foreach my $i (1..20) { my $spawn_ok="not OK"; my $exp = Expect->spawn("./unreliable.pl") or die "Cannot spawn unreliable process $!\n"; $exp->expect($timeout, [ 'It worked', sub { $spawn_ok = "OK"; exp_continue; } ], [ timeout => sub { print "Process timed out.\n"; } ] ); print "Status: $spawn_ok\n"; }
|
|
|
... it seems to me that this can easily be achieved with a korn/expect script. You can use expect to automate dialogs such as logins and sending a series of commands to another host. Windows NT and 2000 support telnet, so you should be able to easily automate ftp'ing your file, telnetting to the NT box, issuing your commands to process your file, then ftp'ing the file back to your unix box.
I'm not going to write the whole thing for you, but I'll post a simple, quick login dialog so you can get a feeling of what expect does:
#!/usr/local/bin/expect --spawn telnet NTserver
expect login:
send ntuser\r
expect password:
send mypasswd\r
expect "c:\>"
send "java -Dmyenv.variable myApp\r"
expect "c:\>"
send "ftp 172.10.10.10\r"
expect login
send unix_user\r
expect password:
send mypassword\r
expect ftp:>
send "put my_resulting_file\r"
expect ftp:>
send exit\r
expect "c:\>"
send exit\r
expect close
exit 0You can get expect at sunfreeware.com.
Oh, and you would need to change the authorization method to login in the NT server, which uses NTLM authentication..
Google matched content |
Download:
Expect-1.21.tar.gz
Expect.pm - Expect for Perl
1.21
use Expect;
# create an Expect object by spawning another process
my $exp = Expect->spawn($command, @params)
or die "Cannot spawn $command: $!\n";
# or by using an already opened filehandle (e.g. from Net::Telnet)
my $exp = Expect->exp_init(\*FILEHANDLE);
# if you prefer the OO mindset:
my $exp = new Expect;
$exp->raw_pty(1);
$exp->spawn($command, @parameters)
or die "Cannot spawn $command: $!\n";
# send some string there:
$exp->send("string\n");
# or, for the filehandle mindset:
print $exp "string\n";
# then do some pattern matching with either the simple interface
$patidx = $exp->expect($timeout, @match_patterns);
# or multi-match on several spawned commands with callbacks,
# just like the Tcl version
$exp->expect($timeout,
[ qr/regex1/ => sub { my $exp = shift;
$exp->send("response\n");
exp_continue; } ],
[ "regexp2" , \&callback, @cbparms ],
);
# if no longer needed, do a soft_close to nicely shut down the command
$exp->soft_close();
# or be less patient with
$exp->hard_close();
Expect.pm is built to either spawn a process or take an existing filehandle and interact with it such that normally interactive tasks can be done without operator assistance. This concept makes more sense if you are already familiar with the versatile Tcl version of Expect. The public functions that make up Expect.pm are:
Expect->new()
Expect::interconnect(@objects_to_be_read_from)
Expect::test_handles($timeout, @objects_to_test)
Expect::version($version_requested | undef);
$object->spawn(@command)
$object->clear_accum()
$object->set_accum($value)
$object->debug($debug_level)
$object->exp_internal(0 | 1)
$object->notransfer(0 | 1)
$object->raw_pty(0 | 1)
$object->stty(@stty_modes) # See the IO::Stty docs
$object->slave()
$object->before();
$object->match();
$object->after();
$object->matchlist();
$object->match_number();
$object->error();
$object->command();
$object->exitstatus();
$object->pty_handle();
$object->do_soft_close();
$object->restart_timeout_upon_receive(0 | 1);
$object->interact($other_object, $escape_sequence)
$object->log_group(0 | 1 | undef)
$object->log_user(0 | 1 | undef)
$object->log_file("filename" | $filehandle | \&coderef | undef)
$object->manual_stty(0 | 1 | undef)
$object->match_max($max_buffersize or undef)
$object->pid();
$object->send_slow($delay, @strings_to_send)
$object->set_group(@listen_group_objects | undef)
$object->set_seq($sequence,\&function,\@parameters);
There are several configurable package variables that affect the behavior of Expect. They are:
$Expect::Debug; $Expect::Exp_Internal; $Expect::IgnoreEintr; $Expect::Log_Group; $Expect::Log_Stdout; $Expect::Manual_Stty; $Expect::Multiline_Matching; $Expect::Do_Soft_Close;
The Expect module is a successor of Comm.pl and a descendent of Chat.pl. It more closely ressembles the Tcl Expect language than its predecessors. It does not contain any of the networking code found in Comm.pl. I suspect this would be obsolete anyway given the advent of IO::Socket and external tools such as netcat.
Expect.pm is an attempt to have more of a switch() & case feeling to make decision processing more fluid. Three separate types of debugging have been implemented to make code production easier.
It is possible to interconnect multiple file handles (and processes) much like Tcl's Expect. An attempt was made to enable all the features of Tcl's Expect without forcing Tcl on the victim programmer :-) .
Please, before you consider using Expect, read the FAQs about "I want to automate password entry for su/ssh/scp/rsh/..." and "I want to use Expect to automate [anything with a buzzword]..."
You can use only real filehandles, certain tied filehandles (e.g. Net::SSH2) that lack a fileno() will not work. Net::Telnet objects can be used but have been reported to work only for certain hosts. YMMV.
undef
if the fork was unsuccessful or the command could not be found. spawn() passes
its parameters unchanged to Perls exec(), so look there for detailed semantics.Note that if spawn cannot exec() the given command, the Expect object is still valid and the next expect() will see "Cannot exec", so you can use that for error handling.
Also note that you cannot reuse an object with an already spawned command, even if that command has exited. Sorry, but you have to allocate a new object...
The '3' setting is new with 1.05, and adds the additional functionality of having the _full_ accumulated buffer printed every time data is read from an Expect object. This was implemented by request. I recommend against using this unless you think you need it as it can create quite a quantity of output under some circumstances..
$object->slave->stty(qw(raw -echo));
Typical values are 'sane', 'raw', and 'raw -echo'. Note that I recommend setting the terminal to 'raw' or 'raw -echo', as this avoids a lot of hassle and gives pipe-like (i.e. transparent) behaviour (without the buffering issue).
expect($timeout,
'-i', [ $obj1, $obj2, ... ],
[ $re_pattern, sub { ...; exp_continue; }, @subparms, ],
[ 'eof', sub { ... } ],
[ 'timeout', sub { ... }, \$subparm1 ],
'-i', [ $objn, ...],
'-ex', $exact_pattern, sub { ... },
$exact_pattern, sub { ...; exp_continue_timeout; },
'-re', $re_pattern, sub { ... },
'-i', \@object_list, @pattern_list,
...);
Simple interface:
Given $timeout in seconds Expect will wait for $object's handle to produce one of the match_patterns, which are matched exactly by default. If you want a regexp match, prefix the pattern with '-re'.
Due to o/s limitations $timeout should be a round number. If $timeout is 0 Expect will check one time to see if $object's handle contains any of the match_patterns. If $timeout is undef Expect will wait forever for a pattern to match.
If called in a scalar context, expect() will return the position of the matched pattern within $match_patterns, or undef if no pattern was matched. This is a position starting from 1, so if you want to know which of an array of @matched_patterns matched you should subtract one from the return value.
If called in an array context expect() will return ($matched_pattern_position, $error, $successfully_matching_string, $before_match, and $after_match).
$matched_pattern_position will contain the value that would have been returned if expect() had been called in a scalar context. $error is the error that occurred that caused expect() to return. $error will contain a number followed by a string equivalent expressing the nature of the error. Possible values are undef, indicating no error, '1:TIMEOUT' indicating that $timeout seconds had elapsed without a match, '2:EOF' indicating an eof was read from $object, '3: spawn id($fileno) died' indicating that the process exited before matching and '4:$!' indicating whatever error was set in $ERRNO during the last read on $object's handle or during select(). All handles indicated by set_group plus STDOUT will have all data to come out of $object printed to them during expect() if log_group and log_stdout are set.
Changed from older versions is the regular expression handling. By default now all strings passed to expect() are treated as literals. To match a regular expression pass '-re' as a parameter in front of the pattern you want to match as a regexp.
Example:
$object->expect(15, 'match me exactly','-re','match\s+me\s+exactly');
This change makes it possible to match literals and regular expressions in the same expect() call.
Also new is multiline matching. ^ will now match the beginning of lines. Unfortunately, because perl doesn't use $/ in determining where lines break using $ to find the end of a line frequently doesn't work. This is because your terminal is returning "\r\n" at the end of every line. One way to check for a pattern at the end of a line would be to use \r?$ instead of $.
Example: Spawning telnet to a host, you might look for the escape character. telnet would return to you "\r\nEscape character is '^]'.\r\n". To find this you might use $match='^Escape char.*\.\r?$';
$telnet->expect(10,'-re',$match);
New more Tcl/Expect-like interface:
It's now possible to expect on more than one connection at a time by specifying
'-i' and a single Expect object or a ref to an array containing
Expect objects, e.g.
expect($timeout,
'-i', $exp1, @patterns_1,
'-i', [ $exp2, $exp3 ], @patterns_2_3,
)
Furthermore, patterns can now be specified as array refs containing [$regexp, sub { ...}, @optional_subprams] . When the pattern matches, the subroutine is called with parameters ($matched_expect_obj, @optional_subparms). The subroutine can return the symbol `exp_continue' to continue the expect matching with timeout starting anew or return the symbol `exp_continue_timeout' for continuing expect without resetting the timeout count.
$exp->expect($timeout,
[ qr/username: /i, sub { my $self = shift;
$self->send("$username\n");
exp_continue; }],
[ qr/password: /i, sub { my $self = shift;
$self->send("$password\n");
exp_continue; }],
$shell_prompt);
`expect' is now exported by default.
Note that this is something different than Tcl Expects before()!!
$exp->restart_timeout_upon_receive(1);
$exp->expect($timeout,
[ timeout => \&report_timeout ],
[ qr/pattern/ => \&handle_pattern],
);
Now the timeout isn't triggered if the command produces any kind of output, i.e. is still alive, but you can act upon patterns in the output.
$exp->set_accum($exp->after);
to their callback, e.g.
$exp->notransfer(1);
$exp->expect($timeout,
# accumulator not truncated, pattern1 will match again
[ "pattern1" => sub { my $self = shift;
...
} ],
# accumulator truncated, pattern2 will not match again
[ "pattern2" => sub { my $self = shift;
...
$self->set_accum($self->after());
} ],
);
This is only a temporary fix until I can rewrite the pattern matching part so it can take that additional -notransfer argument.
For a generic way to interconnect processes, take a look at IPC::Run.
\*FILEHANDLE, $escape_sequence)
Expect::interconnect($object , ...).
Default value is on. During creation of $object the setting will match the value
of $Expect::Log_Group, normally 1. $object->log_file("filename", "w");
Returns the logfilehandle.
If called with an undef value, stops logging and closes logfile:
$object->log_file(undef);
If called without argument, returns the logfilehandle:
$fh = $object->log_file();
Can be set to a code ref, which will be called instead of printing to the logfile:
$object->log_file(\&myloggerfunc);
Defaults to 1. Affects whether or not expect() uses the /m flag for
doing regular expression matching. If set to 1 /m is used.
This makes a difference when you are trying to match ^ and $. If
you have this on you can match lines in the middle of a page of output
using ^ and $ instead of it matching the beginning and end of the entire
expression. I think this is handy.
Lee Eakin <[email protected]> has ported the kibitz script from Tcl/Expect to Perl/Expect.
Jeff Carr <[email protected]> provided a simple example of how handle terminal window resize events (transmitted via the WINCH signal) in a ssh session.
You can find both scripts in the examples/ subdir. Thanks to both!
Historical notes:
There are still a few lines of code dating back to the inspirational Comm.pl and Chat.pl modules without which this would not have been possible. Kudos to Eric Arnold <[email protected]> and Randal 'Nuke your NT box with one line of perl code' Schwartz<[email protected]> for making these available to the perl public.
As of .98 I think all the old code is toast. No way could this have been done without it though. Special thanks to Graham Barr for helping make sense of the IO::Handle stuff as well as providing the highly recommended IO::Tty module.
Mark Rogaski <[email protected]> wrote:
"I figured that you'd like to know that Expect.pm has been very useful to AT&T Labs over the past couple of years (since I first talked to Austin about design decisions). We use Expect.pm for managing the switches in our network via the telnet interface, and such automation has significantly increased our reliability. So, you can honestly say that one of the largest digital networks in existence (AT&T Frame Relay) uses Expect.pm quite extensively."
This is a growing collection of things that might help. Please send you questions that are not answered here to [email protected]
Expect itself doesn't have real system dependencies, but the underlying IO::Tty needs pseudoterminals. IO::Stty uses POSIX.pm and Fcntl.pm.
I have used it on Solaris, Linux and AIX, others report *BSD and OSF as working. Generally, any modern POSIX Unix should do, but there are exceptions to every rule. Feedback is appreciated.
See IO::Tty for a list of verified systems.
Up to now, the answer was 'No', but this has changed.
You still cannot use ActivePerl, but if you use the Cygwin environment (http://sources.redhat.com), which brings its own perl, and have the latest IO::Tty (v0.05 or later) installed, it should work (feedback appreciated).
The tutorial is hopelessly out of date and needs a serious overhaul. I appologize for this, I have concentrated my efforts mainly on the functionality. Volunteers welcomed.
If you set
$Expect::Exp_Internal = 1;
Expect will tell you very verbosely what it is receiving and sending, what matching it is trying and what it found. You can do this on a per-command base with
$exp->exp_internal(1);
You can also set
$Expect::Debug = 1; # or 2, 3 for more verbose output
or
$exp->debug(1);
which gives you even more output.
Yes, just set
$Expect::Log_Stdout = 0;
to globally disable it or
$exp->log_stdout(0);
for just that command. 'log_user' is provided as an alias so Tcl/Expect user get a DWIM experience... :-)
This is caused by the pty, which has probably 'echo' enabled. A solution would
be to set the pty to raw mode, which in general is cleaner for communication between
two programs (no more unexpected character translations). Unfortunately this would
break a lot of old code that sends "\r" to the program instead of "\n" (translating
this is also handled by the pty), so I won't add this to Expect just like that.
But feel free to experiment with $exp->raw_pty(1).
A: You can send any characters to a process with the print command. To represent a control character in Perl, use \c followed by the letter. For example, control-G can be represented with "\cG" . Note that this will not work if you single-quote your string. So, to send control-C to a process in $exp, do:
print $exp "\cC";
Or, if you prefer:
$exp->send("\cC");
The ability to include control characters in a string like this is provided by Perl, not by Expect.pm . Trying to learn Expect.pm without a thorough grounding in Perl can be very daunting. We suggest you look into some of the excellent Perl learning material, such as the books _Programming Perl_ and _Learning Perl_ by O'Reilly, as well as the extensive online Perl documentation available through the perldoc command.
You could be exiting too fast without giving the spawned program enough time to finish. Try adding $exp->soft_close() to terminate the program gracefully or do an expect() for 'eof'.
Alternatively, try adding a 'sleep 1' after you spawn() the program. It could be that pty creation on your system is just slow (but this is rather improbable if you are using the latest IO-Tty).
You shouldn't use Expect for this. Putting passwords, especially root passwords, into scripts in clear text can mean severe security problems. I strongly recommend using other means. For 'su', consider switching to 'sudo', which gives you root access on a per-command and per-user basis without the need to enter passwords. 'ssh'/'scp' can be set up with RSA authentication without passwords. 'rsh' can use the .rhost mechanism, but I'd strongly suggest to switch to 'ssh'; to mention 'rsh' and 'security' in the same sentence makes an oxymoron.
It will work for 'telnet', though, and there are valid uses for it, but you still might want to consider using 'ssh', as keeping cleartext passwords around is very insecure.
Are you sure there is no other, easier way? As a rule of thumb, Expect is useful
for automating things that expect to talk to a human, where no formal standard applies.
For other tasks that do follow a well-defined protocol, there are often better-suited
modules that already can handle those protocols. Don't try to do HTTP requests by
spawning telnet to port 80, use LWP instead. To automate FTP, take a look at
Net::FTP
or ncftp (http://www.ncftp.org).
You don't use a screwdriver to hammer in your nails either, or do you?
Basically yes, with one restriction: you must spawn() your programs in the main thread and then pass the Expect objects to the handling threads. The reason is that spawn() uses fork(), and perlthrtut:
"Thinking of mixing fork() and threads? Please lie down and wait until the feeling passes."
Use
$exp->log_file("filename");
or
$exp->log_file($filehandle);
or even
$exp->log_file(\&log_procedure);
for maximum flexibility.
Note that the logfile is appended to by default, but you can specify an optional mode "w" to truncate the logfile:
$exp->log_file("filename", "w");
To stop logging, just call it with a false argument:
$exp->log_file(undef);
To globally unset multi-line matching for all regexps:
$Expect::Multiline_Matching = 0;
You can do that on a per-regexp basis by stating (?-m) inside the
regexp (you need perl5.00503 or later for that).
You can use the -i parameter to specify a single object or a list of Expect objects. All following patterns will be evaluated against that list.
You can specify -i multiple times to create groups of objects and patterns to match against within the same expect statement.
This works just like in Tcl/Expect.
See the source example below.
Well, pty handling is really a black magic, as it is extremely system dependend. I have extensively revised IO-Tty, so these problems should be gone.
If your system is listed in the "verified" list of IO::Tty, you probably have some non-standard setup, e.g. you compiled your Linux-kernel yourself and disabled ptys. Please ask your friendly sysadmin for help.
If your system is not listed, unpack the latest version of IO::Tty, do a 'perl
Makefile.PL; make; make test; uname -a' and send me the results and
I'll see what I can deduce from that.
[ Are you sure you need Expect for this? How about qx() or open("prog|")? ]
By using expect without any patterns to match.
$process->expect(undef); # Forever until EOF $process->expect($timeout); # For a few seconds $process->expect(0); # Is there anything ready on the handle now?
$read = $process->before();
Find it on CPAN as IO-Tty, which provides both.
What's happening is you are closing the handle before passwd exits. When you close the handle to a process, it is sent a signal (SIGPIPE?) telling it that STDOUT has gone away. The default behavior for processes is to die in this circumstance. Two ways you can make this not happen are:
$process->soft_close();
This will wait 15 seconds for a process to come up with an EOF by itself before killing it.
$process->expect(undef);
This will wait forever for the process to match an empty set of patterns. It will return when the process hits an EOF.
As a rule, you should always expect() the result of your transaction before you continue with processing.
Output is only printed to the logfile/group when Expect reads from the process, during expect(), send_slow() and interconnect(). One way you can force this is to make use of
$process->expect(undef);
and
$process->expect(0);
which will make expect() run with an empty pattern set forever or just for an instant to capture the output of $process. The output is available in the accumulator, so you can grab it using $process->before().
Tty settings are a major pain to keep track of. If you find unexpected behavior such as double-echoing or a frozen session, doublecheck the documentation for default settings. When in doubt, handle them yourself using $exp->stty() and manual_stty() functions. As of .98 you shouldn't have to worry about stty settings getting fouled unless you use interconnect or intentionally change them (like doing -echo to get a password).
If you foul up your terminal's tty settings, kill any hung processes and enter 'stty sane' at a shell prompt. This should make your terminal manageable again.
Note that IO::Tty returns ptys with your systems default setting regarding echoing, CRLF translation etc. and Expect does not change them. I have considered setting the ptys to 'raw' without any translation whatsoever, but this would break a lot of existing things, as '\r' translation would not work anymore. On the other hand, a raw pty works much like a pipe and is more WYGIWYE (what you get is what you expect), so I suggest you set it to 'raw' by yourself:
$exp = new Expect; $exp->raw_pty(1); $exp->spawn(...);
To disable echo:
$exp->slave->stty(qw(-echo));
You have to set the terminal screen size for that. Luckily, IO::Pty already has a method for that, so modify your code to look like this:
my $exp = new Expect;
$exp->slave->clone_winsize_from(\*STDIN);
$exp->spawn("telnet somehost);
Also, some applications need the TERM shell variable set so they know how to move the cursor across the screen. When logging in, the remote shell sends a query (Ctrl-Z I think) and expects the terminal to answer with a string, e.g. 'xterm'. If you really want to go that way (be aware, madness lies at its end), you can handle that and send back the value in $ENV{TERM}. This is only a hand-waving explanation, please figure out the details by yourself.
You have to catch the signal WINCH ("window size changed"), change the terminal size and propagate the signal to the spawned application:
my $exp = new Expect;
$exp->slave->clone_winsize_from(\*STDIN);
$exp->spawn("ssh somehost);
$SIG{WINCH} = \&winch;
sub winch {
$exp->slave->clone_winsize_from(\*STDIN);
kill WINCH => $exp->pid if $exp->pid;
$SIG{WINCH} = \&winch;
}
$exp->interact();
There is an example file ssh.pl in the examples/ subdir that shows how this works with ssh. Please note that I do strongly object against using Expect to automate ssh login, as there are better way to do that (see ssh-keygen).
That means you are anal-retentive. :-) [Gotcha there!]
The OS may not be configured to grant additional pty's (pseudo terminals) to non-root users. /usr/sbin/mkpts should be 4755, not 700 for this to work. I don't know about security implications if you do this.
You are probably on one of the systems where the master doesn't get an EOF when the slave closes stdin/out/err.
One possible solution is when you spawn a process, follow it with a unique string that would indicate the process is finished.
$process = Expect->spawn('telnet somehost; echo ____END____');
And then $process->expect($timeout,'____END____','other','patterns');
my $telnet = new Net::Telnet ("remotehost") # see Net::Telnet
or die "Cannot telnet to remotehost: $!\n";;
my $exp = Expect->exp_init($telnet);
# deprecated use of spawned telnet command
# my $exp = Expect->spawn("telnet localhost")
# or die "Cannot spawn telnet: $!\n";;
my $spawn_ok;
$exp->expect($timeout,
[
qr'login: $',
sub {
$spawn_ok = 1;
my $fh = shift;
$fh->send("$username\n");
exp_continue;
}
],
[
'Password: $',
sub {
my $fh = shift;
print $fh "$password\n";
exp_continue;
}
],
[
eof =>
sub {
if ($spawn_ok) {
die "ERROR: premature EOF in login.\n";
} else {
die "ERROR: could not spawn telnet.\n";
}
}
],
[
timeout =>
sub {
die "No login.\n";
}
],
'-re', qr'[#>:] $', #' wait for shell prompt, then exit expect
);
foreach my $cmd (@list_of_commands) {
push @commands, Expect->spawn($cmd);
}
expect($timeout,
'-i', \@commands,
[
qr"pattern", # find this pattern in output of all commands
sub {
my $obj = shift; # object that matched
print $obj "something\n";
exp_continue; # we don't want to terminate the expect call
}
],
'-i', $some_other_command,
[
"some other pattern",
sub {
my ($obj, $parmref) = @_;
# ...
# now we exit the expect command
},
\$parm
],
);
my $exp = new Expect;
$exp->slave->clone_winsize_from(\*STDIN);
$exp->spawn("ssh somehost);
$SIG{WINCH} = \&winch;
sub winch {
$exp->slave->clone_winsize_from(\*STDIN);
kill WINCH => $exp->pid if $exp->pid;
$SIG{WINCH} = \&winch;
}
$exp->interact();
http://sourceforge.net/projects/expectperl/
There are two mailing lists available, expectperl-announce and expectperl-discuss, at
http://lists.sourceforge.net/lists/listinfo/expectperl-announce
and
http://lists.sourceforge.net/lists/listinfo/expectperl-discuss
You can use the CPAN Request Tracker http://rt.cpan.org/ and submit new bugs under
http://rt.cpan.org/Ticket/Create.html?Queue=Expect
(c) 1997 Austin Schutz <[email protected]> (retired)
expect() interface & functionality enhancements (c) 1999-2006 Roland Giersig.
This module is now maintained by Roland Giersig <[email protected]>
This module can be used under the same terms as Perl.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
In other words: Use at your own risk. Provided as is. Your mileage may vary. Read the source, Luke!
And finally, just to be sure:
Any Use of This Product, in Any Manner Whatsoever, Will Increase the Amount of Disorder in the Universe. Although No Liability Is Implied Herein, the Consumer Is Warned That This Process Will Ultimately Lead to the Heat Death of the Universe.
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: February 19, 2014
