Possible expect bug: interact closes stdout
- From: John Caruso <johnSPAMcarAWAYuso@xxxxxxxxxxxx>
- Date: Fri, 30 Nov 2007 19:02:02 GMT
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
.
- Prev by Date: Re: tcl 8.3.3: concurrent http::geturl fail to save complete image
- Next by Date: Can't manage ... it's a top-level window
- Previous by thread: tcl 8.3.3: concurrent http::geturl fail to save complete image
- Next by thread: Can't manage ... it's a top-level window
- Index(es):
Relevant Pages
|
