Expect FAQ (Frequently Asked Questions)

An HTML version of this FAQ can be found in http://expect.nist.gov/FAQ.html

This FAQ lists common questions, usually about subjects that didn't

fit well in the book for one reason or another (or weren't

indexed sufficiently well so that people can't find the answers easily

enough).  In some cases, I've left the original questions.  I suppose

I could've stripped off the headers, but it seems more realistic to

see actual people who've asked the questions.  Thanks to everyone who

asked.

The man page and the papers listed in the README file should

also be consulted for highly technical or philosophical discussion of

the implementation, design, and practical application of Expect.

Don

======================================================================

		Here is the list of questions.  You can search for the corresponding

		answer by searching for the question number.  For example searching

		for "#3." will get you that answer.

**** General **** 

#1. I keep hearing about Expect.  So what is it?

#2. How do you pronounce "Ousterhout" anyway?  (Or "Libes" for that matter?)

#3. Why should I learn yet another language (Tcl) instead of

writing my interaction in ?

#4. What about Perl?

#5. Do we need to pay or ask for permission to distribute Expect?

#6. Since Expect is free, can we give you a gift?

#7. Are there any hidden dangers in using Expect?

**** Book, newsgroup, FAQ, README, ... **** 

#8. Why is this FAQ so short?

#9. How was this FAQ created?

#10. The background makes the FAQ hard to read.

#11. Why isn't there an Expect mailing list?

#12. Why isn't overlay covered in Exploring Expect?

#13. Is the front cover of your book a self portrait (ha ha)?

#14. Why don't the examples in your USENIX papers work?

#15. Can you put the examples in your book into an anonymous ftp site?

#16. Do you have ideas for more articles on Expect?

**** Can Expect do this? **** 

#17. Can Expect automatically generate a script from watching a session?

#18. Can Expect understand screen-oriented (Curses) programs?

#19. Can Expect be run as a CGI script?

#20. Can Expect act like a browser and retrieve pages or talk to a CGI script?

#21. Can Expect be run from cron?

#22. Why does my Expect script not work under inetd?

**** Compilation or porting questions **** 

#23. Why can't I compile Expect with Tcl 8.0?

#24. Does Expect 5.26 work with Tcl/Tk 8.0.3?

#25. Why can't I compile Expect with Tcl/Tk 8.1aX?

#26. Why can't I compile Expect with Tcl/Tk 8.0b1?

#27. Why does Expect need to be setuid root on Cray?

#28. Does Expect run on VMS?

#29. Is it possible to use Expect and TclX together?

#30. Is it possible to use Expect and <lots of random extensions> together?

#31. Why does configure complain about "cross-compiling"?

#32. Why are make/configure looping endlessly?

#33. Why does compile fail with: Don't know how to make pty_.c?

#34. Does Expect run on MSDOS, Win95, WinNT, MacOS, etc...?

#35. Why does Expect dump core?  Why can I run Expect as root but not as myself?

**** Other... **** 

#36. Is it possible to prevent Expect from printing out its interactions?

#37. Why does it send back the same string twice?

#38. Why can't I send the line "user@hostname\r"?

#39. How do I hide the output of the send command?

#40. Why don't I see pauses between characters sent with send -s?

#41. Why does "talk" fail with "Who are you?  You have no entry utmp" or

	"You don't exist.  Go away"?

#42. Why does . match a newline?

#43. Why doesn't Expect kill telnet (or other programs) sometimes?

#44. How come I get "ioctl(set): Inappropriate ..., bye recursed"?

#45. How come there's no interact function in the Expect library?

#46. Can't you make tkterm understand any terminal type?

#47. Trapping SIGCHLD causes looping sometimes

#48. Why do I get "invalid spawn id"?

#49. Could you put a version number in the filename of the Expect archive?

#50. Why does Expect work as root, but say "out of ptys" when run as myself?

#51. Why does spawn fail with "sync byte ...."?

#52. Why does Expect fail on RedHat 5.0?

#53. Why does Expect fail on RedHat 5.1?

#54. Is Expect Y2K compliant?

*

* Questions and Answers

*

**** General **** 

#1. I keep hearing about Expect.  So what is it?

From: libes (Don Libes)

To: Charles Hymes <chymes@crew.umich.edu>

Subject: I keep hearing about Expect.  So what is it?

Charles Hymes writes:

>

>So, what is Expect?

