Expect is a program that performs programmed dialogue with other interactive programs. For more information about Expect, try
This is Expect 5 for Tcl 8.0 and Tk 8.0. It works with no other versions of Tcl or Tk. This distribution comes with the code for both Tcl 8.0 and Tk 8.0. The Tcl 8.0 distribution has been modified from the original Tcl 8.0 distribution. It adds support for event driven I/O over pipes and event driven console input. This distribution gets information from a different registry key than the Sun distribution, so it can be installed safely with a Tcl 8.0 distribution as long as you use separate install directories.
The distribution comes in both source and binary forms. It comes with Tcl 8.0, Tk 8.0, and Expect 5.21. The distributions can be found here:
Snapshot 23 is an update to Tcl/Tk8.0p2. The snapshot also includes BLT 8.0-unoff with a working blt::bgexec. Everything has been made into packages, so you will need to use package require expect, package require blt, or package require dde (for the send command).
This port comes with a console based telnet application that can be used with expect. This telnet application is not meant as a standalone telnet although it will work as such. It only acts a dumb terminal, however, so it is not generally useful.
Here is the latest buglist
No, this is an independent port that was funded by Mitel Corporation. It has been released under essentially the same terms as Sun's Tcl distribution. Although Don Libes and I have communicated and he gave me plenty of assistance through the porting period, he has not sanctioned this port.
Eric Youngdale provided socket support that was required to work on Windows 95, but there is still one major problem. On NT, one can set a breakpoint in a system DLL. Shared DLLs are set copy on write (COW), so setting a breakpoint in a DLL in one process causes that process to get a private page without affecting other processes. Windows 95 doesn't do this, so it protects the system DLLs and does not allow one to set breakpoints on them. The fix requires rather significant fixes--functions can no longer be intercepted at their entry points but need to be instead intercepted at their calling points. This is not as useful and harder to get right.
There is an expect.exe, but it is not interactive currently. It can run scripts that are given as command line arguments. If you want to run Expect interactively, load it as an extension into the Tcl interpreter. If you run the tclsh80.exe that comes with the Expect NT distribution, it will automatically load the Expect extension. You can see this in $ExpectRoot/lib/tcl/init.tcl.
There are a couple solutions to this problem. The first is to construct a .bat file that will then get rerun as a tclsh file. Here is an example:
The second solution is to use associated file type. You can associate the .exp extension with tclsh80.exe or expect.exe. For more information about this technique, see How do I associate Perl scripts with perl?. From the command line, you can type:
You can also execute shell scripts directly with Tcl's exec command and Expect's spawn command. The process execution code has been patched to check files for #! at the beginning of the file.
These are the commands that are fully working (in theory, at least):
If you are having trouble reading from a subprocess, try using spawn -pipes instead of just spawn. Normally, Expect tries to read the output from the subprocess through function call interception. While this is the most flexible way when it is fully functional, there may still be some bugs associated with it. It should work for almost all programs, but there may be a few exceptions. If you still have trouble, try the -pipes option to spawn since it does not use function call interception and may work. The primary drawback is that for interactive processes, the spawned process needs to flush its output after every write to stdout/stderr. If you own the code to the subprocess or you do not need truly interactive performance or the subprocess already flushes its output, this option may work adequately for you. This was the technique that was used in the Alpha1 release. One benefit that it has is that it is faster than the current function call interception technique.
Even though the script works on some, most, or all Unices, the script is not correct. This is according to Don Libes. It should be using send string\r instead. The reason it works on Unix is that the pseudo-terminal layer translates \n to \r. There is no guarantee that it will on all Unices, so this makes it non-portable. On Don's recommendation, \n will not be translated to \r on Windows NT, so your script will need to be changed. It seems that quite a few Dejagnu scripts are written with \n instead of \r, so those scripts will fail.
Yes. If you set the variable exp_nt_debug to 1, it will display a console when a subprocess is spawned. This can be useful when you are trying to debug the interaction between expect and your spawned process.
Expect runs spawned processes under control of a simple debugger. The Win32 API does not allow either two debuggers to attach to the same process, and it doesn't allow a debugger to detach from a process. This means that you cannot run the Visual C++ debugger, Purify, or any other debugger on a program under the control of Expect. To aid in debugging problems that only show up when running under Expect, there is a simple traceback facility beginning in Snapshot 17. To make use of it, you need to set the variable exp_nt_debug to 1 before spawning the process. If a crash occurs, a traceback will be printed in the console where the crashed occurred, and it will wait for 10 seconds. Additionally, the traceback will be logged in the application event log. This can be viewed with the Event Viewer in the Administrative Tools group. You will need to select the application event log.
You can find some sample scripts in the source distribution. In the expect-5.21/win/tests/ directory, there is a test suite suite. Additionally, expect-5.21/win/etest.tcl has some test procedures.