1.1 --- a/unix-phil.ms	Sat Feb 20 12:14:01 2010 +0100
     1.2 +++ b/unix-phil.ms	Sat Feb 20 15:24:40 2010 +0100
     1.3 @@ -298,14 +298,14 @@
     1.4  .SH
     1.5  Interface architecture
     1.6  .LP
     1.7 -Unix is, first of all, simple: Everything is a file.
     1.8 +Unix is, first of all, simple \(en Everything is a file.
     1.9  Files are sequences of bytes, without any special structure.
    1.10  Programs should be filters, which read a stream of bytes from ``standard input'' (stdin)
    1.11  and write a stream of bytes to ``standard output'' (stdout).
    1.12  .PP
    1.13  If the files \fIare\fP sequences of bytes,
    1.14  and the programs \fIare\fP filters on byte streams,
    1.15 -then there is exactly one standardized interface.
    1.16 +then there is exactly one standardized data interface.
    1.17  Thus it is possible to combine them in any desired way.
    1.18  .PP
    1.19  Even a handful of small programs will yield a large set of combinations,
    1.20 @@ -314,11 +314,39 @@
    1.21  If the programs are orthogonal to each other \(en the best case \(en
    1.22  then the set of different functions is greatest.
    1.23  .PP
    1.24 -The Unix toolchest \fIis\fP a set of small programs that
    1.25 -are filters on byte streams.
    1.26 -They are, to a large extend, unrelated in their function.
    1.27 -Hence, the Unix toolchest provides a large set of functions
    1.28 -that can be accessed by combining the programs in the desired way.
    1.29 +Programs might also have a separate control interface,
    1.30 +besides their data interface.
    1.31 +The control interface is often called ``user interface'',
    1.32 +because it is usually designed to be used by humans.
    1.33 +The Unix Philosophy discourages to assume the user to be human.
    1.34 +Interactive use of software is slow use of software,
    1.35 +because the program waits for user input most of the time.
    1.36 +Interactive software requires the user to be in front of the computer
    1.37 +all the time.
    1.38 +Interactive software occupy the user's attention while they are running.
    1.39 +.PP
    1.40 +Now we come back to the idea of using several small programs, combined,
    1.41 +to have a more specific function.
    1.42 +If these single tools would all be interactive,
    1.43 +how would the user control them?
    1.44 +It is not only a problem to control several programs at once if they run at the same time,
    1.45 +it also very inefficient to have to control each of the single programs
    1.46 +that are intended to work as one large program.
    1.47 +Hence, the Unix Philosophy discourages programs to demand interactive use.
    1.48 +The behavior of programs should be defined at invocation.
    1.49 +This is done by specifying arguments (``command line switches'') to the program call.
    1.50 +Gancarz discusses this topic as ``avoid captive user interfaces''.
    1.51 +.[
    1.52 +%A Mike Gancarz
    1.53 +%T The UNIX Philosophy
    1.54 +%I Digital Press
    1.55 +%D 1995
    1.56 +%P 88 ff.
    1.57 +.]
    1.58 +.PP
    1.59 +Non-interactive use is, during development, also an advantage for testing.
    1.60 +Testing of interactive programs is much more complicated,
    1.61 +than testing of non-interactive programs.
    1.62  
    1.63  .SH
    1.64  The toolchest approach
    1.65 @@ -328,6 +356,13 @@
    1.66  each for one task.
    1.67  Difficult tasks are solved by combining several of the small, simple tools.
    1.68  .PP
    1.69 +The Unix toolchest \fIis\fP a set of small, (mostly) non-interactive programs
    1.70 +that are filters on byte streams.
    1.71 +They are, to a large extend, unrelated in their function.
    1.72 +Hence, the Unix toolchest provides a large set of functions
    1.73 +that can be accessed by combining the programs in the desired way.
    1.74 +.PP
    1.75 +There are also advantages for developing small toolchest programs.
    1.76  It is easier and less error-prone to write small programs.
    1.77  It is also easier and less error-prone to write a large set of small programs,
    1.78  than to write one large program with all the functionality included.
    1.79 @@ -495,8 +530,15 @@
    1.80  then less effort was spent into the project, than it would have be
    1.81  when a different approach had been used.
    1.82  
    1.83 +.SH
    1.84 +Upgrowth and survival of software
    1.85 +.LP
    1.86  
    1.87 +portability
    1.88  
    1.89 +text files
    1.90 +
    1.91 +reuse of independent parts
    1.92  
    1.93  
    1.94