Subject: Returned mail: User unknown (fwd)
To: None <>
From: Rob Shady <>
List: netbsd-users
Date: 11/24/1993 08:27:55
Forwarded message:
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
Message-Id: <>
To: <crt>

Connected to
>>> RCPT To:<>
<<< 550 <>... User unknown
550 <>... User unknown

	id AA28149; Tue, 23 Nov 93 13:57:18 EST
From: crt (Rob Shady)
Message-Id: <>
Subject: Implementing TIOCSTO?
Date: Tue, 23 Nov 1993 14:00:30 -0500 (EST)
Content-Type: text
Content-Length: 2063      

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