mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) (08/26/87)
I'd appreciate any comments from anyone who has used both the "screen"
program recently posted to comp.sources.whatever and the "wm" program
of an earlier vintage, comparing/contrasting the two.
Thanks,
Mike Khaw
--
internet: mkhaw@teknowledge-vaxc.arpa
usenet: {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa
USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303net@tub.UUCP (08/28/87)
> I'd appreciate any comments from anyone who has used both the "screen" > program recently posted to comp.sources.whatever and the "wm" program > of an earlier vintage, comparing/contrasting the two. I use neither "screen" nor "wm", but as the author of "screen" I think I'm in a position to comment on this. Both window managers manage a set of virtual UNIX terminals that have a set of processes connected to it (usually -- but not necessarily -- interactive login shells) and map this set to a single real (or virtual) terminal. While window managers like "wm" split the screen into multiple windows (vertically), "screen" manages a set of independent equally-sized "logical screens". In contrast to "wm", where all windows are visible at each point of time, "screen" always displays exactly one logical screen. You can switch to a different screen by means of a sequence of control characters; for instance, Ctl-A Ctl-A activates the screen that has been displayed previously. Processes connected to a logical screen that is currently not displayed do not get blocked or stopped. You can arrange that each time a bell is output to a background screen, a notification is displayed in the status line of the currently displayed screen; this can be used to indicate that a "make" or something has terminated in a currently not visible screen and to draw one's attention to a background screen when someone directed a talk(1) or write(1) to that screen. I personally don't think that it makes much sense to divide an ordinary 24x80 screen into even smaller areas. If you *do* need this functionality together with the function offered by "screen", you can run a "wm"-like window manager (or an Emacs) under "screen" (you can even have a separate window manager in each logical screen, if you like). Another big problem with "wm"-like window managers is that they require a terminal with scrolling regions or insert/delete line, otherwise the only way for a window to scroll it's contents up is to redraw the entire window. Even with the aid of scrolling regions or insert/delete line, displaying a long text (e.g. "cat /etc/termcap") is unacceptably slow (at least with the window managers I have seen so far). -- Oliver Laumann, Technical University of Berlin, Germany. ...!pyramid!tub!net or net@TUB.BITNET
randy@umn-cs.UUCP (08/31/87)
In article <50000002@tub.UUCP> net@tub.UUCP writes: >> I'd appreciate any comments from anyone who has used both the "screen" >> program recently posted to comp.sources.whatever and the "wm" program >> of an earlier vintage, comparing/contrasting the two. > >I use neither "screen" nor "wm", but as the author of "screen" I think I'm >in a position to comment on this. > >Both window managers manage a set of virtual UNIX terminals that have a set >of processes connected to it (usually -- but not necessarily -- interactive >login shells) and map this set to a single real (or virtual) terminal. >While window managers like "wm" split the screen into multiple windows >(vertically), "screen" manages a set of independent equally-sized "logical >screens". > (goes on to characterize "wm") This is WRONG. I have been using wm for quite a while now. It does give you the ability to split your screen up into windows, vertically and horizontally, but all are not necessarily displayed at the same time. Windows can overlap, in whole or in part. In fact, the way that I usually used wm was with 3 or 4 full-screen sized windows, in which case it functioned exactly like screen. However, wm would also allow me to have two windows on the screen at the same time, for example an error list and an editor. Your terminal doesn't need to be able to define scrolling regions, insert- and delete-line is plenty. WM is a very nice package, more flexible than screen. Neither one is useful at low baud rates, though since it takes too long to re-draw the screen. Another added feature of wm is that a command will send a string to whatever is running in a window, of the form "setenv TERM xxx<nl>setenv TERMCAP 'xxx'" so that if you're telneted to another machine, you can let it know what your terminal looks like. -randy -- Randy Orrison, University of Minnesota School of Mathematics UUCP: {ihnp4, seismo!rutgers!umnd-cs, sun}!umn-cs!randy ARPA: randy@ux.acss.umn.edu (Yes, these are three BITNET: randy@umnacvx different machines)
kai@uicsrd.csrd.uiuc.edu (09/01/87)
Screen blows wm away for features and ease of use. I have tried a number of
virtual window programs including "window", "wm", "wms", and "screen", and
screen is the only one that remains on our systems.
Screen is 4.2 BSD dependant (it uses UNIX sockets), and compiled the first
time on both our Sequent Balance 8000 (as I expected) and our Alliant FX/8 (a
rarity).
It only handles full screen windows, but in doing so, eliminates the awful
speed problems some others have. This also avoid the weird situation that both
"window" and "wm" caused when resizing a window near the right edge of my
VT220 compatible terminal. Just before the right edge of the window moved off
the terminal screen, the terminal was "reset". It was as if I pressed
control-reset on my keyboard, or turned the terminal off and back on.
Screen is also the only package (so far) that re-draws the window correctly.
All of the others end up leaving something on the screen that you don't want,
requiring you to request your pgm to redraw the screen.
Screen is also the only package that handles window logins correctly (as far
as I know). Screen creates an entry in /etc/utmp for each window. This solved
the problem all the other packages had with any program that wanted your login
id (like talk, shutdown, su). Talk under wm generates a message at the
receivers terminal something like "respond by typing 'talk @myhost'" (a null
login id). Even if the person DID know who wanted to talk, the talk daemon
didn't, and would ask you to "respond by typing 'talk yourid@yourhost'",
which of course is how you started.
Of course the disadvantage to this is that each window counts against your
user limit if you have a limited UNIX license, making it possible for a single
user to create 11 login sessions (one original session, and ten "screens"). On
a system with a 16-user license, this has to be kept in mind.
Along this line, just today I sent the diffs to the author that allows screen
to check the current user count against the maximum limit that our UNIX
license allows, to make sure the limit isn't exceeded. While you might think
it handy to be able to exceed this limit, our Sequent panicked with "illegal
number of users" when we had 18 screen windows between two users (a 16 user
license). The fix simply makes sure you don't exceed your limit so the system
stays up.
Screen also doesn't handle VT100 line graphics or double high/wide characters,
but this is not a problems for us. The other window managers are probably more
terminal independant, screen emulates a vt100 terminal with some ANSI
extentions. I haven't the slightest idea about how any of the window managers
perform on non-VT compatible terminals.
To create a new "window" in screen, you type "^ac". In wm, you must type all
kinds of characters to size the new window. Of course wm will remember your
window sizes between invocations, but screen gets by that by only having one
size. Actually I would love to have a "split" screen once in a while (for
reading the C compiler error messages while editing the source), but I don't
mind typing ^A^A to swap back and forth between two windows.
What I have done is program most of the function keys of my Televideo TVS9220
to perform the most often used screen functions (create a window, display the
list of windows, move back and forth between two windows, move forward or
backward along the list of windows, create a window to rlogin to our other
host, create a window that runs the monitor pgm, etc). This means only one
keystroke to perform most screen functions (instead of two).
Screen also allows you to create a new window from the command like. I have
created an SU script that checks if I am running screen (by checking for the
STY environment variable), does an "exec screen /bin/su" if I am, and an "exec
/bin/su" if not. All kinds of possibilities exist.
Anyone who has never tried an virtual window manager should. They really do
make using UNIX much easier. Being a system administrator for three systems,
I am always being interrupted with "can you take a look at ...". Screen lets
me pause, create a new screen, handle the simple user problem (hopefully), and
return to EXACTLY where I was before. Same command history, same display on
the window, same half of a command typed in as when I left.
The software is VERY stable. Not a coredump or bug (other than the userlimit
problem mentioned above) found in approximately eight months constant use.
To summarize, I highly recommend the SCREEN program, especially if you have
ever used any of the other packages and have been annoyed by their
deficiencies.
#include <local/standard_disclaimer.h>
Patrick Wolfe Internet: pat@kai.com
System Manager UUCP: {seismo,ihnp4,uiucuxc}!kai.com!pat
Kuck & Associates, Inc. Arpanet: pat%kailand@uxc.cso.uiuc.edu
1808 Woodfield Dr. Bitnet: pat%kailand@uiucuxc
Savoy, IL USA 61874 CSnet: pat%kailand%uxc@uiuc.csnet
Phone: 217-356-2288 Milnet: pat%kailand@uiucuxc.arpa
Easylink: 6201 1628 Telex: 910 240 9772 (KUCK ASSOC)blair@ncrwic.UUCP (09/01/87)
In article <50000002@tub.UUCP> net@tub.UUCP writes: >I use neither "screen" nor "wm", but as the author of "screen" I think I'm >in a position to comment on this. > [ ... much glowing praise of "screen" ... ] If it's so spectacular, why don't you use it? :-) -- ___________________________________________________________________________ Brian R. Lair NCR Corporation, E&M Wichita, Product Technology Development <brian.lair@Wichita.NCR.COM> <{ece-csc,hubcap,gould,rtech}!ncrcae!ncrwic!brian.lair>
jte@psuvax1.psu.edu (Jon Eckhardt) (09/02/87)
What abouut BSD window? It is a lot better then wm, although I use screen because I feel that a normal terminal windowing package should be invisable, (You don't know your in it unless you want to know about it) and it is quite fast. If you are in BSD window or wm and you type clear you can actuly see it write over the other chars on the screen and then home. Screen on the other hand clears the screen in a snap. The only thing I don't like about screen is that it should emulate a vt220 or something more advanced then a vt100. --Jon
gwyn@brl-smoke.ARPA (Doug Gwyn ) (09/04/87)
In article <45000012@uicsrd> kai@uicsrd.csrd.uiuc.edu writes: >Screen is also the only package that handles window logins correctly (as far >as I know). Screen creates an entry in /etc/utmp for each window. This solved >the problem all the other packages had with any program that wanted your login >id (like talk, shutdown, su). The problem is not with other utmp-manipulating software such as "wm" or "layers", but with software such as "talk" that does not follow the procedure spelled out in the programmer's manual for determining the user name. Some applications simply can't permit "talk" etc. to certain windows (e.g. those running special communication protocols to terminal-resident processes), and they therefore make sure the coresponding utmp entry is voided. This is perfectly reasonable and should not cause problems if software follows the rules. This was discussed in comp.unix.wizards something like a year ago.
len@array.UUCP (Leonard Vanek) (09/04/87)
In article <16048@teknowledge-vaxc.ARPA> mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) writes: >I'd appreciate any comments from anyone who has used both the "screen" >program recently posted to comp.sources.whatever and the "wm" program >of an earlier vintage, comparing/contrasting the two. > >Thanks, >Mike Khaw screen works beautifully! So far the only places it has failed are with a program that test the TERM shell variable before sending the appropriate string to convert a vt100 to 132 column mode and back and with file transmission using kermit in remote host mode. I tried to install wm a while back, but I did not succeed. I forget exactly what the reason was, but I seem to remember something about having to change some things in curses and not having the source to do so because I do not have a source license. By contrast, screen compiled without a hitch. I recommend screen. Len Vanek
len@array.UUCP (Leonard Vanek) (09/04/87)
In article <535@array.UUCP> len@array.UUCP (Leonard Vanek) writes: >In article <16048@teknowledge-vaxc.ARPA> mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) writes: >>I'd appreciate any comments from anyone who has used both the "screen" >>program recently posted to comp.sources.whatever and the "wm" program >>of an earlier vintage, comparing/contrasting the two. >> > >I recommend screen. I forgot to mention that I am using screen on a Sun 3 system. The documentation to wm mentions that there are versions of it that use pipes and run under AT&T systems. Screen only works on BSD systems. Len Len Vanek >
stpeters@dawn.steinmetz (09/08/87)
> While window managers like "wm" split the screen into multiple windows > (vertically), "screen" manages a set of independent equally-sized "logical > screens". > > In contrast to "wm", where all windows are visible at each point of time, > "screen" always displays exactly one logical screen. 'wm' *can* split your screen into multiple windows, but don't misread this capability as a requirement. In fact, displaying a single full- screen window, just as 'screen' does, is both the usual and the default mode of 'wm' usage. It takes just two keystrokes to switch to any other window, and contrary to one claim, it takes exactly four strokes to make a new (full-screen) window. > Screen is also the only package that handles window logins correctly (as far > as I know). Whether 'screen' or 'wm' handle logins "correctly" depends on whether you want such a program fiddling with /etc/utmp. Personally, I would choose not, so I consider 'wm' and not 'screen' to handle this correctly. This does cause 'getlogin()' to return an empty string, which is the cause the of problem with 'talk'. 'wm' comes with an alternative to 'getlogin()' that does work within wm, which you can use to make a working 'talk' if you have source. > "window" and "wm" caused when resizing a window near the right edge of my > VT220 compatible terminal. Just before the right edge of the window moved off > the terminal screen, the terminal was "reset". This is hardly an argument in favor of 'screen', which can't resize its windows at all! Anyway, it sounds like a termcap problem to me. In nearly two years of daily use of 'wm' with a VT220, I never encountered this reset problem. > Anyone who has never tried an virtual window manager should. Absolutely! I've used 'wm' on ULTRIX VAXen, Sun's (1's, 2's, and 3's), and an Alliant, and I highly recommend it. Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters