The Art of Unix Programming [TAOUP] - Job Control -> screen

Eric S. Raymond's book "The Art of Unix Programming [TAOUP]"
also mentions "screen" in the chapter about "Job Control".

"the kernel-level code that overlaps with
 it in function has not been removed."

so - are we in for a serious update to screen?

Sven

===

http://catb.org/~esr/writings/taoup/html/ch20s03.html#id3015943

  Chapter 20. Futures
  Problems in the Design of Unix

The Design of Job Control Was Badly Botched

Apart from the ability to suspend processes (in itself a trivial
addition to the scheduler which could be made fairly inoffensive)
what job control is about is switching a terminal among multiple
processes.  Unfortunately, it does the easiest part - deciding
where keystrokes go - and punts all the hard parts, like saving
and restoring the state of the screen, to the application.

A really good implementation of such a facility would be completely
invisible to user processes: no dedicated signals, no need to save
and restore terminal modes, no need for the applications to redraw
the screen at random times.  The model ought to be a virtual
keyboard that is sometimes connected to the real one (and blocks you
if you ask for input when it isn't connected) and a virtual screen
which is sometimes visible on the real one (and might or might
not block on output when it's not), with the system doing the
multiplexing in the same way it multiplexes access to the disk, the
processor, etc... and no impact on user programs at all. [footnote]

Doing it right would have required the Unix tty driver to track the
entire current screen state rather than just maintaining a line
buffer, and to know about terminal types at kernel level (possibly
with help from a daemon process) so it could do restores properly
when a suspended process is foregrounded again. A consequence of
doing it wrong is that the Unix kernel can't detach a session,
such as an xterm or Emacs job, from one terminal and re-attach
it to another (which could be of a different type).

As Unix usage has shifted to X displays and terminal emulators, job
control has become relatively less important, and this issue does
not have quite the force it once did. It is still annoying that
there is no suspend/attach/detach, however; this feature could be
useful for saving the state of terminal sessions between logins.

A common open-source program called screen(1) solves several of
these problems.  [footnote] However, since it has to be called
explicitly by the user, its facilities are not guaranteed to be
present in every terminal session; also, the kernel-level code
that overlaps with it in function has not been removed.
===

 

Yahoo! Groups Links

To visit your group on the web, go to:
 http://groups.yahoo.com/group/gnu-screen/

To unsubscribe from this group, send an email to:
 [email protected]

Your use of Yahoo! Groups is subject to:
 http://docs.yahoo.com/info/terms/