People want [Expect] for [Microsoft Windows].

Aspects of it exist.  [Gordon Chaffee] ported Expect 5.21r1b1 .
Binary and source are available at
[http://bmrc.berkeley.edu/people/chaffee/expectnt.html],
and also present in [Myrmeco]X (?).  This corresponds to [Tcl] version 8.0.

An up-to-date port of Expect (based off 5.43) is available from [ActiveState] [http://www.activestate.com/Products/Expect/], included in [ActiveTcl] 8.4.11.1 or later.  It works with Tcl 8.4 and is fully [stubs]-enabled, allowing it to be wrapped with [TclApp] (part of the [Tcl Dev Kit]) to create single-file deployable executables.  This is similar to the Chaffee port in that it doesn't have [interact], fork or overlay, but the bulk of the automation core is available.

It could get [interact] if someone really needs it.  All that's needed is lots of development time and good verification test cases. -- [DG]

----
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
[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/expect/expect/win/?only_with_tag=telco-tec-win32-take2-branch]

----
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
[http://groups.google.com/groups?q=testchannel+unstack+subcommand+group%3Acomp.lang.tcl*&num=25&hl=en&safe=off&rnum=1&selm=3B5E031F.42FB3BA4%40ActiveState.com]
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 cygwin's Expect works fine under [Cygwin] as long as what you're expect'ing upon
is a cygwin application.  It does not 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?
[http://groups.google.com/groups?q=consolectrlhandlers+group:comp.lang.tcl*&hl=en&lr=&ie=UTF-8&selm=f758hug4b99ffq8qljolgf14p51bdnfmfi%404ax.com&rnum=1]

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]

----
[Many people who think they need Expect do not need Expect],
for Windows in particular.
----
[LV] Sometimes people talk about wanting Expect running under Windows,
but it turns out that they really are wanting to drive [GUI] applications,
which is a use for which Expect is not intended.


''[escargo] 19 Apr 2005'' - Using '''driving''' as a search produced (among others):
[Techniques for 'driving' Windows applications].

----
[Category Expect]