Download raw (3.1 KB)

Traduction française de la page info coreutils, section Toolbox
===============================================================

    source: http://www.gnu.org/software/coreutils/
    
    Copyright (C) 1994-1996, 2000-2010 Free Software Foundation, Inc.
    
    Permission is granted to copy, distribute and/or modify this document
    under the terms of the GNU Free Documentation License, Version 1.3 or any
    later version published by the Free Software Foundation; with no Invariant
    Sections, with no Front-Cover Texts, and with no Back-Cover Texts.


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