This is the theme of "Expect exceeds expectations" (see the developerworks article at: [L1 ]): 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:
In broad terms, few programmers realize the elegance of integration of pty management into Tcl's framework of event-oriented channels. [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 XOTcloffers Tcl + more.
By the way I am a complete newbie, I have no clue how XOTcl or Expect are ditributed as a separate interpreter or as packages/modules.
c++ publicize it self as a separate language If you visit XOTcl homepage [L2 ] 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 2004-03-31: 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" [L3 ]; 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.