ugfeldmn@sunybcs.UUCP (Jon Feldman) (04/21/88)
In article <969@unmvax.unm.edu> mike@turing.UNM.EDU.UUCP (Michael I. Bushnell) writes: >In article <233@jim.odr.oz> brw@jim.odr.oz (Brian Wallis) writes: >>I'd also like to stop talkd splattering it's message all over the screen, a >>message in the mode line and ringing the bell would be better. >Since talkd is the system program, you can't change its behavior. >Sigh. > Michael I. Bushnell > HASA - "A" division Hmph... It strikes me that there _ought_ to be a way for emacs to intercept system messages --- I know that mh-* pulls up *temp* windows to display system messages, much like TPU in VMS. I wish that I could instruct emacs to be similarly well-behaved. Server mode ("start-server") sounds like a path in the right direction, but I don't know; I'm no all-knowing gnuisance. ;-) One of you gnuisances out there --- yeah, you! Pretty please, couldya tell us proles if there's a way to do this, that is, intercept system messages so that they don't mess up our windows? Danks, - Jon -- Jon Feldman ugfeldmn@joey.cs.buffalo.edu || rutgers!sunybcs!ugfeldmn _^--^_ A fool's brain digests philosophy into folly, science into / . . \ superstition, and art into pedantry. Hence University education. ( \ ) --- George Bernard Shaw ^------------+ `__~_'
mike@turing.UNM.EDU (Michael I. Bushnell) (04/21/88)
Sheesh. Everyone wants a means of intercepting system messages
intended for your terminal, so that emacs can deal with them
nicely. Here is a PAINFUL but workable scheme.
Set up the following:
mas sla
+-------+ +---------+ +---------+ +----------+
| | A | | A | | A | |
| Real |---->| filt |------>| |-------->| |
|login | | | | PTY | | emacs |
| tty |<----| |<------| (login) |<--------| |
| | B | | B | | B | |
+-------+ +---------+ +---------+ +----------+
| ^ ^
| | |
+----------------)------------------+
C |
|C
+---------+
| |
| talkd |
| |
| |
+---------+
The PTY is put in USER IOCTL mode (remember?). That means that
every read on the master side has an extra byte prepended. 0
means it was written normally on the slave side, anything else
is from an ioctl call the slave made. Change emacs to do this
ioctl call before every write to the terminal. Then, filt
watches for this byte. If it's zero, then the write came from a stupid
system process, and is sent to emacs on a pipe. the filt
program is started by emacs, which then changes its tty (to the pty)
and mugs utmp to fool talkd into using the new pty, and then
goes into "ioctl before each write" mode.
Channel A: Your keystrokes
Channel B: Emacs's writes, identified by the ioctl
Channel C: Stupid system program's writes, identified by the lack of ioctl
UGH! But I think it would work....
N u m q u a m G l o r i a D e o
Michael I. Bushnell
HASA - "A" division
14308 Skyline Rd NE Computer Science Dept.
Albuquerque, NM 87123 OR Farris Engineering Ctr.
OR University of New Mexico
mike@turing.unm.edu Albuquerque, NM 87131
{ucbvax,gatech}!unmvax!turing.unm.edu!mikeandrew@frip.gwd.tek.com (Andrew Klossner) (04/24/88)
"tell us proles if there's a way to do this, that is, intercept
system messages so that they don't mess up our windows?"
Talk (at least under 4.2BSD) determine where to send its messages by
reading the utmp file to see which terminal is associated with the
requested user. Normally it will find the terminal on which "login"
ran. You can divert talk's messages by changing this file to reflect a
pty and then monitoring that pty somehow.
The utmp file is normally not writable by non-root, so you would need
the collusion of your system administrator to make this sort of change.
This isn't a problem if you use a workstation. Of course, if you have
a workstation, you could simply rewrite talkd to behave the way you
want.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]