daveb@geac.UUCP (11/02/87)
Although I admit to knowing a fair bit about the history and
philosophy of Unix, I must admit puzzlement in one fairly large and
obvious (spelled "embarassing") area.
I can't for the life of me figure out how to separate material
written to "/dev/ttyXX" by another user or process from material
written by my shell or editor process.
What I wish to do is leave my /dev/tty writable, but direct
it to a particular program, while my shell and editor happily use
the real tty to talk to me, and can talk to the program listening
for my output.
I can think of several ways to approach this:
1) literally: put a FIFO or socket in the path from
/dev/ttyXX to me, and feed that to a program.
2) figuratively: use an existing Streams or Sockets facility
to point the streams of text where I want them.
3) kludgily (n ways).
Suggestions re algorithms, please: I will collect them, post and
(if implemented) post the results.
--
David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb
Geac Computers International Inc., | Computer Science loses its
350 Steelcase Road,Markham, Ontario, | memory (if not its mind)
CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.katzung@laidbak.UUCP (Brian Katzung) (11/07/87)
The easiest way to do it is have /dev/ttyXX be the real tty, but don't make it publicly writeable. Require that stuff from other users (and perhaps BSD biff type output?) go to a socket or FIFO managed by a program. In other words, modify write, talk, etc. If you don't, you have to modify things like init, so that it doesn't try to run a getty on an unmonitored socket/FIFO, and ttyname(), so your processes know what you're really using. Using a control socket or FIFO, you would then send messages to this monitor program telling it where to send stuff. Under BSD, you could even have it deliver stuff only when your shell has control of the terminal (tty process group == shell process group). The computer center at UC Berkeley had most of it's Televideo terminals lobotomized because bored students would send commands to the status line (of other people's terminals) and then send transmit-status-line-to-host. It would have been much better to just make the terminals unwriteable and modify write and talk. -- Brian Katzung ihnp4!laidbak!katzung
chris@mimsy.UUCP (Chris Torek) (11/08/87)
In article <1757@geac.UUCP> daveb@geac.UUCP writes: >... I can't for the life of me figure out how to separate material >written to "/dev/ttyXX" by another user or process from material >written by my shell or editor process. > What I wish to do is leave my /dev/tty writable, but direct >it to a particular program, while my shell and editor happily use >the real tty to talk to me, and can talk to the program listening >for my output. While this is certainly possible, I think it is solving the problem from the wrong direction. It seems to me that opening a /dev file should be the `least complicated' (whatever that means) way that exists for talking to some bit of hardware. Hence opening /dev/ttyXX (or /dev/ttys/XX) should get you a direct path to that terminal, as it does even now. To solve daveb's problem (and my own: I hate interruptions that splat all over my editor windows too), most programs should not talk to the terminal directly, but rather through a negotiator. Whether one talks to this by opening /dev/yyy or by some other means is irrelevant at the moment: First we need to determine just what this negotiator is to do. What I think I want at this moment is to be able to separate requests on the basis of the requesting program, with categories `refuse', `accept', and `conditionally accept'. The last is a trick: The negotiator is to tell me who or what is *behind* the action from the program. In particular, `talk' and `write' are invoked by users, and perhaps I wish not to be interrupted by anyone, but I will take `emergency' messages. Conditional acceptance is thus like having a person screen calls. When a request is accepted, I want a new window to appear on my Sun (or whatever). Since I may be using a remote login facility, the negotiator must be able to speak across the network. Using X or NeWS this is almost trivial, but it might be nice to be able to do this under SunView or other less capable window systems. This may still be almost trivial: A negotiator can simply talk to another negotiator, so that the one on the old clunky Vax can talk to the one on the Sun to have that one open a new window. And of course, the negotiator on the Sun can screen negotiator requests from remote hosts. Oh well, enough brainstorming for now. I need to go find some new kernel bugs I wrote last Friday.... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
matt@oddjob.UChicago.EDU (Keeper of the Sacred Tablets) (11/10/87)
I have a package I got from UCI eons ago that does most of what's
been asked for. It's called "ttyd" and is available by anonymous ftp
from oddjob.uchicago.edu as pub/ttyd.tar.Z. I suggest the those
interested look around in UCI's anonymous ftp area (wherever that is)
first because they may have a newer version. In the copy I have,
the wall command tends to glitch a lot due to a design error.
With ttyd users should set "mesg n" and then run a suid program to
declare the action they want taken upon connection requests. The
action can be to pass messages on to the tty, to refuse messages, to
mail them to a given address, send them to a file, pipe them to a
program, or connect them to a specified socket. There is no
filtering based on the originator, although a wall or write from root
will still go through.
________________________________________________________
Matt University matt@oddjob.uchicago.edu
Crawford of Chicago {astrovax,ihnp4}!oddjob!matt