1 Expect FAQ (Frequently Asked Questions)
3 An HTML version of this FAQ can be found in http://expect.nist.gov/FAQ.html
5 This FAQ lists common questions, usually about subjects that didn't
6 fit well in the book for one reason or another (or weren't
7 indexed sufficiently well so that people can't find the answers easily
8 enough). In some cases, I've left the original questions. I suppose
9 I could've stripped off the headers, but it seems more realistic to
10 see actual people who've asked the questions. Thanks to everyone who
13 The man page and the papers listed in the README file should
14 also be consulted for highly technical or philosophical discussion of
15 the implementation, design, and practical application of Expect.
19 ======================================================================
21 Here is the list of questions. You can search for the corresponding
22 answer by searching for the question number. For example searching
23 for "#3." will get you that answer.
28 #1. I keep hearing about Expect. So what is it?
29 #2. How do you pronounce "Ousterhout" anyway? (Or "Libes" for that matter?)
31 #3. Why should I learn yet another language (Tcl) instead of
32 writing my interaction in <a language I already know>?
34 #5. Do we need to pay or ask for permission to distribute Expect?
35 #6. Since Expect is free, can we give you a gift?
36 #7. Are there any hidden dangers in using Expect?
38 **** Book, newsgroup, FAQ, README, ... ****
40 #8. Why is this FAQ so short?
41 #9. How was this FAQ created?
42 #10. The background makes the FAQ hard to read.
43 #11. Why isn't there an Expect mailing list?
44 #12. Why isn't overlay covered in Exploring Expect?
45 #13. Is the front cover of your book a self portrait (ha ha)?
46 #14. Why don't the examples in your USENIX papers work?
47 #15. Can you put the examples in your book into an anonymous ftp site?
48 #16. Do you have ideas for more articles on Expect?
50 **** Can Expect do this? ****
52 #17. Can Expect automatically generate a script from watching a session?
53 #18. Can Expect understand screen-oriented (Curses) programs?
54 #19. Can Expect be run as a CGI script?
55 #20. Can Expect act like a browser and retrieve pages or talk to a CGI script?
56 #21. Can Expect be run from cron?
57 #22. Why does my Expect script not work under inetd?
59 **** Compilation or porting questions ****
61 #23. Why can't I compile Expect with Tcl 8.0?
62 #24. Does Expect 5.26 work with Tcl/Tk 8.0.3?
63 #25. Why can't I compile Expect with Tcl/Tk 8.1aX?
64 #26. Why can't I compile Expect with Tcl/Tk 8.0b1?
65 #27. Why does Expect need to be setuid root on Cray?
66 #28. Does Expect run on VMS?
67 #29. Is it possible to use Expect and TclX together?
68 #30. Is it possible to use Expect and <lots of random extensions> together?
69 #31. Why does configure complain about "cross-compiling"?
70 #32. Why are make/configure looping endlessly?
71 #33. Why does compile fail with: Don't know how to make pty_.c?
72 #34. Does Expect run on MSDOS, Win95, WinNT, MacOS, etc...?
73 #35. Why does Expect dump core? Why can I run Expect as root but not as myself?
77 #36. Is it possible to prevent Expect from printing out its interactions?
78 #37. Why does it send back the same string twice?
79 #38. Why can't I send the line "user@hostname\r"?
80 #39. How do I hide the output of the send command?
81 #40. Why don't I see pauses between characters sent with send -s?
82 #41. Why does "talk" fail with "Who are you? You have no entry utmp" or
83 "You don't exist. Go away"?
84 #42. Why does . match a newline?
85 #43. Why doesn't Expect kill telnet (or other programs) sometimes?
86 #44. How come I get "ioctl(set): Inappropriate ..., bye recursed"?
87 #45. How come there's no interact function in the Expect library?
88 #46. Can't you make tkterm understand any terminal type?
89 #47. Trapping SIGCHLD causes looping sometimes
90 #48. Why do I get "invalid spawn id"?
91 #49. Could you put a version number in the filename of the Expect archive?
92 #50. Why does Expect work as root, but say "out of ptys" when run as myself?
93 #51. Why does spawn fail with "sync byte ...."?
94 #52. Why does Expect fail on RedHat 5.0?
95 #53. Why does Expect fail on RedHat 5.1?
96 #54. Is Expect Y2K compliant?
100 * Questions and Answers
108 #1. I keep hearing about Expect. So what is it?
110 From: libes (Don Libes)
111 To: Charles Hymes <chymes@crew.umich.edu>
112 Subject: I keep hearing about Expect. So what is it?
114 Charles Hymes writes:
118 Expect is a tool primarily for automating interactive applications
119 such as telnet, ftp, passwd, fsck, rlogin, tip, etc. Expect really
120 makes this stuff trivial. Expect is also useful for testing these
121 same applications. Expect is described in many books, articles,
122 papers, and FAQs. There is an entire book on it available from
125 Expect is free and in the public domain. Download instructions can
126 be found in the Expect homepage.
130 ======================================================================
132 #2. How do you pronounce "Ousterhout" anyway? (Or "Libes" for that matter?)
135 From: ouster@sprite.Berkeley.EDU (John Ousterhout)
136 To: libes@cme.nist.gov
137 Subject: Re: pronunciation?
138 Date: Tue, 29 May 90 21:26:10 PDT
140 Those of us in the family pronounce it "OH-stir-howt", where the
141 first syllable rhymes with "low", the second with "purr", and the
142 third with "doubt". Unfortunately this isn't the correct Dutch
143 pronounciation for a name spelled this way (someplace along
144 the line it got misspelled: it was originally "Oosterhout"), nor
145 is it what you'd guess if you use common sense. So, we've gotten
146 used to responding to almost anything.
150 I suppose I should say something in kind. "Libes" is pronounced
151 "Lee-bis" with stress on the first syllable. Like John though, I've
152 gotten used to responding to anything close.
154 By the way, notice the date on this message. I had only written
155 the first cut of Expect four months earlier. I asked John how to
156 pronounce his name because I had already got a paper accepted into
157 USENIX and needed to be able to say his name correctly while giving
162 ======================================================================
164 #3. Why should I learn yet another language (Tcl) instead of
165 writing my interaction in <a language I already know>?
167 From: libes (Don Libes)
168 Subject: Re: Expect, Tcl, programmed dialogue etc.
169 Date: Mon, 2 Sep 91 15:47:14 EDT
171 >>>A friend told me about "Expect". But then, I have to know the
172 >>>idiocies of "tcl". I would like to know if there is an alternative
173 >>>to Expect that is also useful in other places, so that I do not
174 >>>have to spend time getting used to tcl for just this one tool.
176 >>Your reasoning is shortsighted. Tcl is a language that can be used in
177 >>other applications. It won't be a waste of your time to learn it.
179 >I have nothing against tcl as such.
180 >The reluctance to learn it comes mainly from the feeling that half my
181 >life seems to be spent learning new languages that differ very little
182 >from existing ones, and differ in annoying little details at that.
183 >To add to the misery, every implementation has its own
184 >idiosyncracies...:-(
186 Ironically, Tcl was written specifically to halt this very problem.
188 The author recognized that every utility seems to have its own
189 idiosyncratic .rc file or programming language. Tcl was designed as a
190 general-purpose language that could be included with any utility, to
191 avoid having everyone hack up their own new language.
193 In this context, your statements do Tcl a great disservice.
197 ======================================================================
201 From: libes (Don Libes)
202 To: Joe McGuckin <joe@ns.via.net>
203 Subject: Re: Need Perl examples
204 Date: Sun, 22 Jan 95 20:17:39 EST
208 >Yeah, I've scanned through your book a couple of times in the last
209 >week, trying to make up my mind if I should buy it.
211 I spent three years writing it - so I'm glad to hear you're spending a
212 little time considering its merit!
215 > Looks like implementing some sort of telnet daemon would be trivial.
217 Once you see it as an Expect script, you'll realize how trivial
218 these things can really be.
221 > Yet another language to learn. I know perl reasonably well & would
222 > like to stick with it.
224 Good point. While I'm not a Perl guru, I've used it quite a bit
225 and it's nice for many things. But I wouldn't have bothered writing
226 Expect in the first place if I thought Perl was ideal. And many Perl
227 experts agree - I know a lot of them who call out to Expect scripts
228 rather than do this stuff in Perl - it's that much easier with Expect.
229 Expect is also much more mature. It's portable, stable, robust, and
230 it's fully documented - with lots of examples and a complete tutorial,
233 In response to someone complaining about how difficult it was to do
234 something in Perl, Larry Wall once remarked: "The key to using
235 Perl is to focus on its strengths and avoid its weaknesses." That
236 definitely applies here.
238 Even if you do proceed with Perl, you will find the book
239 helpful. Automating interactive applications has unique pitfalls to
240 it and many of the descriptions and solutions in the book transcend
241 the choice of language that you use to implement them.
245 ======================================================================
247 #5. Do we need to pay or ask for permission to distribute Expect?
249 From: libes (Don Libes)
250 To: Mohammad Reza Jahanbin <mrj@CIS.Prime.COM>
251 Subject: Copyright Question.
252 Date: Tue, 26 Jan 93 23:46:24 EST
254 Mohammad Reza Jahanbin writes:
255 >Before anything let me thank you on behalf of ComputeVision R&D for
256 >putting so much effort into Expect. Part of CV has been using Expect
257 >for the past two years or so to build variety of tools including an
258 >automated testbed for a product.
260 >CV is currently considering shipping the automated testbed to some of its
261 >retailers, to enable them to perform their own tests before distributing
264 >The Question is, are we allowed to ship Expect? Do we need to ask
265 >anyone for permission? Do we need to say or write anything in the
266 >documentation? Do we need to pay for it?
268 >I have not been able to find any copyright (or indeed copyleft) notices
269 >in the usual Expect distribution. Would you be able to clarify our position.
271 It is my understanding that you are allowed to do just about anything
272 with Expect. You can even sell it. You need not ask our permission.
273 You need not pay for it. (Your tax dollars, in effect, already have
276 You should not claim that you wrote it (since this would be a lie), nor
277 should you attempt to copyright it (this would be fruitless as it is a
278 work of the US government and therefore not subject to copyright).
280 NIST would appreciate any credit you can give for this work. One line
281 may suffice (as far as I'm concerned) although there should be
282 something to the effect that this software was produced for research
283 purposes. No warantee, guarantee, or liability is implied.
285 My management is always interested in feedback on our work. If you
286 would like to send letters of praise describing how Expect has helped
287 your business, we would be delighted. Letters (on letterhead please)
288 are strong evidence used by policy makers when deciding where every
289 dollar goes. If you want to send these letters to NIST directly, you
290 may send them to the following individuals:
292 Robert Hebner, Director
294 Admin Bldg, Rm A-1134
295 Gaithersburg, MD 20899
297 Ric Jackson, Manufacturing Engineering Laboratory
300 Gaithersburg, MD 20899
302 Steve Ray, Manufacturing Systems Integration Division
305 Gaithersburg, MD 20899
307 Amy Knutilla, Manufacturing Collaboration Technologies Group
310 Gaithersburg, MD 20899
312 In case you're wondering about the uninformative titles, Robert Hebner
313 is the director of all of NIST (about 3000 people) and
314 Amy Knutilla (way down there at the bottom) is my immediate supervisor.
316 I hope this has answered your questions. Let me know if you have
321 ======================================================================
323 #6. Since Expect is free, can we give you a gift?
325 This is not an actual letter but represents the gist of several
328 >>>Expect has saved us many thousands of dollars. We'd like to send
329 >>>you a free copy of our product.
331 >>Thanks, but please don't. As a federal employee, I'm not
332 >>allowed to accept gifts of any significant value.
334 >But, what if it is for personal use (like at home)? I assume
337 It doesn't matter (much). What the rules address is whether a gift
338 might cause me to make an official decision differently. This is
339 especially a concern because I may very well have to decide whether or
340 not to buy products from your company in the future.
342 There is a clause that says "you may accept gifts from friends,
343 regardless of value ... but you should be careful to avoid accepting
344 gifts which may create an appearance of impropriety, even if permitted
345 as an exception to the gift rules."
347 I'm still permitted to accept small token gifts, such as a t-shirt
348 or reasonably-priced dinner (under $20 per gift to a maximum of $50
349 per year from any person or company) - so things are not totally
350 ridiculous. Although the precise values in the gift rules seem rather
351 arbitrary, I actually like the gift rules. They stop a lot of the
352 nonsense that used to go on involving gifts.
356 ======================================================================
358 #7. Are there any hidden dangers in using Expect?
360 From: Charlton Henry Harrison <charlton@cs.utexas.edu>
362 Date: Fri, 27 Jan 1995 23:30:56 -0600
366 >>> I've been a fan of Expect ever since I first learned of UNIX back
367 >>>in late '93. I'm young and don't have my CS degree just yet, but I worked
368 >>>a while back at Texas Instruments in their Telecom Customer Support dept.
369 >>>I started in late '93 (and hence, that's where I first started exploring
370 >>>the UNIX environment) and immediately forsaw the need of automating a lot
371 >>>of my redundant and mindless duties, but I didn't know how since we were
372 >>>working over a heterogeneous LAN with multiple OSs.
373 >>> Then I found out about Expect. I automated everything! My boss didn't
374 >>>like hearing that I was working on something else in order to get out of
375 >>>work, and I got tired of explaining it to him.
376 >>> Although I accomplished all the aspects of my duties, I was infamous
377 >>>for being the laziest person at work, and it showed (I made my job SO easy).
378 >>>I got a new boss after a while, and he hated me from the start and fired
379 >>>me soon after. Oh well, I guess my mentality didn't click with theirs.
380 >>> There are a lot of people like that: they believe life is putting
381 >>>in a hard day's work to get by. I hate that.
382 >>> So the point is, thank you for the wonderful 'Expect'. I bought
383 >>>your book and now I have the most recent version of it on my Linux system
384 >>>at home. Needless to say I'm looking for another job, though.
388 >> Thanks very much for your nice letter. Sorry to hear about your
389 >> automating yourself out of a job. Actually, I think most computer
390 >> scientists have to face this dilemma. In some ways, it's a
391 >> self-defeating occupation.
395 >Yeah, I'd be interested in hearing if you have a personal philosophy on
396 >how to handle this kind of thing. I plan on pursuing a career in Artificial
397 >Intelligence for similar reason of making life easier for everyone (me
398 >in particular!) What the future holds in this category is a great
401 I'm glad you asked. My personal philosophy on this kind of thing is:
402 Find someone really rich and marry them.
406 ======================================================================
408 **** Book, newsgroup, FAQ, README, ... ****
411 #8. Why is this FAQ so short?
413 From: libes (Don Libes)
414 To: Wade Holst <wade@cs.ualberta.ca>
415 Subject: Expect question
419 > 1) Is there a more up-to-date version of the FAQ than what
420 > comes with expect-5.5? (For such a useful application, I
421 > would expect more than 12 questions).
423 I know that a lot of other packages have *huge* FAQs but I
424 have always believed that this is an indication that their regular
425 documentation sucks. As questions arise that are not addressed well
426 by the original docs, the docs themselves should be fixed rather than
429 In contrast, I believe that an FAQ should literally be a list of
430 frequently asked questions and little else. An FAQ should not be a
431 replacement for good documentation.
433 In that sense, I have tried to use this FAQ as a second place to
434 look rather than a first place. The place you should always look
435 first is Exploring Expect. At over 600 pages, the book is very
436 comprehensive, well-organized, and includes three indices and two
437 tables-of-contents to make it very easy to find what you want to know.
439 The book was not a rush job. During the three years I spent
440 writing it, virtually every question I was asked became incorporated
441 as subject material for the book. I wanted to make sure that the book
442 wouldn't need much of an FAQ!
444 It would not make sense to try and distill the entire book into an
445 FAQ (that is actually comprehensive rather that truly frequently asked
446 questions). There's simply too much material there.
448 So this FAQ is short. It really tries to stick just to *truly*
449 frequently asked questions.
453 ======================================================================
455 #9. How was this FAQ created?
457 The Expect FAQ is regularly recreated by a Tcl script which
458 produces either text or HTML depending on how it is called. Using Tcl
459 has two nice results:
460 + I didn't have to choose one format and worry about
461 converting it to the other. (Remember that the FAQ appears in HTML on
462 the web and it appears in text in the Expect distribution.) The more
463 common approach - doing conversions in either direction - is really
464 painful - plus, it's now easy to generate other formats, too.
465 + It's much, much easier to keep track of questions and
466 answers. For example, when I add a new question, I don't have to add
467 it twice (once at the top and again later with the answer), nor do I
468 have to worry about making the links between them. All this and a lot
469 of other stuff is handled automatically - and the source is much more
470 readable than the actual HTML.
473 You can read about these ideas in a paper that appeared at Tcl '96
474 called Writing CGI Scripts in Tcl. (CGI scripts are the primary focus of the
475 paper, but it also spends time on HTML generation for other purposes -
476 including the example of highly stylized documents like FAQs.)
478 I encourage you to examine the source to this FAQ - it
480 + Expect-specific FAQ source
481 + Generic FAQ Builder source
483 The generic FAQ builder has also been used to build several other
484 FAQs (unrelated to Expect).
488 ======================================================================
490 #10. The background makes the FAQ hard to read.
492 To: bonneau@mudd.csap.af.mil (Allen Bonneau)
493 Subject: FAQ background colors
494 Date: Wed, 10 Apr 96 10:24:52 EDT
496 Allen Bonneau writes:
497 >... the white and gray background makes the FAQ difficult to read.
499 It's not white and gray. It's several very close shades of gray.
500 It's supposed to be very subtle. Sounds like you have your browser in
501 a mode where it is mishandling colors. Turn on dithering and
502 restart your browser.
506 ======================================================================
508 #11. Why isn't there an Expect mailing list?
510 From: libes (Don Libes)
511 To: dclark@nas.nasa.gov (David R. Clark)
512 Subject: Mailing list for Expect
513 Date: Mon, 23 Sep 91 18:21:28 EDT
515 >Would be nice if their were an Expect mailing list. I would use it more
516 >often, and be made aware of other users.
518 Perhaps I'm too myopic, but I don't see the need for it. Most of
519 the questions about Expect posted to Usenet every day can be found in
520 the various FAQs or in the book, so it's pretty easy getting
523 For one reason or another (occasionally a bug fix, but often, just
524 adding a neat example), I update Expect every couple of weeks.
525 Personally, I'd hate being on the other end of something like this.
526 Who needs patches every two weeks for problems that are likely not
527 even relevant to you? (Most patches these days are either extremely
528 esoteric or are related to porting Expect to some unusual machine.)
530 >It would be helpful, too, if this served as an area for swapping programs.
531 >Many of the things that I want to do are done by others already.
533 NIST doesn't distribute software written by other people but if
534 you've got relatively small scripts that show off unique ideas and
535 techniques that would be educational for the Expect community, I can
536 include your script with Expect or put it in a publicly accessible
537 directory so other people can get it. I'm also willing to list links
538 in Expect's home page to other web pages about projects that use
541 There is a Tcl newsgroup, comp.lang.tcl, which many Expect users
542 read. It's pretty good for asking questions about Tcl, and many of
543 the readers use Expect so Expect questions are encouraged. The
544 newsgroup is gatewayed to a mailing list (tcl@sprite.berkeley.edu)
545 which is further described in the Tcl documentation.
549 ======================================================================
551 #12. Why isn't overlay covered in Exploring Expect?
553 To: spaf@cs.purdue.edu
555 Gene Spafford writes:
556 >I'm curious as to why the "overlay" command is not mentioned anywhere
557 >in the book. Is that a recent addition? A deprecated feature? I
558 >ended up using it in one of my scripts....
560 The overlay command has been in Expect for a long time. In all that
561 time no one has ever asked me about it and I have never used it.
562 Well, I used it once but I really didn't like the result, and so I
563 rewrote the script to not use it. I left the overlay command in
564 Expect because it seemed like an interesting idea, but I never really
565 finished it - in the sense that I believe it needs some more options
566 and controls. In comparison, the interact command is very flexible
567 and makes the need for overlay pretty moot.
571 ======================================================================
573 #13. Is the front cover of your book a self portrait (ha ha)?
575 From: libes (Don Libes)
576 To: pkinz@cougar.tandem.com (kinzelman_paul)
579 kinzelman paul writes:
580 >The book finally came in. I tried to buy 4 copies but they had only 2
581 >left and they came in last Saturday. Move over Stephen King! :-)
583 4 copies!? Wow. That's more than my mother bought!
585 >I was discussing your book with somebody who stopped in and we began
586 >to speculate about the monkey on the cover. I don't suppose it's a
589 There is some real humor here. There seems to be considerable
590 debate over what the creature is! The colophon at the end of the book
591 says that it is a chimpanzee. I like that idea much more than a
592 monkey which is what it looks like to me. My wife, who has a degree
593 in zoology, explained to me that chimps are actually the second
594 smartest of primates (humans are the smartest). Chimps are very
595 intelligent and can do many things (but not everything) that humans
596 do. Perfect for describing Expect. Anyway, she says I should be
597 honored to have it grace the cover - even in theory.
599 I remarked to Edie (the cover designer at O'Reilly) that even though
600 the cover was nice looking, everyone was going to stare at it and say,
601 "Gee, but it looks like a monkey." She replied "The purpose of the
602 cover is just to get people to pick the book up. This cover will do
603 that. Don't worry. If you get any rude comments from anyone, at least
604 you know they are paying attention."
606 [After being inundated by people pointing out that the animal
607 really is a monkey, O'Reilly subsequently decided to acquiesce and has
608 changed the colophon to admit that yes it is a rhesus monkey.
609 Evidentally, the book from which O'Reilly has been taking those
610 pictures from was wrong on this one.]
614 ======================================================================
616 #14. Why don't the examples in your USENIX papers work?
618 From: libes (Don Libes)
619 To: Will Smith (AC) <william@ritchie.acomp.usf.edu>
622 Will Smith (AC) writes:
623 >I just entered some scripts from a USENIX paper that my boss had. I get
624 >errors about my quotes in the script. Also, it doesn't seem to know
625 >about expect_match. Thanks in advance for any insight you could offer.
627 The USENIX papers are old and out-of-date as far as quoting goes. A
628 couple years ago, I cleaned up and simplified this aspect of Expect.
629 Similarly, expect_out is now where the results of expect's pattern
632 The man page is always the best reference on what Expect currently
633 supports. Alternatively, you can read the CHANGES files. These files
634 document the changes from one major version to another.
638 ======================================================================
640 #15. Can you put the examples in your book into an anonymous ftp site?
642 From: libes (Don Libes)
643 To: pren@cs.umass.edu
644 Subject: Examples in your book "Exploring Expect"
650 >I bought your book "Exploring Expect" from O'Reilly.
651 >I wonder can you put the eamples in your book into an anonymous ftp
654 All of the substantive examples come with recent versions of Expect.
655 Just look in the example directory.
657 The remaining 50 or so examples are short enough that typing them
658 in only takes a minute or two. If I put them online, you'd spend more
659 time looking for them (reading my online catalog, figuring out what
660 the online descriptions meant, mapping them back to the file, etc.)
661 then it would take to type them in. And since you're likely to want
662 to change the examples anyway, there's nothing to be gained for short
667 ======================================================================
669 #16. Do you have ideas for more articles on Expect?
671 From: libes (Don Libes)
672 To: faught@zeppelin.convex.com (Danny R. Faught)
674 Subject: Re: SQA Quarterly articles
675 Date: Thu, 21 Dec 95 13:31:01 EST
677 Danny R. Faught writes:
678 >I just arranged to write an article on automating interactive
679 >processes for an issue early next year. You have so many good pieces
680 >on expect out there, it's going to be hard to add anything original.
682 One thing I've never written is a good mini-tutorial. Magazine
683 editors love these types of pieces and there's certainly a need for
684 it. So I'd encourage that type of article.
686 Another possibility is an article on how you or your colleagues
687 personally applied Expect to solve your particular problem. Application-
688 oriented papers are the kind that necessarily have to be written by
689 people in the field who are applying the technology. People love this
690 kind of practical paper. For example, a good paper might be "Writing
691 a pager". This is a nice topic because you can start with a simple
692 5-line script that solves the problem and then show progressive
693 refinements that handle different twists on the same problem. (And
694 "how to write a pager" is a very frequently asked question on Usenet.)
698 ======================================================================
700 **** Can Expect do this? ****
703 #17. Can Expect automatically generate a script from watching a session?
705 From: libes (Don Libes)
706 To: pete@willow24.cray.com
708 Date: Fri, 12 Oct 90 17:16:47 EDT
710 >I like "Expect" and am thinking of using it to help automate the
711 >testing of interactive programs. It would be useful if Expect had a
712 >"watch me" mode, where it "looks over the shoulder" of the user and
713 >records his keystrokes for later use in an Expect script.
715 >(Red Ryder and other Macintosh telecommunications packages offer this
716 >sort of thing. You log onto Compuserve once in "watch me" mode, and
717 >RR keeps track of the keystrokes/prompts. When you're done you have a
718 >script that can be used to log onto Compuserve automatically.)
720 >Before I look into adding a "watch me" feature, I thought I should
721 >ask: has this been done already?
723 >I'll say again that I like the tool a lot--nice work! There are other
724 >people here using it for things like the testing of ksh, which
725 >responds differently to signals when not used interactively.
729 The autoexpect script in Expect's example directory does what you
734 ======================================================================
736 #18. Can Expect understand screen-oriented (Curses) programs?
738 Yes, it can - with a little clever scripting. Look at the
739 term_expect script for an example. It uses a Tk text widget to
740 support screen-oriented Expect commands. This technique is described
741 very thoroughly in Chapter 19 of Exploring Expect.
743 Adrian Mariano (adrian@cam.cornell.edu) converted the term_expect
744 code (see above) so that it runs without Tk (exercise 4 in Chapter
745 19!) Both term_expect and virterm can be found in the example
746 directory that comes with Expect.
748 An alternative approach to screen-handling was demonstrated by Mark
749 Weissman (weissman@gte.com) and Christopher Matheus who modified a
750 version of Expect to include a built-in Curses emulator. It can be
751 ftp'd from the Tcl archive as expecTerm1.0beta.tar.Z. (Note that
752 Expecterm does not run with the current version of Expect.)
754 I like the idea of keeping the curses emulator outside of Expect
755 itself. It leaves the interface entirely defineable by the user. And
756 you can do things such as define your own terminal types if you want.
757 For these reasons and several others, I'm not likely to return to
762 ======================================================================
764 #19. Can Expect be run as a CGI script?
766 Expect scripts work fine as CGI scripts. A couple pointers might
767 help to get you going:
769 Many Expect scripts can be run directly with one change - the
770 following line should be inserted before any other output:
772 puts "Content-type: text/html\n"
774 Be sure not to forget that extra newline at the end of the puts.
776 Next, make sure you invoke external programs using full paths. For
777 example, instead of "spawn telnet", use "spawn /usr/ucb/telnet" (or
778 whatever). Remember that the PATH and other environment variables are
779 going to be different than what you are used to. This is very similar
780 to dealing with cron and you can get other good tips and advice from
781 reading the Background chapter in the book.
783 Another tip: If a script runs fine by hand but not from CGI, just
784 log in as "nobody" to the host on which your CGI script runs. Then
785 try running it by hand. This generally makes it very obvious what's
786 going on. (If you can't log in to the server or can't log in as
787 "nobody", use the kibitz trick described in the Background chapter.)
789 You may find it helpful to use cgi.tcl, a nice collection of
790 CGI support utilities for Tcl scripts. It includes an Expect example
791 among many others. The package includes just about everything:
792 tables, frames, cookies, file upload, etc...., with some nice
793 debugging support. It's pure Tcl, no C code - so it's very easy to
798 ======================================================================
800 #20. Can Expect act like a browser and retrieve pages or talk to a CGI script?
802 From: jasont@netscape.com (Jason Tu)
803 Date: Sat, 02 Nov 1996 09:51:03 -0800
805 I read your book "Exploring Expect" and find Expect is just the tool
806 to test Netscape's enterprise server product, since it is very easy to
807 use and quick to develop. I figured I would use telnet to send HTTP
808 protocol dialog to a HTTP server and simulate how it behaves. But I
809 couldn't get it to work at all. I am wondering that there might be a
810 quick example that you can share with me.
812 Yes, this is a useful way of testing HTTP servers and running CGI
813 scripts (and winning Web contests :-). You can add error checking and
814 other stuff, but here's the minimum your script should have to read a
819 spawn telnet $host 80
820 expect "Escape character is *\n"
823 puts "$expect_out(buffer)"
825 If you want to communicate information to a CGI script, you'll want
826 more. One way to see what needs to be sent is to load a real browser
827 with the form and then send it to a fake daemon such as this one:
830 /bin/cat -u > /tmp/catlog
832 Enable this by adding this service to inetd. Then save the form in
833 a temporary file, modify the form's host and port to correspond to
834 your own host and whatever port you've chosen to associate with your
835 fake daemon. Now fill out the form and you'll find the form data in
836 /tmp/catlog. Using this, you can determine exactly how to amend your
837 Expect script to behave like your browser.
841 ======================================================================
843 #21. Can Expect be run from cron?
845 Expect itself works fine from cron - however, you can cause
846 problems if you do things that don't make sense in cron - such as
847 assume that there is a terminal type predefined. There are a number
848 of other pitfalls to watch out for. The list and explanations aren't
849 short - which is why there's a whole chapter ("Background") on the
852 Here's one that someone tried to stump me with recently: They told
853 me that their program started up and then Expect immediately exited.
854 We spent a lot of time tracking this down (Was the spawned program
855 really starting up but then hanging - which would indicate a bug in
856 the program; or was the program NOT starting up - which would indicate
857 a bug in the environment; etc.) Turned out that Expect wasn't even
858 running their program. They had assumed cron honored the #! line
859 (which it doesn't) and so the first line in their script (exec date)
860 was being interpreted by the shell and of course, the script did
861 nothing after that - because that's what the shell's exec is supposed
866 ======================================================================
868 #22. Why does my Expect script not work under inetd?
870 From: dpm@bga.com (David P. Maynard)
871 Subject: Re: Tcl/Expect, inetd service, and no echo password
872 Date: 24 Oct 1996 13:34:57 -0500
874 In article <54ocsh$9i1@urchin.bga.com> dpm@bga.com (David P. Maynard) writes:
875 I am fairly new to expect, so hopefully this isn't too obvious. I also
876 confess to not having looked in "Exploring Expect" becuase I haven't
877 found it in stock at a local bookstore yet.
879 I want to write an expect script that runs as a service from inetd.
880 (Actually, I plan to use the tcpd 'twist' command to launch the
881 binary, but that doesn't seem to affect the problem.) The script will
882 prompt the user for a password. The supplied password is used as a
883 key to decrypt some passwords stored online. The script then fires
884 off a telnet session to a remote box and does some fairly simple
885 things that require the decrypted passwords.
887 I have all of this working when I run the script from a UNIX prompt.
888 However, when I run it out of inetd, the 'stty -echo' commands that
889 turn off character echo when the user types the password fail with the
892 stty: impossible in this context
893 are you disconnected or in a batch, at or cron script?
894 stty: ioctl(user): Bad file descriptor
896 I can understand the cause of the message (no associated tty), but I
897 can't think of an easy solution. If I use 'gets' or 'expect_user,'
898 the user's input is always echoed. I tried a few variations on the
899 stty command, but didn't have any luck.
903 Yes, read Exploring Expect, Chapter 17 (Background Processing). In
904 the section "Expect as a Daemon", there's a very thorough discussion
905 of this problem and how to solve it.
908 In short, there's no tty when you run a process from inetd. Echoing
909 is controlled by the telnet protocol, so you must send and expect
910 telnet protocol packets to solve the problem. Even knowing this, the
911 actual implementation is very non-obvious which is why the book goes
912 into it in such detail.
916 ======================================================================
918 **** Compilation or porting questions ****
921 #23. Why can't I compile Expect with Tcl 8.0?
923 Sounds like you have an old version of Expect. Get a a new version of Expect.
927 ======================================================================
929 #24. Does Expect 5.26 work with Tcl/Tk 8.0.3?
932 Subject: Re: Expect 5.26 and TCL 8.0
933 Aspi Siganporia writes:
937 >We are looking at upgrading Expect. Our last version was Expect5.22
939 >I see that Expect5.26 supports TCL 8.0.
943 >Will it work with TCL8.0.3?
948 It might. 8.0.3 broke a couple of the more esoteric configurations.
949 If you find that you can't compile using 5.26, get 5.27.
953 ======================================================================
955 #25. Why can't I compile Expect with Tcl/Tk 8.1aX?
957 Historically, I've rarely found the time to port Expect to alphas
958 and betas. I recommend you stick with 8.0 unless you're willing to do
963 ======================================================================
965 #26. Why can't I compile Expect with Tcl/Tk 8.0b1?
967 I don't see the point in supporting an old beta. Upgrade to the
968 production release of Tcl/Tk 8.0.
972 ======================================================================
974 #27. Why does Expect need to be setuid root on Cray?
976 From: libes (Don Libes)
977 To: u70217@f.nersc.gov (Lori Wong)
978 Subject: setuid in Expect
979 Date: Thu, 24 Oct 91 16:15:20 EDT
981 > I have been running Expect now under UNICOS 6.1 and CSOS 1.0 (Cray
982 >Computer Corporation's OS). The two machines that I am running Expect
983 >on have stringent security features, one of which is to limit setuid
984 >privileges to specific individuals. I was wondering if you would be
985 >kind enough to explain the purpose of the setuid that is needed by Expect
986 >and whether it could be compiled to run without having to have setuid
987 >privilege? I know it has to do with spawning and communicating with
988 >the various spawned tasks, but don't know enough of the details to be
989 >able to explain why Expect specifically needs setuid and whether or not
990 >it could cause a security problem (could someone use it to enter into
991 >the system and wreak havoc, for example?). Right now, I've limited
992 >the access of Expect to my group, but need to know what the security
993 >implications are if I open it to all users. I'd appreciate any light
994 >you can shed on this subject...
996 Root-access is needed to open a pty under Unicos. Thus, all programs
997 accessing ptys must be setuid root. If you do an "ls -l" of programs
998 like "script", "xterm", etc, you'll see this.
1000 I have no idea why this is. The requirement was probably for security
1001 reasons to begin with, but it has the ironic effect of making more
1002 programs require setuid and therefore greater possibility of errant
1005 In fact, there is one known Unicos bug relating to the way uids are
1006 switched at exec time which requires further special coding. If you
1007 search for "Cray" in the Expect source you will see significant chunks
1008 of code to get around the problem.
1010 I don't know if this reassures you any. All I can tell you is that a
1011 number of Cray experts have looked into the situation and are happy
1012 with the current implementation of Expect.
1016 ======================================================================
1018 #28. Does Expect run on VMS?
1020 From: libes (Don Libes)
1021 To: Cameron Laird <claird@Starbase.NeoSoft.COM>
1022 Subject: VMS question.
1024 Cameron Laird writes:
1025 >Do you know of anyone working with Expect and VMS?
1026 >I'd like not to re-invent wheels, but, if I'm to be
1027 >the first one, I want others to benefit.
1029 No, I'm not aware of anyone doing it. Since VMS claims POSIX
1030 conformance, it shouldn't be that hard - Expect uses the POSIX calls
1031 if it can. Probably the hardest part will just be modifying the Makefile
1032 and the configure script!
1034 However, that there might be a simpler solution. The neat thing
1035 about Expect is that you can control other computers easily. Run
1036 Expect on your UNIX box and have it log in to the VMS box and do its
1037 thing. (You can bypass the login garbage by using an inet daemon.)
1038 We've done exactly this to a number of weird pieces of hardware we
1039 have around the lab (robots, Lisp machines, embedded controllers, and,
1040 of course, a VAX running VMS). It saves time porting!
1044 ======================================================================
1046 #29. Is it possible to use Expect and TclX together?
1048 Is it possible to use Expect and TclX together?
1049 From: bfriesen@iphase.com (Bob Friesenhahn)
1050 Date: 20 Jul 1994 04:09:43 GMT
1051 Organization: Interphase Corporation, Dallas TX - USA
1053 Jeffery A. Echtenkamp (echtenka@michigan.nb.rockwell.com) wrote:
1054 : Do Expect and tclX work together? If so, must anything special be done to
1055 : get them to work together?
1057 This answer courtesy of Bob Friesenhahn, Interphase (bfriesen@iphase.com):
1059 They work fine together. However, you should prepend "exp_" to your Expect
1060 command names. This will ensure that there are no conflicts between Expect
1061 commands and tclX commands of the same name (like wait).
1063 Just pick up the "make-a-wish" package, follow the instructions, and you will
1064 be all set. I have built a wish based on tcl, tk, Expect, tclX, and dp using
1065 this technique with no observed problems.
1069 [If you need additional information, please read Chapter 22
1070 ("Expect as Just Another Tcl Extension") of Exploring Expect. Its
1071 sole focus is how to make Expect work with other extensions. - Don]
1072 ======================================================================
1074 #30. Is it possible to use Expect and <lots of random extensions> together?
1076 From: libes (Don Libes)
1077 To: Frank Winkler <winkler@eas.iis.fhg.de>
1078 Subject: Q Expect + TkSteal
1080 Frank Winkler writes:
1083 >a short question considering installation of Expectk.
1085 >Is it possible to build an Expectk-binary, which uses
1086 >the features of BLT, TkSteal and Expect ?
1088 I've never done it, but I know it must be possible because the tgdb
1089 package in the Tcl archive uses all of those extensions with Expect.
1091 Expect is a "well-behaved extension" in the sense that it requires no
1092 changes to the Tcl core. So Expect should work with any other Tcl
1093 extensions. You just need to add the usual Exp_Init call to main() or
1094 the other _Init calls to Expect's main.
1096 >If yes, which of them should be build first, second ... ?
1098 Order doesn't matter.
1100 I've done this kind of thing by hand. It's pretty simple. But people
1101 tell me the make-a-wish package in the Tcl archive automates the
1102 creation of multi-extension Tcl applications.
1104 [Also see the answer to the previous FAQ answer.]
1108 ======================================================================
1110 #31. Why does configure complain about "cross-compiling"?
1112 From: libes (Don Libes)
1113 To: morton@hendrix.jci.tju.edu (Dan Morton)
1114 Subject: Re: Sorry to bother you, but...
1119 >I've posted an inquiry to comp.lang.tcl about my configure problems with
1120 >expect, but I've not yet gotten a reply. Perhaps you can nudge me in the
1123 >I'm running HP-UX 9.0 on a 735, and I've snagged the latest versions of Tcl
1124 >and expect from NIST (7.4 and 5.18 respectively). My gcc is v2.6. Tcl
1125 >configured and built out of the box, but I can't get expect to configure
1126 >properly. No matter what I do, it thinks it wants to cross-compile. I
1127 >think it's failing that little snippet of eval code. It gets further if I
1128 >specify --host=HP, but still complains about cross compiling. Here's the
1129 >result without options:
1131 >{hendrix:~/expect-5.18:8} ./configure
1132 >checking for gcc... gcc
1133 >checking whether we are using GNU C... yes
1134 >checking whether gcc accepts -g... no
1135 >checking how to run the C preprocessor... gcc -E
1136 >checking whether cross-compiling... yes
1137 >checking whether cross-compiling... (cached) configure: error: You need to
1138 >specify --target to cross compile,
1139 > or the native compiler is broken
1141 I guess the error message has to be clearer. The message:
1143 "or the native compiler is broken"
1145 means that configure tried to compile a simple program and it failed.
1146 Here's the program it tries to compile:
1152 The configure output that you showed me says that it found gcc.
1153 Perhaps it was misinstalled or is just a placeholder and doesn't
1154 actually do anything? Try compiling a tiny C program yourself from
1159 ======================================================================
1161 #32. Why are make/configure looping endlessly?
1163 To: Xiaorong Qu <aqu@cisco.com>
1164 Subject: Make message for Expect
1165 --text follows this line--
1169 >The following is the output of make, you can find
1170 >that the process repeated three times.
1172 I bet what's going on is that your system clock is set to some
1173 ridiculous time such as last year. "Make" is sensitive to your clock.
1174 Please fix your clock. Then check that all the files are "older"
1175 than the current time. (If not, "touch" them all.)
1179 ======================================================================
1181 #33. Why does compile fail with: Don't know how to make pty_.c?
1183 From: libes (Don Libes)
1184 To: wren@io.nosc.mil
1185 Subject: Compile fails with: Don't know how to make pty_.c
1187 > I'm trying to compile Expect on hpux 9.01,
1188 > downloaded from ftp.cme.nist.gov expect.tar
1190 > after running config
1191 > the make fails with "Don't know how to make pty_.c. (compile fails)
1192 > I see three versions pty_sgttyb.c, pty_termios.c and pty_unicos.c in
1193 > the load, but the configure picked none of them.
1194 > I tried forcing to pty_termios.c but that failed with other compile errors.
1196 I've seen this happen because gcc was partially installed. configure
1197 finds the gcc stub and uses gcc for all the tests. But because the
1198 compiler doesn't work, every test fails so configure doesn't select
1201 So either finish installing gcc or delete the stub.
1203 (And if it's not that, then something similar is wrong with whatever
1204 compiler you've got. Look closely at the output from configure, it
1205 will tell you what compiler it is trying to use.)
1207 By the way, Expect compiles fine on my HP (A.09.05 E 9000/735).
1211 ======================================================================
1213 #34. Does Expect run on MSDOS, Win95, WinNT, MacOS, etc...?
1215 Gordon Chaffee has ported Expect to NT. I would like to unify the
1216 UNIX and NT code but I probably won't have the time to do this
1217 personally. Volunteers are welcome.
1219 I have no plans to do other ports. Feel free to volunteer.
1223 ======================================================================
1225 #35. Why does Expect dump core? Why can I run Expect as root but not as myself?
1227 From: Wayne Tcheng <wmt@visi.net>
1228 Subject: Expect on Solaris
1229 Date: Wed, 2 Apr 97 21:34:50 EST
1231 I've compiled Expect 5.21 with Tcl 7.6 and Tk 4.2. Whenever I run Expect
1232 as a non-root user, it core dumps. When I am root, I can run it
1233 successfully. However, if I "su - wmt" to my own id, I can also run it
1234 without a problem. I've tried making the expect binary suid root, but
1235 that does not help either. I'm on Solaris 2.5. Any ideas?
1237 Sounds like something on your system is misconfigured. Everytime
1238 I've had reports like this (works as root, not as user), it's turned
1239 out to be /tmp was unwriteable or something equally improbable.
1241 The easiest way to find out is to use the debugger and tell me where
1242 Expect is dumping core. (If you don't understand this statement, ask
1243 a local C or C++ programmer.)
1245 As an aside, you should be using the most recent version of Expect
1246 (currently 5.22.1). But I don't know of any problems in 5.21 that
1247 caused core dumps, so it's certainly worth trying the debugger
1248 approach before retrieving the latest version. But if you do find a
1249 bug in Expect, before reporting it, please verify that it still exists
1250 in the current version.
1254 ======================================================================
1259 #36. Is it possible to prevent Expect from printing out its interactions?
1261 From: libes (Don Libes)
1262 To: Sunanda Iyengar <sunanda@simvax.labmed.umn.edu>
1263 Subject: Disabling display from Expect
1265 Sunanda Iyengar writes:
1266 >Is it possible to have Expect interact with a process and not print-out
1267 >the results of interaction? In my application, I need it to go into a
1268 >silent mode, communicate with a process without reporting to the user, and
1269 >then come back to normal mode and put the process into interactive mode.
1271 Use the following command:
1279 See the Expect man page for more details or page 175 of Exploring
1280 Expect for details and examples.
1284 ======================================================================
1286 #37. Why does it send back the same string twice?
1289 To: yusufg@himalaya.cc.gatech.edu (Yusuf Goolamabbas)
1290 Subject: Duplicate pattern matches in Expectk
1291 --text follows this line--
1292 Hi, I am trying to do a very simple thing in expectk
1295 expect_background -re ".+" {
1296 send $expect_out(0,string)
1298 exp_send "Hello World\n"
1300 Now the display in the text widget looks like this
1304 whereas I was expecting only one line
1307 Thanks in advance, Yusuf
1309 Yusuf Goolamabbas yusufg@cc.gatech.edu
1310 Graphics, Visualization, & Usability Center (O) 404.894.8791
1311 College of Computing Georgia Tech
1312 http://www.cc.gatech.edu/grads/g/Yusuf.Goolamabbas/home.html
1314 This is correct behavior. The first "Hello World" is echoed by the
1315 terminal driver. The second is echoed by cat. This behavior has
1316 nothing to do with Expectk (or Expect for that matter). You can see
1317 this same thing if you type to cat interactively.
1323 In the example above, I typed "cat" at the shell prompt and pressed
1324 return. Then I entered "Hello World" and pressed return. Looking at
1325 the output I *see* "Hello World" twice even though I only entered it
1328 You can account for this behavior in your patterns. Alternatively,
1329 just turn off the echo. In your particular case though, it's doing
1330 the right thing, showing you the result of an interactive cat just as
1331 if you had typed it yourself.
1333 In practice, this kind of problem doesn't arise - because programs
1334 like cat aren't spawned (except in very special situations). I assume
1335 that cat was just something you chose to experiment with.
1339 ======================================================================
1341 #38. Why can't I send the line "user@hostname\r"?
1343 From: libes (Don Libes)
1344 To: bt@nadine.hpl.hp.com
1345 Subject: Re: [Q] Expect, ftp and '@'
1347 > I am attempting to use Expect to perform anonymous ftp gets without
1348 >my having to type all the stuff --- I mean, waaaiiiting for the
1349 >prompt, entering a-n-o-n-y-m-o-u-s with my fat fingers, and the rest.
1351 > But I have a probleme: as I set the password to be my e-mail address:
1352 > set password "bt@hplb.hpl.hp.com"
1354 > the ftp servers seem not to receive neither my login name nor the
1355 >at-sign. Some of them do not care, some others say "ok, but don't do
1356 >that again", and the last ones throw me off.
1358 The short answer is to upgrade to Expect 5.20 or later. If you
1359 don't feel like doing this, here's the explanation for older versions
1362 spawn initializes the terminal by using your current parameters and
1363 then forces them to be "sane". Unfortunately, on your system, "sane"
1364 says to interpret the "@" as the line-kill character.
1366 The most sensible thing to do is change "sane" in your Makefile to
1367 something that makes sense. (Since you work at HP, you might also
1368 suggest that they modernize stty!)
1370 Here's an example of a replacement line for the Makefile:
1372 STTY = -DDFLT_STTY=\""sane kill ^U"\"
1374 Other alternatives are: quote the @, or use the -nottyinit flag, or
1375 set the stty_init variable.
1379 ======================================================================
1381 #39. How do I hide the output of the send command?
1383 From: tim@mks.com (Timothy D. Prime)
1384 Subject: Re: hide the text of expect's send command?
1385 Date: 29 Mar 1996 15:41:02 GMT
1387 In article <khughesDoy1yH.5zo@netcom.com>, Kirby Hughes <khughes@netcom.com> wrote:
1388 > I don't want to see (on the screen) the text sent by a "send" command. Is
1389 > there a way to hide it? "log_user 0" works for text coming back to me, but
1390 > doesn't (seem to) work for sending...
1392 > #!/usr/local/bin/expect --
1394 > spawn telnet proxy
1396 > send "c [lrange $argv 0 1]\n"
1400 This answer courtesy of Timothy Prime, Mortice Kern Systems (tim@mks.com):
1402 The output you are seeing wasn't printed by the send command.
1403 (I.e., the log_user command is working just fine.) The output you see
1404 is from the interact command. The interact command found program
1405 output and thus wrote it to the terminal so that you could see it.
1406 That's what the interact command is supposed to do!
1408 Although the expanation might take a little thought, the solution is
1409 easy. Simply put an expect command in before the command "log_user 1".
1410 Match against the last characters that you wish to suppress.
1411 ======================================================================
1413 #40. Why don't I see pauses between characters sent with send -s?
1415 From: jcarney@mtl.mit.edu (John C. Carney)
1416 Newsgroups: comp.lang.tcl
1417 Date: 12 Aug 1996 17:32:54 GMT
1418 Organization: Massachvsetts Institvte of Technology
1420 I am trying to use expect to spawn the kermit program. It then
1421 is supposed to dial the modem and procede.
1423 When I run kermit from the shell, it has no problem dialing the
1424 modem. However, when kermit is spawned by expect, it will not dial.
1426 I thought perhaps the input stream was too fast for kermit and tried
1427 send -s. I do see a long delay before the dial message is sent, but it
1428 still won't dial. Also, I would expect (no pun) that I would see the
1429 characters sent as follows:
1431 a<pause>t<pause>d<pause>t<pause> ...
1435 <long_pause>atdt ...
1437 What am I doing wrong?
1439 Thanks for you help.
1442 jcarney@garcon.mit.edu
1444 The send command doesn't wait for responses. The echoing you see
1445 is from an expect command running after send has run. At that point,
1446 all the characters have been echoed already - thus, you see the long
1447 pause (while send is running) and the rush of characters (while expect
1450 Before you ask, no, it doesn't make sense to have send pause
1451 briefly and wait for echoing. Sometimes there is no echoing. And
1452 sometimes things aren't echoed in an intuitive way. So how could send
1453 possibly know what to wait for and how long?
1455 The solution is to use the expect background command:
1456 expect_background -re .+
1458 Just put this after your spawn command and before you start sending
1463 ======================================================================
1465 #41. Why does "talk" fail with "Who are you? You have no entry utmp" or
1466 "You don't exist. Go away"?
1468 From: libes (Don Libes)
1469 To: Will Smith (AC) <william@ritchie.acomp.usf.edu>
1472 Will Smith (AC) writes:
1473 >Hi there. I was wondering if you had any ideas to why i am getting
1474 >this problem running an Expect script which tries to spawn a talk
1475 >process to myself on another machine. Would it have anything to do
1476 >with the fact that the executables are NOT installed in /usr/local/bin
1477 >or because it wasnt installed by ROOT or what. This is what my Expect
1480 >#! /home/ritchie/ops/william/test/expect -f
1482 >spawn talk william@curiac.acomp
1484 >expect {*established*}
1485 >set send_human {.1 .3 1 .05 2}
1486 >send -h "This is only a test.. I swear \ Please don't bust me with expect \n >expect "{*\r*}"
1489 >send -h "Ok, well see ya tomorrow you idiot \n"
1492 >The error i get is that it returns this when i run the script.
1494 > Who are you? You have no entry in /etc/utmp! Aborting...
1496 On most systems, Expect does not automatically make a utmp entry. (A
1497 utmp entry normally indicates login information which seems kind of
1498 pointless for Expect scripts.) This allows Expect to run non-setuid.
1500 Normally, this lack of utmp entries doesn't mean much. However, a few
1501 programs actually refuse to run without a utmp entry. Fortunately,
1502 there are workarounds:
1504 Program-dependent solutions:
1506 "talk" is the only program I'm aware of that falls into this category.
1507 One solution is to get ytalk. ytalk doesn't have this problem plus it
1508 fixes many other bugs in talk, such as being able to communicate with
1509 both old and new talk.
1511 Program-independent solutions:
1513 Use a program specifically intended to create utmp entries. Such
1514 programs are easy to write or get if you don't have them already. For
1515 instance, sessreg is one which comes with the xdm distribution. And
1516 Solaris uses utmp_update. I like this approach because it isolates
1517 the setuid code in a small single system utility rather than in every
1518 program on the system that needs this ability.
1520 Tod Olson <tao@stone.lib.uchicago.edu> sent in the following
1521 example of how to use sessreg. He says: sessreg works nicely. Here
1522 is a fragment showing how we invoke sessreg on our Linux machines.
1523 Note: sessreg must be able to write utmp. We decided to make utmp
1524 work writable, since it's a kinda bogus creature anyhow, rather than
1525 make sessreg suid root (or whatever).
1530 send "sessreg -w /var/run/utmp -a $user\r"
1532 ======================================================================
1534 #42. Why does . match a newline?
1536 From: libes (Don Libes)
1537 To: xipr@alv.teli.se (Ivan Prochazka)
1538 Subject: Why does . match a newline?
1539 Ivan Prochazka writes:
1543 >In my opinion(and emacs) the regexp-symbol "." stands for all
1544 >characters except newline(\n).
1545 >This is not the case in Expect 5.2.
1547 Yes, there are some packages that follow this convention, but I don't
1548 think it is appropriate for Expect. Unlike emacs, most Expect
1549 patterns don't look for full lines - more often they look for prompts
1550 which *don't* end with newlines.
1552 I find that I actually write the [^\n] pattern very rarely. And
1553 if I write it frequently in a script, then the expect itself probably
1554 ought to be in a subroutine.
1556 In fact, the more common line-terminating sequence in Expect is \r\n,
1557 so that might make a more likely argument. In any case, Expect
1558 defines . the way POSIX does. So I feel pretty good about the
1559 definition of . being what it is.
1563 ======================================================================
1565 #43. Why doesn't Expect kill telnet (or other programs) sometimes?
1567 From: libes (Don Libes)
1568 To: Karl.Sierka@Labyrinth.COM
1569 Subject: Re: need help running telnet Expect script from cron on sunos 4.1.3
1571 karl.sierka@labyrinth.com writes:
1572 > The only problem I am still having with the script I wrote is that
1573 > the telnet does not seem to die on it's own, unless I turn on debugging.
1575 Actually, Expect doesn't explicitly kill processes at all. Generally,
1576 processes kill themselves after reading EOF on input. So it just seems
1577 like Expect kills all of its children.
1579 > I was forced to save the pid of the spawned telnet, and kill it with an
1580 > 'exec kill $pid' in a proc that is hopefully called before the script
1581 > exits. This seems to work fine, but it makes me nervous since omnet
1582 > charges for connect time, and leaving a hung telnet lying around could
1583 > get expensive. I warned the rest of the staff so that they will also be
1584 > on the lookout for any possible hung telnets to omnet.
1586 The problem is that telnet is not recognizing EOF. (This is quite
1587 understandable since real users can't actually generate one from the
1588 telnet user interface.) The solution is to either 1) explicitly drive
1589 telnet to kill itself (i.e., a graceful logout) followed by "expect
1590 eof" or 2) "exec kill" as you are doing.
1592 This is described further in Exploring Expect beginning on page 103.
1596 ======================================================================
1598 #44. How come I get "ioctl(set): Inappropriate ..., bye recursed"?
1600 From: libes (Don Libes)
1601 To: james@Solbourne.COM (James B. Davis)
1602 Subject: How come I get "ioctl(set): Inappropriate ..., bye recursed" ...
1603 Date: Tue, 10 Dec 91 10:47:21 MST
1605 >Every time I ^C out of a Expect script run I get:
1607 >ioctl(set): Inappropriate ioctl for device
1610 >james@solbourne.com
1612 This answer courtesy of Michael Grant (mgrant@xdr.ncsl.nist.gov):
1614 You (or whoever installed gcc) forgot to run the fixincludes shell
1615 script while installing gcc. Recompiled gcc with itself, then run the
1616 fixincludes script - and the messages will go away.
1619 ======================================================================
1621 #45. How come there's no interact function in the Expect library?
1623 From: libes (Don Libes)
1624 To: Djamal SIMOHAND <djamal@lyohp5.in2p3.fr>
1625 Subject: Re: exp_expectl
1626 Date: Wed, 3 Jan 96 12:17:01 EST
1628 Djamal SIMOHAND writes:
1629 >I have already used the Expect program to write a script to connect by
1630 >telnet on my machine. Now I made a graphic interface in C and I need
1631 >the expect in C in order to have a coherent executable.
1633 >I've already written most of the C already, but the connection is
1634 >closed just after my program is finished. Then I have no opportunity
1635 >to work on my machine. It seems I need of the equivalent of
1636 >"interact" in C. Is there such a function in the C library?
1638 >Thanks for your help,
1641 No, there is no interact-like function in the C library. The reason
1644 1) It is simple enough to write your own. It's just a loop after
1653 2) There's no way I could possibly provide all the options you might
1654 need. In Expect, it's not a problem because the environment is very
1655 controlled, but in C, it's impossible to control what you might want
1656 to do. For example, you mention that you're embedding your code in a
1657 graphics application. Graphics packages typically have their own
1658 event manager, so you wouldn't want a monolithic interact function.
1660 3) The library is intended for embedding in other applications, where
1661 it rarely makes sense to give the user direct control of a spawned
1662 process. That kind of thing makes so much more sense to handle with
1663 an Expect script than a C program. The C library was not intended as
1664 a replacement for Expect. Expect is really the tool of choice for
1665 interaction problems, not C.
1667 In summary, there's very little payoff for the library to supply an
1668 interact function. A simple one would only satisfy people who should
1669 be using Expect anyway - and it's impossible to create one that would
1670 do everything that everyone wants. It's easier just to let people
1675 ======================================================================
1677 #46. Can't you make tkterm understand any terminal type?
1679 From: swig@teleport.com (Scott Swigart)
1680 Newsgroups: comp.lang.tcl
1681 Date: Tue, 13 Aug 1996 18:50:22 GMT
1683 I looked at tkterm, and it is promising, but it's missing some
1684 critical features. For one, I need something that understands various
1685 terminal types, and can get it's escape sequences from something like
1686 termcap or terminfo, instead of having them hard coded. Also, I
1687 question the ability of an Expect script to keep up if it had 50 or so
1688 types of escape sequences to parse. Actual C code would probably have
1689 to be created to do the parsing, and if you're going to go that far,
1690 why not just create a terminal widget so you could do something like:
1692 terminal .myterm -type vt220
1694 which is more along the lines of what I was originally looking for.
1696 Yes, that would be divine. But terminal emulators are horribly
1697 complex and very little of that complexity can be discerned from the
1698 termcap file. For example, compare xterm's human-readable docs (63k
1699 man page + 18k appendix) to its termcap entry (654 bytes). Now
1700 consider the other hundreds of terminals in termcap each with their
1701 own weird extensions. I can't imagine what kind of ".myterm configure"
1702 interface you'd present to the user. What would you allow the user to
1703 change? The nice thing about tkterm is that everything is accessible
1704 to the user, but I can't imagine doing that through a widget
1707 Unfortunately, like everyone else, I don't have the time...
1709 Me neither. Call me lazy.
1711 As an aside, I wonder why you want the ability for a terminal emulator
1712 to read termcap/info. Turns out that it's useless (unless what you
1713 are doing is testing termcap itself). Because if your app is using
1714 termcap in the first place, then it doesn't care what terminal type
1715 you choose - so why not choose the one that tkterm does? (And if your
1716 app isn't using termcap, then you have the converse problem.)
1718 Actually, I and several other people did a fair amount of
1719 experimentation (i.e., wrote a lot of C code) to do a universal
1720 terminal emulator - turns out that it's not possible in a general
1721 sense. To support any terminal type, you are going to be forced to go
1722 beyond what termcap/info offers. I.e., you'll have to handedit the
1723 definition or add new ones and/or accept certain limitations.
1725 After many revisions, Software - Practice & Experience is
1726 publishing a paper on tkterm. The paper includes more insights on the
1727 difficulties I've mentioned here. You can get a draft of the paper
1728 at: http://www.cme.nist.gov/msid/pubs/libes96d.ps
1732 ======================================================================
1734 #47. Trapping SIGCHLD causes looping sometimes
1736 From: Bryan Kramer <bryan.kramer@hydro.on.ca>
1737 Sender: kramer@hydro.on.ca
1739 Subject: Problem with trap in expect on Solaris
1740 Date: Tue, 17 Sep 1996 11:09:50 -0400
1742 I'm getting an infinite loop running the attached script foo.tcl on my
1743 solaris machine (Ultra Sparc, SunOS 5.5). This does not happen when I
1744 run the version of the same expect that I compiled on a Sparc 20 with
1745 SunOS 4.1.3UI (even though I am running it on the Solaris 5.5. ultra).
1749 puts stderr "CALL TRAP [trap -number] [trap -name]"
1752 puts stderr "TRAP $output"
1759 if {[catch {exec trivial} msg]} {
1760 puts stderr "Error $msg"
1764 Please let me know if there is an immediate work around.
1768 |Bryan M. Kramer, Ph.D. 416-592-8865, fax 416-592-8802|
1769 |Ontario Hydro, 700 University Avenue, H12-C1 |
1770 |Toronto, Ontario, Canada M5G 1X6 |
1771 <A href="http://www.cs.toronto.edu/~kramer">B. Kramer Home Page</A>
1773 I haven't analyzed your script in depth, but this sounds like a
1774 problem I've seen before - it's due to an implementation deficiency in
1775 Tcl. The problem is that when an exec'd process finishes, it raises
1776 SIGCHLD. Expect's "wait" sees that it is Tcl's process.
1777 Unfortunately, there is no way to wait for one of Tcl's processes and
1778 tell Tcl that you've done so, nor is there any way to have Tcl wait
1779 itself. So Expect's wait just returns. On some systems alas, this
1780 just causes SIGCHLD to be reraised.
1782 The solution is multipart:
1783 1 Tell John he needs to fix this problem. (I've told him this but he
1784 didn't agree with me that it's a problem.) Tcl needs to provide a new
1785 interface - either to clean up its process or to allow extensions to
1786 do the wait and pass the status back to Tcl so that it can have it
1788 2 Don't call exec while you are trapping SIGCHLD. Since this is a
1789 severe limitation, I recommend you avoid the problem by using
1790 "expect_before eof" to effectively trap the same event. If you're not
1791 already using expect, well, call it every so often anyway.
1795 ======================================================================
1797 #48. Why do I get "invalid spawn id"?
1799 Subject: Why do I get "invalid spawn id"
1800 In article <53ggqe$hag@hole.sdsu.edu> khumbert@mail.sdsu.edu writes:
1801 I am trying to write a general looping procedure that will handle
1802 many cases that have similar prompt sequences. The function and one
1804 The problem is that when the "looping" function is called I get an
1805 "invalid spawn id(5) while executing "expect $exp1 {send -s "$send1}
1806 timeout {continue}". I only have one spawn in the entire program
1807 (a telnet session). I've tried setting a spawn_id variable for the
1808 telnet spawn and then setting spawn_id to that variable in "looping",
1809 but no dice, same error.
1811 Any ideas? Thanks in advance for any suggestions!!!
1815 proc looping {exp1 exp2 send1 send2} {
1816 global max_tries ### 5 ###
1821 while {$tries <= $max_tries && $connected == 0} {
1824 $exp1 {send -s $send1}
1828 ">? " {send -s "\n"}
1832 $exp2 {incr connected;send -s $send2}
1839 What's going on is that the spawned process has closed the
1840 connection. When Expect detects this, it matches the "eof" pattern,
1841 and the spawn id is marked "invalid". However, you aren't testing for
1842 "eof", so the next command in your script finds the invalid spawn id,
1843 hence the complaint.
1845 If you want to find out where the eof is occurring, enable Expect's
1846 diagnostic mode - Expect will get very chatty about what it is doing
1849 You can handle eof in all your expect statements by add a single
1850 expect_before/after command to your script.
1854 ======================================================================
1856 #49. Could you put a version number in the filename of the Expect archive?
1858 From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
1859 Date: Mon, 23 Dec 1996 08:46:57 -0700 (MST)
1861 It would be helpful for the expect distribution to contain its version
1862 number, e.g. expect-5.21.6.tar.gz; I had an earlier version called
1863 5.21, and it took some diffing to verify that the expect.tar.gz I
1864 fetched from ftp://ftp.cme.nist.gov/pub/subject/expect/expect.tar.gz
1867 I don't name the file with a version number because I make new
1868 distributions so frequently. I realize that many other distributions
1869 include version numbers in them, but constantly changing filenames
1870 really annoys the heck out of people. I've been packaging Expect this
1871 way for five years and I've only gotten this question twice before.
1872 In contrast, I'm responsible for a number of other files on our ftp
1873 server that do occasionally change names, and I get no end of
1874 questions from people about where such and such a file has gone or why
1875 their ftp request fails.
1877 So that people don't have to download the distribution only to find
1878 it hasn't changed, there is a HISTORY file in the distribution
1879 directory. It's relatively short and has the latest version number at
1880 the top (with any changes listed immediately after).
1884 ======================================================================
1886 #50. Why does Expect work as root, but say "out of ptys" when run as myself?
1888 Expect works fine as root, but when I run it as myself it says "out of
1889 ptys" (which I know isn't true). Any ideas?
1891 Sounds like a misconfiguration problem on your system. For
1892 example, once I saw this on a Digital system where the system
1893 administrator had decided to remove setuid from all programs ("I heard
1894 that setuid is a security risk, right?"). On that particular system,
1895 Expect uses a system library function that internally calls an
1896 external program chgpt which exists solely for the purpose of managing
1897 ptys. Needless to say, it must be setuid. Unfortunately, the library
1898 function doesn't do enough error checking, and there's no way for Expect
1899 to know that, so there's nothing I can do to give a better diagnostic
1900 explaining how your system is misconfigured.
1904 ======================================================================
1906 #51. Why does spawn fail with "sync byte ...."?
1908 When I spawned a process using Expect, I got the following
1911 parent: sync byte read: bad file number
1912 child: sync byte write: bad file number
1914 This is one of these "should not happen" errors. For example, the
1915 following question in this FAQ mentions that it could be the fault of
1916 the C library. Another possibility is that you've run out of some
1917 system resource (file descriptors). The most likely reason is that
1918 you're calling spawn in a loop and have neglected to call close and
1923 ======================================================================
1925 #52. Why does Expect fail on RedHat 5.0?
1927 Lots of people have reported the following error from Expect on
1930 failed to get controlling terminal using TIOCSCTTY
1931 parent sync byte write: broken pipe
1933 Martin Bly <ussc@star.rl.ac.uk> reports that:
1935 The fault is/was in the GNU libc (aka glibc) provided by Red Hat
1936 Software. Our sysadmin updated the version of the C libraries we have
1937 installed and both problems have vanished - in the case of the expect
1938 test, without a rebuild.
1939 ======================================================================
1941 #53. Why does Expect fail on RedHat 5.1?
1943 People have reported the following error from Expect on RedHat
1946 failed to get controlling terminal using TIOCSCTTY
1947 parent sync byte write: broken pipe
1949 If there are any people
1950 who have some debugging experience and can reproduce that error on
1951 RedHat 5.1, read on:
1953 First look in the man page (or perhaps diff the 5.1 and pre-5.1 man
1954 pages) governing TIOCSTTY and let me know what you find.
1955 Alternatively look at the source to xterm (or some other program that
1956 must allocate a pty) and see how it is allocating a pty.
1958 If anyone else is wondering if the problem has been fixed by the time
1959 you read this, just check the FAQ again. I'll update it as soon as
1960 the problem has been successfully diagnosed.
1964 ======================================================================
1966 #54. Is Expect Y2K compliant?
1968 The short answer is: Yes, if you're using a modern version of Tcl
1971 Longer answer: Tcl 7.5 and 7.6p0/1 had bugs that caused them to be
1972 noncompliant with regard to how POSIX defines 2-character years. If
1973 your scripts use 2-character years, you should upgrade to a modern
1974 version of Tcl. If your scripts use 4-character years, than you have
1975 nothing to worry about.
1979 ======================================================================
1982 Names of companies and products, and links to commercial pages are
1983 provided in order to adequately specify procedures and equipment used.
1984 In no case does such identification imply recommendation or
1985 endorsement by the National Institute of Standards and Technology, nor
1986 does it imply that the products are necessarily the best available for
1989 Last edited: Tue Sep 22 17:52:23 EDT 1998 by Don Libes