# HG changeset patch
# User meillo@marmaro.de
# Date 1266675880 -3600
# Node ID b32a43a62cae88dfa53b65d76fd3e5dc1ac378b8
# Parent  355ed69a34a8127179fce044e5b547d99d60bab5
some rework about interface arch (ch03)

diff -r 355ed69a34a8 -r b32a43a62cae unix-phil.ms
--- a/unix-phil.ms	Sat Feb 20 12:14:01 2010 +0100
+++ b/unix-phil.ms	Sat Feb 20 15:24:40 2010 +0100
@@ -298,14 +298,14 @@
 .SH
 Interface architecture
 .LP
-Unix is, first of all, simple: Everything is a file.
+Unix is, first of all, simple \(en Everything is a file.
 Files are sequences of bytes, without any special structure.
 Programs should be filters, which read a stream of bytes from ``standard input'' (stdin)
 and write a stream of bytes to ``standard output'' (stdout).
 .PP
 If the files \fIare\fP sequences of bytes,
 and the programs \fIare\fP filters on byte streams,
-then there is exactly one standardized interface.
+then there is exactly one standardized data interface.
 Thus it is possible to combine them in any desired way.
 .PP
 Even a handful of small programs will yield a large set of combinations,
@@ -314,11 +314,39 @@
 If the programs are orthogonal to each other \(en the best case \(en
 then the set of different functions is greatest.
 .PP
-The Unix toolchest \fIis\fP a set of small programs that
-are filters on byte streams.
-They are, to a large extend, unrelated in their function.
-Hence, the Unix toolchest provides a large set of functions
-that can be accessed by combining the programs in the desired way.
+Programs might also have a separate control interface,
+besides their data interface.
+The control interface is often called ``user interface'',
+because it is usually designed to be used by humans.
+The Unix Philosophy discourages to assume the user to be human.
+Interactive use of software is slow use of software,
+because the program waits for user input most of the time.
+Interactive software requires the user to be in front of the computer
+all the time.
+Interactive software occupy the user's attention while they are running.
+.PP
+Now we come back to the idea of using several small programs, combined,
+to have a more specific function.
+If these single tools would all be interactive,
+how would the user control them?
+It is not only a problem to control several programs at once if they run at the same time,
+it also very inefficient to have to control each of the single programs
+that are intended to work as one large program.
+Hence, the Unix Philosophy discourages programs to demand interactive use.
+The behavior of programs should be defined at invocation.
+This is done by specifying arguments (``command line switches'') to the program call.
+Gancarz discusses this topic as ``avoid captive user interfaces''.
+.[
+%A Mike Gancarz
+%T The UNIX Philosophy
+%I Digital Press
+%D 1995
+%P 88 ff.
+.]
+.PP
+Non-interactive use is, during development, also an advantage for testing.
+Testing of interactive programs is much more complicated,
+than testing of non-interactive programs.
 
 .SH
 The toolchest approach
@@ -328,6 +356,13 @@
 each for one task.
 Difficult tasks are solved by combining several of the small, simple tools.
 .PP
+The Unix toolchest \fIis\fP a set of small, (mostly) non-interactive programs
+that are filters on byte streams.
+They are, to a large extend, unrelated in their function.
+Hence, the Unix toolchest provides a large set of functions
+that can be accessed by combining the programs in the desired way.
+.PP
+There are also advantages for developing small toolchest programs.
 It is easier and less error-prone to write small programs.
 It is also easier and less error-prone to write a large set of small programs,
 than to write one large program with all the functionality included.
@@ -495,8 +530,15 @@
 then less effort was spent into the project, than it would have be
 when a different approach had been used.
 
+.SH
+Upgrowth and survival of software
+.LP
 
+portability
 
+text files
+
+reuse of independent parts