X230GV@TAMVM1.BITNET (Glenn Vanderburg) (04/22/88)
Greetings,
This really won't help anyone to solve the problem of intercepting output
from talk, but I just wanted to take the opportunity to pontificate about
daemons writing indiscriminately to the user's terminal. I have strong
feelings about this issue because I am fortunate enough to work on a system
which has better (although not perfect) behavior.
I do a lot of work on a Unix system which is on Bitnet. Bitnet has a
built-in protocol for sending one-line messages to other users:
tell userid@node Are you there?
Unlike talk, the messages are sent as packets, line by line.
This is implemented on our system by some software written in-house by
a friend who used to work here. All such messages go through a FIFO (yes,
we're System V) to a demultiplexing daemon (demulti). Here is what demulti
does with an example message to userid joeuser.
Open a FIFO called ~joeuser/.msgpipe for writing. Using fcntl, determine
whether a process is currently reading from it.
If no process is reading from the FIFO and joeuser is logged on, fork
off a "writer" daemon which will setuid to joeuser, read from
the FIFO, and write to joeuser's terminal. Then demulti writes the
message to the FIFO for writer to handle. writer will die
automatically after 5 minutes of inactivity.
If no process is reading from the FIFO and joeuser is not logged on,
send a "not logged on" message to the originator.
If a process is reading from the FIFO, write the message to it without
caring whether joeuser is logged on or not.
This is obviously kind of strange, but it has the advantage that users
can write their own message handlers using the readmsg function which has
been installed in a local object library. Since demulti doesn't care if the
user is logged on as long as a process is reading from the .msgpipe, the
user can write a daemon to forward or save messages for them during an
absence. It also made it fairly trivial for me to write a "listen" program
for emacs which intercepts the messages and writes them to the echo area
(among other things) rather than splattering the screen. It has proven to
be a fairly versatile mechanism.
One further note: the readmsg function mentioned earlier does something
special when it opens the FIFO the first time. If a process is already
reading from it, readmsg first opens the FIFO for writing and sends a
special message down it (defined by the C macro DIE_U_DAEMON :-) and any
process reading from the FIFO with readmsg will exit. Then the new process
can take over as the message handler.
The implementation is a little kludgey, but the result is great. In the
absence of any action by the user, the output just gets written to the
terminal, just as you would expect. But the user can intercept those
messages if needed, and handle them in a different way. If only everything
was done that way.
Regards,
Glenn Vanderburg