CL writes on news:comp.lang.tcl :
"... The Expect (as a language) we commonly learn is an abbreviation of the platonic Expect in which we can most portably write. The true action pair is
exp_send $challenge expect $response
rather than
send $challenge expect $response
As a convenience, base Expect includes several synonyms, of which {exp_send,send} is one example.
When working with an extended Tcl, such as Tk, it's often necessary to project back to the canonical command forms, specifically to resolve name conflicts (Tk has its own send).
If Expect had been written for ten-year-old Tcl, rather than being the first extension ever discovered, it of course would rely on namespaces to avoid name conflicts.
D. J. Hagberg rightly writes, "Here's the BIG RULE for Expect: Every exp_spawn requires a call to exp_close *and* exp_wait."
Some of the people who have stumbled on Expect in the year 2001 would actually be better served by ssh or such protocol packages from tcllib as ftp, http, smtp,
... [CL] especially emphasizes that
there are many jobs--FTP [L1 ] and e-mail automation, especially--for which Expect is generally not the best tool. For those who insist, though, w3m provides a nice model of what's possible with standard command-line utilities for these protocols. Stubsification of Expect
CL recently mentioned on comp.lang.tcl that expect has a $HOME/.expectrc file that can be used to predefine procs, variables, etc. that one uses regularly.
[CL needs to explain inband_ftp, Expect philosophy, and vivid cat-based example. Also, how to handle sensitive information (passwords) embedded in plain-text Expect scripts.]
Expect's old. Expect disappoints and frustrates some newcomers, because it's done well in the style of 1992-1994. With PHP, for example, if you have a question or a need for explanation, you're likely to find http://www.php.net/ rewarding. That's not how Expect is managed, at least not now (mid-2002). Expect's high-level aim is that, "It's in the book" (BOOK Exploring Expect) accurately answers all questions. The book is really quite marvelous as both introduction and reference--but its style might strike some readers as archaic and inaccessible, at least until they shift to accept the approach that was the best in computing about a decade ago.
This is CL's personal view.