coreutils: Toolbox introduction

 
 Toolbox Introduction
 ====================
 
 This month’s column is only peripherally related to the GNU Project, in
 that it describes a number of the GNU tools on your GNU/Linux system and
 how they might be used.  What it’s really about is the “Software Tools”
 philosophy of program development and usage.
 
    The software tools philosophy was an important and integral concept
 in the initial design and development of Unix (of which Linux and GNU
 are essentially clones).  Unfortunately, in the modern day press of
 Internetworking and flashy GUIs, it seems to have fallen by the wayside.
 This is a shame, since it provides a powerful mental model for solving
 many kinds of problems.
 
    Many people carry a Swiss Army knife around in their pants pockets
 (or purse).  A Swiss Army knife is a handy tool to have: it has several
 knife blades, a screwdriver, tweezers, toothpick, nail file, corkscrew,
 and perhaps a number of other things on it.  For the everyday, small
 miscellaneous jobs where you need a simple, general purpose tool, it’s
 just the thing.
 
    On the other hand, an experienced carpenter doesn’t build a house
 using a Swiss Army knife.  Instead, he has a toolbox chock full of
 specialized tools—a saw, a hammer, a screwdriver, a plane, and so on.
 And he knows exactly when and where to use each tool; you won’t catch
 him hammering nails with the handle of his screwdriver.
 
    The Unix developers at Bell Labs were all professional programmers
 and trained computer scientists.  They had found that while a
 one-size-fits-all program might appeal to a user because there’s only
 one program to use, in practice such programs are
 
   a. difficult to write,
 
   b. difficult to maintain and debug, and
 
   c. difficult to extend to meet new situations.
 
    Instead, they felt that programs should be specialized tools.  In
 short, each program “should do one thing well.” No more and no less.
 Such programs are simpler to design, write, and get right—they only do
 one thing.
 
    Furthermore, they found that with the right machinery for hooking
 programs together, that the whole was greater than the sum of the parts.
 By combining several special purpose programs, you could accomplish a
 specific task that none of the programs was designed for, and accomplish
 it much more quickly and easily than if you had to write a special
 purpose program.  We will see some (classic) examples of this further on
 in the column.  (An important additional point was that, if necessary,
 take a detour and build any software tools you may need first, if you
 don’t already have something appropriate in the toolbox.)