Expect is a tool primarily for automating interactive applications

such as telnet, ftp, passwd, fsck, rlogin, tip, etc.  Expect really

makes this stuff trivial.  Expect is also useful for testing these

same applications.  Expect is described in many books, articles,

papers, and FAQs.  There is an entire book on it available from

O'Reilly.

Expect is free and in the public domain.  Download instructions can

be found in the Expect homepage.

Don

======================================================================

#2. How do you pronounce "Ousterhout" anyway?  (Or "Libes" for that matter?)

From: ouster@sprite.Berkeley.EDU (John Ousterhout)

To: libes@cme.nist.gov

Subject: Re: pronunciation?

Date: Tue, 29 May 90 21:26:10 PDT

Those of us in the family pronounce it "OH-stir-howt", where the

first syllable rhymes with "low", the second with "purr", and the

third with "doubt".  Unfortunately this isn't the correct Dutch

pronounciation for a name spelled this way (someplace along

the line it got misspelled:  it was originally "Oosterhout"), nor

is it what you'd guess if you use common sense.  So, we've gotten

used to responding to almost anything.

					-John-

I suppose I should say something in kind.  "Libes" is pronounced

"Lee-bis" with stress on the first syllable.  Like John though, I've

gotten used to responding to anything close.

By the way, notice the date on this message.  I had only written

the first cut of Expect four months earlier.  I asked John how to

pronounce his name because I had already got a paper accepted into

USENIX and needed to be able to say his name correctly while giving

the talk!

Don

======================================================================

#3. Why should I learn yet another language (Tcl) instead of

writing my interaction in ?

From: libes (Don Libes)

Subject: Re: Expect, Tcl, programmed dialogue etc.

Date: Mon, 2 Sep 91 15:47:14 EDT

>>>A friend told me about "Expect". But then, I have to know the

>>>idiocies of "tcl". I would like to know if there is an alternative

>>>to Expect that is also useful in other places, so that I do not

>>>have to spend time getting used to tcl for just this one tool.

>

>>Your reasoning is shortsighted.  Tcl is a language that can be used in

>>other applications.  It won't be a waste of your time to learn it.

>

>I have nothing against tcl as such.

>The reluctance to learn it comes mainly from the feeling that half my

>life seems to be spent learning new languages that differ very little

>from existing ones, and differ in annoying little details at that.

>To add to the misery, every implementation has its own

