It was really tempting to name the program "sex" (for either
"Smart EXec" or "Send-EXpect"), but good sense (or perhaps just
Puritanism) prevailed.
On some systems, when a shell is spawned, it complains about not
being able to access the tty but runs anyway. This means your
system has a mechanism for gaining the controlling tty that
Expect doesn't know about. Please find out what it is, and send
this information back to me.
Ultrix 4.1 (at least the latest versions around here) considers
timeouts of above 1000000 to be equivalent to 0.
Digital UNIX 4.0A (and probably other versions) refuses to
allocate ptys if you define a SIGCHLD handler. See grantpt page
for more info.
IRIX 6.0 does not handle pty permissions correctly so that if
Expect attempts to allocate a pty previously used by someone
else, it fails. Upgrade to IRIX 6.1.
Telnet (verified only under SunOS 4.1.2) hangs if TERM is not
set. This is a problem under cron, at and in cgi scripts, which
do not define TERM. Thus, you must set it explicitly - to what
type is usually irrelevant. It just has to be set to something!
The following probably suffices for most cases.
set env(TERM) vt100
Tip (verified only under BSDI BSD/OS 3.1 i386) hangs if SHELL and
HOME are not set. This is a problem under cron, at and in cgi
scripts, which do not define these environment variables. Thus,
you must set them explicitly - to what type is usually
irrelevant. It just has to be set to something! The following
probably suffices for most cases.
set env(SHELL) /bin/sh
set env(HOME) /usr/local/bin
Some implementations of ptys are designed so that the kernel
throws away any unread output after 10 to 15 seconds (actual
number is implementation-dependent) after the process has closed
the file descriptor. Thus Expect programs such as
spawn date
sleep 20
expect
will fail. To avoid this, invoke non-interactive programs with
exec rather than spawn. While such situations are conceivable,
in practice I have never encountered a situation in which the
final output of a truly interactive program would be lost due to
this behavior.
On the other hand, Cray UNICOS ptys throw away any unread output
immediately after the process has closed the file descriptor. I
have reported this to Cray and they are working on a fix.
Sometimes a delay is required between a prompt and a response,
such as when a tty interface is changing UART settings or
matching baud rates by looking for start/stop bits. Usually, all
this is require is to sleep for a second or two. A more robust
technique is to retry until the hardware is ready to receive
input. The following example uses both strategies:
send "speed 9600\r";
sleep 1
expect {
timeout {send "\r"; exp_continue}
$prompt
}
trap -code will not work with any command that sits in Tcl's
event loop, such as sleep. The problem is that in the event
loop, Tcl discards the return codes from async event handlers. A
workaround is to set a flag in the trap code. Then check the
flag immediately after the command (i.e., sleep).
The expect_background command ignores -timeout arguments and has
no concept of timeouts in general.
