docs/unix-phil
view unix-phil.ms @ 4:c707b0c5c849
new text about pipes
| author | meillo@marmaro.de |
|---|---|
| date | Fri, 12 Feb 2010 19:30:13 +0100 |
| parents | aebbe3e76f5e |
| children | 48f1f3465550 |
line source
1 .\".if n .pl 1000i
2 .de XX
3 .pl 1v
4 ..
5 .em XX
6 .\".nr PI 0
7 .\".if t .nr PD .5v
8 .\".if n .nr PD 1v
9 .nr lu 0
10 .de CW
11 .nr PQ \\n(.f
12 .if t .ft CW
13 .ie \\$1 .if n .ul 999
14 .el .if n .ul 1
15 .if t .if !\\$1 \&\\$1\f\\n(PQ\\$2
16 .if n .if \\n(.$=1 \&\\$1
17 .if n .if \\n(.$>1 \&\\$1\c
18 .if n .if \\n(.$>1 \&\\$2
19 ..
20 .ds [. \ [
21 .ds .] ]
22 .\"----------------------------------------
23 .TL
24 Why the Unix Philosophy matters
25 .AU
26 markus schnalke <meillo@marmaro.de>
27 .AB
28 .ti \n(.iu
29 This paper discusses the importance of the Unix Philosophy in software design.
30 Today, few software designers are aware of these concepts,
31 and thus most modern software is limited and does not make use of software leverage.
32 Knowing and following the tenets of the Unix Philosophy makes software more valuable.
33 .AE
35 .if t .2C
37 .FS
38 .ps -1
39 This paper was prepared for the seminar ``Software Analysis'' at University Ulm.
40 Mentor was professor Schweiggert. 2010-02-05
41 .br
42 You may get this document from my website
43 .CW \s-1http://marmaro.de/docs
44 .FE
46 .NH 1
47 Introduction
48 .LP
49 Building a software is a process from an idea of the purpose of the software
50 to its release.
51 No matter \fIhow\fP the process is run, two things are common:
52 the initial idea and the release.
53 The process inbetween can be of any shape.
54 The the maintainance work after the release is ignored for the moment.
55 .PP
56 The process of building splits mainly in two parts:
57 the planning of what and how to build, and implementing the plan by writing code.
58 This paper focuses on the planning part \(en the designing of the software.
59 .PP
60 Software design is the plan of how the internals and externals of the software should look like,
61 based on the requirements.
62 This paper discusses the recommendations of the Unix Philosphy about software design.
63 .PP
64 The here discussed ideas can get applied by any development process.
65 The Unix Philosphy does recommend how the software development process should look like,
66 but this shall not be of matter here.
67 Similar, the question of how to write the code is out of focus.
68 .PP
69 The name ``Unix Philosophy'' was already mentioned several times, but it was not explained yet.
70 The Unix Philosophy is the essence of how the Unix operating system and its toolchest was designed.
71 It is no limited set of rules, but what people see to be common to typical Unix software.
72 Several people stated their view on the Unix Philosophy.
73 Best known are:
74 .IP \(bu
75 Doug McIlroy's summary: ``Write programs that do one thing and do it well.''
76 .[
77 %A M. D. McIlroy
78 %A E. N. Pinson
79 %A B. A. Taque
80 %T UNIX Time-Sharing System Forward
81 %J The Bell System Technical Journal
82 %D 1978
83 %V 57
84 %N 6
85 %P 1902
86 .]
87 .IP \(bu
88 Mike Gancarz' book ``The UNIX Philosophy''.
89 .[
90 %A Mike Gancarz
91 %T The UNIX Philosophy
92 %D 1995
93 %I Digital Press
94 .]
95 .IP \(bu
96 Eric S. Raymond's book ``The Art of UNIX Programming''.
97 .[
98 %A Eric S. Raymond
99 %T The Art of UNIX Programming
100 %D 2003
101 %I Addison-Wesley
102 %O .CW \s-1http://www.faqs.org/docs/artu/
103 .]
104 .LP
105 These different views on the Unix Philosophy have much in common.
106 Especially, the main concepts are similar for all of them.
107 But there are also points on which they differ.
108 This only underlines what the Unix Philosophy is:
109 A retrospective view on the main concepts of Unix software;
110 especially those that were sucessful and unique to Unix.
111 .PP
112 Before we will have a look at concrete concepts,
113 we discuss why software design is important
114 and what problems bad design introduces.
117 .NH 1
118 Importance of software design
119 .LP
120 Why should we design software at all?
121 It is general knowledge, that a bad plan is better than no plan.
122 As stated earlier in this document, the process of building a software
123 means going from an idea to a release.
124 The development process tells how to get from the idea to the release.
125 Software design is the shape of the built software.
126 This means, that different designs of a software would be different target points to go to.
127 Thus, the design of a software defines the global direction the development goes.
128 .PP
129 It is not enough that the released software offers all requested functionality.
130 It is a misbelief that only function matters.
131 Building a software the first time is only a small part of the overall work.
132 The larger part begins when the software is released for the first time
133 \(en maintainance and extending work..
134 This part soon covers more time than the time which was needed to build the software the first time.
135 .\" cf. brooks?
136 .PP
137 The extendability and maitainability of a software highly depends on its design.
138 Good design eases these tasks much.
139 Bad design, in contrast, requires much more effort for maintaining and
140 extending the software.
141 Developers should, for their own best, have maintainability and extendability in mind
142 when they design the software.
143 .PP
144 Users of the software, in contrast, do not care about maintainability and extendability,
145 at least not directly.
146 They care about usability and flexibility.
147 They want the software to directly solve their problems.
148 They want to be able to to use all its functions if they learned a few of them.
149 They want to use the software for similar tasks.
150 Software is successful if users enjoy using it.
151 Good software design can offer great flexibility and usability.
152 .PP
153 Good design matters for developers \fIand\fP for users.
154 Hence both groups should care about good software design.
155 Bad design limits the software in some way.
156 It may still provide all requested function, but it will have worse quality,
157 and thus require more work effort for developers or frustrate users.
158 .PP
159 Good software design is to the implementation like data structures are to algorithms
160 \(en if you get the former right, then you do not need to care about the latter,
161 it will simply go the right way.
162 .\" cf. ??? ``good data, bad algos''
167 .NH 1
168 The Unix Philosophy
169 .LP
170 The origins of the Unix Philosophy were already introduced.
171 This chapter explains the philosophy and shows concrete examples of its application.
172 .NH 2
173 Examples
174 .LP
175 Following are some examples to demonstrate how applied Unix Philosophy feels like.
176 Knowledge of using the Unix shell is assumed.
177 .PP
178 Counting the number of files in the current directory:
179 .DS
180 .CW
181 ls | wc -l
182 .DE
183 The
184 .CW ls
185 command lists all files in the current directory, one per line,
186 and
187 .CW "wc -l
188 counts how many lines they are.
189 .PP
190 Counting all files that do not contain ``foo'' in their name:
191 .DS
192 .CW
193 ls | grep -v foo | wc -l
194 .DE
195 Here, the list of files is filtered by
196 .CW grep
197 to remove all that contain ``foo''.
198 The rest is the same as in the previous example.
199 .PP
200 Finding the five largest entries in the current directory.
201 .DS
202 .CW
203 du -s * | sort -nr | sed 5q
204 .DE
205 .CW "du -s *
206 returns the recursively summed sizes of all files
207 -- no matter if they are regular files or directories.
208 .CW "sort -nr
209 sorts the list numerically in reverse order.
210 Finally,
211 .CW "sed 5q
212 quits after it has printed the fifth line.
213 .PP
214 The presented command lines are examples of what Unix people would use
215 to get the desired output.
216 There are also other ways to get the same output.
217 It's a user's decision which way to go.
218 .NH 2
219 Pipes
220 .LP
221 The examples show that a lot of tasks on a Unix system
222 are accomplished by combining several small programs.
223 The connection between the single programs is denoted by the pipe operator `|'.
224 .PP
225 Pipes, and their extensive and easy use, are one of the great
226 achievements of the Unix system.
227 Pipes between programs have been possible in earlier operating systems,
228 but it has never been a so central part of the concept.
229 When, in the early seventies, Doug McIlroy introduced pipes for the
230 Unix system,
231 ``it was this concept and notation for linking several programs together
232 that transformed Unix from a basic file-sharing system to an entirely new way of computing.''
233 .[
234 %T Unix: An Oral History
235 %O http://www.princeton.edu/~hos/frs122/unixhist/finalhis.htm
236 .]
237 .PP
238 Being able to specify pipelines in an easy way is,
239 however, not enough by itself.
240 It is only one part.
241 The other is the design of the programs that are used in the pipeline.
242 They have to be of an external shape that allows them to be be used in a pipeline.
246 .NH 2
247 Architecture
248 .LP
249 the most important design decision.
251 the topic here
253 .NH 2
254 Interface architecture
255 .LP
256 standalone vs. tool chain
257 .LP
258 software leverage
259 .LP
260 possiblities
262 .NH 2
263 Results
264 .LP
265 The unix phil is an answer to the sw design question
266 .LP
267 tool chains empower the uses of sw
269 .NH 1
270 Case study: nmh
272 .NH 2
273 History
274 .LP
275 MH, nmh.
276 They are old.
278 .NH 2
279 Contrasts to similar sw
280 .LP
281 vs. Thunderbird, mutt, mailx, pine
282 .LP
283 flexibility, no redundancy, use the shell
285 .NH 2
286 Gains of the design
287 .LP
289 .NH 2
290 Problems
291 .LP
293 .NH 1
294 Case study: uzbl
296 .NH 2
297 History
298 .LP
299 uzbl is young
301 .NH 2
302 Contrasts to similar sw
303 .LP
304 like with nmh
305 .LP
306 addons, plugins, modules
308 .NH 2
309 Gains of the design
310 .LP
312 .NH 2
313 Problems
314 .LP
315 broken web
317 .NH 1
318 Final thoughts
320 .NH 2
321 Quick summary
322 .LP
323 good design
324 .LP
325 unix phil
326 .LP
327 case studies
329 .NH 2
330 Why people should choose
331 .LP
332 Make the right choice!
334 .nr PI .5i
335 .rm ]<
336 .de ]<
337 .LP
338 .de FP
339 .IP \\\\$1.
340 \\..
341 .rm FS FE
342 ..
343 .SH
344 References
345 .[
346 $LIST$
347 .]
348 .wh -1p