I forgot to bump this thread yesterday, sorry about that.

The 9th and last chapter is a very light chapter compared to the previous one.
It has five main topics: the troff(1) "low-level" commands, the ms(7) and man(7) macro packages, and the tbl(7) and eqn(7) preprocessors.

We write two documents: a manual for the hoc language using ms(7) and a manual for the hoc interpreter using man(7). The former is presented in its final form as an appendix.

However, man(7) may be considered deprecated in favor of mdoc(7), which is a semantic markup for manual pages. See this video on the topic. I have to confess that to this day I still use man(7). This is a bad practice that I take with me from the time I learned how to write manpages in Linux, as some GNU and Linux manuals are written in it; compared to BSD, in which mdoc(7) is the norm.

Quote:The man language was the standard formatting language for AT&T UNIX manual pages from 1979 to 1989. Do not use it to write new manual pages: it is a purely presentational language and lacks support for semantic markup. Use the mdoc(7) language, instead.
-- OpenBSD man(7)

The chapter 10 (the Epilog) summarizes the UNIX philosophy and history. It explains how a system free of market pressure or commercial interest became a success.

The chapter also cites the feature creep in modern UNIXes.

Quote:The UNIX system [...] with marked dominance has come responsibility and the need for “features” provided by competing system. As a result, the kernel has grown in size by a factor of 10 in the past decade, although it has certainly not improved by the same amount. This growth has been accompanied by a surfeit of ill-conceived programs that don't build on the existing environment. Creeping featurism encrusts commands with options that obscure the original intention of the programs.
Because source code is often not distributed with the system, models of good style are harder come by.

... the UNIX philosophy

Quote:The principles on which UNIX is based -- simplicity of structure, the lack of disproportionate means, building on existing programs rather than recreating, programmability of the command interpreter, a tree-structured file system, and so on.
[...]
We said in the preface that there is a UNIX approach or philosophy, a style of how to approach a programming task.

... this approach is summarized:

• First, let the machine do the work: use existing programs to mechanize tasks that you might do by hand on other systems.
  
• Second, let other people do the work: use programs that already exist as building blocks in your programs, with the shell and the programmable filters to glue them together.
  
• Third, do the job in stages: build the simplest thing that will be useful, and let your experience with that determine what (if anything) is worth doing next.
  
• Fourth, build tools: write programs that mesh with the existing environment, enhancing it rather than merely adding to it;
  

...and a comment on the future

Quote:The UNIX system can't last forever, but systems that hope to supersede it will have to incorporate many of its fundamental ideas.

That's it.
It has been a good reading. I learned a lot of stuff: yacc(1), lex(1), troff(1), ms(7), the UNIX history and principles, its tools and the way to glue them together, etc.