1.1 --- a/unix-phil.ms	Fri Feb 12 19:30:13 2010 +0100
     1.2 +++ b/unix-phil.ms	Sat Feb 13 11:37:50 2010 +0100
     1.3 @@ -169,7 +169,8 @@
     1.4  .LP
     1.5  The origins of the Unix Philosophy were already introduced.
     1.6  This chapter explains the philosophy and shows concrete examples of its application.
     1.7 -.NH 2
     1.8 +
     1.9 +.SH
    1.10  Examples
    1.11  .LP
    1.12  Following are some examples to demonstrate how applied Unix Philosophy feels like.
    1.13 @@ -215,7 +216,8 @@
    1.14  to get the desired output.
    1.15  There are also other ways to get the same output.
    1.16  It's a user's decision which way to go.
    1.17 -.NH 2
    1.18 +
    1.19 +.SH
    1.20  Pipes
    1.21  .LP
    1.22  The examples show that a lot of tasks on a Unix system
    1.23 @@ -232,26 +234,93 @@
    1.24  that transformed Unix from a basic file-sharing system to an entirely new way of computing.''
    1.25  .[
    1.26  %T Unix: An Oral History
    1.27 -%O http://www.princeton.edu/~hos/frs122/unixhist/finalhis.htm
    1.28 +%O .CW \s-1http://www.princeton.edu/~hos/frs122/unixhist/finalhis.htm
    1.29  .] 
    1.30  .PP
    1.31  Being able to specify pipelines in an easy way is,
    1.32  however, not enough by itself.
    1.33 -It is only one part.
    1.34 +It is only one half.
    1.35  The other is the design of the programs that are used in the pipeline.
    1.36 -They have to be of an external shape that allows them to be be used in a pipeline.
    1.37 +They have to be of an external shape that allows them to be be used in such a way.
    1.38 +
    1.39 +.SH
    1.40 +Interface architecture
    1.41 +.LP
    1.42 +Unix is, first of all, simple: Everything is a file.
    1.43 +Files are sequences of bytes, without any special structure.
    1.44 +Programs should be filters, which read a stream of bytes from ``standard input'' (stdin)
    1.45 +and write a stream of bytes to ``standard output'' (stdout).
    1.46 +.PP
    1.47 +If our files \fIare\fP sequences of bytes,
    1.48 +and our programs \fIare\fP filters on byte streams,
    1.49 +then there is exactly one standardized interface.
    1.50 +Thus it is possible to combine them in any desired way.
    1.51 +.PP
    1.52 +Even a handful of small programs will yield a large set of combinations,
    1.53 +and thus a large set of different functions.
    1.54 +This is leverage!
    1.55 +.PP
    1.56 +If the programs are orthogonal to each other \(en the best case \(en
    1.57 +then the set of different functions is greatest.
    1.58 +.PP
    1.59 +Now, the Unix toolchest is a set of small programs that
    1.60 +are filters on byte streams.
    1.61 +They are to a large extend unrelated in their function.
    1.62 +Hence, the Unix toolchest provides a large set of functions
    1.63 +that can be accessed by combining the programs in the desired way.
    1.64 +
    1.65 +.SH
    1.66 +Advantages of toolchests
    1.67 +.LP
    1.68 +A toolchest is a set of tools.
    1.69 +Instead of having one big tool for all tasks, one has many small tools,
    1.70 +each for one task.
    1.71 +Difficult tasks are solved by combining several of the small, simple tools.
    1.72 +.PP
    1.73 +It is easier and less error-prone to write small programs.
    1.74 +It is also easier and less error-prone to write a large set of small programs,
    1.75 +than to write one large program with all the functionality included.
    1.76 +If the small programs are combinable, then they offer even a larger set
    1.77 +of functions than the single large program.
    1.78 +Hence, one gets two advantages out of writing small, combinable programs.
    1.79 +.PP
    1.80 +There are two drawbacks of the toolchest approach.
    1.81 +First, one simple, standardized, unidirectional Interface has to be sufficient.
    1.82 +If one feels the need for more ``logic'' than a stream of bytes,
    1.83 +then a different approach might be of need, or, more likely,
    1.84 +he just did not came to a design where a stream of bytes is sufficient.
    1.85 +The other drawback of a toolchest affects the users.
    1.86 +A toolchest is often more difficult to use for novices.
    1.87 +It is neccessary to become familiar with each of the tools,
    1.88 +to be able to use the right one in a given situation.
    1.89 +Additinally, one needs to combine the tools in a senseful way on its own.
    1.90 +This is like a sharp knive \(en it is a powerful tool in the hand of a master,
    1.91 +but of no good value in the hand of an unskilled.
    1.92 +.PP
    1.93 +Luckily, the second drawback can be solved easily by adding wrappers around the single tools.
    1.94 +Novice users do not need to learn several tools if a professional wraps
    1.95 +the single commands into a single script.
    1.96 +Note that the wrapper script still calls the small tools;
    1.97 +the wrapper script is just like a skin around.
    1.98 +No complexity is added this way.
    1.99 +.PP
   1.100 +A wrapper script for finding the five largest entries in the current directory
   1.101 +could look like this:
   1.102 +.DS
   1.103 +.CW
   1.104 +#!/bin/sh
   1.105 +du -s * | sort -nr | sed 5q
   1.106 +.DE
   1.107 +The script itself is just a text file that calls the command line
   1.108 +a professional user would type in directly.
   1.109 +
   1.110 +
   1.111 +
   1.112  
   1.113  
   1.114  
   1.115  .NH 2
   1.116 -Architecture
   1.117 -.LP
   1.118 -the most important design decision.
   1.119 -
   1.120 -the topic here
   1.121 -
   1.122 -.NH 2
   1.123 -Interface architecture
   1.124 +foo
   1.125  .LP
   1.126  standalone vs. tool chain
   1.127  .LP