rev |
line source |
meillo@2
|
1 .\".if n .pl 1000i
|
meillo@0
|
2 .de XX
|
meillo@0
|
3 .pl 1v
|
meillo@0
|
4 ..
|
meillo@0
|
5 .em XX
|
meillo@1
|
6 .\".nr PI 0
|
meillo@1
|
7 .\".if t .nr PD .5v
|
meillo@1
|
8 .\".if n .nr PD 1v
|
meillo@0
|
9 .nr lu 0
|
meillo@0
|
10 .de CW
|
meillo@0
|
11 .nr PQ \\n(.f
|
meillo@0
|
12 .if t .ft CW
|
meillo@0
|
13 .ie \\$1 .if n .ul 999
|
meillo@0
|
14 .el .if n .ul 1
|
meillo@0
|
15 .if t .if !\\$1 \&\\$1\f\\n(PQ\\$2
|
meillo@0
|
16 .if n .if \\n(.$=1 \&\\$1
|
meillo@0
|
17 .if n .if \\n(.$>1 \&\\$1\c
|
meillo@0
|
18 .if n .if \\n(.$>1 \&\\$2
|
meillo@0
|
19 ..
|
meillo@0
|
20 .ds [. \ [
|
meillo@0
|
21 .ds .] ]
|
meillo@1
|
22 .\"----------------------------------------
|
meillo@0
|
23 .TL
|
meillo@6
|
24 Why the Unix Philosophy still matters
|
meillo@0
|
25 .AU
|
meillo@0
|
26 markus schnalke <meillo@marmaro.de>
|
meillo@0
|
27 .AB
|
meillo@1
|
28 .ti \n(.iu
|
meillo@2
|
29 This paper discusses the importance of the Unix Philosophy in software design.
|
meillo@0
|
30 Today, few software designers are aware of these concepts,
|
meillo@3
|
31 and thus most modern software is limited and does not make use of software leverage.
|
meillo@0
|
32 Knowing and following the tenets of the Unix Philosophy makes software more valuable.
|
meillo@0
|
33 .AE
|
meillo@0
|
34
|
meillo@2
|
35 .if t .2C
|
meillo@2
|
36
|
meillo@2
|
37 .FS
|
meillo@2
|
38 .ps -1
|
meillo@2
|
39 This paper was prepared for the seminar ``Software Analysis'' at University Ulm.
|
meillo@2
|
40 Mentor was professor Schweiggert. 2010-02-05
|
meillo@2
|
41 .br
|
meillo@2
|
42 You may get this document from my website
|
meillo@2
|
43 .CW \s-1http://marmaro.de/docs
|
meillo@2
|
44 .FE
|
meillo@2
|
45
|
meillo@0
|
46 .NH 1
|
meillo@0
|
47 Introduction
|
meillo@0
|
48 .LP
|
meillo@0
|
49 Building a software is a process from an idea of the purpose of the software
|
meillo@3
|
50 to its release.
|
meillo@0
|
51 No matter \fIhow\fP the process is run, two things are common:
|
meillo@0
|
52 the initial idea and the release.
|
meillo@3
|
53 The process inbetween can be of any shape.
|
meillo@3
|
54 The the maintainance work after the release is ignored for the moment.
|
meillo@1
|
55 .PP
|
meillo@0
|
56 The process of building splits mainly in two parts:
|
meillo@0
|
57 the planning of what and how to build, and implementing the plan by writing code.
|
meillo@3
|
58 This paper focuses on the planning part \(en the designing of the software.
|
meillo@3
|
59 .PP
|
meillo@3
|
60 Software design is the plan of how the internals and externals of the software should look like,
|
meillo@3
|
61 based on the requirements.
|
meillo@3
|
62 This paper discusses the recommendations of the Unix Philosphy about software design.
|
meillo@3
|
63 .PP
|
meillo@3
|
64 The here discussed ideas can get applied by any development process.
|
meillo@3
|
65 The Unix Philosphy does recommend how the software development process should look like,
|
meillo@3
|
66 but this shall not be of matter here.
|
meillo@0
|
67 Similar, the question of how to write the code is out of focus.
|
meillo@1
|
68 .PP
|
meillo@3
|
69 The name ``Unix Philosophy'' was already mentioned several times, but it was not explained yet.
|
meillo@1
|
70 The Unix Philosophy is the essence of how the Unix operating system and its toolchest was designed.
|
meillo@3
|
71 It is no limited set of rules, but what people see to be common to typical Unix software.
|
meillo@1
|
72 Several people stated their view on the Unix Philosophy.
|
meillo@1
|
73 Best known are:
|
meillo@1
|
74 .IP \(bu
|
meillo@1
|
75 Doug McIlroy's summary: ``Write programs that do one thing and do it well.''
|
meillo@1
|
76 .[
|
meillo@1
|
77 %A M. D. McIlroy
|
meillo@1
|
78 %A E. N. Pinson
|
meillo@1
|
79 %A B. A. Taque
|
meillo@1
|
80 %T UNIX Time-Sharing System Forward
|
meillo@1
|
81 %J The Bell System Technical Journal
|
meillo@1
|
82 %D 1978
|
meillo@1
|
83 %V 57
|
meillo@1
|
84 %N 6
|
meillo@1
|
85 %P 1902
|
meillo@1
|
86 .]
|
meillo@1
|
87 .IP \(bu
|
meillo@1
|
88 Mike Gancarz' book ``The UNIX Philosophy''.
|
meillo@1
|
89 .[
|
meillo@1
|
90 %A Mike Gancarz
|
meillo@1
|
91 %T The UNIX Philosophy
|
meillo@1
|
92 %D 1995
|
meillo@1
|
93 %I Digital Press
|
meillo@1
|
94 .]
|
meillo@1
|
95 .IP \(bu
|
meillo@1
|
96 Eric S. Raymond's book ``The Art of UNIX Programming''.
|
meillo@1
|
97 .[
|
meillo@1
|
98 %A Eric S. Raymond
|
meillo@1
|
99 %T The Art of UNIX Programming
|
meillo@1
|
100 %D 2003
|
meillo@1
|
101 %I Addison-Wesley
|
meillo@2
|
102 %O .CW \s-1http://www.faqs.org/docs/artu/
|
meillo@1
|
103 .]
|
meillo@0
|
104 .LP
|
meillo@1
|
105 These different views on the Unix Philosophy have much in common.
|
meillo@3
|
106 Especially, the main concepts are similar for all of them.
|
meillo@1
|
107 But there are also points on which they differ.
|
meillo@1
|
108 This only underlines what the Unix Philosophy is:
|
meillo@1
|
109 A retrospective view on the main concepts of Unix software;
|
meillo@1
|
110 especially those that were sucessful and unique to Unix.
|
meillo@6
|
111 .\" really?
|
meillo@1
|
112 .PP
|
meillo@1
|
113 Before we will have a look at concrete concepts,
|
meillo@1
|
114 we discuss why software design is important
|
meillo@1
|
115 and what problems bad design introduces.
|
meillo@0
|
116
|
meillo@0
|
117
|
meillo@0
|
118 .NH 1
|
meillo@6
|
119 Importance of software design in general
|
meillo@0
|
120 .LP
|
meillo@2
|
121 Why should we design software at all?
|
meillo@6
|
122 It is general knowledge, that even a bad plan is better than no plan.
|
meillo@6
|
123 Ignoring software design is programming without a plan.
|
meillo@6
|
124 This will lead pretty sure to horrible results.
|
meillo@2
|
125 .PP
|
meillo@6
|
126 The design of a software is its internal and external shape.
|
meillo@6
|
127 The design talked about here has nothing to do with visual appearance.
|
meillo@6
|
128 If we see a program as a car, then its color is of no matter.
|
meillo@6
|
129 Its design would be the car's size, its shape, the number and position of doors,
|
meillo@6
|
130 the ratio of passenger and cargo transport, and so forth.
|
meillo@2
|
131 .PP
|
meillo@6
|
132 A software's design is about quality properties.
|
meillo@6
|
133 Each of the cars may be able to drive from A to B,
|
meillo@6
|
134 but it depends on its properties whether it is a good car for passenger transport or not.
|
meillo@6
|
135 It also depends on its properties if it is a good choice for a rough mountain area.
|
meillo@2
|
136 .PP
|
meillo@6
|
137 Requirements to a software are twofold: functional and non-functional.
|
meillo@6
|
138 Functional requirements are easier to define and to verify.
|
meillo@6
|
139 They are directly the software's functions.
|
meillo@6
|
140 Functional requirements are the reason why software gets written.
|
meillo@6
|
141 Someone has a problem and needs a tool to solve it.
|
meillo@6
|
142 Being able to solve the problem is the main functional requirement.
|
meillo@6
|
143 It is the driving force behind all programming effort.
|
meillo@2
|
144 .PP
|
meillo@6
|
145 On the other hand, there are also non-functional requirements.
|
meillo@6
|
146 They are called \fIquality\fP requirements, too.
|
meillo@6
|
147 The quality of a software is about properties that are not directly related to
|
meillo@6
|
148 the software's basic functions.
|
meillo@6
|
149 Quality aspects are about the properties that are overlooked at first sight.
|
meillo@2
|
150 .PP
|
meillo@6
|
151 Quality is of few matter when the software gets initially built,
|
meillo@6
|
152 but it will be of matter in usage and maintainance of the software.
|
meillo@6
|
153 A short-sighted might see in developing a software mainly building something up.
|
meillo@6
|
154 Reality shows, that building the software the first time is only a small amount
|
meillo@6
|
155 of the overall work.
|
meillo@6
|
156 Bug fixing, extending, rebuiling of parts \(en short: maintainance work \(en
|
meillo@6
|
157 does soon take over the major part of the time spent on a software.
|
meillo@6
|
158 Not to forget the usage of the software.
|
meillo@6
|
159 These processes are highly influenced by the software's quality.
|
meillo@6
|
160 Thus, quality should never be neglected.
|
meillo@6
|
161 The problem is that you hardly ``stumble over'' bad quality during the first build,
|
meillo@6
|
162 but this is the time when you should care about good quality most.
|
meillo@6
|
163 .PP
|
meillo@6
|
164 Software design is not about the basic function of a software;
|
meillo@6
|
165 this requirement will get satisfied anyway, as it is the main driving force behind the development.
|
meillo@6
|
166 Software design is about quality aspects of the software.
|
meillo@6
|
167 Good design will lead to good quality, bad design to bad quality.
|
meillo@6
|
168 The primary functions of the software will be affected modestly by bad quality,
|
meillo@6
|
169 but good quality can provide a lot of additional gain from the software,
|
meillo@6
|
170 even at places where one never expected it.
|
meillo@6
|
171 .PP
|
meillo@6
|
172 The ISO/IEC 9126-1 standard, part 1,
|
meillo@6
|
173 .[
|
meillo@6
|
174 %I International Organization for Standarization
|
meillo@6
|
175 %T ISO Standard 9126: Software Engineering \(en Product Quality, part 1
|
meillo@6
|
176 %C Geneve
|
meillo@6
|
177 %D 2001
|
meillo@6
|
178 .]
|
meillo@6
|
179 defines the quality model as consisting out of:
|
meillo@6
|
180 .IP \(bu
|
meillo@6
|
181 .I Functionality
|
meillo@6
|
182 (suitability, accuracy, inter\%operability, security)
|
meillo@6
|
183 .IP \(bu
|
meillo@6
|
184 .I Reliability
|
meillo@6
|
185 (maturity, fault tolerance, recoverability)
|
meillo@6
|
186 .IP \(bu
|
meillo@6
|
187 .I Usability
|
meillo@6
|
188 (understandability, learnability, operability, attractiveness)
|
meillo@6
|
189 .IP \(bu
|
meillo@6
|
190 .I Efficiency
|
meillo@6
|
191 (time behaviour, resource utilisation)
|
meillo@6
|
192 .IP \(bu
|
meillo@6
|
193 .I Maintainability
|
meillo@6
|
194 (analysability, changeability, stability, testability)
|
meillo@6
|
195 .IP \(bu
|
meillo@6
|
196 .I Portability
|
meillo@6
|
197 (adaptability, installability, co-existence, replaceability)
|
meillo@6
|
198 .LP
|
meillo@6
|
199 These goals are parts of a software's design.
|
meillo@6
|
200 Good design can give these properties to a software,
|
meillo@6
|
201 bad designed software will miss them.
|
meillo@0
|
202
|
meillo@0
|
203
|
meillo@0
|
204 .NH 1
|
meillo@0
|
205 The Unix Philosophy
|
meillo@4
|
206 .LP
|
meillo@4
|
207 The origins of the Unix Philosophy were already introduced.
|
meillo@4
|
208 This chapter explains the philosophy and shows concrete examples of its application.
|
meillo@5
|
209
|
meillo@5
|
210 .SH
|
meillo@4
|
211 Examples
|
meillo@4
|
212 .LP
|
meillo@4
|
213 Following are some examples to demonstrate how applied Unix Philosophy feels like.
|
meillo@4
|
214 Knowledge of using the Unix shell is assumed.
|
meillo@4
|
215 .PP
|
meillo@4
|
216 Counting the number of files in the current directory:
|
meillo@4
|
217 .DS
|
meillo@4
|
218 .CW
|
meillo@4
|
219 ls | wc -l
|
meillo@4
|
220 .DE
|
meillo@4
|
221 The
|
meillo@4
|
222 .CW ls
|
meillo@4
|
223 command lists all files in the current directory, one per line,
|
meillo@4
|
224 and
|
meillo@4
|
225 .CW "wc -l
|
meillo@4
|
226 counts how many lines they are.
|
meillo@4
|
227 .PP
|
meillo@4
|
228 Counting all files that do not contain ``foo'' in their name:
|
meillo@4
|
229 .DS
|
meillo@4
|
230 .CW
|
meillo@4
|
231 ls | grep -v foo | wc -l
|
meillo@4
|
232 .DE
|
meillo@4
|
233 Here, the list of files is filtered by
|
meillo@4
|
234 .CW grep
|
meillo@4
|
235 to remove all that contain ``foo''.
|
meillo@4
|
236 The rest is the same as in the previous example.
|
meillo@4
|
237 .PP
|
meillo@4
|
238 Finding the five largest entries in the current directory.
|
meillo@4
|
239 .DS
|
meillo@4
|
240 .CW
|
meillo@4
|
241 du -s * | sort -nr | sed 5q
|
meillo@4
|
242 .DE
|
meillo@4
|
243 .CW "du -s *
|
meillo@4
|
244 returns the recursively summed sizes of all files
|
meillo@4
|
245 -- no matter if they are regular files or directories.
|
meillo@4
|
246 .CW "sort -nr
|
meillo@4
|
247 sorts the list numerically in reverse order.
|
meillo@4
|
248 Finally,
|
meillo@4
|
249 .CW "sed 5q
|
meillo@4
|
250 quits after it has printed the fifth line.
|
meillo@4
|
251 .PP
|
meillo@4
|
252 The presented command lines are examples of what Unix people would use
|
meillo@4
|
253 to get the desired output.
|
meillo@4
|
254 There are also other ways to get the same output.
|
meillo@4
|
255 It's a user's decision which way to go.
|
meillo@5
|
256
|
meillo@5
|
257 .SH
|
meillo@4
|
258 Pipes
|
meillo@4
|
259 .LP
|
meillo@4
|
260 The examples show that a lot of tasks on a Unix system
|
meillo@4
|
261 are accomplished by combining several small programs.
|
meillo@4
|
262 The connection between the single programs is denoted by the pipe operator `|'.
|
meillo@4
|
263 .PP
|
meillo@4
|
264 Pipes, and their extensive and easy use, are one of the great
|
meillo@4
|
265 achievements of the Unix system.
|
meillo@4
|
266 Pipes between programs have been possible in earlier operating systems,
|
meillo@4
|
267 but it has never been a so central part of the concept.
|
meillo@4
|
268 When, in the early seventies, Doug McIlroy introduced pipes for the
|
meillo@4
|
269 Unix system,
|
meillo@4
|
270 ``it was this concept and notation for linking several programs together
|
meillo@4
|
271 that transformed Unix from a basic file-sharing system to an entirely new way of computing.''
|
meillo@4
|
272 .[
|
meillo@4
|
273 %T Unix: An Oral History
|
meillo@5
|
274 %O .CW \s-1http://www.princeton.edu/~hos/frs122/unixhist/finalhis.htm
|
meillo@4
|
275 .]
|
meillo@4
|
276 .PP
|
meillo@4
|
277 Being able to specify pipelines in an easy way is,
|
meillo@4
|
278 however, not enough by itself.
|
meillo@5
|
279 It is only one half.
|
meillo@4
|
280 The other is the design of the programs that are used in the pipeline.
|
meillo@5
|
281 They have to be of an external shape that allows them to be be used in such a way.
|
meillo@5
|
282
|
meillo@5
|
283 .SH
|
meillo@5
|
284 Interface architecture
|
meillo@5
|
285 .LP
|
meillo@5
|
286 Unix is, first of all, simple: Everything is a file.
|
meillo@5
|
287 Files are sequences of bytes, without any special structure.
|
meillo@5
|
288 Programs should be filters, which read a stream of bytes from ``standard input'' (stdin)
|
meillo@5
|
289 and write a stream of bytes to ``standard output'' (stdout).
|
meillo@5
|
290 .PP
|
meillo@5
|
291 If our files \fIare\fP sequences of bytes,
|
meillo@5
|
292 and our programs \fIare\fP filters on byte streams,
|
meillo@5
|
293 then there is exactly one standardized interface.
|
meillo@5
|
294 Thus it is possible to combine them in any desired way.
|
meillo@5
|
295 .PP
|
meillo@5
|
296 Even a handful of small programs will yield a large set of combinations,
|
meillo@5
|
297 and thus a large set of different functions.
|
meillo@5
|
298 This is leverage!
|
meillo@5
|
299 .PP
|
meillo@5
|
300 If the programs are orthogonal to each other \(en the best case \(en
|
meillo@5
|
301 then the set of different functions is greatest.
|
meillo@5
|
302 .PP
|
meillo@5
|
303 Now, the Unix toolchest is a set of small programs that
|
meillo@5
|
304 are filters on byte streams.
|
meillo@5
|
305 They are to a large extend unrelated in their function.
|
meillo@5
|
306 Hence, the Unix toolchest provides a large set of functions
|
meillo@5
|
307 that can be accessed by combining the programs in the desired way.
|
meillo@5
|
308
|
meillo@5
|
309 .SH
|
meillo@5
|
310 Advantages of toolchests
|
meillo@5
|
311 .LP
|
meillo@5
|
312 A toolchest is a set of tools.
|
meillo@5
|
313 Instead of having one big tool for all tasks, one has many small tools,
|
meillo@5
|
314 each for one task.
|
meillo@5
|
315 Difficult tasks are solved by combining several of the small, simple tools.
|
meillo@5
|
316 .PP
|
meillo@5
|
317 It is easier and less error-prone to write small programs.
|
meillo@5
|
318 It is also easier and less error-prone to write a large set of small programs,
|
meillo@5
|
319 than to write one large program with all the functionality included.
|
meillo@5
|
320 If the small programs are combinable, then they offer even a larger set
|
meillo@5
|
321 of functions than the single large program.
|
meillo@5
|
322 Hence, one gets two advantages out of writing small, combinable programs.
|
meillo@5
|
323 .PP
|
meillo@5
|
324 There are two drawbacks of the toolchest approach.
|
meillo@5
|
325 First, one simple, standardized, unidirectional Interface has to be sufficient.
|
meillo@5
|
326 If one feels the need for more ``logic'' than a stream of bytes,
|
meillo@5
|
327 then a different approach might be of need, or, more likely,
|
meillo@5
|
328 he just did not came to a design where a stream of bytes is sufficient.
|
meillo@5
|
329 The other drawback of a toolchest affects the users.
|
meillo@5
|
330 A toolchest is often more difficult to use for novices.
|
meillo@5
|
331 It is neccessary to become familiar with each of the tools,
|
meillo@5
|
332 to be able to use the right one in a given situation.
|
meillo@5
|
333 Additinally, one needs to combine the tools in a senseful way on its own.
|
meillo@5
|
334 This is like a sharp knive \(en it is a powerful tool in the hand of a master,
|
meillo@5
|
335 but of no good value in the hand of an unskilled.
|
meillo@5
|
336 .PP
|
meillo@5
|
337 Luckily, the second drawback can be solved easily by adding wrappers around the single tools.
|
meillo@5
|
338 Novice users do not need to learn several tools if a professional wraps
|
meillo@5
|
339 the single commands into a single script.
|
meillo@5
|
340 Note that the wrapper script still calls the small tools;
|
meillo@5
|
341 the wrapper script is just like a skin around.
|
meillo@5
|
342 No complexity is added this way.
|
meillo@5
|
343 .PP
|
meillo@5
|
344 A wrapper script for finding the five largest entries in the current directory
|
meillo@5
|
345 could look like this:
|
meillo@5
|
346 .DS
|
meillo@5
|
347 .CW
|
meillo@5
|
348 #!/bin/sh
|
meillo@5
|
349 du -s * | sort -nr | sed 5q
|
meillo@5
|
350 .DE
|
meillo@5
|
351 The script itself is just a text file that calls the command line
|
meillo@5
|
352 a professional user would type in directly.
|
meillo@5
|
353
|
meillo@5
|
354
|
meillo@5
|
355
|
meillo@0
|
356
|
meillo@4
|
357
|
meillo@0
|
358
|
meillo@0
|
359 .NH 2
|
meillo@5
|
360 foo
|
meillo@0
|
361 .LP
|
meillo@0
|
362 standalone vs. tool chain
|
meillo@0
|
363 .LP
|
meillo@0
|
364 software leverage
|
meillo@0
|
365 .LP
|
meillo@0
|
366 possiblities
|
meillo@0
|
367
|
meillo@0
|
368 .NH 2
|
meillo@0
|
369 Results
|
meillo@0
|
370 .LP
|
meillo@0
|
371 The unix phil is an answer to the sw design question
|
meillo@0
|
372 .LP
|
meillo@0
|
373 tool chains empower the uses of sw
|
meillo@0
|
374
|
meillo@0
|
375 .NH 1
|
meillo@0
|
376 Case study: nmh
|
meillo@0
|
377
|
meillo@0
|
378 .NH 2
|
meillo@0
|
379 History
|
meillo@0
|
380 .LP
|
meillo@0
|
381 MH, nmh.
|
meillo@0
|
382 They are old.
|
meillo@0
|
383
|
meillo@0
|
384 .NH 2
|
meillo@0
|
385 Contrasts to similar sw
|
meillo@0
|
386 .LP
|
meillo@0
|
387 vs. Thunderbird, mutt, mailx, pine
|
meillo@0
|
388 .LP
|
meillo@0
|
389 flexibility, no redundancy, use the shell
|
meillo@0
|
390
|
meillo@0
|
391 .NH 2
|
meillo@0
|
392 Gains of the design
|
meillo@0
|
393 .LP
|
meillo@0
|
394
|
meillo@0
|
395 .NH 2
|
meillo@0
|
396 Problems
|
meillo@0
|
397 .LP
|
meillo@0
|
398
|
meillo@0
|
399 .NH 1
|
meillo@0
|
400 Case study: uzbl
|
meillo@0
|
401
|
meillo@0
|
402 .NH 2
|
meillo@0
|
403 History
|
meillo@0
|
404 .LP
|
meillo@0
|
405 uzbl is young
|
meillo@0
|
406
|
meillo@0
|
407 .NH 2
|
meillo@0
|
408 Contrasts to similar sw
|
meillo@0
|
409 .LP
|
meillo@0
|
410 like with nmh
|
meillo@0
|
411 .LP
|
meillo@0
|
412 addons, plugins, modules
|
meillo@0
|
413
|
meillo@0
|
414 .NH 2
|
meillo@0
|
415 Gains of the design
|
meillo@0
|
416 .LP
|
meillo@0
|
417
|
meillo@0
|
418 .NH 2
|
meillo@0
|
419 Problems
|
meillo@0
|
420 .LP
|
meillo@0
|
421 broken web
|
meillo@0
|
422
|
meillo@0
|
423 .NH 1
|
meillo@0
|
424 Final thoughts
|
meillo@0
|
425
|
meillo@0
|
426 .NH 2
|
meillo@0
|
427 Quick summary
|
meillo@0
|
428 .LP
|
meillo@0
|
429 good design
|
meillo@0
|
430 .LP
|
meillo@0
|
431 unix phil
|
meillo@0
|
432 .LP
|
meillo@0
|
433 case studies
|
meillo@0
|
434
|
meillo@0
|
435 .NH 2
|
meillo@0
|
436 Why people should choose
|
meillo@0
|
437 .LP
|
meillo@0
|
438 Make the right choice!
|
meillo@0
|
439
|
meillo@0
|
440 .nr PI .5i
|
meillo@0
|
441 .rm ]<
|
meillo@0
|
442 .de ]<
|
meillo@0
|
443 .LP
|
meillo@0
|
444 .de FP
|
meillo@0
|
445 .IP \\\\$1.
|
meillo@0
|
446 \\..
|
meillo@0
|
447 .rm FS FE
|
meillo@0
|
448 ..
|
meillo@0
|
449 .SH
|
meillo@0
|
450 References
|
meillo@0
|
451 .[
|
meillo@0
|
452 $LIST$
|
meillo@0
|
453 .]
|
meillo@0
|
454 .wh -1p
|