dave@micropen (David F. Carlson) (06/12/87)
I am running system V r2 and need to have several processes update
a single terminal screen. I know Pike's pty model (in user code)
is problably the way to go. I know the PD wm *might* do some things
right. What other programs are available to do this sort of tty
multiplexing?
Any assistance would be greatly appreciated.
--
David F. Carlson, Micropen, Inc.
...!{seismo}!rochester!ur-valhalla!micropen!dave
"The faster I go, the behinder I get." --Lewis Carrollrwhite@nu3b2.UUCP (Robert C. White Jr.) (06/16/87)
In article <355@micropen>, dave@micropen (David F. Carlson) writes: > I am running system V r2 and need to have several processes update > a single terminal screen. I know Pike's pty model (in user code) > is problably the way to go. I know the PD wm *might* do some things > right. What other programs are available to do this sort of tty > multiplexing? Might I seggust a curses terminal driver and a somple rondivous? Juts share a block of memory or use message mode to salve a single curses program/window/screen. If you get creative the sme rondivous could be used on multiple terminals from multiple trees. define functions to 1) position cursor 2) write text/attributes 3) field erase 4) trigger screen updating no matter how inefficent 1,2 and 3 are, 4 is the only one doing any work and curses will optomize that for you. Steal the input yourself and volia! Robert. (-: just a thought 8-)
guy@gorodish.UUCP (06/16/87)
> > I am running system V r2 and need to have several processes update > > a single terminal screen. I know Pike's pty model (in user code) > > is problably the way to go. I know the PD wm *might* do some things > > right. What other programs are available to do this sort of tty > > multiplexing? > > Might I seggust a curses terminal driver and a somple rondivous? > Juts share a block of memory or use message mode to salve a single curses > program/window/screen. If you get creative the sme rondivous could be used > on multiple terminals from multiple trees. Assuming this person wants to have the processes update the terminal screen *by writing to something they think is a terminal*, that solves the easy part of his problem, and leaves the hard part untouched. Using shared memory or message queues is all very well and good, but it means you have to change *all* programs run by the processes to use them for output rather than writing to a terminal. This means, for example, that you can't just have a UNIX shell running in a window. You could also use pipes; however, since pipes don't respond appropriately to terminal "ioctl"s, lots of programs that have to use those "ioctl"s will be surprised. This includes such unimportant programs as "vi", EMACS, other screen editors, office automation packages, etc., etc. - or, for that matter, any program that uses standard I/O for output, and that the user would want to run in line-buffered mode in a window; if "isatty" says "no", the standard I/O package will use full buffering for standard output. The problem is that S5, as distributed by AT&T, doesn't have pseudo-ttys. The "as distributed by AT&T" is important; many vendors have added them to their S5 systems. There are a couple of pseudo-tty based window managers around: 1) the one in the S5R3 source directory "/usr/src/lib/libcurses/demo/window", written by Mark Horton. It will take some work to get it running on such an S5 system, but not a huge amount. 2) the one in the 4.3BSD source directory "/usr/src/ucb/window". The README file says "window only runs on 4.2 machines", which means it requires some functionality present in 4.2BSD but not in all UNIX variants. Some S5 systems may have this, some may not; I don't know what functionality is required other than pseudo-ttys. There are probably others out there somewhere. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com