--- a/unix-phil.ms	Thu Feb 18 12:15:39 2010 +0100
+++ b/unix-phil.ms	Fri Feb 19 12:31:56 2010 +0100
@@ -216,7 +216,8 @@
 The Unix Philosophy
 .LP
 The origins of the Unix Philosophy were already introduced.
-This chapter explains the philosophy and shows concrete examples of its application.
+This chapter explains the philosophy, oriented on Gancarz,
+and shows concrete examples of its application.
 
 .SH
 Examples
@@ -234,9 +235,9 @@
 command lists all files in the current directory, one per line,
 and
 .CW "wc -l
-counts how many lines they are.
+counts the number of lines.
 .PP
-Counting all files that do not contain ``foo'' in their name:
+Counting the number of files that do not contain ``foo'' in their name:
 .DS
 .CW
 ls | grep -v foo | wc -l
@@ -253,7 +254,7 @@
 .DE
 .CW "du -s *
 returns the recursively summed sizes of all files
--- no matter if they are regular files or directories.
+\(en no matter if they are regular files or directories.
 .CW "sort -nr
 sorts the list numerically in reverse order.
 Finally,
@@ -268,7 +269,7 @@
 .SH
 Pipes
 .LP
-The examples show that a lot of tasks on a Unix system
+The examples show that many tasks on a Unix system
 are accomplished by combining several small programs.
 The connection between the single programs is denoted by the pipe operator `|'.
 .PP
@@ -289,7 +290,7 @@
 however, not enough by itself.
 It is only one half.
 The other is the design of the programs that are used in the pipeline.
-They have to be of an external shape that allows them to be be used in such a way.
+They have to interfaces that allows them to be used in such a way.
 
 .SH
 Interface architecture
@@ -299,26 +300,25 @@
 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 our files \fIare\fP sequences of bytes,
-and our programs \fIare\fP filters on byte streams,
+If the files \fIare\fP sequences of bytes,
+and the programs \fIare\fP filters on byte streams,
 then there is exactly one standardized 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,
 and thus a large set of different functions.
 This is leverage!
-.PP
 If the programs are orthogonal to each other \(en the best case \(en
 then the set of different functions is greatest.
 .PP
-Now, the Unix toolchest is a set of small programs that
+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.
+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.
 
 .SH
-Advantages of toolchests
+The toolchest approach
 .LP
 A toolchest is a set of tools.
 Instead of having one big tool for all tasks, one has many small tools,
@@ -333,11 +333,16 @@
 Hence, one gets two advantages out of writing small, combinable programs.
 .PP
 There are two drawbacks of the toolchest approach.
-First, one simple, standardized, unidirectional Interface has to be sufficient.
+First, one simple, standardized, unidirectional interface has to be sufficient.
 If one feels the need for more ``logic'' than a stream of bytes,
-then a different approach might be of need, or, more likely,
-he just did not came to a design where a stream of bytes is sufficient.
-The other drawback of a toolchest affects the users.
+then a different approach might be of need.
+But it is also possbile, that he just can not imaging a design where
+a stream of bytes is sufficient.
+By becoming more familiar with the ``Unix style of thinking'',
+developers will more often and easier find simple designs where
+a stream of bytes is a sufficient interface.
+.PP
+The second drawback of a toolchest affects the users.
 A toolchest is often more difficult to use for novices.
 It is neccessary to become familiar with each of the tools,
 to be able to use the right one in a given situation.
@@ -345,12 +350,20 @@
 This is like a sharp knive \(en it is a powerful tool in the hand of a master,
 but of no good value in the hand of an unskilled.
 .PP
-Luckily, the second drawback can be solved easily by adding wrappers around the single tools.
+However, learning single, small tool of the toolchest is easier than
+learning a complex tool.
+The user will have a basic understanding of a yet unknown tool,
+if the several tools of the toolchest have a common style.
+He will be able to transfer knowledge over one tool to another.
+.PP
+Moreover, the second drawback can be removed easily by adding wrappers
+around the single tools.
 Novice users do not need to learn several tools if a professional wraps
-the single commands into a single script.
+the single commands into a more high-level script.
 Note that the wrapper script still calls the small tools;
 the wrapper script is just like a skin around.
-No complexity is added this way.
+No complexity is added this way,
+but new programs can get created out of existing one with very low effort.
 .PP
 A wrapper script for finding the five largest entries in the current directory
 could look like this:
@@ -361,20 +374,47 @@
 .DE
 The script itself is just a text file that calls the command line
 a professional user would type in directly.
+Making the program flexible on the number of entries it prints,
+is easily possible:
+.DS
+.CW
+#!/bin/sh
+num=5
+[ $# -eq 1 ] && num="$1"
+du -sh * | sort -nr | sed "${num}q"
+.DE
+This script acts like the one before, when called without an argument.
+But one can also specify a numerical argument to define the number of lines to print.
 
-
+.SH
+A powerful shell
+.LP
+The Unix shell provides the possibility to combine small programs into
+large ones easily.
+But the powerful shell is great feature in other ways, too.
+.PP
+It encourages rapid prototyping.
+It includes a scripting language with built in control statements.
+The functions, however, are the normal programs, everyone can use on the system.
+Thus, the programs are known and learning to program in the shell is easy.
+Using normal programs as functions in the shell programming language
+is only possible because they are small, combinable tools in a toolchest style.
+.PP
+The Unix shell encourages to write small scripts out of other programs,
+because it is so easy to do.
+This is a great step towards automation.
+It is wonderful if the effort to automate a task equals the effort
+it takes to do it the second time by hand.
+If it is so, then the user will be happy to automate everything he does more than once.
+.PP
+Small programs that do one job well, standardized interfaces between them,
+a mechanism to combine parts to larger parts, and an easy way to automate tasks,
+this will inevitably produce software leverage.
+Getting multiple times the benefit of an investment is a great offer.
 
 
 
 
-.NH 2
-foo
-.LP
-standalone vs. tool chain
-.LP
-software leverage
-.LP
-possiblities
 
 .NH 2
 Results
@@ -383,6 +423,8 @@
 .LP
 tool chains empower the uses of sw
 
+
+
 .NH 1
 Case study: nmh
 
@@ -407,6 +449,8 @@
 Problems
 .LP
 
+
+
 .NH 1
 Case study: uzbl
 
@@ -431,6 +475,8 @@
 .LP
 broken web
 
+
+
 .NH 1
 Final thoughts