>idiosyncracies...:-(

Ironically, Tcl was written specifically to halt this very problem.

The author recognized that every utility seems to have its own

idiosyncratic .rc file or programming language.  Tcl was designed as a

general-purpose language that could be included with any utility, to

avoid having everyone hack up their own new language.

 In this context, your statements do Tcl a great disservice.  

Don

======================================================================

#4. What about Perl?

From: libes (Don Libes)

To: Joe McGuckin <joe@ns.via.net>

Subject: Re: Need Perl examples

Date: Sun, 22 Jan 95 20:17:39 EST

Joe McGuckin writes:

>

>Yeah, I've scanned through your book a couple of times in the last

>week, trying to make up my mind if I should buy it.

I spent three years writing it - so I'm glad to hear you're spending a

little time considering its merit!

>Pro:

>   Looks like implementing some sort of telnet daemon would be trivial.

Once you see it as an Expect script, you'll realize how trivial

these things can really be.

>Con:

>   Yet another language to learn. I know perl reasonably well & would

>   like to stick with it.

Good point.  While I'm not a Perl guru, I've used it quite a bit

and it's nice for many things.  But I wouldn't have bothered writing

Expect in the first place if I thought Perl was ideal.  And many Perl

experts agree - I know a lot of them who call out to Expect scripts

rather than do this stuff in Perl - it's that much easier with Expect.

Expect is also much more mature.  It's portable, stable, robust, and

it's fully documented - with lots of examples and a complete tutorial,

too.

In response to someone complaining about how difficult it was to do

something in Perl, Larry Wall once remarked: "The key to using

Perl is to focus on its strengths and avoid its weaknesses."  That

definitely applies here.

Even if you do proceed with Perl, you will find the book

helpful.  Automating interactive applications has unique pitfalls to

it and many of the descriptions and solutions in the book transcend

the choice of language that you use to implement them.

Don

======================================================================

#5. Do we need to pay or ask for permission to distribute Expect?

From: libes (Don Libes)

To: Mohammad Reza Jahanbin <mrj@CIS.Prime.COM>

Subject: Copyright Question.

Date: Tue, 26 Jan 93 23:46:24 EST

Mohammad Reza Jahanbin writes:

>Before anything let me thank you on behalf of ComputeVision R&D for

>putting so much effort into Expect. Part of CV has been using Expect

>for the past two years or so to build variety of tools including an

>automated testbed for a product.

>

>CV is currently considering shipping the automated testbed to some of its

>retailers, to enable them to perform their own tests before distributing

>the product.

>

>The Question is, are we allowed to ship Expect? Do we need to ask

>anyone for permission? Do we need to say or write anything in the

>documentation? Do we need to pay for it?

>

>I have not been able to find any copyright (or indeed copyleft) notices

>in the usual Expect distribution. Would you be able to clarify our position.

It is my understanding that you are allowed to do just about anything

with Expect.  You can even sell it.  You need not ask our permission.

You need not pay for it.  (Your tax dollars, in effect, already have

paid for it.)

You should not claim that you wrote it (since this would be a lie), nor

should you attempt to copyright it (this would be fruitless as it is a

work of the US government and therefore not subject to copyright).

NIST would appreciate any credit you can give for this work.  One line

may suffice (as far as I'm concerned) although there should be

something to the effect that this software was produced for research

purposes.  No warantee, guarantee, or liability is implied.

My management is always interested in feedback on our work.  If you

would like to send letters of praise describing how Expect has helped

your business, we would be delighted.  Letters (on letterhead please)

are strong evidence used by policy makers when deciding where every

dollar goes.  If you want to send these letters to NIST directly, you

may send them to the following individuals:

Robert Hebner, Director

NIST

Admin Bldg, Rm A-1134

Gaithersburg, MD 20899

Ric Jackson, Manufacturing Engineering Laboratory

NIST

Bldg 220, Rm B-322

Gaithersburg, MD 20899

Steve Ray, Manufacturing Systems Integration Division

NIST

Bldg 220, Rm A-127

Gaithersburg, MD 20899

Amy Knutilla, Manufacturing Collaboration Technologies Group

NIST

Bldg 220, Rm A-127

Gaithersburg, MD 20899

In case you're wondering about the uninformative titles, Robert Hebner

is the director of all of NIST (about 3000 people) and

Amy Knutilla (way down there at the bottom) is my immediate supervisor.

I hope this has answered your questions.  Let me know if you have

further questions.

Don

======================================================================

#6. Since Expect is free, can we give you a gift?

This is not an actual letter but represents the gist of several

that I've received.

>>>Expect has saved us many thousands of dollars.  We'd like to send

>>>you a free copy of our product.

>>

>>Thanks, but please don't.  As a federal employee, I'm not

>>allowed to accept gifts of any significant value.

>

>But, what if it is for personal use (like at home)? I assume

>that would be okay.

It doesn't matter (much).  What the rules address is whether a gift

might cause me to make an official decision differently.  This is

especially a concern because I may very well have to decide whether or

not to buy products from your company in the future.

There is a clause that says "you may accept gifts from friends,

regardless of value ... but you should be careful to avoid accepting

gifts which may create an appearance of impropriety, even if permitted

as an exception to the gift rules."

I'm still permitted to accept small token gifts, such as a t-shirt

or reasonably-priced dinner (under $20 per gift to a maximum of $50

per year from any person or company) - so things are not totally

ridiculous.  Although the precise values in the gift rules seem rather

arbitrary, I actually like the gift rules.  They stop a lot of the

nonsense that used to go on involving gifts.

Don

======================================================================

#7. Are there any hidden dangers in using Expect?

From: Charlton Henry Harrison <charlton@cs.utexas.edu>

To: libes@NIST.GOV

Date: Fri, 27 Jan 1995 23:30:56 -0600

>>>Dear Don:

>>>

>>>	I've been a fan of Expect ever since I first learned of UNIX back

>>>in late '93. I'm young and don't have my CS degree just yet, but I worked

>>>a while back at Texas Instruments in their Telecom Customer Support dept.

>>>I started in late '93 (and hence, that's where I first started exploring

>>>the UNIX environment) and immediately forsaw the need of automating a lot

>>>of my redundant and mindless duties, but I didn't know how since we were

>>>working over a heterogeneous LAN with multiple OSs.

>>>	Then I found out about Expect. I automated everything! My boss didn't

>>>like hearing that I was working on something else in order to get out of

>>>work, and I got tired of explaining it to him.

>>>	Although I accomplished all the aspects of my duties, I was infamous

>>>for being the laziest person at work, and it showed (I made my job SO easy).

>>>I got a new boss after a while, and he hated me from the start and fired

>>>me soon after. Oh well, I guess my mentality didn't click with theirs. 

>>>	There are a lot of people like that: they believe life is putting

>>>in a hard day's work to get by. I hate that.

>>>	So the point is, thank you for the wonderful 'Expect'. I bought

>>>your book and now I have the most recent version of it on my Linux system

>>>at home. Needless to say I'm looking for another job, though.

>>>

>>>							Charlton

>>> 

>> Thanks very much for your nice letter.  Sorry to hear about your

>> automating yourself out of a job.  Actually, I think most computer

>> scientists have to face this dilemma.  In some ways, it's a

>> self-defeating occupation.

>>

>> Don

>

>Yeah, I'd be interested in hearing if you have a personal philosophy on

>how to handle this kind of thing. I plan on pursuing a career in Artificial

>Intelligence for similar reason of making life easier for everyone (me

>in particular!)  What the future holds in this category is a great

>mystery.

I'm glad you asked.  My personal philosophy on this kind of thing is:

Find someone really rich and marry them.

Don

======================================================================

**** Book, newsgroup, FAQ, README, ... **** 

#8. Why is this FAQ so short?

From: libes (Don Libes)

To: Wade Holst <wade@cs.ualberta.ca>

Subject: Expect question

Wade Holst writes:

>

> 1) Is there a more up-to-date version of the FAQ than what

