two-way terminal multiplexing

[Simias]

Tom Judge <tom at tomjudge.com> writes:

> Simias wrote:
>> "djembe nazar" <dn77881188 at googlemail.com> writes:
>>
>>> I am trying to work out a way to do the following for a
>>> "FreeBSD teaching environment":
>>>
>>> The intention is to have two terminals, one above the other.
>>> The bottom terminal shows one's own commands and output like
>>> an ordinary xterm whilst the top terminal shows the commands
>>> and output of a peer (such as an instructor).
>>>
>>> The pupil is not allowed to enter commands into the
>>> instructor's terminal, it simply shows what the instructor
>>> typed and the resulting output of the commands. The same
>>> is true of the reverse. The overall concept is to allow an
>>> instructor to tutor a pupil over an appropriate medium such
>>> as instant messaging whilst allowing the pupil to learn by
>>> example with a very hands-on approach.
>>>
>>> In the case of a standard 1-to-1 teaching environment, the
>>> instructor would see his/her own terminal on the bottom and
>>> the terminal of the pupil on the top. The pupil would see the
>>> reverse (instructor's terminal above, his/her own terminal
>>> below).
>>>
>>>      pupil sees:            instructor sees:
>>>   +-----------------+     +-----------------+
>>>   | INSTRUCTOR TERM |     |    PUPIL TERM   |
>>>   +-----------------+     +-----------------+
>>>   |    PUPIL TERM   |     | INSTRUCTOR TERM |
>>>   +-----------------+     +-----------------+
>>>
>>> I do not understand how to achieve this. Is this even possible
>>> given standard unix security with regards to hijacking the
>>> tty devices of other users on the system?
>>>
>>
>> I think you may achieve this with GNU Screen, since it supports multi
>> users sessions (look for addacl and aclchg in the screen(1) man page).
>>
>> If you want to do that by yourself, I'd use a client/server
>> architecture, the instructor would start a program like script(1), but
>> instead of writing to a file, it'd write to a socket, and the pupil
>> would start a client version that will just read the socket and output
>> what it receives. Note that it probably won't work very well if the two
>> terminals have different size and/or different Termcaps (especially with
>> curses apps like vi or emacs).
>>
>> It's quite trivial to implement, but maybe it won't meet your requirements.
>>
>
> The other option might be to use the terminal snooping option in the
> kernel.  I have never used it but it sounds like what you may want.
>
> Tom
>

Oh and I just thought about this quick solution:

$ mkfifo foo
$ script -f foo

This will create a fifo called "foo" in the current directory and put
the output of script(1) in it. Then on an other terminal you can

$ cat foo

To see what's happening in the first terminal.

However, you'll probably still have strange results if both terminals
are not identical.

-- 
Simias