8

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?

Andrew Grimm
  • 78,473
  • 57
  • 200
  • 338
never_had_a_name
  • 90,630
  • 105
  • 267
  • 383
  • I think that it's de facto because it was the first one and it was based on TCL which is/was quite popular in some circles, e.g. embedded stuff like Cisco routers. So if you already knew TCL in order to configure the router, why not use an automation framework compatible with it? – Cristian Ciupitu Sep 19 '10 at 16:12
  • 4
    Expect has become the standard in such things. You can find Expect implementations like shown in the answers, but I doubt you will find something _superior_. – Muhammad Alkarouri Sep 19 '10 at 19:51
  • 1
    Not “a” book, “the” book. The [Expect book](http://oreilly.com/catalog/9781565920903) remains very highly regarded, though what it says about Tcl is somewhat out of date. (Well, what do you expect for a book about computing software that is that old?) – Donal Fellows Sep 19 '10 at 21:03

4 Answers4

9

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
  • 1,067
  • 5
  • 9
  • Which other automation tools are you talking about? – never_had_a_name Sep 19 '10 at 20:00
  • "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 Sep 20 '10 at 23:55
  • 1
    @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 Sep 21 '10 at 08:22
  • 1
    @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 Sep 21 '10 at 08:31
  • @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 Sep 21 '10 at 09:10
  • @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 Sep 21 '10 at 10:18
  • @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 Sep 22 '10 at 21:03
7

Check out Expect for Perl

user449592
  • 208
  • 1
  • 3
4

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
  • 1,067
  • 5
  • 9
2

Check out Pexpect for Python

dekomote
  • 3,817
  • 1
  • 17
  • 13