Tips and
Techniques: Simplifying the Debugging
of expect-lite scripts
Introduction
Over the years of using and improving expect-lite, a few debugging
techniques have proven quite useful. The purpose of the document is to
provide some additional information to assist the user of expect-lite
in debugging scripts, and tips to make expect-lite script writing even
easier. Familiarity with expect-lite is assumed, if not, please refer
to the expect-lite
documentation.
Contents
Some Tips and Techniques for expect-lite:
Interact
Setting a breakpoint, the easiest debugging aid to use
General Tips
Some rules of thumb when writing expect-lite scripts
Interact - setting breakpoints
Interact may be the
quickest, easiest, and overall best debugging aid. It is equivalent to
setting a breakpoint in the script. Interact is a mode
which turns control of the keyboard over to the user, so
that one may type directly to the process on the remote host With
version 3.5.0 there are two methods to invoke Interact: programmatic,
and instant-interact.
Programmatic Interact is called in the script with the following
command:
*INTERACT
Expect-lite will pause at this point in the script, and connect the
keyboard to the remote session (which may be at a prompt). Any command
may be entered and responses observed.
Typing '+++' (3 pluses) will return control to the script, and it will
continue. This is very helpful for automation assist, allowing the
script to perform complicated setup commands, before turning control
over to the user for an interactive session.
The other
method is instant-interact.
This feature no longer requires the tcl package Tclx to be installed.
The user can press '^\' (control+backslash) at anytime
creating a breakpoint on the fly. This is the easiest, and fastest way
to debug a script, dropping the user into the IDE.
Debugging
with the IDE
To make debugging of scripts even easier, both methods of interact
support the new and powerful expect-lite Integrated Debugger
Environment (IDE). Inside the IDE, it is possible to do many things:
Type command directly to the remote host (router, embedded
system, Linux box)
Step or sKip line by line through the expect-lite script
Show all expect-lite variables and constants
Show the most recently executed lines, or the next few
lines of the script
Paste
expect-lite script line(s) into the IDE and have them execute. This is
really cool, since it will dereference any variables in the pasted
text, or allow you to run just a few lines of script over and over
The IDE can't die, since *NOFAIL automatically enabled
while in the IDE.
Type expect-lite command directly while in the IDE,
including >, <, $var, +$var,@n (set timeout).
Stepping, sKipping and Showing
In
the above list, #1 is the same as previous versions of expect-lite.
Stepping, sKipping, and Showing are new in the IDE (#2, #3, #4). These
commands are all two-keystroke commands. The first key is the escape
key (or esc) followed by s, k, c, v, h and 0 through 9. These keys are
not echoed to the screen, nor are they received by the remote host. To
represent the key presses [type <esc>h] has been added to
the text for completeness.
[type <esc>h] IDE: Help Key Action ---- ------ <esc>s Step <esc>k sKip next step <esc>c Continue <esc>v show Vars <esc>0to9 Show N next lines of script <esc>-1to-9 Show N previous lines of script ctrl+D Quit & Exit expect-lite <esc>h this Help
Showing
the lines of the script running up to the breakpoint, the current line,
or the next few lines of the script can all be displayed by typing
<esc> and a number. If the number is negative, say -3, then the
last 3 lines will be displayed. The following example is displaying the
next 5 lines of the script:
Typing <esc>0 will display the current line in the script:
[type <esc>0] $ Printing current line of script: *INTERACT
To exit the IDE and continue the execution of the script type
<esc>c This is the same as typing '+++'
Typing
commands directly into the IDE
In the IDE, expect-lite
script commands can be typed directly into the terminal, even assigning
variables and displaying them, inside the
paused script, for example:
Note that variables are printed with any overriding constants.
Pasting
into the IDE
Of
course, typing is useful, but copy and paste is much easier. Pasting
lines into the IDE can be really helpful in debugging a script. For
example, you may want to debug a dynamic variable assignment. The
script may have the following lines:
>ifconfig # get IP address of loopback interface <lo +$ip_addr=inet addr:([0-9.]+)
This
code snippet displays all the interfaces on this machine, expecting lo
will clear the capture buffer above 'lo', thus removing the info from
the eth0 interface. The dynamic variable will capture any numbers and
periods after the words 'inet addr:'
By copying the lines from the script and pasting them into the IDE the
terminall will display following:
$ ifconfig eth0 Link encap:Ethernet HWaddr 00:30:65:98:e5:4a inet addr:10.1.1.125 Bcast:10.1.1.255 Mask:255.255.255.0 inet6 addr: fe80::230:65ff:fe98:e54a/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ... Interrupt:41 Base address:0x6c00
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 ... Assigned Var:ip_addr=127.0.0.1 $
And of course, code blocks can be pasted into the IDE as well. Take
care to paste the entire code block to get the desired result.
Pasting the $i=0 is important, since it initializes the counter in the while loop.
IDE, It lives!
It
is possible to paste in lines which would normally fail the script.
However getting kicked out of the script while one is debugging is not
only irritating but not all that useful. For example, using similar
script lines to above:
>ifconfig <eth2
Since
there is no eth2 interface on this machine the script snippet will
fail. However, the *NOFAIL directive is automatically enabled inside
the IDE, there pasting the snippet results in:
Instead of the expect-lite exiting, and declaring the script has
failed, it remains in the IDE (at the *INTERACT, or breakpoint), ready
to
receive another command.
Running to Completion
The
normal operation of expect-lite is to stop with any failure. However,
this may not always be the desired behaviour. Using the *NOFAIL
directive, will prevent the expect-lite script from stopping prior to
completion. The directive *NOFAIL can be placed in the script, or on
the command line (as well as any other directive).
expect-lite will still detect failures and report them at the end with
the message:
##Overall Result: FAILED (*NOFAIL on)
Once
*NOFAIL has been directed, it remains on for the rest of the script.
Conceptually it is the opposite of *FAIL, which fails the script
immediately (if *NOFAIL isn't set).
Finding
In...
Verbose
Since most expect-lite scripts are composed of > and <
lines, it
can be difficult to understand why expect-lite isn't finding the
desired text. Using the -vv or --verbose option (in version 3.1.4 or
later) will display the string that is to be matched (find) and the
entire string that is being searched (in).
Both the 'find' and 'in' text are wrapped in <<
>> to show
any line feeds. The 'find', if successful,
will almost always be at the bottom of the 'in' text. Often when
there is a unexpected failure, the '<' is defined too
broadly, and expect-lite has matched an unexpected piece of 'in' text.
(see Define '<' narrowly)
As of expect-lite version 3.1.4, -vv or --verbose will also display
'find and 'in' for dynamic variable capture, thus providing a bit more
information to assist in debugging this feature as well.
As of expect-lite version 3.5.0, -vv or --verbose will display all
warnings and debug information (including user defined prompt debug
info)
Showing
Variables, Values & Constants with *SHOW VARS
Sometimes when troubleshooting a script, it is really useful to display
the value of an expect-lite variable. The easiest method to display a
variable is to use the printable comment ';' For example,
there
is a variable named '$max', by adding the following line to the script,
$max will be dereferenced and displayed:
; The value of max is:$max
The above method works well for a few variables, but it may be
neccessary to view all the expect-lite variables. In previous versions
of expect-lite, a script (show_vars.inc) was required to view all
variable values. As of version 4.0.x, the expect-lite directive: *SHOW
VARS now displays variables, values, and any overriding constants.
All variables can now be displayed by using the line:
*SHOW VARS
The include script is written in embedded expect and will walk the
array of expect-lite variables, and print their respective values. The
output will appear like the following:
*SHOW VARS can also be used with *INTERACT and instant-interact to view
the values all assigned variables, however, <esc>v performs the
same action and is less typing.
Define
'<' narrowly
Do not define '<' too broadly. For example, DO NOT use the
following:
<\n.*
The above defines 0 or more of any character after a newline. This will
match just about anything, and more than likely not what is intended.
Instead use a more specific '<'. If the expected string is only
composed of numbers at the beginning of a line, use:
<\n[0-9]+
Use with the --verbose option
to see what is
being matched, and to
assist in refining the '<' statements.
Decreasing the
log
chatter
After one's scripts are succesfully debugged, it may not be desireable
to see all the log chatter which expect-lite produces, such as
warnings, conditional reports, dynamic variable assignments. This
chatter can be reduced by using the expect-lite logging directives at
or
near the beginning of the script, such as:
*NOWARN
If while debugging the script, it is desirable to see the additional
logging info (chatter), it can be turned on via the command line with
the -v parameter:
expect-lite -v r=myhost c=myscript
Removing Colour from output
In
an automated environment, it is probably not desirable to have ANSI
color sequences embedded in the logs. Although it is possible to use
the expect-lite directive *NOCOLOUR in each script to turn off colour,
there is an easier way. Define the terminal type to a dumb terminal,
such as tty.
export TERM=tty
expect-lite will detect the dumb terminal type and turn off colour
output automatically.
Or
as of version 4.0.x, *DIRECTIVES can be placed on on the command line,
therefore it is possible to turn off colour on the command line:
expect-lite -r myhost -c myscript *NOCOLOUR
General Tips
Here are some simple tips when script writing:
Use reasonable timeouts, if 30 seconds is needed to
get a
response, set the timeout at 45 or 60 seconds, not 600.
There is no cost to changing the timeout, timeout
values
can
also be variables
Beware of expect-lite using regex, when creating
lines
like:
<0.005 secs (5 micro secs)
The parentheses is used by the regex engine,
instead
escape
these characters: <0.005 secs \(5 micro secs\)
or use '<<' which does not use regex,
and
does not require escaping: <<0.005 secs (5 micro secs)
Use the expect character '<' or
'<<'
often. Check for valid results
when possible. A script which expects nothing will never fail!
Use printable comments ';' and ';;' often. Think of
it as
writing a note to oneself, it will make reading log files much easier.
As of version 3.7.0 printable comments will be coloured blue (this is user
configurable).
Variable assignments use no spaces e.g. $var=value. Note no spaces
around the equals sign, this permits leading spaces in the value such
as $var= myvalue
Summary
By using these troubleshooting aids, it should be even easier to write
and debug expect-lite scripts. Feel free to send me any tips. cvmiller at gmail dot com
Why Expect-lite
Expect-lite was written to create quick and easy automation of
repetitive tasks.