How to do binary-safe "exec":
proc bexec {command input} {
# Execute shell "command", send "input" to stdin, return stdout.
# Ignores stderr (but "2>@1" can be part of "command").
# Supports binary input and output. e.g.:
# set flac_data [bexec {flac -} $wav_data]
# Run "command" in background...
set f [open |$command {RDWR BINARY}]
fconfigure $f -blocking 0
# Connect read function to collect "command" output...
set ::bexec_done.$f 0
set ::bexec_output.$f {}
fileevent $f readable [list bexec_read $f]
# Send "input" to command...
puts -nonewline $f $input
close $f write
# Wait for read function to signal "done"...
vwait ::bexec_done.$f
# Retrieve output...
set result [set ::bexec_output.$f]
unset ::bexec_output.$f
unset ::bexec_done.$f
fconfigure $f -blocking 1
try {
close $f
} trap {CHILDSTATUS} {options info} {
dict set info -errorinfo $result
return -options $info $result
}
return $result
}
proc bexec_read {f} {
# Accumulate output in ::bexec_output.$f.
append ::bexec_output.$f [read $f]
if {[eof $f]} {
fileevent $f readable {}
set ::bexec_done.$f 1
}
}PYK 2014-05-11: The code above does not need to go to the effort of setting the channel to non-blocking, as Tcl will manage the buffer behind the scenes. Forget about setting the channel to non-blocking, dispense with the vwait, send the desired data into the channel, close the write side of the channel, and then read the output. For code that does need to use non-blocking channels, it's generally best not to interfere with the event loop by using vwait as the code above does. Instead, consider structuring the code such that it works in an event-oriented manner. See also Example of reading and writing to a piped command, which provides a template for conducting an interactive conversation with another process.