job control

[Moderator, John Quarterman]

From: guy at sun.com (Guy Harris)
Date: Sat, 11 Oct 86 03:05:09 PDT

> (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.

At some point, perhaps.  It's unclear whether now is the time to do so.  I
don't think window systems have been around long enough that people can say
"this is how to do a window system".  I don't think window systems have
settled down enough to start standardizing yet.  (How many people would have
thought of using PostScript as a rendering language for a window system, and
extending it to handle input events as well and act as an extension
language, before James Gosling first talked about his work?  Would people
have missed that entirely when developing a standard?)

Also, what would the standard specify?  A C-language binding to routines to
manipulate the screen?  A set of low-level operations to render images
within a window, a high-level user interface toolkit, something in between,
all of the above, or none of the above?

> (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).

For what it's worth, I will point out that even though I have access to (1),
I still use (3).  I haven't analyzed my use of it enough to really say why.
Some of it may be that it takes a while to pop up a new shell window in my
environment (time to start the window process that provides the simulated
terminal and time to start up the Korn shell).  Some of it may be that the
EMACS key bindings I have let me suspend EMACS but not easily fork off a new
shell.  Some of it may be that it is occasionally convenient to move a job
into the background when you discover it'll take a while to complete, or
move a backgrounded job into the foreground to abort it.

> I do think that certain things should be standardized:

> (a) termio, or at least the subset that's commonly used.

The current proposal before 1003.1 does this; it fixes some botches in
"termio" as it exists (MIN and TIME are not overloaded with EOF and EOL, for
instance) and restores a couple of capabilities deleted when the System III
terminal driver first appeared.

> (b) an ioctl to find out the current window size, in chars and pixels.

The current proposal has this, but does not give the window size in pixels.
The "termio" interface is really not a good portable interface for doing
graphics, since most terminals can't do graphics.  As such, it's not clear
why the window size in pixels should be provided by this interface.  A
program that really cares how big the window is in pixels should probably
use the local window system primitives for this, since it has to use the
window system's rendering primitives to draw things anyway.

Volume-Number: Volume 7, Number 51