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