Linux, Unix, /etc

Danger Will Robinson! You are now entering a condescending Unix user zone!

Review of The Unix Programming Environment

What This Book Means To Me

This was the book that made me want to move to a Unix system — from Windows, OS/2, and, God help us, OS/400 in my case. Perhaps no-one who hasn't programmed extensively on other systems can realise just how programmer-friendly Unix really is. Try RPG on an AS/400 for size; then you'll really know the meaning of the phrase "bondage-and-discipline language". Even without access to a Unix box, even just through reading this book, I knew that it was better than anything I'd been used to.

Also, I wanted a command line, I've never liked GUIs; but COMMAND.COM just wasn't good enough. What I read here convinced me that what I wanted was Unix. I chose Linux, a system not without differences from the Version 7 Unix described in this book, first published as it was in 1984, when Linux was still seven years in the future. The Unix Programming Environment was still relevant to me, the neophyte Linux user, in 1994; and it is just as relevant today, six years later. It is as useful for the Linux user as for any Unix user. There is still no better way of really understanding how to get the most from the tools available.

The Book in Outline

The book has 9 chapters, falling into four distinct sections: Unix, Shell, C, Document Preparation.

Unix

We begin, logically enough, with the chapter "Unix for Beginners". This packs a good amount of introductory knowledge into one longish chapter, and will repay several readings for the neophyte. Chapter 2 introduces the Unix file system: its basic structure, underlying concepts, and the commands that manipulate it. Outdated in parts, it remains a good general introduction.

Shell

Particularly useful are the shell chapters, 3-5. Here is the core of the Unix Philosophy, clearly and convincingly expressed.

Tools doing one thing well.
Filters using standard input and output.
Tools linked together to make new tools, with no programming required.

These three chapters provide a first-rate tutorial on effectively using and programming the shell. They need supplementing only by a good man page, and a bit of practice. The fourth chapter, on "Filters", is particularly impressive.

Filters

The concept of a filter is a key idea for anyone who wishes to use Unix effectively, but especially for the programmer. It is one that migrants from other operating systems may find new and unusual.

So what is a filter? At the most basic level, a filter is a program that accepts input, transforms it, and outputs the transformed data. The idea of the filter is closely associated with several ideas that are central features of Unix: standard input and output, input/output redirection, and pipes.

Standard input and output refer to default places from which a program will take input and to which it will write output respectively. The standard input (STDIN) for a program running interactively at the command line is the keyboard; the standard output (STDOUT), the terminal screen.

With input/output redirection, a program can take input or send output someplace other than standard input or output — to a file, for instance. Redirection of STDIN is accomplished using the < symbol, redirection of STDOUT by >.

The pipe (|) is a junction that allows us to connect the standard output of one program with the standard input of another. A moment's thought should make the usefulness of this when combined with filters quite obvious. We can build quite complex programs, on the command line or in a shell script, simply by stringing filters together.

The combination of filters and pipes is very powerful, because it allows you a) to break down tasks and b) to pick the best tool for tackling each task. Many jobs that would have to be handled in a programming language (Perl, for example) in another computing environment, can be done under Unix by stringing together a few simple filters on the command line. Even when a programming language must be used for a particularly complicated filter, you are still saving a lot of development effort through doing as much as possible using existing tools.

The chapter is an excellent introduction to sed and awk in particular, but also covers the greps, sort, tr and others. A puzzling ommission is the m4 macro processor, surely the ultimate filter.

Some people find perl a panacea for this sort of "text-mangling", but to me it seems too big and complicated. I find I can remember how to do simple stuff in sed and awk more easily than I can with perl.

C

Two solid chapters on C programming, covering respectively using the Standard C library and Unix System calls, lead up to an excellent example of Unix C programming in practice. A complete system is developed, the hoc mathematical programming language, that also allows the authors to illustrate the usage of lex, yacc and make, all very useful Unix tools for programming development.

Someone who knows the basics can really pick up a lot of practical advice on developing solid C code from this part of the book. Certainly, I learned enough to fix minor problems with porting source to Linux: not much of an issue these days, but a few years ago it still happened quite often that a bit of tweaking was required even with source packages that had ostensibly been ported to Linux already.

Troff

The book shows its age most clearly in the last chapter, "Document Preparation", which is all about using troff, nroff, and their various macro packages. On the other hand, this chapter is invaluable simply for the clear and simple instructions on how to write a man page— anyone at the FSF reading?!

Reflections

Some things don't work quite the way they used to e.g. the little filters 2, 3 et al: but this is simple to fix. Someone changed $0 so it reports the whole path, not just the program name: 2 and co., given in the text as


pr -$0 -t -l1 $*

now look like this:


#!/bin/sh
pr -`basename $0` -t -l1 $*

Naturally, some modern tools are lacking. Perl hadn't been thought of back in 1984, for instance. The nearest we get to Internet tools is a bare mention of "bang paths" (the old UUCP-style method of addressing e-mail). And their idea of a "standard editor" is.... ed! No one could accuse me of being an MS-Word fan, but ed is a little too far in the other direction even for my taste. That said, a knowledge of The Standard Editor is a handy basis for using vi's ex mode; and even in this day and age, ed is the easiest editor to fit on a rescue disk.

Why This Book Is Important

For learning about Unix, there is no better guide. The book also has some more general lessons for us today. It hearkens back to a leaner, cleaner Unix. For example, we read: "All input and output is done by two system calls, read and write." Those were the days! Perhaps today's Unices are all too hairy: maybe the future lies in a brand-new system?

The thought occurs to me that the clearest illustration of how relevant this book remains to all Unix users is to show how this document was prepared. Granted, it's not a programming example; but part of the point of this review was to show that the Unix "programming environment" is useful to all sorts of users.

A Practical Example

I find HTML a clumsy mark-up language, so I avoid dealing with it directly. Instead, I've written a set of m4 macros that generate HTML. This has the advantage that the HTML in my documents in guaranteed to be correct — no more weird-looking web pages due to overlooked typos. Also, to my eyes the document looks much neater, and thus is easier to work on.

The tools used in creating this document were as follows:

vi: editing
rcs: to provide version control.

sed: a script to replace certain characters with their html encoding, like so:


#!/bin/sed -f
#htmlize: convert special characters to html codes
#naive: assumes no special characters already present!
s/&/\&amp;/g
s/>/\&gt;/g
s/</\&lt;/g
...

And so on for all the ISO-8859-1 character set.

m4: macros to generate html. Too big to put here, and still being worked on. I'll put it up on my webpage when I'm finished.

make to automate the previous three steps.

all: *.html

clean:
	rm -f *.html

*.html: html.m4

%.html: %.m4
	ci -m. -l $*.m4
	cat $*.m4 | htmlize | m4 -P &gt; $*.html
	chmod 644 $*.html

Each tool on its own performs useful work. Used together, their power is magnified. By having several Unix tools cooperate, I've gained more control over my writing than I could possibly hope for using one monolithic program — such as any traditional word-processor. And that's what the Unix environment is all about.

In conclusion, I must say that, despite being 15 years old, an aeon in computing terms, this books retains much of its value for the present-day Unix user and programmer both. A must for any Linux book collection.

Paul Dunne 2000

[back to Linux, Unix, /etc]