# HG changeset patch # User meillo@marmaro.de # Date 1266579116 -3600 # Node ID 924b2ac2d477f2b2aba5d94e366af8393234821f # Parent 606f0ffca834f50dfcb412dcbabcd984d9b9d598 new text about toolchest and shell (ch03) diff -r 606f0ffca834 -r 924b2ac2d477 unix-phil.ms --- 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,28 +374,57 @@ .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 .LP The unix phil is an answer to the sw design question .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