Watch, Spy, whatever you wanna call it

[John B. Milton]

In article <29835 at netnews.upenn.edu> kehoe at scotty.dccs.upenn.edu (Brendan Kehoe) writes:
[stuff about VMS WATCH]
> Well, anyway, what's the deal? Has one ever been written for under Unix? (With
>the plethora of hackers [old definition, not vernacular] that have and are in
>the Unix world today, I'd be really surprised if it hadn't.)
> Ok, let's say it hasn't. Then how about what it'd take to write one? I can
>think of a little theory (sharing their device buffers, etc etc) but I can see
>that I'd probably know more internals (how oddly appropriate) than I would
>ever want to if I were to sit down and do this (preferably not alone). But
>that may not be that bad.
> Whatcha think?

Hmm. As far as I know, this has not been done for UNIX. This was available
under TOPS/20, I think it was called ADVISE. 

I would very much shy away from trying to modify one driver to accomplish this.

There are some ugly high level sorts of things (tee-ish) that might sort of
work, but certainly not retroactively.

I would think that the appropriate way to implement it would be with a STREAMS
module. The monitor program would open the tty device  of the person to be
monitored/assisted. The monitor would then push a monitor module onto the
device and communicate with the module through ioctl() calls. One problem is
that the tty (pty, sxt) device would have to be a STREAMS device. The monitor
program could put the input/output through the tty in a window, look into the
envp of the process to get the TERM variable (or dynamically figure out the
term type), blah blah. The rest is just window dressing. Adapting to stty modes
and such could be partially done by the monitor module.

In the absence of STREAMS, one might be able to do it with a line discepline
(old STREAMS).

John
-- 
John Bly Milton IV, jbm at uncle.UUCP, n8emr!uncle!jbm at osu-cis.cis.ohio-state.edu
(614) h:252-8544, w:469-1990; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!