job control

[Moderator, John Quarterman]

From: cbosgd!cbosgd.ATT.COM!mark at seismo.css.gov (Mark Horton)
Date: Sun, 12 Oct 86 23:50:46 edt
Organization: AT&T Medical Information Systems, Columbus

The virtual screen stuff, such as UNIX or Xenix on a PC have, should be
considered a poor cousin of a true bitmapped window capability.  Aside
from losing the ability to watch two windows at once, they are essentially
the same.  Both are nice, neither is an alternative for anything except
a personal computer or workstation.

By the way, another possibility has been suggested: something like System
V's shell layers, but using scrolling regions in a vt100 or similar terminal
to lock the terminal into the appropriate window.  You lose the ability to
see async updates in another window, and you still need ptys and select,
but you don't need curses, and you shouldn't get the mushy feeling.
Something would have to be done about ^Z not working in raw mode, so you
could break out of an rlogin or cu or vi.  One way to do this would be
something like Berkeley's TIOCSTI, so the program can detect the situation
(using a multi-char escape sequence), take itself out of raw mode, and
type the ^Z itself.

(Henry's complaint about user programs having to be modified is a minor
one, in my opinion.  A program that isn't screen oriented needs no
modification.  A program that is screen oriented can use curses, and
curses can catch the signal and redraw the screen as needed.  The only
programs that need modification are those that have to be transparently
able to pass ^Z through, this mostly means remote login programs, and
they need this kind of capability without job control anyway.)

>From: guy at sun.com (Guy Harris)
>
>> (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 did not mean to imply that it should be standardized NOW, although I
think the field is starting to generate enough examples that it would be
worthwhile for someone to start looking at it.  We certainly aren't ready
to put it into P.1003 yet.

What I meant is that certain common elements should be standardized,
in particular, the ioctl to get and set the current window size.
These all look the same, but with different particulars.

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

The reason I mention pixels is that many of the existing ioctls seem to
bundle the pixel numbers and char numbers into the same ioctl.  Perhaps
it does make sense to separate them.

By the way, I think both "get" and "set" operations should be standardized,
and the standard should state that both ioctls must work on both sides of
the pty.  (This assumes we can appropriately specify what a "pty" is.)

The "get" operation can indeed be isolated into tgetnum (termcap) and
setupterm (terminfo.)  But lack of standardization means that the sources
to termcap and terminfo have to be cluttered up with umpteen different
ways to do the same thing.

The "set" operation is needed for window managers, and also so there can
be a shell command to set the window size when the system gets it wrong.
(The system gets it wrong a lot in practice, all you have to do is remote
login through a link that doesn't pass the window size, such as cu, telnet,
or 4.2's rlogin.  (4.3 passes the size.))  Sometimes windows get resized,
too, so it would be useful for the cu/rlogin program to be able to send a
shell command through when this happens.)

	Mark

Volume-Number: Volume 7, Number 55