>    comes with expect-5.5?  (For such a useful application, I

>    would expect more than 12 questions).

I know that a lot of other packages have *huge* FAQs but I

have always believed that this is an indication that their regular

documentation sucks.  As questions arise that are not addressed well

by the original docs, the docs themselves should be fixed rather than

new ones created.

In contrast, I believe that an FAQ should literally be a list of

frequently asked questions and little else.  An FAQ should not be a

replacement for good documentation.

In that sense, I have tried to use this FAQ as a second place to

look rather than a first place.  The place you should always look

first is Exploring Expect.  At over 600 pages, the book is very

comprehensive, well-organized, and includes three indices and two

tables-of-contents to make it very easy to find what you want to know.

The book was not a rush job.  During the three years I spent

writing it, virtually every question I was asked became incorporated

as subject material for the book.  I wanted to make sure that the book

wouldn't need much of an FAQ!

It would not make sense to try and distill the entire book into an

FAQ (that is actually comprehensive rather that truly frequently asked

questions).  There's simply too much material there.

So this FAQ is short.  It really tries to stick just to *truly*

frequently asked questions.

Don

======================================================================

#9. How was this FAQ created?

The Expect FAQ is regularly recreated by a Tcl script which

produces either text or HTML depending on how it is called.  Using Tcl

has two nice results:

   +  I didn't have to choose one format and worry about

converting it to the other.  (Remember that the FAQ appears in HTML on

the web and it appears in text in the Expect distribution.)  The more

common approach - doing conversions in either direction - is really

painful - plus, it's now easy to generate other formats, too.

   +  It's much, much easier to keep track of questions and

answers.  For example, when I add a new question, I don't have to add

it twice (once at the top and again later with the answer), nor do I

have to worry about making the links between them.  All this and a lot

of other stuff is handled automatically - and the source is much more

readable than the actual HTML.

(see "FAQbuilder")

You can read about these ideas in a paper that appeared at Tcl '96

called Writing CGI Scripts in Tcl.  (CGI scripts are the primary focus of the

paper, but it also spends time on HTML generation for other purposes -

including the example of highly stylized documents like FAQs.)

I encourage you to examine the source to this FAQ - it

comes in two parts:

   +  Expect-specific FAQ source

   +  Generic FAQ Builder source

The generic FAQ builder has also been used to build several other

FAQs (unrelated to Expect).

Don

======================================================================

#10. The background makes the FAQ hard to read.

To: bonneau@mudd.csap.af.mil (Allen Bonneau)

Subject: FAQ background colors

Date: Wed, 10 Apr 96 10:24:52 EDT

Allen Bonneau writes:

>... the white and gray background makes the FAQ difficult to read.

It's not white and gray.  It's several very close shades of gray.

