Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!decwrl!purdue!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.unix.wizards
Subject: Re: cat -u
Summary: cat files ... | cat -u | cat -s
Message-ID: <5077@bsu-cs.UUCP>
Date: 11 Dec 88 16:52:05 GMT
References: <175@ernie.NECAM.COM> <189@wyn386.UUCP> <8910@smoke.BRL.MIL> <8160@bloom-beacon.MIT.EDU> <146@minya.UUCP>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 36

In article <146@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
>What ever happened to the original Unix Philosophy of lots of little
>programs, each of which did exactly one job well, and which could be
>fitted together to do bigger jobs?

With the right point of view, this question becomes non-sequitorial.
From the user's point of view, where the code lies (i.e., whether it's
in separate programs called ex and vi, or in one program with two
links) is not relevant.  What matters is the way the user interface
looks.

Think of "cat", "cat -u", and "cat -s" as separate programs.
Then create a pipeline like this:

     cat files ... | cat -u | cat -s

Now go "AHA!" with the realization that both cat -u and cat -s will
accept multiple filenames, so cat alone isn't needed any more:

     cat -u files ... | cat -s

At this point the purist stops and is deliriously happy at using two
small, single-purpose utilities.  The pragmatist continues to optimize
by eliminating an extra process and an extra pipe and gets:

     cat -us files ...

Whether you need three single-purpose utilities, or a single
triple-purpose utility, the 4.3BSD cat delivers.

By the way, if you took the one-function-per-program philosophy too far,
you would have separate commands such as cc-g, cc-O, cc-ld, cc-E, etc.,
instead of having a single front-end called cc that accepts a large
number of switches.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi