Eighth Edition and job control (was Re: UNIX Futures)

Chris Maio chris at columbia.UUCP
Sat Apr 5 09:30:48 AEST 1986


In article <559 at basser.oz> john at basser.oz (John Mackin) writes:

>Now that I've got that out of the way, let's go on to discuss
>so-called job control.  The whole point about Berkeley job control
>is, it is a massive hack.  Witness the huge number of user-mode
>programs that had to be modified to know about SIGTSTP, etc.
>Not to mention the far-reaching kernel modifications.  I think
>we can agree that a window system *in which the user program
>need have no idea that it is running in a window* is much better.
>
>You say as much, but then you say you still want to be able to
>stop and restart processes.  On V8, that is as easy as opening
>the process' /proc entry and doing a single ioctl().  No harder
>than doing a kill().  For the purposes you say you use the
>facility, having it generated from a character typed on the
>controlling terminal (^Z) is pretty pointless.  So there's
>no clear advantage there.

Without a window system or a second terminal, how do you suspend
foreground processes?  How much extra work is involved in suspending an
entire process group?  And if there's no point in having a special
character to suspend a process, why have one to kill a process?  (Or
to generate a core dump?  Now *that* is strange.)

In the TOPS-20 operating system, there is a special character to suspend
a process group, but none to kill a process group -- TOPS-20 gives you
roughly the same process manipulation capability as Berkeley job control
with only a single interrupt character.  Imagine that.

The "huge number of programs that have to be modified to recognize
SIGTSTP" is a poor argument, in my opinion.  Sure, the shells and stty
have to know about it, but (and correct me if I'm wrong) any other
program modified to know about it has only been modified to make it more
user-friendly (e.g. redrawing a curses screen), not because it was
absolutely necessary.  And surely this is no less work than modifying
the same programs to know about window resizing under a window system
(ideally they shouldn't have to, but you know that they will).

There are other arguments that have been stated before.  The bottom line
for me is that regular users appreciate berkeley-style job control
semantics and are loathe to give them up once they've used them, and
windowing displays are always going to be more expensive than "dumb"
terminals.

Providing a flexible process control mechanism for the ordinary user
seems to me a lot more important than providing fancy window systems;
what do window systems have to do with UNIX anyway?



More information about the Comp.unix.wizards mailing list