lee@minnow.UUCP (06/02/87)
xxxxxx
I would like to have multiple screens on Unix the way I do on
SCO Xenix and Microport Unix.
1). Has anyone written something do this?
2). Does anyone have any ideas on how to approach doing this?
Thanks in advance
--
Gene Lee UUCP: ...ihnp4!{meccts,dayton,rosevax}!ems!minnow!lee
UNISYS Corporation ATT: (612) 635-6334
If not for the courage of the fearless crew, the minnow would be lost.gwyn@brl-smoke.UUCP (06/04/87)
In article <910@minnow.UUCP> lee@A60.UUCP (Gene Lee ) writes: > I would like to have multiple screens on Unix the way I do on >SCO Xenix and Microport Unix. The best ways I know of to acquire this facility are to either purchase a UNIX system with windows integrated into it (such as a Sun workstation) or acquire an AT&T (nee Teletype) model 5620 (or follow-on whenever it is finally announced; we've been expecting one for a while) Dot-Mapped Display terminal and associated UNIX support software. There are also some public- domain implementations of windowing systems for "dumb" CRTs, although they're not nearly as spiffy. I imagine others will tell you about those.
dhesi@rb442.UUCP (Rahul Dhesi) (06/06/87)
Followup-To: lee@A60.UUCP (Gene Lee ) writes: > I would like to have multiple screens on Unix the way I do on ^^^^^^^^ ^^^^^^^ >SCO Xenix and Microport Unix. gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) replies: >The best ways I know of to acquire this facility are to either purchase >a UNIX system with windows integrated into it (such as a Sun workstation) ^^^^^^^ >or acquire an AT&T (nee Teletype) model 5620 (or follow-on whenever it is >finally announced; we've been expecting one for a while) Dot-Mapped Display >terminal and associated UNIX support software. There are also some public- >domain implementations of windowing systems for "dumb" CRTs, although ^^^^^^^^^ ^^^^^^^ >they're not nearly as spiffy. I imagine others will tell you about those. Windows and multiple screens are not the same thing. My UNIX PC has windows. You can create them, then you can reshape them and move them. My Microport System V/AT has multiple screens. You can's reshape them amd move them. The difference is like night and day. On my UNIX PC, it's so much of a bother to use multiple windows that I got rid of them altogether. It's no fun pressing keys here and there, then finding the mouse, then location a corner here and here, and then finally (a few minutes later) getting a new window to work in. On my Microport system, I can hit a key and be working on a fresh new screen in about 50 milliseconds. I don't waste time finding keys and mice, and I don't waste screen space on fancy but useless borders. Now, I don't know how Sun implements its windows, and I'm sure they are implemented better than they are on the UNIX PC. But it's good to be precise in our terminlogy, and I just wanted to emphasize that: WINDOWS AND MULTIPLE SCREENS ARE NOT THE SAME THING.
guy@gorodish.UUCP (06/07/87)
> Windows and multiple screens are not the same thing. > > My UNIX PC has windows. You can create them, then you can reshape them > and move them. > > My Microport System V/AT has multiple screens. You can's reshape them > amd move them. I presume "You can's reshape them and move them" really should have read "You can't reshape them or move them". > The difference is like night and day. On my UNIX PC, it's so much > of a bother to use multiple windows that I got rid of them altogether. > It's no fun pressing keys here and there, then finding the mouse, > then location a corner here and here, and then finally (a few minutes > later) getting a new window to work in. > > On my Microport system, I can hit a key and be working on a fresh new screen > in about 50 milliseconds. I don't waste time finding keys and mice, and > I don't waste screen space on fancy but useless borders. There is nothing about a window system that obliges you to have "fancy but useless borders". There is also nothing about a window system that obliges you to use mice or multiple keystrokes (you will *still* have to find the one key that gets you a new screen, even on your Microport system, although it may be placed so that "finding" it is trivial) to create a new window, or that requires the creation of a window to take minutes. (Yes, I know, SunView puts stuff on the borders and can take a while to create windows, and may not make it possible to pop up a new window and move to that window in one keystroke. I'm saying what's possible here.) > But it's good to be precise in our terminlogy, and I just wanted to > emphasize that: > > WINDOWS AND MULTIPLE SCREENS ARE NOT THE SAME THING. Multiple screens are just windows that are obliged to cover the entire screen; in other words, a multiple-screen system is just a window system with a number of restrictions. The only fundamental difference between a multiple-screen system and a general window system is that a multiple-screen system doesn't have to arrange to multiplex the display, and can possibly use tricks to multiplex the keyboard. The person requested multiple screens "on UNIX". The only way to do this "on UNIX", rather than on a particular UNIX machine or set of UNIX machines, is to assume that all you have available is a dumb terminal. Doing so requires you to do things like maintaining virtual screens, separate from the physical screen; after doing this, the extra work of supporting non full-screen windows isn't much. All that you'd get from not making that step is that you wouldn't have to worry about having programs capable of dealing with variable-size screens, and there are even ways of providing some of that by playing games with things like the TERMCAP or TERMINFO environment variables. In the particular case of a PC, there may be tricks you can play with multiple screens that won't work with windows. The programs running in the "active" window can be given direct access to the screen, and when switching screens you can just copy the entire screen image to a holding buffer; you could just freeze programs running in inactive windows, and thus not have to worry about multiplexing input or output. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
guy@gorodish.UUCP (06/07/87)
> I would like to have multiple screens on Unix the way I do on > SCO Xenix and Microport Unix. The only way to do multiple screens "on UNIX", rather than on a particular UNIX machine or set of UNIX machines, is to assume that all you have available is a dumb terminal. There's a fair bit of work involved in this. > 1). Has anyone written something do this? Various people have done this; Mark Horton wrote a window system whose source can be found in the System V, Release 3.0 source distribution in the directory "/usr/src/lib/libcurses/demo/window". (Various games, including what appears to be a version of the Space Invaders game supplied with 4.1BSD, can also be found in the "demo" directory.) I think there may have been such a window system supplied with the 4.3BSD alpha tape, or something like that; I don't see it in any obvious place in the 4.3BSD distribution. > 2). Does anyone have any ideas on how to approach doing this? If a program is writing to screen 1, while screen 2 is the screen currently being displayed, some window manager must keep track of the "virtual" screen 1. This either means that: 1) the window manager must be able to recognize all the various control sequences that can be sent to any of the terminals it supports - it could do a lot of this by reading the "termcap" or "terminfo" description for that terminal (idea courtesy of Dave Rosenthal's "psterm" terminal emulator for NeWS), but this would require that no program use any sequence other than the ones in the description (which may very well be the case) or 2) the window manager will have to emulate a virtual terminal of some sort, accepting sequences for that virtual terminal as input and updating the physical display using e.g. "curses". (Mark Horton's window system works this way.) Both of these strategies are best done using some sort of pseudo-tty mechanism, which is not supplied with vanilla System V, but appears in 4.[23]BSD and a lot of other UNIX systems (including lots of System V-compatible systems). (There may be ways of doing this with pipes, but there are some problems with that - see below.) Also, the window manager would have to intercept input from the terminal, in order to know when to switch windows/screens, unless you added a new "switch windows" character to the tty driver and arranged to have some event, such as a signal, delivered to the window manager when this character was typed, without affecting any programs running in the window. If this trick were used, the window manager would somehow have to "freeze" programs running in inactive windows/screens, to prevent them from reading from the keyboard, or would have to use some mechanism such as the "sxt" devices used by shell layers to multiplex screens. ("sxt" devices would also provide the "switch" character for switching "shell layers", which could be used to switch between windows/screens instead - alas, "sxt"s have NO mechanism for multiplexing output, so you'd have to have something like pseudo-ttys for this.) If you have pseudo-terminals, you can use them for input multiplexing and capturing the screen-switching commands as well. If not, you might be able to cobble something together with "sxt"s and pipes, although some programs might get confused if their standard input were an "sxt" and their standard output and error were pipes - some would think they were at a terminal and behave correctly, some wouldn't and wouldn't act correctly (e.g., not line-buffering their output), and some might work half-correctly. Note that pipes could not substitute for pseudo-ttys on the *input* side, unless you're willing to sacrifice a lot of things; pipes don't do erase/kill processing, and don't pass "ioctl"s through, so the window manager would either always have to do the erase/kill processing, never do it, or be told via a special window-manager command whether to do it or not. Would you rather not be able to correct typing errors, not be able to run screen editors (or other non-cooked-mode programs) inside a window, or be obliged to switch modes when entering and leaving screen editors? Some programs that do "isatty(0)" to see if they're being run from a terminal (i.e., interactively) would get confused as well. A way of getting around this would be some way of running full-screen programs from the window manager, rather than from a shell in a window. The window manager would make the current screen no longer be the active screen, without making any other screen the active screen, and would also hand control of the keyboard over to the program in question. When that program exited, it would reclaim control of the keyboard and would make the current screen the active screen again. Of course, this means that when you're running a full-screen program, you don't have multiple screens or windows.... Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
ram@nucsrl.UUCP (06/08/87)
Guy Harris wrote: >directory.) I think there may have been such a window system >supplied with the 4.3BSD alpha tape, or something like that; I don't >see it in any obvious place in the 4.3BSD distribution. Well, its as obvious as in /usr/src/ucb/window - all 258K of it. Its on our 4.3BSD alpha's disk :-). > Guy Harris > {ihnp4, decvax, seismo, decwrl, ...}!sun!guy ^^^^^^^^^^^^ where does machine "..." reside:-? > guy@sun.com >---------- ------------------- Renu Raman UUCP:...ihnp4!alpha!ram 1410 Chicago Ave., #505 ARPA:ram@eecs.nwu.edu Evanston IL 60201 AT&T:(312)-869-4276
naim@nucsrl.UUCP (Naim Abdullah) (06/08/87)
Guy Harris writes: > [on the difficulty of implementing a window system that would run > on a *GENERIC* unix system] I remember using a program called "wm" on a 4.1bsd system, that allowed you to create multiple windows via the cursor keys and run programs in each one. I don't remember if vi worked in any of the windows, but I doubt it, since the program used pipes and Guy already talked about the problems that would occur. The program was written by somebody at the Naval Postgraduate School and was supposedly portable to V7 systems. I haven't the slightest idea where to get either the source or the binary. Naim Abdullah Dept. of EECS Northwestern University {ihnp4, chinet, gargoyle}!nucsrl!naim
jfh@killer.UUCP (John Haugh) (06/08/87)
Yes, it is sort of being done. I spoke with John Bremsteller (who I wish would start reading Usenet more) last week and he told me of his current work putting multiple screens per terminal into his kernel. You can reach him at Pinnacle Systems, Inc. Dallas TX. (214)-340-494[12]. He should be able to tell you more than you ever wanted to know. PS - this is NOT a IBM-PC clone running SCO-Xenix - so you _should_ be able to use terminals with this feature. - John (not at pinnacle anymore) Haugh Disclaimer: I don't work for them and I don't speak for them either.
rjk@mrstve.UUCP (06/10/87)
In article <20550@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: >The person requested multiple screens "on UNIX". The only way to do >this "on UNIX", rather than on a particular UNIX machine or set of >UNIX machines, is to assume that all you have available is a dumb >terminal. Doing so requires you to do things like maintaining >virtual screens, separate from the physical screen; after doing this, >the extra work of supporting non full-screen windows isn't much. All >that you'd get from not making that step is that you wouldn't have to >worry about having programs capable of dealing with variable-size >screens, and there are even ways of providing some of that by playing >games with things like the TERMCAP or TERMINFO environment variables. > Guy Harris > {ihnp4, decvax, seismo, decwrl, ...}!sun!guy > guy@sun.com Has anyone done anything like this with STREAMS-oriented tty drivers? It seems to me that windows/multiple screens would be relatively easy to implement by just PUSHing an appropriate module onto the stream that controlled your physical terminal that kept track of what was on your (physical) screen at all times, similar to curses. It could also be handy to have a `virtual' screen of, say, 66 lines, allowing one to scroll both up and down. The more I think about it, the more I could do with a STREAM-based tty driver. Now all I need do is figure out how to get one... -- !pur-ee!pur-phy!mrstve!rjk Rich Kuhns {ihnp4, decvax, etc...} !itivax!mrstve!rjk
roy@phri.UUCP (06/10/87)
In article <3680021@nucsrl.UUCP> naim@nucsrl.UUCP (Naim Abdullah) writes: > I remember using a program called "wm" on a 4.1bsd system, that allowed > you to create multiple windows via the cursor keys and run programs in > each one. I don't remember if vi worked in any of the windows, but I > doubt it, since the program used pipes and Guy already talked about the > problems that would occur. We've got wm running on our 4.3 Vax, and before that, under 4.2; it doesn't get much use, partly because not many people know about it, partly becuase you just don't have enough real estate on a 24 x 80 screen to make windows practical, and partly because our Suns do a much better job. There's no denying, however, that it's handy for those times when you're stuck with with an ASCII crt. I just fired up a wm and sure enough, vi works fine. Emacs won't run but that's only because emacs uses terminfo and I havn't bothered to convert the supplied wmvirt termcap entry to terminfo. 4.3 comes with "window" which does pretty much the same thing as wm. If anybody wants the wm source, I can send you a copy (it was in mod.sources in August, 1985). The uncompressed distribution kit is 6 files totaling just under 200 kbytes. The version I have is advertised as being "horribly 4.2 dependent", but apparantly early versions (with pipes instead of ptys) ran under v6. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
mberkley@watmath.UUCP (06/10/87)
In article <3680021@nucsrl.UUCP> naim@nucsrl.UUCP (Naim Abdullah) writes: >I remember using a program called "wm" on a 4.1bsd system, that >allowed you to create multiple windows via the cursor keys and >run programs in each one. I don't remember if vi worked in any >of the windows, but I doubt it, since the program used pipes >and Guy already talked about the problems that would occur. vi certainly does work inside of the "wm" that's on our systems here. If all you've got is a dumb ascii terminal, then "wm" is the program for you. It's awfully nice to be able to start up a compile or something and then switch to another window to read news while it's running. There are other ways of doing this (GNUemacs for one), but "wm" is one of the nicest. The version of "wm" that used pipes was the one for version 7. The Berkeley version has lots of nifty new features (most of which depend on Berkeley'isms). For example, each window has it's own TERMCAP environment variable, created by "wm" according to the size of the window. Mike Berkley, University of Waterloo ************************************************************************ *UUCP: {allegra,ihnp4,utcsri,utzoo}!watmath!watsup!mberkley * *Bitnet: mberkley@watdcs.BITNET * ************************************************************************
greg@xios.XIOS.UUCP (Greg Franks) (06/10/87)
In article <20550@sun.uucp> guy@gorodish.UUCP writes: >In the particular case of a PC, there may be tricks you can play with >multiple screens that won't work with windows. The programs running >in the "active" window can be given direct access to the screen, and >when switching screens you can just copy the entire screen image to a >holding buffer; you could just freeze programs running in inactive >windows, and thus not have to worry about multiplexing input or >output. PC's use memory mapped output for the console. To write to the screen, simply write to memory. The screen controller attends to the rest of the nonsense. To switch screens, simply point the screen controller at a new place in memory. No multiplexing, synchronization, or copying is needed. I think that implmenting something like this on a run-of-the-mill terminal may be a bit difficult (and a wee bit slow too). Microport does not freeze output going to a "virtual console". Thus, you can run a "tar cv..." on one virtual console while doing something else on another. In fact, one could think of the console proper as being four terminals in the package of one. And if you really wanted to get inspired, you could have multiple windows in each of the virtual consoles - yeah - that's the ticket! :-) -- Greg Franks (613) 725-5411 "Vermont ain't flat" {net-land}!utzoo!dciem!nrcaer!xios!greg (Other paths will undoubtably work too - your mileage will vary)
guy@gorodish.UUCP (06/10/87)
> Has anyone done anything like this with STREAMS-oriented tty drivers? > It seems to me that windows/multiple screens would be relatively > easy to implement by just PUSHing an appropriate module onto the > stream that controlled your physical terminal that kept track of > what was on your (physical) screen at all times, similar to curses. "Relatively easy"? "Similar to curses"? "curses" is a pretty big library, and even something just handling this would be pretty big. It would either have to implement a virtual terminal, and support *lots* of different kinds of physical terminals, or would have to keep track of the screen image by understanding how the physical terminal works, and would still have to support lots of different kinds of physical terminals. STREAMS modules live in the kernel, and I don't want something that big living in my kernel. (There are enough big things living there already.) Furthermore, it would also have to maintain a copy of the screen, which means even more big things in the kernel. Sorry, but putting this into a STREAMS module would be the wrong thing to do. Pseudo-ttys make much more sense, since most of the support can be moved into user mode. Under the right circumstances, a STREAMS-based tty driver could make it easier to do pseudo-ttys; a pseudo-tty might be something similar to a streams pipe, with any other modules pushed atop the "slave" side. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
rjk@mrstve.UUCP (06/19/87)
In article <20837@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: (earlier, I wrote) >> Has anyone done anything like this with STREAMS-oriented tty drivers? >> It seems to me that windows/multiple screens would be relatively >> easy to implement by just PUSHing an appropriate module onto the >> stream that controlled your physical terminal that kept track of >> what was on your (physical) screen at all times, similar to curses. > >"Relatively easy"? "Similar to curses"? "curses" is a pretty big >library, and even something just handling this would be pretty big. >It would either have to implement a virtual terminal, and support >*lots* of different kinds of physical terminals, or would have to >keep track of the screen image by understanding how the physical >terminal works, and would still have to support lots of different >kinds of physical terminals. [...] > Guy Harris > {ihnp4, decvax, seismo, decwrl, ...}!sun!guy > guy@sun.com I didn't mean to emulate the entire curses library -- I just want to keep track of what is on 1 or more virtual screens (via an array/structure indicating size/location/etc). On receipt of (say) a certain escape sequence, the appropriate module of the terminal driver would redraw the physical screen so it looked like the requested virtual screen. The terminal driver shouldn't have to care about the *type* of the terminal at all -- it just passes whatever terminal control sequences it receives right on thru (thru to the structure (a queue, maybe), anyhow, which would later, when requested, just dump to the terminal). ...so I don't always explain myself very well... ...I knew what I meant... -- !pur-ee!pur-phy!mrstve!rjk Rich Kuhns {ihnp4, decvax, etc...} !itivax!mrstve!rjk
chris@mimsy.UUCP (06/19/87)
>In article <3680021@nucsrl.UUCP> naim@nucsrl.UUCP (Naim Abdullah) writes: >>I remember using a program called "wm" on a 4.1bsd system.... >>I don't remember if vi worked in any of the windows, but I doubt it.... In article <13537@watmath.UUCP> mberkley@watmath.UUCP writes: >vi certainly does work inside of the "wm" that's on our systems here. But you are not running 4.1BSD. Your `wm' uses pseudo terminals, which of course look like terminals to vi. (4.1BSD actually had pty code, but it did not quite work. I recall installing a fix from, I think, CMU.) Once again, vi misbehaves rather horridly when it is writing to a pipe (in 4.1BSD and 4.3BSD, at least). Try `vi | tee /dev/null', and see if it says `Missing lhs' for you too. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
guy%gorodish@Sun.COM (Guy Harris) (06/20/87)
> I didn't mean to emulate the entire curses library Please reread what I said. I never said you had to emulate the entire curses library, just that you'd have to do enough of the same thing that you're talking about putting LOTS of stuff into the kernel. > -- I just want to keep track of what is on 1 or more virtual screens (via > an array/structure indicating size/location/etc). On receipt of (say) a > certain escape sequence, the appropriate module of the terminal driver > would redraw the physical screen so it looked like the requested virtual > screen. OK, so how is it going to "keep track" of what's on the screen? It can't just blindly remember everything sent to the screen, unless it remembers everything you sent since you first started talking to that terminal, or until you last sent the terminal something that *this module* recognized as somehow resetting the state of the terminal. Frankly, the notion of redrawing the screen by retransmitting everything sent to it since the screen was last cleared doesn't appeal to me somehow; the fact that it's generally transmitted at no better than 19.2KB, and could thus take a LONG time to redraw, may have something to do with it. (We won't even discuss the memory required to hold this information.) > The terminal driver shouldn't have to care about the *type* of the > terminal at all -- it just passes whatever terminal control sequences > it receives right on thru (thru to the structure (a queue, maybe), anyhow, > which would later, when requested, just dump to the terminal). See above. Without large amounts of memory on the machine, and large amounts of patience on the part of the user, this isn't going to work very well at all. You can do this sort of thing on PCs because their displays tend to be memory-mapped, and the kernel could just stash the entire screen image away somewhere and restore another one from its stored copy; this takes a bounded amount of memory. Doing this on arbitrary terminals just won't fly. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
allbery@ncoast.UUCP (06/21/87)
As quoted from <699@mrstve.UUCP> by rjk@mrstve.UUCP (Richard Kuhns): +--------------- | I didn't mean to emulate the entire curses library -- I just want to | keep track of what is on 1 or more virtual screens (via an array/structure | indicating size/location/etc). On receipt of (say) a certain escape | sequence, the appropriate module of the terminal driver would redraw | the physical screen so it looked like the requested virtual screen. | | The terminal driver shouldn't have to care about the *type* of the | terminal at all -- it just passes whatever terminal control sequences | it receives right on thru (thru to the structure (a queue, maybe), anyhow, | which would later, when requested, just dump to the terminal). +--------------- Ah, but it does! How is the protocol module to know that ESC [ is a lead-in for an escape sequence on ANSI terminals and "position cursor to row" (may be column?) on Wyse 50's? It'll get the current cursor position wrong if it treats ESC [1;1H as "home" when the Wyse 50 moves to line 18 and prints ";1H". -- Copyright (C) 1987 Brandon S. Allbery. Redistribution permitted only if the redistributor permits further redistribution. (Stargate take heed!) ---- Moderator for comp.sources.misc and comp.binaries.ibm.pc ---- Brandon S. Allbery {decvax,cbosgd}!cwruecmp!ncoast!allbery aXcess Company {ames,mit-eddie,talcott}!necntc!ncoast!allbery 6615 Center St. #A1-105 necntc!ncoast!allbery@harvard.HARVARD.EDU Mentor, OH 44060-4101 +01 216 974 9210 (also eddie.MIT.EDU)
wagner@iaoobelix.UUCP (06/22/87)
Some time ago (I don't remember the date exactly) Oliver Laumann (TU Berlin,
West Germany) posted a program called `screen'. I think, it does exactly what
we have been talking about so long: You don't get multiple windows but
multiple screens you can switch between. `screen' uses `libtermcap.a'.
The email address of Oliver Laumann is seismo!unido!tub!net (which seems to be
a collective account).
Juergen Wagner, (USENET) ...seismo!unido!iaoobel!wagner
("Gandalf") Fraunhofer Institute IAO, Stuttgartchris@mimsy.UUCP (Chris Torek) (06/23/87)
>As quoted from <699@mrstve.UUCP> by rjk@mrstve.UUCP (Richard Kuhns): >+--------------- >| I didn't mean to emulate the entire curses library -- I just want to >| keep track of what is on 1 or more virtual screens.... >+--------------- In article <2690@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes: >Ah, but it does! How is the protocol module to know that ESC [ is a lead-in >for an escape sequence on ANSI terminals and "position cursor to row" (may >be column?) on Wyse 50's? I am not sure I should be feeding this discussion, but I would point out that this is not necessary. Any screen management system, whether user or kernel based, can provide a virtual terminal with a private termcap to each separate screen or window. The protocol module could interpret ANSI sequences, while the ultimate screen refersh is done with Wyse sequences. (The Maryland Window System, which was all user code, worked this way.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
net@tub.UUCP (06/23/87)
> Some time ago (I don't remember the date exactly) Oliver Laumann (TU Berlin, > West Germany) posted a program called `screen'. I think, it does exactly what > we have been talking about so long: You don't get multiple windows but > multiple screens you can switch between. `screen' uses `libtermcap.a'. I have published "screen" in net.sources about three months ago. I'm going to publish a new (better, faster, etc.) release in the now moderated comp.sources.unix as soon as 1) I get the impression that this newsgroup is really alive again (we have received only very few articles since comp.sources.unix has been reactivated); and 2) I have figured out how to send mail to "sources@uunet.uu.net" from Germany. > The email address of Oliver Laumann is seismo!unido!tub!net (which seems to be > a collective account). Please avoid sending mail to me over seismo, this costs us about $1 per KByte; use the addresses listed in my signature instead. "net" is not a collective account; my account has always been "net" for certain, well, historical reasons... -- Oliver Laumann, Technical University of Berlin, Germany. ...!pyramid!tub!net or net@TUB.BITNET
joey@tessi.UUCP (Joe Pruett) (06/25/87)
Many people have been saying how hard it would be to make a program
present multiple sessions on one terminal line and be able to
repaint the screen when switching back and forth... Well, such
a program exists. The version I've seen is called screen and it
works with termcap. It presents a VT100 like command set and then
maps that to whatever your terminal really needs (including doing
intelligent insert/delete stuff). You type ^A^C to create a new
screen and ^A<space> to cycle through the screens. Other ^A pairs
do other things. It works with vi and rogue and other such programs.
I'll try to find the sources and author and see about posting it
to comp.sources.{appropriate}.
Joe Pruett
Test Systems Strategies
...!tektronix!tessi!joey