People want Expect for Microsoft Windows.
Aspects of it exist. Gordon Chaffee ported Expect 5.21r1b1 . Binary and source are available at [L1 ], and also present in MyrmecoX (?), but not Tcl Dev Kit (for want of stubsication?). This corresponds to Tcl version 8.0.
During the early winter 2001-2002, Telindustrie LLC briefly supported David Gravereaux's work to port 8.4 to Windows. Davy's pretty much the world's most knowledgeable person about what this will involve. He writes,
"There is a *somewhat* working 8.4 ready binary of Expect for windows @ http://sf.net/project/showfiles.php?group_id=13179 . It's far from done. Using spawn with the -open option one can 'expect' on an already open channel, such as a socket or a serial port. The 'slave driver' aspect of spawn is where all the deep black magic is. The mojo isn't yet complete."
The windows specific code is already in the official repository off on a branch [L2 ]
With some support, this could be completed, but Davy can only do so much as a hobby.
There are lots of ways this could go. Perl (and Python?) people might help out with Expect, and Win* expertise perhaps would be part of the package. Also interesting is a comp.lang.tcl exchange [L3 ] between Jiang Wu and Jeffrey Hobbs; note mention of how more of Expect might move into the Tcl core.
Andreas Kupries says [2001-sep-20] that Expect works fine under Cygwin as long as what you're expect'ing upon is a cygwin application. It can't work with normal/native Win32 console applications.
[Why and how it doesn't work for Win95. Problems with interact.] [Experience with Win2000.] [ Pure-Tcl telnet available--this sometimes suffices.]
[Expect 5.25/Tcl 7.6 for Japanese.] [5.31/8.2 as source.]
[ Tony Summerfelt's been mostly successful with Expect under Win2000.]
Is there a need for a trap to receive the "signal" when Expect is used as a Windows service? [L4 ]
IMO, No. The windows model provides this and the "shell" being used for the service control should get "going down" notices and hopefully "do the right thing". If expect.exe knows nothing for being a windows service, for which it shouldn't being a CLI shell, one should build a shell with all the needed service parts to get the notifications they need. See tclsvc - Tcl as an NT Service -- DG
[ CL intends to explain four reasons why many people who think they need Expect do not need Expect, for Windows in particular.]
[Put in reference to gloomy December 2002 thread that concludes full Expect for Windows is impractically difficult, because Windows programs are so squirrely in their I/O.]
The c.l.t thread started here, with the innocent question why expect isn't in ActiveState Tcl on windows: [L5 ]
Another c.l.t thread about Expect, this time Windows XP is looked at: [L6 ]
[On another hand, davygrvy has also written, "All the hard work (system stuff) is already done."]
David Graveraux paints the big picture whats possible with his expect port effor on windows right now and whats not: [L7 ]