It's supposed to be very subtle.  Sounds like you have your browser in

a mode where it is mishandling colors.  Turn on dithering and

restart your browser.

Don

======================================================================

#11. Why isn't there an Expect mailing list?

From: libes (Don Libes)

To: dclark@nas.nasa.gov (David R. Clark)

Subject: Mailing list for Expect

Date: Mon, 23 Sep 91 18:21:28 EDT

>Would be nice if their were an Expect mailing list.  I would use it more

>often, and be made aware of other users.

Perhaps I'm too myopic, but I don't see the need for it.  Most of

the questions about Expect posted to Usenet every day can be found in

the various FAQs or in the book, so it's pretty easy getting

answers to them.

For one reason or another (occasionally a bug fix, but often, just

adding a neat example), I update Expect every couple of weeks.

Personally, I'd hate being on the other end of something like this.

Who needs patches every two weeks for problems that are likely not

even relevant to you?  (Most patches these days are either extremely

esoteric or are related to porting Expect to some unusual machine.)

>It would be helpful, too, if this served as an area for swapping programs.

>Many of the things that I want to do are done by others already.

NIST doesn't distribute software written by other people but if

you've got relatively small scripts that show off unique ideas and

techniques that would be educational for the Expect community, I can

include your script with Expect or put it in a publicly accessible

directory so other people can get it.  I'm also willing to list links

in Expect's home page to other web pages about projects that use

Expect.

There is a Tcl newsgroup, comp.lang.tcl, which many Expect users

read.  It's pretty good for asking questions about Tcl, and many of

the readers use Expect so Expect questions are encouraged.  The

newsgroup is gatewayed to a mailing list (tcl@sprite.berkeley.edu)

which is further described in the Tcl documentation.

Don

======================================================================

#12. Why isn't overlay covered in Exploring Expect?

To: spaf@cs.purdue.edu

Gene Spafford writes:

>I'm curious as to why the "overlay" command is not mentioned anywhere

>in the book.  Is that a recent addition?  A deprecated feature?  I

>ended up using it in one of my scripts....

The overlay command has been in Expect for a long time.  In all that

time no one has ever asked me about it and I have never used it.

Well, I used it once but I really didn't like the result, and so I

rewrote the script to not use it.  I left the overlay command in

Expect because it seemed like an interesting idea, but I never really

finished it - in the sense that I believe it needs some more options

and controls.  In comparison, the interact command is very flexible

and makes the need for overlay pretty moot.

Don

======================================================================

#13. Is the front cover of your book a self portrait (ha ha)?

From: libes (Don Libes)

To: pkinz@cougar.tandem.com (kinzelman_paul)

Subject: the cover?

kinzelman paul writes:

>The book finally came in. I tried to buy 4 copies but they had only 2

>left and they came in last Saturday. Move over Stephen King! :-)

4 copies!?  Wow.  That's more than my mother bought!

>I was discussing your book with somebody who stopped in and we began

>to speculate about the monkey on the cover. I don't suppose it's a

>self portrait? :-)

There is some real humor here.  There seems to be considerable

debate over what the creature is!  The colophon at the end of the book

says that it is a chimpanzee.  I like that idea much more than a

monkey which is what it looks like to me.  My wife, who has a degree

in zoology, explained to me that chimps are actually the second

smartest of primates (humans are the smartest).  Chimps are very

intelligent and can do many things (but not everything) that humans

do.  Perfect for describing Expect.  Anyway, she says I should be

honored to have it grace the cover - even in theory.

