docs/unix-phil
view unix-phil.ms @ 48:40caeb9e9b25
switched to new header macro; cleaned up CW
| author | meillo@marmaro.de |
|---|---|
| date | Mon, 12 Apr 2010 14:45:29 +0200 |
| parents | b6ae4a8ab1d3 |
| children | 2f188a5dc0dc |
line source
1 .nr PS 11
2 .nr VS 13
4 .de CW
5 .nr PQ \\n(.f
6 .if t \{\
7 . ft CW
8 . if !^\\$1^^ \&\\$1\f\\n(PQ\\$2
9 .\}
10 .if n \{\
11 . ie ^\\$1^^ .ul 999
12 . el .ul 1
13 . if \\n(.$=1 \&\\$1
14 . if \\n(.$>1 \&\\$1\c
15 . if \\n(.$>1 \&\\$2
16 .\}
17 ..
19 .ds [. \ [
20 .ds .] ]
22 .de H
23 .if '\\$1'1' \{\
24 . sp 2v
25 . nr PS +2
26 . NH \\$1
27 \\$2
28 . nr PS -2
29 . LP
30 . XS
31 . sp .5v
32 . B
33 \\*(SN \\$2
34 . XE
35 .\}
36 .if '\\$1'2' \{\
37 . NH \\$1
38 \\$2
39 . LP
40 . XS
41 \\*(SN \\$2
42 . XE
43 .\}
44 ..
46 .am QP
47 .ps -1
48 ..
50 .am DS
51 .CW
52 .ps -1
53 ..
55 .\"----------------------------------------
57 .TL
58 .ps +4
59 Why the Unix Philosophy still matters
60 .AU
61 markus schnalke <meillo@marmaro.de>
62 .AB
63 .ti \n(.iu
64 This paper explains the importance of the Unix Philosophy for software design.
65 Today, few software designers are aware of these concepts,
66 and thus a lot of modern software is more limited than necessary
67 and makes less use of software leverage than possible.
68 Knowing and following the guidelines of the Unix Philosophy makes software more valuable.
69 .AE
71 .FS
72 .ps -1
73 This paper was prepared for the ``Software Analysis'' seminar at University Ulm.
74 Mentor was professor Franz Schweiggert.
75 Handed in on 2010-04-12.
76 You may retrieve this document from
77 .CW \s-1http://marmaro.de/docs \ .
78 .FE
80 .H 1 Introduction
81 .LP
82 The Unix Philosophy is the essence of how the Unix operating system,
83 especially its toolchest, was designed.
84 It is no limited set of fixed rules,
85 but a loose set of guidelines which tell how to write software that
86 suites well into Unix.
87 Actually, the Unix Philosophy describes what is common to typical Unix software.
88 The Wikipedia has an accurate definition:
89 .[
90 wikipedia
91 unix philosophy
92 .]
93 .QP
94 The \fIUnix philosophy\fP is a set of cultural norms and philosophical
95 approaches to developing software based on the experience of leading
96 developers of the Unix operating system.
97 .PP
98 As there is no single definition of the Unix Philosophy,
99 several people have stated their view on what it comprises.
100 Best known are:
101 .IP \(bu
102 Doug McIlroy's summary: ``Write programs that do one thing and do it well.''
103 .[
104 mahoney
105 oral history
106 .]
107 .IP \(bu
108 Mike Gancarz' book ``The UNIX Philosophy''.
109 .[
110 gancarz
111 unix philosophy
112 .]
113 .IP \(bu
114 Eric S. Raymond's book ``The Art of UNIX Programming''.
115 .[
116 raymond
117 art of unix programming
118 .]
119 .LP
120 These different views on the Unix Philosophy have much in common.
121 Especially, the main concepts are similar in all of them.
122 McIlroy's definition can surely be called the core of the Unix Philosophy,
123 but the fundamental idea behind it all, is ``small is beautiful''.
125 .PP
126 The Unix Philosophy explains how to design good software for Unix.
127 Many concepts described here, base on facilities of Unix.
128 Other operating systems may not offer such facilities,
129 hence it may not be possible to design software in the way of the
130 Unix Philosophy for them.
131 .PP
132 The Unix Philosophy has an idea of how the process of software development
133 should look like, but large parts of the philosophy are quite independent
134 from a concrete development process.
135 However, one will soon recognize that some development processes work well
136 with the ideas of the Unix Philosophy and support them, while others are
137 at cross-purposes.
138 Kent Beck's books about Extreme Programming are valuable supplemental
139 resources on this topic.
140 .PP
141 The question of how to actually write code and how the code should looks
142 like in detail, are out of focus here.
143 ``The Practice of Programming'' by Kernighan and Pike,
144 .[
145 kernighan pike
146 practice of programming
147 .]
148 is a good book that covers this topic.
149 Its point of view matches to the one of this paper.
151 .H 1 "Importance of software design in general
152 .LP
153 Software design is the planning of how the internal structure
154 and external interfaces of a software should look like.
155 It has nothing to do with visual appearance.
156 If we take a program as a car, then its color is of no matter.
157 Its design would be the car's size, its shape, the locations of doors,
158 the passenger/space ratio, the available controls and instruments,
159 and so forth.
160 .PP
161 Why should software get designed at all?
162 It is general knowledge, that even a bad plan is better than no plan.
163 Not designing software means programming without plan.
164 This will pretty sure lead to horrible results.
165 Software that is horrible to use and horrible to maintain.
166 These two aspects are the visible ones.
167 Often invisible though, are the wasted possible gains.
168 Good software design can make these gains available.
169 .PP
170 A software's design deals with quality properties.
171 Good design leads to good quality, and quality is important.
172 Any car may be able to drive from A to B,
173 but it depends on the car's properties whether it is a good choice
174 for passenger transport or not.
175 It depends on its properties if it is a good choice
176 for a rough mountain area.
177 And it depends on its properties if the ride will be fun.
179 .PP
180 Requirements for a software are twofold:
181 functional and non-functional.
182 .IP \(bu
183 Functional requirements define directly the software's functions.
184 They are the reason why software gets written.
185 Someone has a problem and needs a tool to solve it.
186 Being able to solve the problem is the main functional goal.
187 It is the driving force behind all programming effort.
188 Functional requirements are easier to define and to verify.
189 .IP \(bu
190 Non-functional requirements are called \fIquality\fP requirements, too.
191 The quality of a software are the properties that are not directly related to
192 the software's basic functions.
193 Tools of bad quality often do solve the problems they were written for,
194 but introduce problems and difficulties for usage and development, later on.
195 Quality aspects are often overlooked at first sight,
196 and are often difficult to define clearly and to verify.
197 .PP
198 Quality is hardly interesting when the software gets built initially,
199 but it has a high impact on usability and maintenance of the software, later.
200 A short-sighted might see in developing a software, mainly building something up.
201 But experience shows, that building the software the first time is
202 only a small amount of the overall work.
203 Bug fixing, extending, rebuilding of parts \(en maintenance work \(en
204 does soon take over the major part of the time spent on a software.
205 And of course, the time spent actually using the software.
206 These processes are highly influenced by the software's quality.
207 Thus, quality must not be neglected.
208 However, the problem with quality is that you hardly ``stumble over''
209 bad quality during the first build,
210 although this is the time when you should care about good quality most.
211 .PP
212 Software design has little to do with the basic function of a software \(en
213 this requirement will get satisfied anyway.
214 Software design is more about quality aspects of the software.
215 Good design leads to good quality, bad design to bad quality.
216 The primary functions of the software will be affected modestly by bad quality,
217 but good quality can provide a lot of additional gain,
218 even at places where one never expected it.
219 .PP
220 The ISO/IEC\|9126-1 standard, part\|1,
221 .[
222 iso product quality
223 .]
224 defines the quality model as consisting out of:
225 .IP \(bu
226 .I Functionality
227 (suitability, accuracy, inter\%operability, security)
228 .IP \(bu
229 .I Reliability
230 (maturity, fault tolerance, recoverability)
231 .IP \(bu
232 .I Usability
233 (understandability, learnability, operability, attractiveness)
234 .IP \(bu
235 .I Efficiency
236 (time behavior, resource utilization)
237 .IP \(bu
238 .I Maintainability
239 (analyzability, changeability, stability, testability)
240 .IP \(bu
241 .I Portability
242 (adaptability, installability, co-existence, replaceability)
243 .LP
244 Good design can improve these properties of a software,
245 bad designed software likely suffers in these points.
246 .PP
247 One further goal of software design is consistency.
248 Consistency eases understanding, working on, and using things.
249 Consistent internal structure and consistent interfaces to the outside
250 can be provided by good design.
251 .PP
252 Software should be well designed because good design avoids many
253 problems during a software's lifetime.
254 And software should be well designed because good design can offer
255 much additional gain.
256 Indeed, much effort should be spent into good design to make software more valuable.
257 The Unix Philosophy shows a way of how to design software well.
258 It offers guidelines to achieve good quality and high gain for the effort spent.
261 .H 1 "The Unix Philosophy
262 .LP
263 The origins of the Unix Philosophy were already introduced.
264 This chapter explains the philosophy, oriented on Gancarz,
265 and shows concrete examples of its application.
267 .H 2 Pipes
268 .LP
269 Following are some examples to demonstrate how applied Unix Philosophy feels like.
270 Knowledge of using the Unix shell is assumed.
271 .PP
272 Counting the number of files in the current directory:
273 .DS
274 ls | wc -l
275 .DE
276 The
277 .CW ls
278 command lists all files in the current directory, one per line,
279 and
280 .CW "wc -l
281 counts the number of lines.
282 .PP
283 Counting the number of files that do not contain ``foo'' in their name:
284 .DS
285 ls | grep -v foo | wc -l
286 .DE
287 Here, the list of files is filtered by
288 .CW grep
289 to remove all lines that contain ``foo''.
290 The rest equals the previous example.
291 .PP
292 Finding the five largest entries in the current directory.
293 .DS
294 du -s * | sort -nr | sed 5q
295 .DE
296 .CW "du -s *
297 returns the recursively summed sizes of all files in the current directory
298 \(en no matter if they are regular files or directories.
299 .CW "sort -nr
300 sorts the list numerically in reverse order (descending).
301 Finally,
302 .CW "sed 5q
303 quits after it has printed the fifth line.
304 .PP
305 The presented command lines are examples of what Unix people would use
306 to get the desired output.
307 There are also other ways to get the same output.
308 It's a user's decision which way to go.
309 .PP
310 The examples show that many tasks on a Unix system
311 are accomplished by combining several small programs.
312 The connection between the single programs is denoted by the pipe operator `|'.
313 .PP
314 Pipes, and their extensive and easy use, are one of the great
315 achievements of the Unix system.
316 Pipes between programs have been possible in earlier operating systems,
317 but it has never been a so central part of the concept.
318 When, in the early seventies, Doug McIlroy introduced pipes into the
319 Unix system,
320 ``it was this concept and notation for linking several programs together
321 that transformed Unix from a basic file-sharing system to an entirely new way of computing.''
322 .[
323 aughenbaugh
324 unix oral history
325 .]
326 .PP
327 Being able to specify pipelines in an easy way is,
328 however, not enough by itself.
329 It is only one half.
330 The other is the design of the programs that are used in the pipeline.
331 They need interfaces that allow them to be used in such a way.
333 .H 2 "Interface design
334 .LP
335 Unix is, first of all, simple \(en Everything is a file.
336 Files are sequences of bytes, without any special structure.
337 Programs should be filters, which read a stream of bytes from standard input (stdin)
338 and write a stream of bytes to standard output (stdout).
339 If the files \fIare\fP sequences of bytes,
340 and the programs \fIare\fP filters on byte streams,
341 then there is exactly one data interface.
342 Hence it is possible to combine programs in any desired way.
343 .PP
344 Even a handful of small programs yields a large set of combinations,
345 and thus a large set of different functions.
346 This is leverage!
347 If the programs are orthogonal to each other \(en the best case \(en
348 then the set of different functions is greatest.
349 .PP
350 Programs can also have a separate control interface,
351 besides their data interface.
352 The control interface is often called ``user interface'',
353 because it is usually designed to be used by humans.
354 The Unix Philosophy discourages to assume the user to be human.
355 Interactive use of software is slow use of software,
356 because the program waits for user input most of the time.
357 Interactive software requires the user to be in front of the computer.
358 Interactive software occupy the user's attention while they are running.
359 .PP
360 Now to come back to the idea of combining several small programs,
361 to have a more specific function.
362 If these single tools would all be interactive,
363 how would the user control them?
364 It is not only a problem to control several programs at once,
365 if they run at the same time,
366 it also very inefficient to have to control each of the single programs
367 that are intended to act as one large program.
368 Hence, the Unix Philosophy discourages programs to demand interactive use.
369 The behavior of programs should be defined at invocation.
370 This is done by specifying arguments to the program call
371 (command line switches).
372 Gancarz discusses this topic as ``avoid captive user interfaces''.
373 .[ [
374 gancarz unix philosophy
375 .], page 88 ff.]
376 .PP
377 Non-interactive use is, during development, also an advantage for testing.
378 Testing of interactive programs is much more complicated,
379 than testing of non-interactive programs.
381 .H 2 "The toolchest approach
382 .LP
383 A toolchest is a set of tools.
384 Instead of having one big tool for all tasks, one has many small tools,
385 each for one task.
386 Difficult tasks are solved by combining several of the small, simple tools.
387 .PP
388 The Unix toolchest \fIis\fP a set of small, (mostly) non-interactive programs
389 that are filters on byte streams.
390 They are, to a large extend, unrelated in their function.
391 Hence, the Unix toolchest provides a large set of functions
392 that can be accessed by combining the programs in the desired way.
393 .PP
394 There are also advantages for developing small toolchest programs.
395 It is easier and less error-prone to write small programs.
396 It is also easier and less error-prone to write a large set of small programs,
397 than to write one large program with all the functionality included.
398 If the small programs are combinable, then they offer even a larger set
399 of functions than the single large program.
400 Hence, one gets two advantages out of writing small, combinable programs:
401 They are easier to write and they offer a greater set of functions through
402 combination.
403 .PP
404 But there are also two main drawbacks of the toolchest approach.
405 First, one simple, standardized interface has to be sufficient.
406 If one feels the need for more ``logic'' than a stream of bytes,
407 then a different approach might be of need.
408 But it is also possible, that he just can not imagine a design where
409 a stream of bytes is sufficient.
410 By becoming more familiar with the ``Unix style of thinking'',
411 developers will more often and easier find simple designs where
412 a stream of bytes is a sufficient interface.
413 .PP
414 The second drawback of a toolchest affects the users.
415 A toolchest is often more difficult to use.
416 It is necessary to become familiar with each of the tools,
417 to be able to use the right one in a given situation.
418 Additionally, one needs to combine the tools in a senseful way himself.
419 This is like a sharp knife \(en it is a powerful tool in the hand of a
420 master, but of no good value in the hand of an unskilled.
421 However, learning single, small tools of a toolchest is easier than
422 learning a complex tool.
423 And the user will already have a basic understanding of a yet unknown tool,
424 if the tools of a toolchest have a common, consistent style.
425 He will be able to transfer knowledge over from one tool to another.
426 .PP
427 Moreover, the second drawback can be removed to a large extend
428 by adding wrappers around the basic tools.
429 Novice users do not need to learn several tools, if a professional wraps
430 complete command lines into a higher-level script.
431 Note that the wrapper script still calls the small tools;
432 it is just like a skin around them.
433 No complexity is added this way.
434 But new programs can get created out of existing one with very low effort.
435 .PP
436 A wrapper script for finding the five largest entries in the current directory
437 could look like this:
438 .DS
439 #!/bin/sh
440 du -s * | sort -nr | sed 5q
441 .DE
442 The script itself is just a text file that calls the command line,
443 which a professional user would type in directly.
444 It is probably worth to make the program flexible on the number of
445 entries it prints:
446 .DS
447 #!/bin/sh
448 num=5
449 [ $# -eq 1 ] && num="$1"
450 du -sh * | sort -nr | sed "${num}q"
451 .DE
452 This script acts like the one before, when called without an argument.
453 But one can also specify a numerical argument to define the number of lines to print.
454 One can surely imagine even more flexible versions, however,
455 they will still relay on the external programs,
456 which do the actual work.
458 .H 2 "A powerful shell
459 .LP
460 The Unix shell provides the possibility to combine small programs into large ones.
461 But a powerful shell is a great feature in other ways, too.
462 For instance by being scriptable.
463 Control statements are build into the shell.
464 The functions, however, are the normal programs of the system.
465 Thus, as the programs are already known,
466 learning to program in the shell becomes easy.
467 Using normal programs as functions in the shell programming language
468 is only possible because they are small and combinable tools in a toolchest style.
469 .PP
470 The Unix shell encourages to write small scripts,
471 by combining existing programs, because it is so easy to do.
472 This is a great step towards automation.
473 It is wonderful if the effort to automate a task equals the effort
474 to do the task a second time by hand.
475 If this holds,
476 then the user will be happy to automate everything he does more than once.
477 .PP
478 Small programs that do one job well, standardized interfaces between them,
479 a mechanism to combine parts to larger parts, and an easy way to automate tasks,
480 this will inevitably produce software leverage.
481 Getting multiple times the benefit of an investment is a great offer.
482 .PP
483 The shell also encourages rapid prototyping.
484 Many well known programs started as quickly hacked shell scripts,
485 and turned into ``real'' programs, written in C, later.
486 Building a prototype first, is a way to avoid the biggest problems
487 in application development.
488 Fred Brooks explains in ``No Silver Bullet'':
489 .[
490 brooks
491 no silver bullet
492 .]
493 .QP
494 The hardest single part of building a software system is deciding precisely what to build.
495 No other part of the conceptual work is so difficult as establishing the detailed
496 technical requirements, [...].
497 No other part of the work so cripples the resulting system if done wrong.
498 No other part is more difficult to rectify later.
499 .PP
500 Writing a prototype is a great method for becoming familiar with the requirements
501 and to run into real problems early.
502 .[ [
503 gancarz
504 unix philosophy
505 .], page 28 f.]
506 .PP
507 Prototyping is often seen as a first step in building a software.
508 This is, of course, good.
509 However, the Unix Philosophy has an \fIadditional\fP perspective on prototyping:
510 After having built the prototype, one might notice, that the prototype is already
511 \fIgood enough\fP.
512 Hence, no reimplementation, in a more sophisticated programming language,
513 might be of need, at least for the moment.
514 Maybe later, it might be necessary to rewrite the software, but not now.
515 By delaying further work, one keeps the flexibility to react on
516 changing requirements.
517 Software parts that are not written will not miss the requirements.
519 .H 2 "Worse is better
520 .LP
521 The Unix Philosophy aims for the 90% solution;
522 others call it the ``Worse is better'' approach.
523 Experience from real life projects shows:
524 .PP
525 (1) It is almost never possible to define the
526 requirements completely and correctly the first time.
527 Hence one should not try to; one will fail anyway.
528 .PP
529 (2) Requirements change during time.
530 Hence it is best to delay requirement-based design decisions as long as possible.
531 The software should be small and flexible as long as possible
532 to react on changing requirements.
533 Shell scripts, for example, are more easily adjusted as C programs.
534 .PP
535 (3) Maintenance work is hard work.
536 Hence, one should keep the amount of code as small as possible;
537 it should just fulfill the \fIcurrent\fP requirements.
538 Software parts that will be written in future,
539 do not need maintenance till then.
540 .PP
541 See Brooks' ``The Mythical Man-Month'' for reference.
542 .[ [
543 brooks
544 mythical man-month
545 .], page 115 ff.]
546 .PP
547 Starting with a prototype in a scripting language has several advantages:
548 .IP \(bu
549 As the initial effort is low, one will likely start right away.
550 .IP \(bu
551 As working parts are available soon, the real requirements can get identified soon.
552 .IP \(bu
553 When a software is usable and valuable, it gets used, and thus tested.
554 Hence problems will be found at early stages of the development.
555 .IP \(bu
556 The prototype might be enough for the moment,
557 thus further work on the software can get delayed to a time
558 when one knows better about the requirements and problems,
559 than now.
560 .IP \(bu
561 Implementing now only the parts that are actually needed at the moment,
562 introduces fewer programming and maintenance work.
563 .IP \(bu
564 If the global situation changes so that the software is not needed anymore,
565 then less effort was spent into the project, than it would have be
566 when a different approach had been used.
568 .H 2 "Upgrowth and survival of software
569 .LP
570 So far it was talked about \fIwriting\fP or \fIbuilding\fP software.
571 Although these are just verbs, they do imply a specific view on the work process
572 they describe.
573 The better verb, however, is to \fIgrow\fP.
574 Creating software in the sense of the Unix Philosophy is an incremental process.
575 It starts with a first prototype, which evolves as requirements change.
576 A quickly hacked shell script might become a large, sophisticated,
577 compiled program this way.
578 Its lifetime begins with the initial prototype and ends when the software is not used anymore.
579 While being alive it will get extended, rearranged, rebuilt.
580 Growing software matches the view that ``software is never finished. It is only released.''
581 .[ [
582 gancarz
583 unix philosophy
584 .], page 26]
585 .PP
586 Software can be seen as being controlled by evolutionary processes.
587 Successful software is software that is used by many for a long time.
588 This implies that the software is needed, useful, and better than alternatives.
589 Darwin talks about: ``The survival of the fittest.''
590 .[
591 darwin
592 origin of species
593 .]
594 Transferred to software: The most successful software, is the fittest,
595 is the one that survives.
596 (This may be at the level of one creature, or at the level of one species.)
597 The fitness of software is affected mainly by four properties:
598 portability of code, portability of data, range of usability, and reusability of parts.
599 .PP
600 (1)
601 .I "Portability of code
602 means, using high-level programming languages,
603 sticking to the standard,
604 .[ [
605 kernighan pike
606 practice of programming
607 .], chapter\|8]
608 and avoiding optimizations that introduce dependencies on specific hardware.
609 Hardware has a much lower lifetime than software.
610 By chaining software to a specific hardware,
611 the software's lifetime gets shortened to that of this hardware.
612 In contrast, software should be easy to port \(en
613 adaptation is the key to success.
614 .PP
615 (2)
616 .I "Portability of data
617 is best achieved by avoiding binary representations
618 to store data, because binary representations differ from machine to machine.
619 Textual representation is favored.
620 Historically, \s-1ASCII\s0 was the charset of choice.
621 For the future, \s-1UTF\s0-8 might be the better choice.
622 Important is that it is a plain text representation in a
623 very common charset encoding.
624 Apart from being able to transfer data between machines,
625 readable data has the great advantage, that humans are able to directly
626 read and edit it with text editors and other tools from the Unix toolchest.
627 .[ [
628 gancarz
629 unix philosophy
630 .], page 56 ff.]
631 .PP
632 (3)
633 A large
634 .I "range of usability
635 ensures good adaptation, and thus good survival.
636 It is a special distinction if a software becomes used in fields of action,
637 the original authors did never imagine.
638 Software that solves problems in a general way will likely be used
639 for many kinds of similar problems.
640 Being too specific limits the range of usability.
641 Requirements change through time, thus use cases change or even vanish.
642 As a good example in this point,
643 Allman identifies flexibility to be one major reason for sendmail's success:
644 .[
645 allman
646 sendmail
647 .]
648 .QP
649 Second, I limited myself to the routing function [...].
650 This was a departure from the dominant thought of the time, [...].
651 .QP
652 Third, the sendmail configuration file was flexible enough to adapt
653 to a rapidly changing world [...].
654 .LP
655 Successful software adapts itself to the changing world.
656 .PP
657 (4)
658 .I "Reuse of parts
659 is even one step further.
660 A software may completely lose its field of action,
661 but parts of which the software is build may be general and independent enough
662 to survive this death.
663 If software is build by combining small independent programs,
664 then these parts are readily available for reuse.
665 Who cares if the large program is a failure,
666 but parts of it become successful instead?
668 .H 2 "Summary
669 .LP
670 This chapter explained central ideas of the Unix Philosophy.
671 For each of the ideas, the advantages they introduce were explained.
672 The Unix Philosophy are guidelines that help to write more valuable software.
673 From the view point of a software developer or software designer,
674 the Unix Philosophy provides answers to many software design problem.
675 .PP
676 The various ideas of the Unix Philosophy are very interweaved
677 and can hardly be applied independently.
678 However, the probably most important messages are:
679 .I "``Keep it simple!''" ,
680 .I "``Do one thing well!''" ,
681 and
682 .I "``Use software leverage!''
686 .H 1 "Case study: \s-1MH\s0
687 .LP
688 The previous chapter introduced and explained the Unix Philosophy
689 from a general point of view.
690 The driving force were the guidelines; references to
691 existing software were given only sparsely.
692 In this and the next chapter, concrete software will be
693 the driving force in the discussion.
694 .PP
695 This first case study is about the mail user agents (\s-1MUA\s0)
696 \s-1MH\s0 (``mail handler'') and its descendent \fInmh\fP
697 (``new mail handler'').
698 .[
699 nmh website
700 .]
701 \s-1MUA\s0s provide functions to read, compose, and organize mail,
702 but (ideally) not to transfer it.
703 In this document, the name \s-1MH\s0 will be used to include nmh.
704 A distinction will only be made if differences between
705 \s-1MH\s0 and nmh are described.
708 .H 2 "Historical background
709 .LP
710 Electronic mail was available in Unix very early.
711 The first \s-1MUA\s0 on Unix was \f(CWmail\fP,
712 which was already present in the First Edition.
713 .[ [
714 salus
715 quarter century of unix
716 .], page 41 f.]
717 It was a small program that either printed the user's mailbox file
718 or appended text to someone elses mailbox file,
719 depending on the command line arguments.
720 .[
721 manual mail(1)
722 .]
723 It was a program that did one job well.
724 This job was emailing, which was very simple then.
725 .PP
726 Later, emailing became more powerful, and thus more complex.
727 The simple \f(CWmail\fP, which knew nothing of subjects,
728 independent handling of single messages,
729 and long-time email storage, was not powerful enough anymore.
730 In 1978 at Berkeley, Kurt Shoens wrote \fIMail\fP (with capital `M')
731 to provide additional functions for emailing.
732 Mail was still one program, but now it was large and did
733 several jobs.
734 Its user interface is modeled after the one of \fIed\fP.
735 It is designed for humans, but is still scriptable.
736 \fImailx\fP is the adaptation of Berkeley Mail into System V.
737 .[
738 ritter
739 mailx history
740 .]
741 Elm, pine, mutt, and a whole bunch of graphical \s-1MUA\s0s
742 followed Mail's direction.
743 They are large, monolithic programs which include all emailing functions.
744 .PP
745 A different way was taken by the people of \s-1RAND\s0 Corporation.
746 In the beginning, they also had used a monolithic mail system,
747 called \s-1MS\s0 (for ``mail system'').
748 But in 1977, Stockton Gaines and Norman Shapiro
749 came up with a proposal of a new email system concept \(en
750 one that honored the Unix Philosophy.
751 The concept was implemented by Bruce Borden in 1978 and 1979.
752 This was the birth of \s-1MH\s0 \(en the ``mail handler''.
753 .PP
754 Since then, \s-1RAND\s0, the University of California at Irvine and
755 at Berkeley, and several others have contributed to the software.
756 However, it's core concepts remained the same.
757 In the late 90s, when development of \s-1MH\s0 slowed down,
758 Richard Coleman started with \fInmh\fP, the new mail handler.
759 His goal was to improve \s-1MH\s0 especially in regard of
760 the requirements of modern emailing.
761 Today, nmh is developed by various people on the Internet.
762 .[
763 ware
764 rand history
765 .]
766 .[
767 peek
768 mh
769 .]
771 .H 2 "Contrasts to monolithic mail systems
772 .LP
773 All \s-1MUA\s0s are monolithic, except \s-1MH\s0.
774 Although there might actually exist further, very little known,
775 toolchest \s-1MUA\s0s, this statement reflects the situation pretty well.
776 .PP
777 Monolithic \s-1MUA\s0s gather all their functions in one program.
778 In contrast, \s-1MH\s0 is a toolchest of many small tools \(en one for each job.
779 Following is a list of important programs of \s-1MH\s0's toolchest
780 and their function.
781 It gives a feeling of how the toolchest looks like.
782 .IP \(bu
783 .CW inc :
784 incorporate new mail (this is how mail enters the system)
785 .IP \(bu
786 .CW scan :
787 list messages in folder
788 .IP \(bu
789 .CW show :
790 show message
791 .IP \(bu
792 .CW next\fR/\fPprev :
793 show next/previous message
794 .IP \(bu
795 .CW folder :
796 change current folder
797 .IP \(bu
798 .CW refile :
799 refile message into different folder
800 .IP \(bu
801 .CW rmm :
802 remove message
803 .IP \(bu
804 .CW comp :
805 compose new message
806 .IP \(bu
807 .CW repl :
808 reply to message
809 .IP \(bu
810 .CW forw :
811 forward message
812 .IP \(bu
813 .CW send :
814 send prepared message (this is how mail leaves the system)
815 .LP
816 \s-1MH\s0 has no special user interface like monolithic \s-1MUA\s0s have.
817 The user does not leave the shell to run \s-1MH\s0,
818 instead he uses the various \s-1MH\s0 programs within the shell.
819 Using a monolithic program with a captive user interface
820 means ``entering'' the program, using it, and ``exiting'' the program.
821 Using toolchests like \s-1MH\s0 means running programs,
822 alone or in combination with others, also from other toolchests,
823 without leaving the shell.
825 .H 2 "Data storage
826 .LP
827 \s-1MH\s0's mail storage is a directory tree under the user's
828 \s-1MH\s0 directory (usually \f(CW$HOME/Mail\fP),
829 where mail folders are directories and mail messages are text files
830 within them.
831 Each mail folder contains a file \f(CW.mh_sequences\fP which lists
832 the public message sequences of that folder,
833 for instance the \fIunseen\fP sequence for new messages.
834 Mail messages are text files located in a mail folder.
835 The files contain the messages as they were received.
836 They are named by ascending numbers in each folder.
837 .PP
838 This mailbox format is called ``\s-1MH\s0'' after the \s-1MUA\s0.
839 Alternatives are \fImbox\fP and \fImaildir\fP.
840 In the mbox format all messages are stored within one file.
841 This was a good solution in the early days, when messages
842 were only a few lines of text and were deleted soon.
843 Today, when single messages often include several megabytes
844 of attachments, it is a bad solution.
845 Another disadvantage of the mbox format is that it is
846 more difficult to write tools that work on mail messages,
847 because it is always necessary to first find and extract
848 the relevant message in the mbox file.
849 With the \s-1MH\s0 mailbox format, each message is a separate file.
850 Also, the problem of concurrent access to one mailbox is
851 reduced to the problem of concurrent access to one message.
852 The maildir format is generally similar to the \s-1MH\s0 format,
853 but modified towards guaranteed reliability.
854 This involves some complexity, unfortunately.
855 .PP
856 Working with \s-1MH\s0's toolchest on mailboxes is much like
857 working with Unix' toolchest on directory trees:
858 \f(CWscan\fP is like \f(CWls\fP,
859 \f(CWshow\fP is like \f(CWcat\fP,
860 \f(CWfolder\fP is like \f(CWcd\fP and \f(CWpwd\fP,
861 \f(CWrefile\fP is like \f(CWmv\fP,
862 and \f(CWrmm\fP is like \f(CWrm\fP.
863 .PP
864 \s-1MH\s0 extends the context of processes in Unix by two more items,
865 for its tools:
866 .IP \(bu
867 The current mail folder, which is similar to the current working directory.
868 For mail folders, \f(CWfolder\fP provides the corresponding functionality
869 of \f(CWcd\fP and \f(CWpwd\fP for directories.
870 .IP \(bu
871 Sequences, which are named sets of messages in a mail folder.
872 The current message, relative to a mail folder, is a special sequence.
873 It enables commands like \f(CWnext\fP and \f(CWprev\fP.
874 .LP
875 In contrast to Unix' context, which is maintained by the kernel,
876 \s-1MH\s0's context must be maintained by the tools themselves.
877 Usually there is one context per user, which resides in his
878 \f(CWcontext\fP file in the \s-1MH\s0 directory,
879 but a user can have several contexts, too.
880 Public sequences are an exception, as they belong to a mail folder,
881 and reside in the \f(CW.mh_sequences\fP file there.
882 .[
883 man page mh-profile mh-sequence
884 .]
886 .H 2 "Discussion of the design
887 .LP
888 This section discusses \s-1MH\s0 in regard to the tenets
889 of the Unix Philosophy that Gancarz identified.
891 .PP
892 .B "Small is beautiful
893 and
894 .B "do one thing well
895 are two design goals that are directly visible in \s-1MH\s0.
896 Gancarz actually presents \s-1MH\s0 in his book as example under the
897 headline ``Making \s-1UNIX\s0 Do One Thing Well'':
898 .[ [
899 gancarz
900 unix philosophy
901 .], page 125 ff.]
902 .QP
903 [\s-1MH\s0] consists of a series of programs which
904 when combined give the user an enormous ability
905 to manipulate electronic mail messages.
906 A complex application, it shows that not only is it
907 possible to build large applications from smaller
908 components, but also that such designs are actually preferable.
909 .LP
910 The various programs of \s-1MH\s0 were relatively easy to write,
911 because each of them is small, limited to one function,
912 and has clear boundaries.
913 For the same reasons, they are also good to maintain.
914 Further more, the system can easily get extended.
915 One only needs to put a new program into the toolchest.
916 This was done, for instance, when \s-1MIME\s0 support was added
917 (e.g. \f(CWmhbuild\fP).
918 Also, different programs can exist to do the basically same job
919 in different ways (e.g. in nmh: \f(CWshow\fP and \f(CWmhshow\fP).
920 .PP
921 If someone needs a mail system with some additionally
922 functions that are not available anywhere yet, he best expands a
923 toolchest system like \s-1MH\s0.
924 There he can add new functionality by simply adding additional
925 programs to the toolchest.
926 There he does not risk to break existing functionality by doing so.
928 .PP
929 .B "Store data in flat text files
930 is followed by \s-1MH\s0.
931 This is not surprising, because email messages are already plain text.
932 \s-1MH\s0 stores the messages as it receives them,
933 thus any other tool that works on \s-1RFC\s0\|2822 mail messages can operate
934 on the messages in an \s-1MH\s0 mailbox.
935 All other files \s-1MH\s0 uses are plain text, too.
936 It is therefore possible and encouraged to use the text processing
937 tools of Unix' toolchest to extend \s-1MH\s0's toolchest.
939 .PP
940 .B "Avoid captive user interfaces" .
941 \s-1MH\s0 is perfectly suited for non-interactive use.
942 It offers all functions directly and without captive user interfaces.
943 If, nonetheless, users want a graphical user interface,
944 they can have it with \fIxmh\fP or \fIexmh\fP.
945 These are graphical frontends for the \s-1MH\s0 toolchest.
946 This means, all email-related work is still done by \s-1MH\s0 tools,
947 but the frontend calls the appropriate commands when the user
948 clicks on buttons.
949 .PP
950 Providing easy-to-use user interfaces in form of frontends is a good
951 approach, because it does not limit the power of the backend itself.
952 The frontend will anyway only be able to make a subset of the
953 backend's power and flexibility available to the user.
954 But if it is a separate program,
955 then the missing parts can still be accessed at the backend directly.
956 If it is integrated, then this will hardly be possible.
957 An additional advantage is the possibility to have different frontends
958 to the same backend.
960 .PP
961 .B "Choose portability over efficiency
962 and
963 .B "use shell scripts to increase leverage and portability" .
964 These two tenets are indirectly, but nicely, demonstrated by
965 Bolsky and Korn in their book about the Korn Shell.
966 .[
967 bolsky korn
968 korn shell
969 .]
970 Chapter\|18 of the book shows a basic implementation
971 of a subset of \s-1MH\s0 in ksh scripts.
972 Of course, this is just a demonstration, but a brilliant one.
973 It shows how quickly one can implement such a prototype with shell scripts,
974 and how readable they are.
975 The implementation in the scripting language may not be very fast,
976 but it can be fast enough though, and this is all that matters.
977 By having the code in an interpreted language, like the shell,
978 portability becomes a minor issue, if we assume the interpreter
979 to be widespread.
980 .PP
981 This demonstration also shows how easy it is to create single programs
982 of a toolchest software.
983 Eight tools (two of them have multiple names) and 16 functions
984 with supporting code are presented to the reader.
985 The tools comprise less than 40 lines of ksh each,
986 in total about 200 lines.
987 The functions comprise less than 80 lines of ksh each,
988 in total about 450 lines.
989 Such small software is easy to write, easy to understand,
990 and thus easy to maintain.
991 A toolchest improves the possibility to only write some parts
992 and though create a working result.
993 Expanding the toolchest, even without global changes,
994 will likely be possible.
996 .PP
997 .B "Use software leverage to your advantage
998 and the lesser tenet
999 .B "allow the user to tailor the environment
1000 are ideally followed in the design of \s-1MH\s0.
1001 Tailoring the environment is heavily encouraged by the ability to
1002 directly define default options to programs.
1003 It is even possible to define different default options
1004 depending on the name under which a program is called.
1005 Software leverage is heavily encouraged by the ease of
1006 creating shell scripts that run a specific command line,
1007 built of several \s-1MH\s0 programs.
1008 There is few software that so much wants users to tailor their
1009 environment and to leverage the use of the software, like \s-1MH\s0.
1010 .PP
1011 Just to make one example:
1012 One might prefer a different listing format for the \f(CWscan\fP
1013 program.
1014 It is possible to take one of the distributed format files
1015 or to write one yourself.
1016 To use the format as default for \f(CWscan\fP, a single line,
1017 reading
1018 .DS
1019 scan: -form FORMATFILE
1020 .DE
1021 must be added to \f(CW.mh_profile\fP.
1022 If one wants this different format as an additional command,
1023 instead of changing the default, he needs to create a link to
1024 \f(CWscan\fP, for instance titled \f(CWscan2\fP.
1025 The line in \f(CW.mh_profile\fP would then start with \f(CWscan2\fP,
1026 as the option should only be in effect for a program that is called as
1027 \f(CWscan2\fP.
1029 .PP
1030 .B "Make every program a filter
1031 is hard to find in \s-1MH\s0.
1032 The reason therefore is that most of \s-1MH\s0's tools provide
1033 basic file system operations for mailboxes.
1034 It is the same reason because of which \f(CWls\fP, \f(CWcp\fP, \f(CWmv\fP,
1035 and \f(CWrm\fP aren't filters neither.
1036 \s-1MH\s0 does not provide many filters itself, but it is a basis
1037 to write filters for.
1038 An example would be a mail text highlighter,
1039 that means a program that makes use of a color terminal to display
1040 header lines, quotations, and signatures in distinct colors.
1041 The author's version of such a program is an awk script with 25 lines.
1043 .PP
1044 .B "Build a prototype as soon as possible
1045 was again well followed by \s-1MH\s0.
1046 This tenet, of course, focuses on early development, which is
1047 long time ago for \s-1MH\s0.
1048 But without following this guideline at the very beginning,
1049 Bruce Borden may have not convinced the management of \s-1RAND\s0
1050 to ever create \s-1MH\s0.
1051 In Bruce' own words:
1052 .[ [
1053 ware rand history
1054 .], page 132]
1055 .QP
1056 [...] but [Stockton Gaines and Norm Shapiro] were not able
1057 to convince anyone that such a system would be fast enough to be usable.
1058 I proposed a very short project to prove the basic concepts,
1059 and my management agreed.
1060 Looking back, I realize that I had been very lucky with my first design.
1061 Without nearly enough design work,
1062 I built a working environment and some header files
1063 with key structures and wrote the first few \s-1MH\s0 commands:
1064 inc, show/next/prev, and comp.
1065 [...]
1066 With these three, I was able to convince people that the structure was viable.
1067 This took about three weeks.
1069 .H 2 "Problems
1070 .LP
1071 \s-1MH\s0 is not without problems.
1072 There are two main problems: one is technical, the other is about human behavior.
1073 .PP
1074 \s-1MH\s0 is old and email today is very different to email in the time
1075 when \s-1MH\s0 was designed.
1076 \s-1MH\s0 adapted to the changes pretty well, but it is limited, though.
1077 \s-1MIME\s0 support and support for different character encodings
1078 is available, but only on a moderate level.
1079 This comes from limited development resources.
1080 More active developers could quickly change this.
1081 But \s-1MH\s0 is also limited by design, which is the larger problem.
1082 \s-1IMAP\s0, for example, conflicts with \s-1MH\s0's design to a large extend.
1083 These design conflicts are not easily solvable.
1084 Possibly, they require a redesign.
1085 \s-1IMAP\s0 may be too different to the classic mail model,
1086 which \s-1MH\s0 covers, so that \s-1MH\s0 may never support it well.
1087 .PP
1088 The other kind of problem are human habits.
1089 In this world, where almost all \s-1MUA\s0s are monolithic,
1090 it is very difficult to convince people to use a toolbox style \s-1MUA\s0
1091 like \s-1MH\s0.
1092 The habits are so strong, that even people who understand the concept
1093 and advantages of \s-1MH\s0 do not like to switch,
1094 simply because \s-1MH\s0 is different.
1095 Unfortunately, the frontends to \s-1MH\s0, which could provide familiar look'n'feel,
1096 are quite outdated and thus not very appealing, compared to the modern interfaces
1097 of many monolithic \s-1MUA\s0s.
1099 NH 2 "Summary \s-1MH\s0
1100 .LP
1101 \s-1MH\s0 is an \s-1MUA\s0 that follows the Unix Philosophy in its design.
1102 It consists of a toolchest of small tools, each of them does one job well.
1103 The toolchest approach offers great flexibility to the user.
1104 It is possible to utilize the complete power of the Unix shell with \s-1MH\s0.
1105 This makes \s-1MH\s0 a very powerful mail system.
1106 Extending and customizing \s-1MH\s0 is easy and encouraged.
1107 .PP
1108 Apart from the user's perspective, \s-1MH\s0 is development-friendly.
1109 Its overall design follows clear rules.
1110 The single tools do only one job, thus they are easy to understand,
1111 easy to write, and good to maintain.
1112 They are all independent and do not interfere with the others.
1113 Automated testing of their function is a straight forward task.
1114 .PP
1115 It is sad, that \s-1MH\s0's differentness is its largest problem,
1116 as its differentness is also its largest advantage.
1117 Unfortunately, for most people their habits are stronger
1118 than the attraction of the clear design and the power, \s-1MH\s0 offers.
1122 .H 1 "Case study: uzbl
1123 .LP
1124 The last chapter took a look on the \s-1MUA\s0 \s-1MH\s0,
1125 which is an old and established software.
1126 This chapter covers uzbl, a fresh new project.
1127 Uzbl is a web browser that adheres to the Unix Philosophy.
1128 Its name comes from the \fILolspeak\fP word for ``usable'';
1129 it is pronounced identical.
1131 .H 2 "Historical background
1132 .LP
1133 Uzbl was started by Dieter Plaetinck in April 2009.
1134 The idea was born in a thread in the Arch Linux Forums.
1135 .[
1136 arch linux forums
1137 browser
1138 .]
1139 After some discussion about failures of well known web browsers,
1140 Plaetinck (alias Dieter@be) came up with a very sketchy proposal
1141 of how a better web browser could look like.
1142 To the question of another member, if Plaetinck would write that program,
1143 because it would sound fantastic, Plaetinck replied:
1144 ``Maybe, if I find the time ;-)''.
1145 .PP
1146 Fortunately, he found the time.
1147 One day later, the first prototype was out.
1148 One week later, uzbl had an own website.
1149 .[
1150 uzbl website
1151 .]
1152 One month after the first code showed up,
1153 a mailing list was installed to coordinate and discuss further development,
1154 and a wiki was added to store documentation and scripts that showed up on the
1155 mailing list and elsewhere.
1156 .PP
1157 In the, now, one year of uzbl's existence, it was heavily developed on various branches.
1158 Plaetinck's task became more and more to only merge the best code from the
1159 different branches into his main branch, and to apply patches.
1160 .[
1161 lwn uzbl
1162 .]
1163 About once a month, Plaetinck released a new version.
1164 In September 2009, he presented several forks of uzbl.
1165 .[ [
1166 uzbl website
1167 .], news archive]
1168 Uzbl, actually, opened the field for a whole family of web browsers with similar shape.
1169 .PP
1170 In July 2009, \fILinux Weekly News\fP published an interview with Plaetinck about uzbl.
1171 .[
1172 lwn uzbl
1173 .]
1174 In September 2009, the uzbl web browser was on \fISlashdot\fP.
1175 .[
1176 slashdot uzbl
1177 .]
1179 .H 2 "Contrasts to other web browsers
1180 .LP
1181 Like most \s-1MUA\s0s are monolithic, but \s-1MH\s0 is a toolchest,
1182 most web browsers are monolithic, but uzbl is a frontend to a toolchest.
1183 .PP
1184 Today, uzbl is divided into uzbl-core and uzbl-browser.
1185 Uzbl-core is, how its name already indicates, the core of uzbl.
1186 It handles commands and events to interface other programs,
1187 and also displays webpages by using \fIwebkit\fP as render engine.
1188 Uzbl-browser combines uzbl-core with a bunch of handler scripts, a status bar,
1189 an event manager, yanking, pasting, page searching, zooming, and more stuff,
1190 to form a ``complete'' web browser.
1191 In the following text, the term ``uzbl'' usually stands for uzbl-browser,
1192 so uzbl-core is included.
1193 .PP
1194 Unlike most other web browsers, uzbl is mainly the mediator between the
1195 various tools that cover single jobs.
1196 Therefore, uzbl listens for commands on a named pipe (fifo), a Unix socket,
1197 and on stdin, and it writes events to a Unix socket and to stdout.
1198 Loading a webpage in a running uzbl instance requires only:
1199 .DS
1200 echo 'uri http://example.org' >/path/to/uzbl-fifo
1201 .DE
1202 The graphical rendering of the webpage is done by webkit,
1203 a web content engine.
1204 Uzbl-core is built around libwebkit.
1205 .PP
1206 Downloads, browsing history, bookmarks, and the like are not provided
1207 by the core itself, like they are in other web browsers.
1208 Uzbl-browser also only provides, so called, handler scripts that wrap
1209 external applications which provide the actual functionality.
1210 For instance, \fIwget\fP is used to download files and uzbl-browser
1211 includes a script that calls wget with appropriate options in
1212 a prepared environment.
1213 .PP
1214 Modern web browsers are proud to have addons, plugins, and modules, instead.
1215 This is their effort to achieve similar goals.
1216 But instead of using existing, external programs, modern web browsers
1217 include these functions.
1219 .H 2 "Discussion of the design
1220 .LP
1221 This section discusses uzbl in regard of the Unix Philosophy,
1222 as identified by Gancarz.
1224 .PP
1225 .B "Make each program do one thing well" .
1226 Uzbl tries to be a web browser and nothing else.
1227 The common definition of a web browser is, of course, highly influenced by
1228 existing implementations of web browsers, although they are degenerated.
1229 Web browsers should be programs to browse the web, and nothing more.
1230 This is the one thing they should do.
1231 .PP
1232 Web browsers should not, for instance, manage downloads.
1233 This is the job download managers exist for.
1234 Download managers do primary care about being good in downloading files.
1235 Modern web browsers provide download management only as a secondary feature.
1236 How could they do this job better, than programs that exist only for
1237 this very job?
1238 And how could anyone want less than the best download manager available?
1239 .PP
1240 A web browser's job is to let the user browse the web.
1241 This means, navigating through websites by following links.
1242 Rendering the \s-1HTML\s0 sources is a different job, too.
1243 It is covered by the webkit render engine, in uzbl's case.
1244 Audio and video content and files like PostScript, \s-1PDF\s0, and the like,
1245 are also not the job of a web browser.
1246 They should be handled by external applications \(en
1247 ones which's job is to handle such data.
1248 Uzbl strives to do it this way.
1249 .PP
1250 Remember Doug McIlroy:
1251 .I
1252 ``Write programs that do one thing and do it well.
1253 Write programs to work together.''
1254 .R
1255 .PP
1256 The lesser tenet
1257 .B "allow the user to tailor the environment
1258 matches good here.
1259 There was the question, how anyone could want anything less than the
1260 best program for the job.
1261 But as personal preferences matter, it is probably more important to ask:
1262 How could anyone want something else than his preferred program for the job?
1263 .PP
1264 Usually users want one program for a specific job.
1265 Hence, whenever the task is, for instance, downloading,
1266 the same download manager should be used.
1267 More advanced users might want to have this download manager in this
1268 situation and that one in that situation.
1269 They should be able to configure it this way.
1270 With uzbl, one can use any download manager the user wants.
1271 To switch to a different one, only one line in a small handler script
1272 needs to be changed.
1273 Alternatively it would be possible to query the program to use by
1274 reading a global file or an environment variable, in the handler script.
1275 .PP
1276 Uzbl does neither have its own download manager nor depends on a
1277 specific one, hence uzbl's browsing abilities will not be lowered by having
1278 a bad download manager.
1279 Uzbl's download capabilities will be just as good as the ones of the best
1280 download manager available on the system.
1281 Of course, this applies to all of the other supplementary tools, too.
1283 .PP
1284 .B "Use software leverage to your advantage" .
1285 Uzbl is designed to be extended by external tools.
1286 These external tools are usually wrapped by small handler shell scripts.
1287 Shell scripts are the glue in this approach.
1288 They make the various parts fit together.
1289 .PP
1290 The history mechanism of uzbl shall be presented as an example.
1291 Uzbl is configured to spawn a script to append an entry to the history
1292 whenever the event of a fully loaded page occurs.
1293 The script to append the entry to the history is not much more than:
1294 .DS
1295 #!/bin/sh
1296 file=/path/to/uzbl-history
1297 echo `date +'%Y-%m-%d %H:%M:%S'`" $6 $7" >> $file
1298 .DE
1299 \f(CW$6\fP and \f(CW$7\fP expand to the \s-1URL\s0 and the page title.
1300 .PP
1301 For loading an entry, a key is bound to spawn a load-from-history script.
1302 The script reverses the history to have newer entries first,
1303 then displays \fIdmenu\fP to let the user select an item,
1304 and afterwards writes the selected \s-1URL\s0 into uzbl's command input pipe.
1305 With error checking and corner case handling removed,
1306 the script looks like this:
1307 .DS
1308 #!/bin/sh
1309 file=/path/to/uzbl-history
1310 goto=`tac $file | dmenu | cut -d' ' -f 3`
1311 echo "uri $goto" > $4
1312 .DE
1313 \f(CW$4\fP expands to the path of the command input pipe of the current
1314 uzbl instance.
1316 .PP
1317 .B "Avoid captive user interfaces" .
1318 One could say, that uzbl, to a large extend, actually \fIis\fP
1319 a captive user interface.
1320 But the difference to most other web browsers is, that uzbl is only
1321 the captive user interface frontend (and the core of the backend).
1322 Many parts of the backend are independent of uzbl.
1323 Some are distributed with uzbl, for some external programs,
1324 handler scripts are distributed,
1325 but arbitrary additional functionality can be added if desired.
1326 .PP
1327 The frontend is captive \(en that is true.
1328 This is okay for the task of browsing the web, as this task is only relevant
1329 for humans.
1330 Automated programs would \fIcrawl\fP the web.
1331 That means, they read the source directly.
1332 The source includes all the semantics.
1333 The graphical representation is just for humans to transfer the semantics
1334 more intuitively.
1336 .PP
1337 .B "Make every program a filter" .
1338 Graphical web browsers are almost dead ends in the chain of information flow.
1339 Thus it is difficult to see what graphical web browsers should filter.
1340 Graphical web browsers exist almost only to be interactively used by humans.
1341 The only case when one might want to automate the rendering function is
1342 to generate images of rendered webpages.
1344 .PP
1345 .B "Small is beautiful"
1346 is not easy to apply to a web browser, because modern web technology
1347 is very complex, hence the rendering task is very complex.
1348 Modern web browsers have to consist of many thousand lines of code,
1349 unfortunately.
1350 Using the toolchest approach and wrappers can split the browser into
1351 several small parts, tough.
1352 .PP
1353 As of March 2010, uzbl-core consists of about 3\,500 lines of C code.
1354 The distribution includes another 3\,500 lines of Shell and Python code,
1355 which are the handler scripts and plugins like a modal interface.
1356 Further more, uzbl uses functionality of external tools like
1357 \fIwget\fP and \fInetcat\fP.
1358 Up to this point, uzbl looks pretty neat and small.
1359 The ugly part of uzbl is the web content renderer, webkit.
1360 Webkit consists of roughly 400\,000 (!) lines of code.
1361 Unfortunately, small web render engines are not possible anymore
1362 because of the modern web.
1364 .PP
1365 .B "Build a prototype as soon as possible" .
1366 Plaetinck made his code public, right from the beginning.
1367 Discussion and development was, and still is, open to everyone interested.
1368 Development versions of uzbl can be obtained very simply from the code
1369 repository.
1370 Within the first year of uzbl's existence, a new version was released
1371 more often than once a month.
1372 Different forks and branches arose.
1373 They introduced new features, which were tested for suitability
1374 for the main branch.
1375 The experiences of using prototypes influenced further development.
1376 Actually, all development was community driven.
1377 Plaetinck says, three months after uzbl's birth:
1378 ``Right now I hardly code anything myself for Uzbl.
1379 I just merge in other people's code, ponder a lot, and lead the discussions.''
1380 .[
1381 lwn
1382 uzbl
1383 .]
1386 .H 2 "Problems
1387 .LP
1388 Similar to \s-1MH\s0, uzbl, too suffers from being different.
1389 It is sad, but people use what they know.
1390 Fortunately, uzbl's user interface can look and feel very much the
1391 same as the one of the well known web browsers,
1392 hiding the internal differences.
1393 But uzbl has to provide this similar look and feel to be accepted
1394 as a ``normal'' browser by ``normal'' users.
1395 .PP
1396 Though, the more important problem is the modern web.
1397 The modern web is simply broken.
1398 It has state in a state-less protocol,
1399 it misuses technologies,
1400 and it is helplessly overloaded.
1401 The result are web content render engines that must consist
1402 of hundreds of thousands lines of code.
1403 They also must combine and integrate many different technologies,
1404 only to make our modern web accessible.
1405 Website to image converter are hardly possible to run without
1406 human interaction because of state in sessions, impossible
1407 deep-linking, and unautomatable technologies.
1408 .PP
1409 The web was misused to provide all kinds of imaginable wishes.
1410 Now web browsers, and eventually the users, suffer from it.
1413 .H 2 "Summary uzbl
1414 .LP
1415 ``Uzbl is a browser that adheres to the Unix Philosophy'',
1416 that is how uzbl is seen by its authors.
1417 Indeed, uzbl follows the Unix Philosophy in many ways.
1418 It consists of independent parts that work together,
1419 while its core is mainly a mediator which glues the parts together.
1420 .PP
1421 Software leverage can excellently be seen in uzbl.
1422 External tools are used, independent tasks are separated
1423 in independent parts and glued together with small handler scripts.
1424 .PP
1425 As uzbl, more or less, consists of a set of tools and a bit
1426 of glue, anyone can put the parts together and expand it
1427 in any desired way.
1428 Uzbl is very flexible and customizable.
1429 These properties make it valuable for advanced users,
1430 but may keep novice users from using it.
1431 .PP
1432 But uzbl's main problem is the modern web, that makes it hard
1433 to design a sane web browser.
1434 Despite this bad situation, uzbl does a fairly good job.
1437 .H 1 "Final thoughts
1439 .H 2 "Quick summary
1440 .LP
1441 good design
1442 .LP
1443 unix phil
1444 .LP
1445 case studies
1447 .H 2 "Why people should choose
1448 .LP
1449 Make the right choice!
1452 .bp
1453 .TL
1454 References
1455 .LP
1456 .XS
1457 .sp .5v
1458 .B
1459 References
1460 .XE
1461 .ev r
1462 .rm ]<
1463 .de ]<
1464 .LP
1465 .de FP
1466 .IP \\\\$1.
1467 \\..
1468 .rm FS FE
1469 ..
1470 .nr PS -1
1471 .nr VS -1
1472 .[
1473 $LIST$
1474 .]
1475 .nr PS +1
1476 .nr VS +1
1477 .ev
1479 .bp
1480 .TL
1481 Table of Contents
1482 .LP
1483 .PX no