Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!princeton!allegra!mit-eddie!genrad!panda!teddy!jpn
From: jpn@teddy.UUCP
Newsgroups: comp.unix.questions
Subject: Re: BSD & Sys5 Job Control
Message-ID: <3702@teddy.UUCP>
Date: Fri, 23-Jan-87 18:21:46 EST
Article-I.D.: teddy.3702
Posted: Fri Jan 23 18:21:46 1987
Date-Received: Sat, 24-Jan-87 16:16:07 EST
References: <1324@cadovax.UUCP> <161@piaget.UUCP> <114@dolphy.UUCP>
Reply-To: jpn@teddy.UUCP (John P. Nelson)
Organization: GenRad, Inc., Concord, Mass.
Lines: 27

In article <114@dolphy.UUCP> jmg@dolphy.UUCP (Jeffrey Greenberg) writes:
>In BSD, processes must be coded to properly handle job control. In sys5,
>whoever manipulates the terminal driver, is in control.

Wait just a second!!!  "simple" BSD tasks do NOT need to be recoded to
be manipulated with job control (i.e they can be stopped and started just
fine, thank you), but tasks have the CAPABILITY to catch signals which
indicate a job state change.  In other words, if you don't recode any
BSD tasks (except the shell, perhaps), it works just like "shl".  On the
other hand, editors can fix the tty mode and redraw the screen if they
want to.

Shl has two major flaws, in my opinion:

    1.  You must set it up in advance (i.e the normal shell can't take
	advantage of it).

    2.  Tasks have no notification of state changes.  Perhaps if the Shl layer
	also did screen maintainance (restoration), this would be OK, but
	raw shl is happy to let the screen get botched.  As far as I can
	tell, it is not POSSIBLE to write a "shl" that fixes the screen.
	Well, maybe with special tty drivers and such.


Both shl and "job control" are unnecessary if you have a true windowing
system.  Both are HACKS to provide capabilities close to window systems
using dumb terminals.