1.1 --- a/unix-phil.ms	Thu Feb 18 12:15:39 2010 +0100
     1.2 +++ b/unix-phil.ms	Fri Feb 19 12:31:56 2010 +0100
     1.3 @@ -216,7 +216,8 @@
     1.4  The Unix Philosophy
     1.5  .LP
     1.6  The origins of the Unix Philosophy were already introduced.
     1.7 -This chapter explains the philosophy and shows concrete examples of its application.
     1.8 +This chapter explains the philosophy, oriented on Gancarz,
     1.9 +and shows concrete examples of its application.
    1.10  
    1.11  .SH
    1.12  Examples
    1.13 @@ -234,9 +235,9 @@
    1.14  command lists all files in the current directory, one per line,
    1.15  and
    1.16  .CW "wc -l
    1.17 -counts how many lines they are.
    1.18 +counts the number of lines.
    1.19  .PP
    1.20 -Counting all files that do not contain ``foo'' in their name:
    1.21 +Counting the number of files that do not contain ``foo'' in their name:
    1.22  .DS
    1.23  .CW
    1.24  ls | grep -v foo | wc -l
    1.25 @@ -253,7 +254,7 @@
    1.26  .DE
    1.27  .CW "du -s *
    1.28  returns the recursively summed sizes of all files
    1.29 --- no matter if they are regular files or directories.
    1.30 +\(en no matter if they are regular files or directories.
    1.31  .CW "sort -nr
    1.32  sorts the list numerically in reverse order.
    1.33  Finally,
    1.34 @@ -268,7 +269,7 @@
    1.35  .SH
    1.36  Pipes
    1.37  .LP
    1.38 -The examples show that a lot of tasks on a Unix system
    1.39 +The examples show that many tasks on a Unix system
    1.40  are accomplished by combining several small programs.
    1.41  The connection between the single programs is denoted by the pipe operator `|'.
    1.42  .PP
    1.43 @@ -289,7 +290,7 @@
    1.44  however, not enough by itself.
    1.45  It is only one half.
    1.46  The other is the design of the programs that are used in the pipeline.
    1.47 -They have to be of an external shape that allows them to be be used in such a way.
    1.48 +They have to interfaces that allows them to be used in such a way.
    1.49  
    1.50  .SH
    1.51  Interface architecture
    1.52 @@ -299,26 +300,25 @@
    1.53  Programs should be filters, which read a stream of bytes from ``standard input'' (stdin)
    1.54  and write a stream of bytes to ``standard output'' (stdout).
    1.55  .PP
    1.56 -If our files \fIare\fP sequences of bytes,
    1.57 -and our programs \fIare\fP filters on byte streams,
    1.58 +If the files \fIare\fP sequences of bytes,
    1.59 +and the programs \fIare\fP filters on byte streams,
    1.60  then there is exactly one standardized interface.
    1.61  Thus it is possible to combine them in any desired way.
    1.62  .PP
    1.63  Even a handful of small programs will yield a large set of combinations,
    1.64  and thus a large set of different functions.
    1.65  This is leverage!
    1.66 -.PP
    1.67  If the programs are orthogonal to each other \(en the best case \(en
    1.68  then the set of different functions is greatest.
    1.69  .PP
    1.70 -Now, the Unix toolchest is a set of small programs that
    1.71 +The Unix toolchest \fIis\fP a set of small programs that
    1.72  are filters on byte streams.
    1.73 -They are to a large extend unrelated in their function.
    1.74 +They are, to a large extend, unrelated in their function.
    1.75  Hence, the Unix toolchest provides a large set of functions
    1.76  that can be accessed by combining the programs in the desired way.
    1.77  
    1.78  .SH
    1.79 -Advantages of toolchests
    1.80 +The toolchest approach
    1.81  .LP
    1.82  A toolchest is a set of tools.
    1.83  Instead of having one big tool for all tasks, one has many small tools,
    1.84 @@ -333,11 +333,16 @@
    1.85  Hence, one gets two advantages out of writing small, combinable programs.
    1.86  .PP
    1.87  There are two drawbacks of the toolchest approach.
    1.88 -First, one simple, standardized, unidirectional Interface has to be sufficient.
    1.89 +First, one simple, standardized, unidirectional interface has to be sufficient.
    1.90  If one feels the need for more ``logic'' than a stream of bytes,
    1.91 -then a different approach might be of need, or, more likely,
    1.92 -he just did not came to a design where a stream of bytes is sufficient.
    1.93 -The other drawback of a toolchest affects the users.
    1.94 +then a different approach might be of need.
    1.95 +But it is also possbile, that he just can not imaging a design where
    1.96 +a stream of bytes is sufficient.
    1.97 +By becoming more familiar with the ``Unix style of thinking'',
    1.98 +developers will more often and easier find simple designs where
    1.99 +a stream of bytes is a sufficient interface.
   1.100 +.PP
   1.101 +The second drawback of a toolchest affects the users.
   1.102  A toolchest is often more difficult to use for novices.
   1.103  It is neccessary to become familiar with each of the tools,
   1.104  to be able to use the right one in a given situation.
   1.105 @@ -345,12 +350,20 @@
   1.106  This is like a sharp knive \(en it is a powerful tool in the hand of a master,
   1.107  but of no good value in the hand of an unskilled.
   1.108  .PP
   1.109 -Luckily, the second drawback can be solved easily by adding wrappers around the single tools.
   1.110 +However, learning single, small tool of the toolchest is easier than
   1.111 +learning a complex tool.
   1.112 +The user will have a basic understanding of a yet unknown tool,
   1.113 +if the several tools of the toolchest have a common style.
   1.114 +He will be able to transfer knowledge over one tool to another.
   1.115 +.PP
   1.116 +Moreover, the second drawback can be removed easily by adding wrappers
   1.117 +around the single tools.
   1.118  Novice users do not need to learn several tools if a professional wraps
   1.119 -the single commands into a single script.
   1.120 +the single commands into a more high-level script.
   1.121  Note that the wrapper script still calls the small tools;
   1.122  the wrapper script is just like a skin around.
   1.123 -No complexity is added this way.
   1.124 +No complexity is added this way,
   1.125 +but new programs can get created out of existing one with very low effort.
   1.126  .PP
   1.127  A wrapper script for finding the five largest entries in the current directory
   1.128  could look like this:
   1.129 @@ -361,28 +374,57 @@
   1.130  .DE
   1.131  The script itself is just a text file that calls the command line
   1.132  a professional user would type in directly.
   1.133 +Making the program flexible on the number of entries it prints,
   1.134 +is easily possible:
   1.135 +.DS
   1.136 +.CW
   1.137 +#!/bin/sh
   1.138 +num=5
   1.139 +[ $# -eq 1 ] && num="$1"
   1.140 +du -sh * | sort -nr | sed "${num}q"
   1.141 +.DE
   1.142 +This script acts like the one before, when called without an argument.
   1.143 +But one can also specify a numerical argument to define the number of lines to print.
   1.144  
   1.145 +.SH
   1.146 +A powerful shell
   1.147 +.LP
   1.148 +The Unix shell provides the possibility to combine small programs into
   1.149 +large ones easily.
   1.150 +But the powerful shell is great feature in other ways, too.
   1.151 +.PP
   1.152 +It encourages rapid prototyping.
   1.153 +It includes a scripting language with built in control statements.
   1.154 +The functions, however, are the normal programs, everyone can use on the system.
   1.155 +Thus, the programs are known and learning to program in the shell is easy.
   1.156 +Using normal programs as functions in the shell programming language
   1.157 +is only possible because they are small, combinable tools in a toolchest style.
   1.158 +.PP
   1.159 +The Unix shell encourages to write small scripts out of other programs,
   1.160 +because it is so easy to do.
   1.161 +This is a great step towards automation.
   1.162 +It is wonderful if the effort to automate a task equals the effort
   1.163 +it takes to do it the second time by hand.
   1.164 +If it is so, then the user will be happy to automate everything he does more than once.
   1.165 +.PP
   1.166 +Small programs that do one job well, standardized interfaces between them,
   1.167 +a mechanism to combine parts to larger parts, and an easy way to automate tasks,
   1.168 +this will inevitably produce software leverage.
   1.169 +Getting multiple times the benefit of an investment is a great offer.
   1.170  
   1.171  
   1.172  
   1.173  
   1.174  
   1.175  .NH 2
   1.176 -foo
   1.177 -.LP
   1.178 -standalone vs. tool chain
   1.179 -.LP
   1.180 -software leverage
   1.181 -.LP
   1.182 -possiblities
   1.183 -
   1.184 -.NH 2
   1.185  Results
   1.186  .LP
   1.187  The unix phil is an answer to the sw design question
   1.188  .LP
   1.189  tool chains empower the uses of sw
   1.190  
   1.191 +
   1.192 +
   1.193  .NH 1
   1.194  Case study: nmh
   1.195  
   1.196 @@ -407,6 +449,8 @@
   1.197  Problems
   1.198  .LP
   1.199  
   1.200 +
   1.201 +
   1.202  .NH 1
   1.203  Case study: uzbl
   1.204  
   1.205 @@ -431,6 +475,8 @@
   1.206  .LP
   1.207  broken web
   1.208  
   1.209 +
   1.210 +
   1.211  .NH 1
   1.212  Final thoughts
   1.213