autoexpect - generate an Expect script from watching a session

Author

       Don Libes, National Institute of Standards and Technology

       expect and autoexpect are in the public domain.  NIST and I would appreciate credit if these programs  or
       parts of them are used.

                                                  30 June 1995                                     AUTOEXPECT(1)

Introduction

autoexpect watches you interacting with another program and creates an Expect script that reproduces your
interactions. For straightline scripts, autoexpect saves substantial time over writing scripts by hand.
Even if you are an Expect expert, you will find it convenient to use autoexpect to automate the more
mindless parts of interactions. It is much easier to cut/paste hunks of autoexpect scripts together than
to write them from scratch. And if you are a beginner, you may be able to get away with learning nothing
more about Expect than how to call autoexpect.

The simplest way to use autoexpect is to call it from the command line with no arguments. For example:

% autoexpect

By default, autoexpect spawns a shell for you. Given a program name and arguments, autoexpect spawns
that program. For example:

% autoexpect ftp ftp.cme.nist.gov

Once your spawned program is running, interact normally. When you have exited the shell (or program that
you specified), autoexpect will create a new script for you. By default, autoexpect writes the new
script to "script.exp". You can override this with the -f flag followed by a new script name.

The following example runs "ftp ftp.cme.nist.gov" and stores the resulting Expect script in the file
"nist".

% autoexpect -f nist ftp ftp.cme.nist.gov

It is important to understand that autoexpect does not guarantee a working script because it necessarily
has to guess about certain things – and occasionally it guesses wrong. However, it is usually very easy
to identify and fix these problems. The typical problems are:

• Timing. A surprisingly large number of programs (rn, ksh, zsh, telnet, etc.) and devices
(e.g., modems) ignore keystrokes that arrive "too quickly" after prompts. If you find your
new script hanging up at one spot, try adding a short sleep just before the previous send.

You can force this behavior throughout by overriding the variable "force_conservative" near
the beginning of the generated script. This "conservative" mode makes autoexpect
automatically pause briefly (one tenth of a second) before sending each character. This
pacifies every program I know of.

This conservative mode is useful if you just want to quickly reassure yourself that the
problem is a timing one (or if you really don't care about how fast the script runs). This
same mode can be forced before script generation by using the -c flag.

Fortunately, these timing spots are rare. For example, telnet ignores characters only after
entering its escape sequence. Modems only ignore characters immediately after connecting to
them for the first time. A few programs exhibit this behavior all the time but typically have
a switch to disable it. For example, rn's -T flag disables this behavior.

The following example starts autoexpect in conservative mode.

autoexpect -c

The -C flag defines a key to toggle conservative mode. The following example starts
autoexpect (in non-conservative mode) with ^L as the toggle. (Note that the ^L is entered
literally – i.e., enter a real control-L).

autoexpect -C ^L

The following example starts autoexpect in conservative mode with ^L as the toggle.

autoexpect -c -C ^L

• Echoing. Many program echo characters. For example, if you type "more" to a shell, what
autoexpect actually sees is:

you typed 'm',
computer typed 'm',
you typed 'o',
computer typed 'o',
you typed 'r',
computer typed 'r',
...

Without specific knowledge of the program, it is impossible to know if you are waiting to see
each character echoed before typing the next. If autoexpect sees characters being echoed, it
assumes that it can send them all as a group rather than interleaving them the way they
originally appeared. This makes the script more pleasant to read. However, it could
conceivably be incorrect if you really had to wait to see each character echoed.

• Change. Autoexpect records every character from the interaction in the script. This is
desirable because it gives you the ability to make judgements about what is important and what
can be replaced with a pattern match.

On the other hand, if you use commands whose output differs from run to run, the generated
scripts are not going to be correct. For example, the "date" command always produces
different output. So using the date command while running autoexpect is a sure way to produce
a script that will require editing in order for it to work.

The -p flag puts autoexpect into "prompt mode". In this mode, autoexpect will only look for
the last line of program output - which is usually the prompt. This handles the date problem
(see above) and most others.

The following example starts autoexpect in prompt mode.

autoexpect -p

The -P flag defines a key to toggle prompt mode. The following example starts autoexpect (in
non-prompt mode) with ^P as the toggle. Note that the ^P is entered literally – i.e., enter a
real control-P.

autoexpect -P ^P

The following example starts autoexpect in prompt mode with ^P as the toggle.

autoexpect -p -P ^P

Name

       autoexpect - generate an Expect script from watching a session

Other Flags

       The -quiet flag disables informational messages produced by autoexpect.

       The -Q flag names a quote character which can be used to enter characters that autoexpect would otherwise
       consume because they are used as toggles.

       The following example shows a number of flags with quote used to provide a way of  entering  the  toggles
       literally.

            autoexpect -P ^P -C ^L -Q ^Q

Style

       I don't know if there is a "style" for Expect programs but autoexpect should definitely not be held up as
       any  model  of style.  For example, autoexpect uses features of Expect that are intended specifically for
       computer-generated scripting.  So don't try to faithfully write scripts  that  appear  as  if  they  were
       generated by autoexpect.  This is not useful.

       On  the  other hand, autoexpect scripts do show some worthwhile things.  For example, you can see how any
       string must be quoted in order to use  it  in  a  Tcl  script  simply  by  running  the  strings  through
       autoexpect.