testsuite/lib/libsup.exp appears to be an interesting fossil

[Jacob Bachmeyer]

While recently improving the DejaGnu testsuite, I found that using 
"pass" in a unit test case that loads framework.exp produced an error:  
"PASS doesn't exist in incr_count".  The immediate solution was "well, 
of course that does not work" and just writing {puts "PASSED: ..."} 
instead, but libs.exp uses a make_defaults_file procedure that turns out 
to be defined in libsup.exp.  The libsup.exp file seems to mostly be a 
fossil, older than the 1997 ChangeLog entry that recorded grouping test 
counts into an array:  the defaults file libsup.exp writes still 
contains the old variable names, leading to the error mentioned above.

The ChangeLog indicates that libsup.exp was added about a week before 
the *.test unit test cases were added, when the original unit test 
drivers that the *.test files replaced were written.  (An apparent typo 
records the file as "testsuite/lib/libsupp.exp" but that is the only 
match for "libsup" anywhere in the ChangeLog that indicates a new file.)

Reading libsup.exp is interesting.  The file appears to be mostly-unused 
infrastructure for running unit tests with an interactive Expect 
subprocess.  This looks like a solution to the slightly inelegant {spawn 
-open [open "|$EXPECT ..."]} currently used in libs.exp.  I had tried 
directly spawning each unit test process, but encountered a strange bug 
where the output could be truncated if the child exits before it has all 
been read.  The dbg.log simply records "expect: read eof" and the "END" 
is never seen.  This bug could be partially worked around by having the 
child sleep before exiting and does not occur if the child is connected 
using a pipe rather than a pty.  For unknown reasons, this bug does not 
occur with my project's unit tests that use the same approach of 
directly spawning a subprocess connected with a pty.  Using an 
interactive Expect shell would also solve the problem, as an interactive 
shell will not exit until so directed, and this provides a handshake 
that should solve the problem, as it seems to be a timing issue.

Is there a known reason that this approach (an interactive Expect 
subprocess) is not used, or was there simply not time to pursue it in 
early 1996?


-- Jacob