(coreutils.info)Toolbox introduction

---

Next: I/O redirection Up: Opening the software toolbox

---

Enter node , (file) or (file)node

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.)