Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!know!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.questions
Subject: Re: ps and wall; How do they work?
Message-ID: <13871@smoke.BRL.MIL>
Date: 16 Sep 90 00:50:17 GMT
References: <27XgP3w163w@mudos.ann-arbor.mi.us> <13859@smoke.BRL.MIL> <1990Sep15.132001.28596@virtech.uucp>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 20

In article <1990Sep15.132001.28596@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes:
-Doesn't wall(1) just send messages to terminals that users are logged
-into?  Then there shouldn't be a problem with printer or other comm
-ports where user's are not logged in.

I didn't say that the printer hadn't been logged in.  Users with hardcopy
terminals (e.g. letter-quaility) have used them for printing nroff output
for quite a long time now.  A side effect of a reasonable nroff with
output sent to such a printing terminal is that the equivalent of "mesg n"
is performed to block "write" and "wall" during printing.

-To handle the case where a comm program is initiated once the connection
-is established, the comm program should be able to handle (and ignore) 
-the noise generated by the message.  If that is not feasible, perhaps 
-a solution where the process turns off the "owner-write" permission
-bits (this is not what mesg -n does) on a tty and write is modified to
-not send a message to this port.  I don't think this is necessary.

You're getting too elaborate.  All that is necessary is for "mesg" and
"write"/"wall" to cooperate.