Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: std-unix@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-ID: <5965@ut-sally.UUCP>
Date: Thu, 9-Oct-86 12:25:20 EDT
Article-I.D.: ut-sally.5965
Posted: Thu Oct  9 12:25:20 1986
Date-Received: Fri, 10-Oct-86 00:49:46 EDT
References: <5932@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 58
Keywords: POSIX Appendix C
Approved: jsq@sally.utexas.edu

From: cbosgd!cbosgd.ATT.COM!mark@seismo.css.gov (Mark Horton)
Date: Thu, 9 Oct 86 01:30:59 edt
Organization: AT&T Bell Laboratories, Columbus

I've made significant use of four different sorts of systems
for multiplexing, so hopefully I can provide some feedback on
their relative merits, from a user's point of view.

(1) True windows, such as a 5620, Sun, UNIX PC, etc.  Each window
acts like a terminal.  This is unquestionably the best, but it
requires special hardware, and is an area that needs to be
standardized.

(2) A dumb-terminal window manager as Henry describes.  I've written
such a window manager; on a system that has ptys, select, and a smart
curses package, it's easy (my code is only 700 lines.)  It runs on both
4.2BSD and System V, provided that all three ingredients are present.
This package runs about as well as you could hope for, (the buffering
and ioctl problems Henry mentions are solved using ptys, and it doesn't
eat up much CPU time, and all my windows are the full 80 cols wide)
and I have a 60 line terminal so there's really room for two or three
windows.  I use this rarely, because I dont' like the "mushy" feeling I
get from the screen management layer.

(3) Berkeley job control.  Henry may think this is ugly, but from a user's
point of view, if you can't have a real bitmapped display, this is the
next best thing.  I strongly prefer it to (2).

(4) System V shell layers.  I don't use this very often, it's just not
very powerful and awfully inconvenient.  It can't pop you out from any
program that runs in raw mode, such as cu or rlogin, because there's
no way for a program to suspend itself.  rlogin really NEEDS to suspend
output in a non-window environment, otherwise your screen will be a mess.

I should mention that my major use of multiplexing is to switch between
rlogins to various other systems on our LAN, and a few local applications
such as vi, mail, and news.  For situations where I really need two windows
(e.g. developing a network client and server) I strongly prefer to do it
on a true window system.  It is possible that others, running other mixes
of applications, will feel differently.

My recommendation is, however, similar to Henry's, for the standard.
I don't think the dumb terminal window manager is the answer, but I
think it's clear we don't have the best answer yet, in general.  I do
think that certain things should be standardized:

(a) termio, or at least the subset that's commonly used.  You could always
    put in a few high level subroutines like the cbreak/nocbreak echo/noecho
    erasechar/killchar/baudrate routines in curses, just to provide a
    portable interface.
(b) an ioctl to find out the current window size, in chars and pixels.
(c) a pty-like mechanism.  (Streams may be a viable candidate here, or
    Illinois/Berkeley ptys might be expedient.)
(d) a software-multiplexing mechanism, like select.

	Mark

Volume-Number: Volume 7, Number 40