geo@watdcsu.UUCP (Geo Swan) (07/07/84)
In a recent article one Ron Natalie, an Arpanaut, comments on why cat should not have an option to list the names of the files it is printing. > From: Ron Natalie <ron@BRL-TGR.ARPA> > > Because "cat" is for transferring files to it's standard output > (see Rob Pike's "Cat -u considered harmful). Try "pr -t". Pr is > for pretty printing. I agree completely. I heard Pike deliver this talk at USENIX in Toronto last summer. Unfortunately, the proceeding do not contain a copy of the talk. Instead there is a short paragraph directing people to read Rob's soon to be published book. (ie "The UNIX Programming Environment", Kernighan and Pike) Does anyone know if this talk has been published elsewhere? UPE is a very good book, but it is not nearly as pointed in its criticisms as the USENIX talk.
dan@haddock.UUCP (07/11/84)
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.gwyn@BRL-VLD.ARPA (07/16/84)
From: Doug Gwyn (VLD/VMB) <gwyn@BRL-VLD.ARPA> Very good points. Does anyone know whether "stream I/O" (currently in 8th Edition UNIX and rumored to be slated for a future release of UNIX System V) helps solve these problems (lack of uniformity of different types of stream I/O)?