I remarked to Edie (the cover designer at O'Reilly) that even though

the cover was nice looking, everyone was going to stare at it and say,

"Gee, but it looks like a monkey."  She replied "The purpose of the

cover is just to get people to pick the book up. This cover will do

that. Don't worry. If you get any rude comments from anyone, at least

you know they are paying attention."

[After being inundated by people pointing out that the animal

really is a monkey, O'Reilly subsequently decided to acquiesce and has

changed the colophon to admit that yes it is a rhesus monkey.

Evidentally, the book from which O'Reilly has been taking those

pictures from was wrong on this one.]

Don

======================================================================

#14. Why don't the examples in your USENIX papers work?

From: libes (Don Libes)

To: Will Smith (AC) <william@ritchie.acomp.usf.edu>

Subject: Expect

Will Smith (AC) writes:

>I just entered some scripts from a USENIX paper that my boss had.  I get

>errors about my quotes in the script.  Also, it doesn't seem to know

>about expect_match.  Thanks in advance for any insight you could offer.

The USENIX papers are old and out-of-date as far as quoting goes.  A

couple years ago, I cleaned up and simplified this aspect of Expect.

Similarly, expect_out is now where the results of expect's pattern

matching are saved.

The man page is always the best reference on what Expect currently

supports.  Alternatively, you can read the CHANGES files.  These files

document the changes from one major version to another.

Don

======================================================================

#15. Can you put the examples in your book into an anonymous ftp site?

From: libes (Don Libes)

To: pren@cs.umass.edu

Subject: Examples in your book "Exploring Expect"

Peifong Ren writes:

>

>Hi,

>

>I bought your book "Exploring Expect" from O'Reilly.

>I wonder can you put the eamples in your book into an anonymous ftp

>site?

All of the substantive examples come with recent versions of Expect.

Just look in the example directory.  

The remaining 50 or so examples are short enough that typing them

in only takes a minute or two.  If I put them online, you'd spend more

time looking for them (reading my online catalog, figuring out what

the online descriptions meant, mapping them back to the file, etc.)

then it would take to type them in.  And since you're likely to want

to change the examples anyway, there's nothing to be gained for short

ones.

Don

======================================================================

#16. Do you have ideas for more articles on Expect?

From: libes (Don Libes)

To: faught@zeppelin.convex.com (Danny R. Faught)

Cc: libes

Subject: Re: SQA Quarterly articles

Date: Thu, 21 Dec 95 13:31:01 EST

Danny R. Faught writes:

>I just arranged to write an article on automating interactive

>processes for an issue early next year.  You have so many good pieces

>on expect out there, it's going to be hard to add anything original.

One thing I've never written is a good mini-tutorial.  Magazine

editors love these types of pieces and there's certainly a need for

it.  So I'd encourage that type of article.

Another possibility is an article on how you or your colleagues

personally applied Expect to solve your particular problem. Application-

oriented papers are the kind that necessarily have to be written by

people in the field who are applying the technology.  People love this

kind of practical paper.  For example, a good paper might be "Writing

a pager".  This is a nice topic because you can start with a simple

5-line script that solves the problem and then show progressive

refinements that handle different twists on the same problem.  (And

"how to write a pager" is a very frequently asked question on Usenet.)

Don

======================================================================

**** Can Expect do this? **** 

#17. Can Expect automatically generate a script from watching a session?

From: libes (Don Libes)

To: pete@willow24.cray.com

Subject: Expect

Date: Fri, 12 Oct 90 17:16:47 EDT

>I like "Expect" and am thinking of using it to help automate the

>testing of interactive programs.  It would be useful if Expect had a

>"watch me" mode, where it "looks over the shoulder" of the user and

>records his keystrokes for later use in an Expect script.

>

>(Red Ryder and other Macintosh telecommunications packages offer this

>sort of thing.  You log onto Compuserve once in "watch me" mode, and

>RR keeps track of the keystrokes/prompts.  When you're done you have a

>script that can be used to log onto Compuserve automatically.)   

>

>Before I look into adding a "watch me" feature, I thought I should

>ask: has this been done already?

>

>I'll say again that I like the tool a lot--nice work!  There are other

>people here using it for things like the testing of ksh, which

>responds differently to signals when not used interactively.

>

>-- Pete

The autoexpect script in Expect's example directory does what you

want.

Don

======================================================================

#18. Can Expect understand screen-oriented (Curses) programs?

Yes, it can - with a little clever scripting.  Look at the

term_expect script for an example.  It uses a Tk text widget to

support screen-oriented Expect commands.  This technique is described

very thoroughly in Chapter 19 of Exploring Expect.

Adrian Mariano (adrian@cam.cornell.edu) converted the term_expect

code (see above) so that it runs without Tk (exercise 4 in Chapter

19!)  Both term_expect and virterm can be found in the example

directory that comes with Expect.

An alternative approach to screen-handling was demonstrated by Mark

Weissman (weissman@gte.com) and Christopher Matheus who modified a

version of Expect to include a built-in Curses emulator.  It can be

ftp'd from the Tcl archive as expecTerm1.0beta.tar.Z.  (Note that

Expecterm does not run with the current version of Expect.)

I like the idea of keeping the curses emulator outside of Expect

