Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1a 12/4/83; site rlgvax.UUCP
Path: utzoo!watmath!clyde!floyd!harpo!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix-wizards,net.bugs
Subject: Re: Terminal output: parity, 7 vs. 8 bits, etc.
Message-ID: <1830@rlgvax.UUCP>
Date: Wed, 28-Mar-84 00:45:11 EST
Article-I.D.: rlgvax.1830
Posted: Wed Mar 28 00:45:11 1984
Date-Received: Thu, 29-Mar-84 05:01:30 EST
References: <1484@vax4.fluke.UUCP>, <1142@cbosgd.UUCP> <247@basser.SUN>
Organization: CCI Office Systems Group, Reston, VA
Lines: 72

> Dichotomy?  You seem to forget about Ritchie's System 3 (now
> in system 5) terminal driver.  It's beautiful!

I agree that it's extremely elegant (as does at least one of the major
architects of 4.xBSD) - was it also Dennis'?

> Berkeley can keep that revolting (~30k) mess that the call a
> terminal driver.  I can't recall one of it's "features" being
> "wonderful".  I shouldn't need to set ~12 options to get my
> terminal in a useable state.

A lot of it is overkill, but I've gotten used to its handling of control
characters (echoing them as ^x, although I wouldn't insist on more than
echoing the "special characters" - kill, interrupt, etc. as ^x) and its handling
of character erase (again, I wouldn't insist on its handling of line kill,
although it's kind of cute).

> Nor do I want that horrible job control stuff.  If you want virtual
> terminals then use a Blit.  What ever happened to
> invisibility?  Why do *so* many programs have to be modified
> to understand about this layer that should have been
> invisible to them.  But I suppose Berkeley again can justify
> that it's ok to break everything in the name of progress.

Blits cost money.  Somebody may need features a Blit doesn't have.  Job
control isn't an attempt at virtual terminals - but then, neither is the
S5R2 job control.  In order to support virtual terminals without a terminal
(such as the Blit or Convergent's PT) designed to support virtual
terminals you either have to go through a lot of contortions or you have
to have the *program* know that it's dealing with virtual terminals.  And
the only programs that *need* to know about job control are those that
control the full screen (with the S5R2 "virtual terminal" facility, you
have to tell the program to repaint its screen when you switch your terminal
to it - i.e., you gotta give a ^L to "vi"), those that put the terminal
in a non-standard state (i.e., a program which puts a VT100 with a
Retro-graphics type graphics board into Tek 4014 emulation mode), or those
that want to reprint a prompt when they're restarted (like Mail).  "cat",
"ls", "ed", and the like don't have to know *anything* about job control -
they invisibly get suspended and resumed.  "vi" has to get told about it,
but the alternative is something like the S5R2 job control, where when you
"invisibly" hand control to "vi" (or any other full-screen program) you
have to very visibly type a command at it to repaint the screen.

> What happened to "fcntl", why are there ~28 "ioctls"?

Because "fcntl" is supposed to manipulate file descriptors and "ioctl" is
supposed to manipulate devices.  I agree that "close on exec" belongs as
an "fcntl" function (S3/S5 style) rather than an "ioctl" (V7 style - can't
"blame" that one on Berkeley), but the reason the Berkeley TTY driver
has so many "ioctl"s is that it's an add-on to the V7 driver which, in
turn, was somewhat of an add-on to the V6 driver.  As such, you had the
original "stty/gtty" layer (3 "ioctl"s - two sets, one which flushes
and one which doesn't), the special characters (V7 add-on), the exclusive-
use mode (which, I agree, should have been handled as a (file-)descriptor
function - and is, in 4.2BSD - rather than an "ioctl" function; 2 "ioctl"s),
the "hang up on close" function (one "ioctl" - this was probably done because
when they went to V7 they ran out of bits in the "sg_flags" word), and the
"flush output" function (one "ioctl").  Then, with the Berkeley system,
you add on some more - more than I think were *really* necessary, but
if you're adding on more flag bits and control characters you either have
to tack them on the side, which V7 already did, or throw out the old "set
modes" function and come up with a new one, which Berkeley did.  However,
there might have been some legal problems with adopting the USG "ioctl"s
(BTW, the S3 manual isn't "public domain" as it's Copyright 1980 BTL, but
they did make it available to people without source licenses).

Count your blessings - at least 4.xBSD (and 2.xBSD) *have* "ioctl"s for
the mag tape.  We had to hack our own in at Harvard College Observatory -
I would much rather have had them a standard part of UNIX at that time.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy