Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!hao!oddjob!gargoyle!ihnp4!inuxc!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!uicsrd!kai From: kai@uicsrd.csrd.uiuc.edu Newsgroups: comp.unix.questions Subject: Re: "screen" vs. "wm" Message-ID: <45000012@uicsrd> Date: Mon, 31-Aug-87 22:07:00 EDT Article-I.D.: uicsrd.45000012 Posted: Mon Aug 31 22:07:00 1987 Date-Received: Sat, 5-Sep-87 06:27:49 EDT References: <16048@teknowledge-vaxc.ARPA> Lines: 92 Nf-ID: #R:teknowledge-vaxc.ARPA:16048:uicsrd:45000012:000:5156 Nf-From: uicsrd.csrd.uiuc.edu!kai Aug 31 21:07:00 1987 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 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)