itself.  It leaves the interface entirely defineable by the user.  And

you can do things such as define your own terminal types if you want.

For these reasons and several others, I'm not likely to return to

Expecterm.

Don

======================================================================

#19. Can Expect be run as a CGI script?

Expect scripts work fine as CGI scripts.  A couple pointers might

help to get you going:

Many Expect scripts can be run directly with one change - the

following line should be inserted before any other output:

puts "Content-type: text/html\n"

Be sure not to forget that extra newline at the end of the puts.

Next, make sure you invoke external programs using full paths.  For

example, instead of "spawn telnet", use "spawn /usr/ucb/telnet" (or

whatever).  Remember that the PATH and other environment variables are

going to be different than what you are used to.  This is very similar

to dealing with cron and you can get other good tips and advice from

reading the Background chapter in the book.

 Another tip: If a script runs fine by hand but not from CGI, just

log in as "nobody" to the host on which your CGI script runs.  Then

try running it by hand.  This generally makes it very obvious what's

going on.  (If you can't log in to the server or can't log in as

"nobody", use the kibitz trick described in the Background chapter.)

You may find it helpful to use cgi.tcl, a nice collection of

CGI support utilities for Tcl scripts.  It includes an Expect example

among many others.  The package includes just about everything:

tables, frames, cookies, file upload, etc...., with some nice

debugging support.  It's pure Tcl, no C code - so it's very easy to

try out and use.

Don

======================================================================

#20. Can Expect act like a browser and retrieve pages or talk to a CGI script?

From: jasont@netscape.com (Jason Tu)

Date: Sat, 02 Nov 1996 09:51:03 -0800

I read your book "Exploring Expect" and find Expect is just the tool

to test Netscape's enterprise server product, since it is very easy to

use and quick to develop. I figured I would use telnet to send HTTP

protocol dialog to a HTTP server and simulate how it behaves.  But I

couldn't get it to work at all.  I am wondering that there might be a

quick example that you can share with me.

Yes, this is a useful way of testing HTTP servers and running CGI

scripts (and winning Web contests :-).  You can add error checking and

other stuff, but here's the minimum your script should have to read a

web page: 

match_max 100000

set timeout -1

spawn telnet $host 80

expect "Escape character is *\n"

send "GET $page\r\n"

expect

puts "$expect_out(buffer)"

If you want to communicate information to a CGI script, you'll want

more.  One way to see what needs to be sent is to load a real browser

with the form and then send it to a fake daemon such as this one:

#!/bin/sh

/bin/cat -u > /tmp/catlog

Enable this by adding this service to inetd.  Then save the form in

a temporary file, modify the form's host and port to correspond to

your own host and whatever port you've chosen to associate with your

fake daemon.  Now fill out the form and you'll find the form data in

/tmp/catlog.  Using this, you can determine exactly how to amend your

Expect script to behave like your browser.  

Don

======================================================================

#21. Can Expect be run from cron?

Expect itself works fine from cron - however, you can cause

problems if you do things that don't make sense in cron - such as

assume that there is a terminal type predefined.  There are a number

of other pitfalls to watch out for.  The list and explanations aren't

short - which is why there's a whole chapter ("Background") on the

subject in the book.

Here's one that someone tried to stump me with recently: They told

me that their program started up and then Expect immediately exited.

We spent a lot of time tracking this down (Was the spawned program

really starting up but then hanging - which would indicate a bug in

the program; or was the program NOT starting up - which would indicate

a bug in the environment; etc.)  Turned out that Expect wasn't even

running their program.  They had assumed cron honored the #! line

(which it doesn't) and so the first line in their script (exec date)

was being interpreted by the shell and of course, the script did

nothing after that - because that's what the shell's exec is supposed

to do!)

Don

======================================================================

#22. Why does my Expect script not work under inetd?

From: dpm@bga.com (David P. Maynard)

Subject: Re: Tcl/Expect, inetd service, and no echo password

Date: 24 Oct 1996 13:34:57 -0500

In article <54ocsh$9i1@urchin.bga.com> dpm@bga.com (David P. Maynard) writes:

   I am fairly new to expect, so hopefully this isn't too obvious.  I also

   confess to not having looked in "Exploring Expect" becuase I haven't

   found it in stock at a local bookstore yet.

   I want to write an expect script that runs as a service from inetd.

   (Actually, I plan to use the tcpd 'twist' command to launch the