expect script pauses at finish

I've noticed that behaviour on issuing exit in a script that doesn't use interact. Out of curiousity I tinkered with it for a bit, but couldn't make it go away. The second or so delay didn't bother me a lot, so I didn't pursue it further. Actually I tried quite hard to get rid of it but couldn't - would be interested if anybody has a solution but my take is that you have to live with it.

Hi thanks for the comments, but those links don't seem to help with my problem.  I tried to use the ``interact +++ return'' as well as ``interact -o eof return'' but neither seemed to work.  The one second pause at the end is still happenning.

Looking further, I can see it's a part of the expect library.  I would ask the expect mailing list but I don't see an expect mailing list on their web site.  On their FAQ they say they don't have a mailing list anyway.

I guess I can try to look in the sources for this string and make it not sleep if this happens and just exit.  Who knows maybe it will work.

strings /usr/lib/libexpect5.43.so | grep "write() failed to write anything "
write() failed to write anything - will sleep(1) and retry...

                                              

1:
2:

Yes that might work - at least on Linux platform. The message comes from ExpOutputProc in exp_chan.c (see Code Snippet).
The sleep is done after write() returns a written byte count of 0. The expect code treats this as a transient condition - hence the sleep and return of EAGAIN - which may cause the caller to re-try the write, by which time the condition has cleared.
Whether or not it still happens on Sun platforms, it's now happening under Linux.
I take issue with the comment "this is not a documented return value". Actually it *is* documented in the man page:

If count is zero and  the file descriptor refers to a regular file, 0 will be returned without causing any other effect

Is that happening?
Will post more if I find time to investigate

   219 /*
   220  *----------------------------------------------------------------------
   221  *
   222  * ExpOutputProc--
   223  *
   224  *^IThis procedure is invoked from the generic IO level to write
   225  *^Ioutput to an exp channel.
   226  *
   227  * Results:
   228  *^IThe number of bytes written is returned or -1 on error. An
   229  *^Ioutput argument^Icontains a POSIX error code if an error occurred,
   230  *^Ior zero.
   231  *
   232  * Side effects:
   233  *^IWrites output on the output device of the channel.
   234  *
   235  *----------------------------------------------------------------------
   236  */
   237
   238 static int
   239 ExpOutputProc(instanceData, buf, toWrite, errorCodePtr)
   240     ClientData instanceData;^I^I/* Exp state. */
   241     char *buf;^I^I^I^I/* The data buffer. */
   242     int toWrite;^I^I^I/* How many bytes to write? */
   243     int *errorCodePtr;^I^I^I/* Where to store error code. */
   244 {
   245     ExpState *esPtr = (ExpState *) instanceData;
   246     int written = 0;
   247
   248     *errorCodePtr = 0;
   249
   250     if (toWrite < 0) Tcl_Panic("ExpOutputProc: called with negative char count");
   251
   252     written = write(esPtr->fdout, buf, (size_t) toWrite);
   253     if (written == 0) {
   254       /* This shouldn't happen but I'm told that it does
   255        * nonetheless (at least on SunOS 4.1.3).  Since this is
   256        * not a documented return value, the most reasonable
   257        * thing is to complain here and retry in the hopes that
   258        * it is some transient condition.  */
   259       sleep(1);
   260       expDiagLogU("write() failed to write anything - will sleep(1) and retry...\n");
   261       *errorCodePtr = EAGAIN;
   262       return -1;
   263     } else if (written < 0) {
   264       *errorCodePtr = errno;
   265       return -1;
   266     }
   267     return written;
   268 }

                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:

I wouldn't waste time trying to fix expect 5.43. There is a newer one - 5.44.1.11 (on my Slackware 12.2 DVD image).
I diffed the sources and found inter alia:

diff -r -w expect-5.43/exp_chan.c expect-5.44.1.11/exp_chan.c
[lots of stuff]
250a266,268
>     if (toWrite ==0) {
>         return 0;
>     }

That looks quite likely to fix our problem. I'll try an upgrade as soon as I get time (have to go now)

Hi Duncan_roe, I had similar results, it works in the new version of expect with slackware 12.2 but not the old version of expect with slackware 12.1.

I tried to compile from sources but no luck (even with the tcl8.5.5 sources available).  Were you able to upgrade both the tcl and the expect packages ``in place'' on the slackware 12.1 system to the slackware 12.2 versions of those packages?  I will give that a try later today when I have a chance.

Thanks for all your help.

Yes I did that. Actually I did rather more - upgraded glibc (Slackware upgradepkg can do that on a running system - really cool:). Because I was upgrading from SW10.1 I had a bit more to do - kernel was too old so had to config up my current version (2.6.25.4) for the 32-bit system, also had to move /lib/tls/ out of the way because no dynamic executables would run after ldconfig. Had to do something like
cd /lib;./ld-2.3.so /usr/bin/mv tls tls.old
so move it out the way first if you still have it. I'd expect to be able to build tcl/tk/expect after upgrading glibc and gcc to the versions shipped with SW12.2 - nowadays I always try to use the Slackware build script e.g. expect.SlackBuild having copied the entire expect dir off the ISO to /tmp. I need to do that to build 64-bit Slackware packages - these don't seem to be shipping yet.
Upgrading is a snip - got this hint from some doco somewhere in the DVD:

cd /mnt/slkdvd/slackware/tcl
upgradepkg *.tgz