This is the theme of "Expect exceeds expectations" (see the developerworks article at: [http://www-106.ibm.com/developerworks/library/l-sc1/?n-l-4112]): even most active [Expect] programmers are aware of only a fraction of its capabilities. First, they don't realize that Expect is a proper [superset] of [Tcl], and therefore can do everything Tcl can. Moreover, they're not aware that Tcl is a quite capable general-purpose programming language. They also are not aware of the relation between [Tk] and Expect, so don't realize how easy it is to add a [GUI] to existing Expect scripts. Expect extends Tcl in three principal ways: * with pseudo-terminal (pty) management * with debugging facilities * with a command language for "challenge"-response dialogues. In broad terms, few programmers realize the elegance of integration of pty management into Tcl's framework of event-oriented [channel]s. [[Much more explanation.]] ---- [interact] is one of Expect's wonders. ---- '''Usability notice''': The referenced developerWorks article contains what appear to be hyperlinks to a discussion forum. They are not hyperlinks. They are javascript directives. So, turn on your javascript, and forget about any "open in a new tab" option you may be used to when something looks like a link. '''Usability followup''': Once you navigate the maze above and actually reach the discussion forum, it is completely unusable. Do not waste your time. Just read the article, then go home. ---- [Expect] is a superset of [Tcl]? That's shocking news to me. Then how come we program in [Tcl] instead of [Expect]? Such play on words can have a mind-boggling effect on newbies. Luciano, can we do this in clt? I don't understand whether you have an other-than-rhetorical question. No, my dear IP number gumshoe. The wording has confused me indeed. I always thought that Expect was a Tcl application, or a Tcl '''subset''' in other words. Just tell us what "superset" means here, edit (delete) my clueless questioning and we're good. ;-) ---- "superset" afaik is slang, I can't find it in the dictionary, "subset" on the other hand did appear in the dictionary but, languages evolve all the time, and dictinaries add new words, so maybe it's just that I have an old dictionary. Now, let say that c have a set of features {structs, int, functions, pointers, arrays, recursion} we can say that c++ have a larger set of features {structs, int, functions, pointers, recursion, classes, references, templates} instead we can say c++ have {{c}, classes, templates, references} which will make c's set of features a subset of c++ set of features '''or''' in simpler words we can say c is a subset of c++. In the same way we can say Tcl is a subset of [XOTcl], or snit, or [Expect], etc... that [XOTcl]offers Tcl + more. By the way I am a complete newbie, I have no clue how [XOTcl] or [Expect] are ditributed as a seperate interpreter or as packages/modules. c++ publicize it self as a seperate language If you visit [XOTcl] homepage [http://www.xotcl.org/] you will see similar behavior, but not exactly [Expect] publicize it self as tool, not a language, it doesn't even matter that it's writen in Tcl (maybe it does, but I never used it and I don't know what it does, but this is how expect pulbicize it self anyway, their mistake if any). But regardless of all this, I think it's politicaly correct to call Tcl a subset of these tools (even if those tools are writen in Tcl, because it doesn't really matter how they were implement, maybe in c, maybe in ocaml or c++, and we alse can't claim that Tcl is a subset of Tkman, Tkman being writing in Tcl, we can say so about [XOTcl] or [Expect] for what they do, not how they were implemented), and maybe even enlightening, cause now I know that if I learn Tcl well, I will have no problem using these tools ---- [RJ] 3/31/04 - Allow me to suggest a compromise. In most of the Expect documentation I have, (e.g., [BOOK Exploring Expect]) Expect is referred to as an extension of TCL. It was written by Don Libes at NIST - in TCL - after John Ousterhout announced TCL. It has since been adapted as an extension to other languages. ---- [CL] is, as often, insensitive to all the emotional content here. For him, there's no cant or artifice with "superset" [http://en.wikipedia.org/wiki/Superset]; mathematicians have used it routinely for at least the last century. And there ''is'' a point to its employment here. It appears that hundreds of thousands of systems administrators are aware of Expect as an administrative tool or utility. A minority of that number appear to recognize that Expect is based on Tcl. A very small portion of the total understand that Expect is a proper '''[extension]''' of Tcl, that is, Expect does all the things Tcl does, and it also does more. I run into many, MANY Expect developers who sincerely don't realize that Expect can interpret individual Tcl commands, let alone whole scripts. My choice of "superset" is an attempt to cast about for different words, ones that might get through to naive audiences. ---- [RJ] - An example of what Expect can do for programmers is multixterm, which comes with the package. Using multixterm, a programmer can test portability, by simply porting the application, logging into each server simultaneously using multixterm, then running the test app from the provided "broadcast" window. Anything typed into this window is sent to all open windows (one for each server in this case). If it fails on the ported-to server(s), it's simply a matter of comparing the environments of the working and not working machines. At my company, I have adapted multixterm to allow simultaneous management and maintenance on routers and other network devices in our network. This has since been added to an application used in our Network Operations Center that provides automated login to these devices without the need for storing account ids and passwords in the clear in files or scripts. Passwords are stored in a secure database, accessed via a secure website, downloaded using ssl to the application and encrypted using DES into the user's subdirectory, and decrypted as needed by the application. Passwords can then be changed globally, routinely, without notification to users. In a global NOC, some devices require access from regional servers to pass Access List restrictions. This is also handled by the application. All of the automated logins are performed using Expect commands. All the administrivia (e.g., password handling, application flow) is done with Tcl. I agree, Cameron. Superset, subset, extension. To me it's all one language. And I'm still constantly amazed at what it can do. ---- So this business of superset vs extension all has to do with history. In the beginning there was expect it was a souped up Tcl interpreter. Therefore it was a supserset of tclsh. Don't know the history of when expectTk came into being, but it was a souped up Tk interpreter..and therefore a superset of wish. Somewhat later Tcl added package management. Somewhen around then, the functionality (commands) of expect were separated out into a loadable package, as was Tk, so starting with a tclsh you could: package require Tk package require Expect and get the same effect as running expectTk. So now you can consider expect a package. So everyone's right except those who said expect was a subset of Tcl. The least it ever was was a superset of a snapshot in time of tclsh. <> Expect