pipe without EOF

[pan]

Dear tcl experts,

Wanting to incorporate dbus messages in my tcl program, I am trying to
open a pipe to the dbus-monitor program.
The following fragment of code is my attempt to just echo the dbus-monitor.
It is not working, however. I guess this is because dbus-monitor does not
send an EOF character.
For example, "dbus-monitor | less" also produces no output.
Is there a trick to make this work?

Thanks in advance!

proc ProcessMessage {in} {
puts "In ProcessMessage..."
if {[eof $in]} {
fileevent $in readable {}
close $in
return
}
set data [read $in]
puts $data
}

set in [open "|/usr/bin/dbus-monitor" r]
fconfigure $in -blocking 0
fileevent $in readable [list ProcessMessage $in]

[pan]

Two smalls things I forgot to say:

1-

> set in [open "|/usr/bin/dbus-monitor" r]

changing the command to "|cat" or "|ls" seems to work fine.

2-
> fconfigure $in -blocking 0
adding -buffering none does not help me as well.

[Ralf Fassel]

* pan <p...@zutt.org>

| For example, "dbus-monitor | less" also produces no output.
| Is there a trick to make this work?

dbus-monitor needs to flush its output, otherwise it might be buffered
by stdio or the OS. Does 'dbus-monitor' exit? If so, I would expect
that all open channels are flushed at exit, so the output should
appear. However, if 'dbus-monitor' is a long running program,
you might need to convince it to flush its output after e.g. each
line. For more details, check also the wiki at http://wiki.tcl.tk

R'

[pan]

Thanks, that's very clear to me. Not much I can do.
I filed a feature request at dbus's bugzilla.
dbus-monitor does not exit, it keeps waiting and printing new
incoming signals for ever.
I created a plugin that can display these messages nicely
integrated in a chat client, so I hope they make this change for me (since
me doing it locally is only useful to me).

[Ulrich Schöbel]

Hi Pan,

did you try 'unbuffer', an expect program?
If 'dbus-monitor' works correctly when connected
to a terminal, 'unbuffer' should help.

Best regards

Ulrich

In article <pan.2005.10.12...@zutt.org>,

[pan]

Wow, thanks, that works!
I didn't know that trick :)

[Ralf Fassel]

* pan <p...@zutt.org>

| dbus-monitor does not exit, it keeps waiting and printing new
| incoming signals for ever.

As you already have noticed, the difference is in the buffering of
stdout of 'dbus-monitor': usually stdout is line-buffered when
connected to a terminal, and fully-buffered else.

If you can fool 'dbus-monitor' into thinking it is connected to a
terminal (this is what 'expect' does), then its stdout will still be
line buffered, and you can read it line by line.

R'