Subject: Returned mail: User unknown (fwd)
To: None <firstname.lastname@example.org>
From: Rob Shady <email@example.com>
Date: 11/24/1993 08:27:55
From Mailer-Daemon Tue Nov 23 21:23:43 1993
Date: Tue, 23 Nov 93 21:23:36 EST
From: Mailer-Daemon (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
----- Transcript of session follows -----
Connected to sun-lamp.cs.berkeley.edu:
>>> RCPT To:<firstname.lastname@example.org>
<<< 550 <email@example.com>... User unknown
550 <firstname.lastname@example.org>... User unknown
----- Unsent message follows -----
id AA28149; Tue, 23 Nov 93 13:57:18 EST
From: crt (Rob Shady)
Subject: Implementing TIOCSTO?
Date: Tue, 23 Nov 1993 14:00:30 -0500 (EST)
Okay, here is the situation... I have a need (as do others) to implement
a tty 'watch' program, in which the system operator can see exactly
what is on another tty, and possible interject input as well. (For
tutoring, debugging user problems, etc). The problem is trying to figure
out what the PROPER way to do it is, I have at LEAST 4 different ideas,
which are as follows:
1) I started this one, then decided to ask about it. I added a
TIOCSTO call to tty.c, which when called returns one character from
the output buffer of the watched terminal. (TIOCSTO to complement
TIOCSTI, which simulates terminal input). The problem is, if this
is not called at a relatively fast rate of speed, we loose characters.
So, on to solution #2...
2) Implement a fourth queue in the tty structure that keeps the last
X # of bytes sent to each terminal. Create the TIOCSTO as above,
but return an entire buffer of characters each call, therefor loosening
up the time restraints on the calling program. The problem with this
is that now every tty has an extra buffer that more than likely won't
be used most of the time, therefor wasting system resources.
3) The third solution is to create a TIOCSTO call, but instead of
retrieving a character or buffer from the watched terminal, we pass
it a point to a routine in our program that get's called every time
a buffer get's full in the tty structure OR everytime a character
get's output to the watched terminal. Problems with both as above.
4) The final solution I've come up with is this, and I don't like it, but
it is PROBABLY the best solution since it SHOULD work without modification
on most UNIX systems. Create a process with a virtual tty, and have
that process execute a shell piping the output to both the watched
terminal AND the watcher's terminal. Problem is, the person being
watched has to run the command to allow someone else to watch them.
Now is that a problem, or a feature? ;)
-- Rob Shady