command pipelines, blocking and stderr

[David N. Welton]

Hello,

I've written a bit of code that is quite useful for launching commands
from Tk without locking up the application (at the end of the message),
but there's something I don't quite get. The code to close things down
is like so:

if { [eof $fl] } {
fconfigure $fl -blocking 1
catch { close $fl } err

which is saying that if there is nothing more to read from the
processes's stdout, we need to close things down and report back to
whoever called us. The problem I was encountering was that without
setting the channel back to blocking before closing it, it didn't report
in 'err' the command's stderr. I sort of see the logic behind this, but
I wanted to enquire about it to see if others feel that this is the
right way to do things...

Opinions?

Thanks,
--
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/

------------------

namespace eval runcommand {}

proc ::runcommand::runcommand {cmd} {
variable standarderror
variable standardout

#puts "running $cmd"

set standardout ""
set standarderror ""

set fl [open "| $cmd" r]
fconfigure $fl -blocking 0
fconfigure $fl -buffering none

::runcommand::runcommandloop $fl
vwait ::runcommand::finished

#puts "stdout: $standardout"
#puts "stderr: $standarderror"
return "Output:\n$standardout\nErrors:\n$standarderror"
}

proc ::runcommand::runcommandloop {fl} {
variable standarderror
variable standardout

append standardout [read $fl]
if { [eof $fl] } {
fconfigure $fl -blocking 1
catch { close $fl } err
append standarderror $err
after 1 [list set ::runcommand::finished 1]
return
}
after 100 [list ::runcommand::runcommandloop $fl]
}

set out [runcommand::runcommand "make aaaa"]

puts $out

[Steve Bold]

It's a troublesome area. Until recently, closes on Windows were always blocking,
regardless of the fconfigure settings, see:

http://sourceforge.net/tracker/index.php?func=detail&aid=947693&group_id=10894&atid=110894

BLT's bgexec can capture error information without blocking, though BLT is not
present in all Tcl distributions and I have had problems with bgexec:

http://sourceforge.net/tracker/index.php?func=detail&aid=1052238&group_id=18616&atid=118616
http://sourceforge.net/tracker/index.php?func=detail&aid=1016629&group_id=18616&atid=118616

I have proposed a TIP to add more flexiblity to the Tcl core's process management capabilities,
which could address this issue in a future release:

http://www.tcl.tk/cgi-bin/tct/tip/240.html

Steve.

"David N. Welton" <dav...@dedasys.com> wrote in message news:433d0011$0$15701$4faf...@reader4.news.tin.it...

[David N. Welton]

Steve Bold wrote:

> I have proposed a TIP to add more flexiblity to the Tcl core's process management capabilities,
> which could address this issue in a future release:
>
> http://www.tcl.tk/cgi-bin/tct/tip/240.html

Looks pretty good, how is it progressing?

I was running my code on Linux. It surprised me that the close didn't
grab the stderr from the process being run, and was curious if that's
known/documented/a bug/?

[Steve Bold]

"David N. Welton" <dav...@dedasys.com> wrote in message

news:43417A0B...@dedasys.com...

> Steve Bold wrote:
>
>> I have proposed a TIP to add more flexiblity to the Tcl core's process
>> management capabilities,
>> which could address this issue in a future release:
>>
>> http://www.tcl.tk/cgi-bin/tct/tip/240.html
>
> Looks pretty good, how is it progressing?

Thanks. I've neglected it since getting it working on Windows. The recent
push to finish TIPs
has reminded me I should get the implementation submitted. It also needs a
TCT sponsor to
gete it voted on.

> I was running my code on Linux. It surprised me that the close didn't
> grab the stderr from the process being run, and was curious if that's
> known/documented/a bug/?

You mean close with blocking disabled not reporting the stderr text? Well
...
Is it known? I've tripped over it in the past and I doubt I'm the only one.
Is it documented? Not in the manuals. The Wiki probably has a comment about
it somewhere.
Is it a bug? I'd call it a limitation of the 'open |' interface.