Mercurial > docs > unix-phil
changeset 5:48f1f3465550
new content about interfaces and toolchests
author | meillo@marmaro.de |
---|---|
date | Sat, 13 Feb 2010 11:37:50 +0100 |
parents | c707b0c5c849 |
children | a6b837d822b7 |
files | unix-phil.ms |
diffstat | 1 files changed, 82 insertions(+), 13 deletions(-) [+] |
line wrap: on
line diff
--- a/unix-phil.ms Fri Feb 12 19:30:13 2010 +0100 +++ b/unix-phil.ms Sat Feb 13 11:37:50 2010 +0100 @@ -169,7 +169,8 @@ .LP The origins of the Unix Philosophy were already introduced. This chapter explains the philosophy and shows concrete examples of its application. -.NH 2 + +.SH Examples .LP Following are some examples to demonstrate how applied Unix Philosophy feels like. @@ -215,7 +216,8 @@ to get the desired output. There are also other ways to get the same output. It's a user's decision which way to go. -.NH 2 + +.SH Pipes .LP The examples show that a lot of tasks on a Unix system @@ -232,26 +234,93 @@ that transformed Unix from a basic file-sharing system to an entirely new way of computing.'' .[ %T Unix: An Oral History -%O http://www.princeton.edu/~hos/frs122/unixhist/finalhis.htm +%O .CW \s-1http://www.princeton.edu/~hos/frs122/unixhist/finalhis.htm .] .PP Being able to specify pipelines in an easy way is, however, not enough by itself. -It is only one part. +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 a pipeline. +They have to be of an external shape that allows them to be be used in such a way. + +.SH +Interface architecture +.LP +Unix is, first of all, simple: 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 our files \fIare\fP sequences of bytes, +and our 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 +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. + +.SH +Advantages of toolchests +.LP +A toolchest is a set of tools. +Instead of having one big tool for all tasks, one has many small tools, +each for one task. +Difficult tasks are solved by combining several of the small, simple tools. +.PP +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. +If the small programs are combinable, then they offer even a larger set +of functions than the single large program. +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. +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. +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. +Additinally, one needs to combine the tools in a senseful way on its own. +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. +Novice users do not need to learn several tools if a professional wraps +the single commands into a single 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. +.PP +A wrapper script for finding the five largest entries in the current directory +could look like this: +.DS +.CW +#!/bin/sh +du -s * | sort -nr | sed 5q +.DE +The script itself is just a text file that calls the command line +a professional user would type in directly. + + + .NH 2 -Architecture -.LP -the most important design decision. - -the topic here - -.NH 2 -Interface architecture +foo .LP standalone vs. tool chain .LP