Mercurial > docs > unix-phil

comparison unix-phil.ms @ 11:b32a43a62cae

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
some rework about interface arch (ch03)
author meillo@marmaro.de
date Sat, 20 Feb 2010 15:24:40 +0100
parents 355ed69a34a8
children 018d5f9a2993
comparison
equal deleted inserted replaced
10:355ed69a34a8 11:b32a43a62cae
296 They have to interfaces that allows them to be used in such a way. 296 They have to interfaces that allows them to be used in such a way.
297 297
298 .SH 298 .SH
299 Interface architecture 299 Interface architecture
300 .LP 300 .LP
301 Unix is, first of all, simple: Everything is a file. 301 Unix is, first of all, simple \(en Everything is a file.
302 Files are sequences of bytes, without any special structure. 302 Files are sequences of bytes, without any special structure.
303 Programs should be filters, which read a stream of bytes from ``standard input'' (stdin) 303 Programs should be filters, which read a stream of bytes from ``standard input'' (stdin)
304 and write a stream of bytes to ``standard output'' (stdout). 304 and write a stream of bytes to ``standard output'' (stdout).
305 .PP 305 .PP
306 If the files \fIare\fP sequences of bytes, 306 If the files \fIare\fP sequences of bytes,
307 and the programs \fIare\fP filters on byte streams, 307 and the programs \fIare\fP filters on byte streams,
308 then there is exactly one standardized interface. 308 then there is exactly one standardized data interface.
309 Thus it is possible to combine them in any desired way. 309 Thus it is possible to combine them in any desired way.
310 .PP 310 .PP
311 Even a handful of small programs will yield a large set of combinations, 311 Even a handful of small programs will yield a large set of combinations,
312 and thus a large set of different functions. 312 and thus a large set of different functions.
313 This is leverage! 313 This is leverage!
314 If the programs are orthogonal to each other \(en the best case \(en 314 If the programs are orthogonal to each other \(en the best case \(en
315 then the set of different functions is greatest. 315 then the set of different functions is greatest.
316 .PP 316 .PP
317 The Unix toolchest \fIis\fP a set of small programs that 317 Programs might also have a separate control interface,
318 are filters on byte streams. 318 besides their data interface.
319 They are, to a large extend, unrelated in their function. 319 The control interface is often called ``user interface'',
320 Hence, the Unix toolchest provides a large set of functions 320 because it is usually designed to be used by humans.
321 that can be accessed by combining the programs in the desired way. 321 The Unix Philosophy discourages to assume the user to be human.
322 Interactive use of software is slow use of software,
323 because the program waits for user input most of the time.
324 Interactive software requires the user to be in front of the computer
325 all the time.
326 Interactive software occupy the user's attention while they are running.
327 .PP
328 Now we come back to the idea of using several small programs, combined,
329 to have a more specific function.
330 If these single tools would all be interactive,
331 how would the user control them?
332 It is not only a problem to control several programs at once if they run at the same time,
333 it also very inefficient to have to control each of the single programs
334 that are intended to work as one large program.
335 Hence, the Unix Philosophy discourages programs to demand interactive use.
336 The behavior of programs should be defined at invocation.
337 This is done by specifying arguments (``command line switches'') to the program call.
338 Gancarz discusses this topic as ``avoid captive user interfaces''.
339 .[
340 %A Mike Gancarz
341 %T The UNIX Philosophy
342 %I Digital Press
343 %D 1995
344 %P 88 ff.
345 .]
346 .PP
347 Non-interactive use is, during development, also an advantage for testing.
348 Testing of interactive programs is much more complicated,
349 than testing of non-interactive programs.
322 350
323 .SH 351 .SH
324 The toolchest approach 352 The toolchest approach
325 .LP 353 .LP
326 A toolchest is a set of tools. 354 A toolchest is a set of tools.
327 Instead of having one big tool for all tasks, one has many small tools, 355 Instead of having one big tool for all tasks, one has many small tools,
328 each for one task. 356 each for one task.
329 Difficult tasks are solved by combining several of the small, simple tools. 357 Difficult tasks are solved by combining several of the small, simple tools.
330 .PP 358 .PP
359 The Unix toolchest \fIis\fP a set of small, (mostly) non-interactive programs
360 that are filters on byte streams.
361 They are, to a large extend, unrelated in their function.
362 Hence, the Unix toolchest provides a large set of functions
363 that can be accessed by combining the programs in the desired way.
364 .PP
365 There are also advantages for developing small toolchest programs.
331 It is easier and less error-prone to write small programs. 366 It is easier and less error-prone to write small programs.
332 It is also easier and less error-prone to write a large set of small programs, 367 It is also easier and less error-prone to write a large set of small programs,
333 than to write one large program with all the functionality included. 368 than to write one large program with all the functionality included.
334 If the small programs are combinable, then they offer even a larger set 369 If the small programs are combinable, then they offer even a larger set
335 of functions than the single large program. 370 of functions than the single large program.
493 .IP \(bu 528 .IP \(bu
494 If the global situation changes so that the software is not needed anymore, 529 If the global situation changes so that the software is not needed anymore,
495 then less effort was spent into the project, than it would have be 530 then less effort was spent into the project, than it would have be
496 when a different approach had been used. 531 when a different approach had been used.
497 532
498 533 .SH
499 534 Upgrowth and survival of software
535 .LP
536
537 portability
538
539 text files
540
541 reuse of independent parts
500 542
501 543
502 544
503 545
504 546