I've already reported this upstream: http://core.tcl.tk/tcl/tktview/30c5d37cfa0028c9ef83fa9efc490f4bc28b64ff I'm reporting it here, in part, in case any of the maintainers may have any insight on this one. This one is a pretty big problem for me at the moment. An expect block in an expect script that uses the eof pattern, especially in conjunction with other regex patterns, can frequently get the eof and close the process before all output from the spawned process is received, or output by the script. I first encountered this using expect to run commands on remote systems via ssh, but then discovered that it had nothing specifically to do with ssh. See the example script I put in the upstream bug which duplicates it simply be spawning a cat command. As noted in that bug, I've been able to reproduce this on Gentoo and other distros such as Cent OS, but I am unable to reproduce it on any older system running tcl 8.4. Also note that, while it does no always occur, it seems to be very easy to duplicate. It's much more likely to occur when there are regex (-re) patterns in the block (as in the example), and even more likely to occur if match_max is reduced. Reproducible: Sometimes Steps to Reproduce: 1. Run the script in the upstream bug, using a fair sized text file named in.txt, and redirect the scripts output to out.txt. 2. Run "diff -w in.txt out.txt" Actual Results: More often than not, the output will be missing (often many) lines from the end of the output. Expected Results: You would think it would get an eof at the end of the output of the process.
As noted in the upstream issue, this one can be closed. As it turns out, this was rooted in a misunderstanding on my part of the use of "log_user 1", and the fact that relying on that can randomly drop unmatched text in the last part of the expect buffer. Sorry for the noise.
