----
[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."

[RJ] (06/21/2007) - Yeah, I don't know.  I've only ever ran across
a single issue that required an exp_close/exp_wait to deal with it.
That was a script that was testing how many processes I could spawn
before running into memory problems on a Solaris station.  I ran
out of ptys first, and that hung the Xserver and dumped a huge core file.
But I've never needed to close/wait - the script exits and the processes 
go away, unless you loop a spawn command too many times.  I've never 
seen that in a real-use script, aside from [multixterm].

----

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 [http://phaseit.net/claird/comp.unix.programmer/ftp_automation.html]
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.]] <===  [RJ]  8 Aug 04 - To whomever authored this request, see [Secure expect].
----
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.

[Ro]: This is is really very interesting Cameron.  I just got a copy of the Expect book by my dear old dad, and I'm about to start it.  What is this 'older approach'?  My thanks, on this 30 May 2004.
----
There are things that Expect can do that few other things can.  I'm using it to jump off Cisco boxes and grab config, stuff like that.
I have to agree to a point about the outdated writing style.  It's almost easier to learn myself through trial and error, than to understand and help guides.
----
[SB]:When debugging why expect/send_exp doesn't behave the expected way, execute the command

exp_internal 1

on top level.

<<categories>> Expect