views:

157

answers:

4

I am amazed by how Expect (TCL) can automate a lot of things I normally could not do.

I thought I could dig deeper into Expect by reading a book, but before I do that I want to ask if there are other solutions/languages that could do what Expect does?

Eg. I have read that people compare Expect with Awk and also Perl.

Could Awk and Perl do the same thing?

How about other languages like Python and Ruby?

Is Expect the de-facto automation tool or are there other solutions/languages that are more superior?

+2  A: 

Check out Pexpect for Python

dekomote
Seems unmaintained for 2.5 year
never_had_a_name
+6  A: 

Check out Expect for Perl

One could argue that the perl implementation isn't superior per se, just similar in function.
Bryan Oakley
+7  A: 

There's more to it.

Bluntly, the original Expect--the Tcl Expect--is the best one. It better supports "interact" and various pty eccentricities than any of its successors. It has no superior, for what it does.

HOWEVER, at the same time, most Expect users exploit such a small fraction of Expect's capabilities that this technical superiority is a matter of indifference to them. In nearly all cases, I advise someone coming from Perl to use Expect.pm, someone familiar with Python to rely on Pexpect, and so on.

Naive comparisons of Perl with "... Awk and also Perl" are ill-founded.

In the abstract, all the common scripting languages--Lua, awk, sh, Tcl, Ruby, Perl, Python, ...--are about the same. Expect slightly but very effectively extends this common core in the direction of pty-awareness (there's a little more to the story that we can neglect for the moment). Roughly speaking, if your automation involves entering an invisible password, you want Expect. Awk and Perl do NOT build in this capability.

There are other automation tools for other contexts.

Cameron Laird
Which other automation tools are you talking about?
never_had_a_name
"Lua, awk, sh, Tcl, Ruby, Perl, Python, ...--are about the same" my personal opinion is that you have to be out of your mind to compare full fledged languages like Lua, Ruby and Python with awk and sh.
aaronasterling
@Aaron: I see you have not looked in detail at the raving madness that is `autoconf`… (They're all real programming languages – not just turing-complete, but also in use in the real world – but they do have different basic operations and different domains of applicability.)
Donal Fellows
@Donal. I'm not saying that they are not real languages. I'm saying that you would not want to write a real program in one of them. Modifying bits "with a magnetized needle and a steady hand" is turing complete (though not in use in the real world) but that doesn't mean that you would want to. awk and sh are meant to do a small set of things and do them extremely well. They succeed at that but not much more.
aaronasterling
@Aaron: That's a silly example (it isn't turing complete *per se*) but the key point I was making is that you're wrong in that you're bringing in your prejudices. (I wouldn't personally want to write a real program in Lua, but that doesn't mean it isn't a real programming language! Just that some design decisions involved in it don't sit with my preferences.)
Donal Fellows
@Donal I challange to you present 5 large programs written in the past ten years in awk or sh. Newer and better languages came along for writing large programs and neither one was ever intended for that purpose to start with. That's not to say that they aren't real languages, they are. It's that they lack _batteries included library support_ for a wide range of domains. This makes them __inferior__ for __general purpose__ programming. however, they are still __superior__ for __specialized projects__. Any large program written in awk could be better written in python.
aaronasterling
@Aaron: Whether or not the battery is included is not quite as important as you seem to think – downloading extras just isn't hard – but the difficulty of adding libraries for additional functionality is one key reason why I don't write big awk programs. (In fact, for what I do professionally, Java turns out to be the best solution.)
Donal Fellows
+4  A: 

ajsie asks, "Which other automation tools are you talking about?"

I'll answer a different question: "which other contexts do I have in mind"? The answer: any interactive environment OTHER than a stdio one. Expect is NOT for automation of GUI points-and-clicks, for example. Expect is also not available for Win* non-console applications, even if they look as though they are character-oriented (such exist).

An exciting counter-realization: Expect is for automation of wacky equipment that permits control by a term-like connection. If your diesel engine (or, more typically, telecomm iron) says it can be monitored by hooking up a telnet-like process (even through an old-style serial line, say), you're in a domain where Expect has a chance to work its magic.

Cameron Laird