Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!hao!hplabs!sdcrdcf!sdcsvax!akgua!mcnc!decvax!cca!ima!haddock!dan
From: dan@haddock.UUCP
Newsgroups: net.unix
Subject: Re: Re: cat -v considered harmful
Message-ID: <209@haddock.UUCP>
Date: Tue, 10-Jul-84 23:46:14 EDT
Article-I.D.: haddock.209
Posted: Tue Jul 10 23:46:14 1984
Date-Received: Tue, 17-Jul-84 05:46:11 EDT
Lines: 37
Nf-ID: #R:watdcsu:-29800:haddock:16700027:000:2248
Nf-From: haddock!dan    Jul  9 21:14:00 1984

While Rob Pike's USENIX talk ("cat -v considered harmful") was very good,
I felt that Rob let Bell Labs off too easily.
For example, he (justifiably) excoriated cat -v, but not Bell's cat -u,
because "cat's job is moving data around, so an option to control buffering
is alright".  But cat -u is just the tip of the iceberg that floated into
UNIX waters when stdio was introduced.	Originally, UNIX pipes were
interactive; you could couple several programs together, type a line of
input, and see a line of output.  But not any more!  Now output to a pipe
is automatically buffered, so a hack like

    m4 adb-macros | adb | tee script

just doesn't work.  So how is this problem fixed?  By changing stdio to
support interactive pipes?  Not at all--instead, each time somebody thinks
of a reason for a program to be in an interactive pipe, that program grows
a flag to "unbuffer" its output.  Since
it's done ad-hoc, the flag is different for each program: cat -u, m4 -e,
and for grep, sed, etc.--you just lose, until V.3 adds grep -X, sed -Y, etc.
Stdio ought to flush all output buffers before reading a tty or pipe.

Rob also (again justifiably) complained about "more".  But whose fault is
it that "more" exists, anyway?	It was at Bell Labs that the design decision
was made to have two kinds of streams--pipes and ttys.	The obvious thing
to do when CRT terminals first came out was to insert a pipe between the
shell and your terminal to do paging.  Too bad it doesn't work:
pipes can't pass ioctls (so screen editors can't go into raw mode,
and get an error instead), pipes don't "look" like terminals (so stdio
buffers), they're not bidirectional, etc.  If pipes had been more like
tty streams, "more" would never have existed--and the kernel terminal driver
(4.2 or System V, take your choice) would not have grown into the monstrosity
it is today.  Berkeley just continued the UNIX tradition; at the same time
that a very wise person was saying "the kernel should just be an 
I/O multiplexer", the kernel tty driver was capable of expanding tabs,
performing line editing, and other things that violated that rule.

I like UNIX very much, and I have a lot of respect for the people who
invented it.  But we should not be blind to its flaws.