For Programmers: Free Programming Magazines  


Home > Archive > Tcl > November 2007 > Possible expect bug: interact closes stdout









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Possible expect bug: interact closes stdout
John Caruso

2007-11-30, 10:12 pm

I'm running into an issue in which expect (5.42.1 and 5.43.0) closes stdout
if a script that uses the interact statment is run with input redirected
from /dev/null. It seems like a bug to me, since I don't see why stdout
should be affected. Here's the script:

---- 8< ---------------------------------------------------------
#!/usr/bin/expect

proc bugaboo { count } {
puts -nonewline "Here's some initial output (count=$count)\n"
spawn date
expect 2007
interact
puts -nonewline " ========================================
====\n"
wait -nowait
}

set count 0
while true {
incr count
if { [catch { bugaboo $count } error] } {
send_error "An error occurred (count=$count): '$error'\n"
catch { send_user "This will produce no output\n" }
catch { puts "And neither will this" }
exit $count
}
}
---- 8< ---------------------------------------------------------

If you run this script with no input redirection it will loop indefinitely,
as expected. If you run it with "< /dev/null", though, it will bomb with
'error writing "stdout": bad file number' on either the first or second
iteration, and both the send_user and puts statements within the if will
produce no output:

---- 8< ---------------------------------------------------------
% ./script < /dev/null
Here's some initial output (count=1)
spawn date
Fri Nov 30 10:53:32 PST 2007
========================================
====
Here's some initial output (count=2)
spawn date
Fri Nov 30 10:53:33 PST 2007
An error occurred (count=2): 'error writing "stdout": bad file number'
---- 8< ---------------------------------------------------------

If you comment out the "expect 2007" it always bombs on the first loop.

Removing the interact statement fixes the problem, so the interact is
definitely the source of this behavior. I'd have thought that using
interact in a script with input redirected from /dev/null would just
behave like an expect statement, but that's not what's happening.

Is this a bug? If not, can anyone explain what's going on here?

- John
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com