whh.jhu@Brl-Bmd@sri-unix (08/09/82)
Date: 13 Jul 82 7:01:02-EDT (Tue)
There ought to be a book-review editor somewhere on the net.
Have been trying to find out what to do with the accompanying item.
(Thought I had a text book for my TOOLS course this fall, but now
clearly not --)
U S I N G T H E U N I X S Y S T E M
by Richard L. Gauthier
Reston Publishing Company, Inc. Reston, VA., 1982
(287 pp., $18.95).
(Reviewed by W.H. Huggins, <whh@jhu>)
We need a good introductory book on using the UNIX system that is
suitable for class-room use and individual users. At first glance,
I thought this book might fill the bill and I was intrigued by the
fact that it had been produced by the author using Don Knuth's TEX
system running under UNIX on the ONYX C8002. But after careful
reading, I regret to report that it leaves much to be desired.
Gauthier has tried to describe the major UNIX commands without
using the rather concise and careful terminology and notations
derived from CS theory that permeate the BTL UNIX Manuals. That
objective is laudable, provided it can be done successfully without
implying erroneous or misleading ideas. Unfortunately, not many
people have the skills of E.B. White to express simply concise
ideas, and in much of the author's attempt to reduce the carefully
phrased definitions given in the UNIX Manual to simple English,
certain key ideas (and, I believe, absolutely essential ideas) have
been obscured or lost all together. I will mention some of these
difficulties later, since I plan to send Gauthier a copy of this
memo so that he can make whatever use of it he chooses in a later
revision of his book.
On the positive side, the inclusion of specific examples in using
the various commands was useful and helpful, even to an experienced
UNIX user because most people never fully explore all of the
options and strategies that are available, once they master a main
corpus of commands. I learned several interesting things from
reading the book.
1. Typography
This appears to be an example of an author-produced book using TEX
(it could well have been TROFF in view of the typographical errors
and formatting difficulties that are evident), and has apparently
been untouched by a professional copy-editor. It needs a good
editor's pen to tighten up the writing and remove redundant and
obscure verbiage and expressions. The formatting is irregular and
ungainly in places -- The large 3/4 inch space that has been left
between section headings and the first printed line that follows
not only wastes valuable space and makes the material hard to read,
but the whole matter of "style" seems to have been treated quite
inconsistently.
In some chapters, the first lines of paragraphs are indented by 5
ens spacing, whereas in other chapters indentation is twice that.
Bold face type is used for section headings and for the main labels
(ala UNIX Manual style), but is not used in the text to distin-
guish command and file names from variable names (as is done in
the BTL Manuals). The use of bold-face versus italic and Roman
type styles seems capricious without regard to the function that
different types faces can fulfill. For instance, every line that
might appear on the user's terminal is preceded by bold-face
labels (UNIX -> , user ->, ED ->, etc) to identify what has pro-
duced that line, while the actual command lines are in lighter
weight Roman or typewriter fonts that are inconsistent and changing
throughout the work. The heading of the Summary section of each
chapter is indented and printed in ordinary Roman type that doesn't
attract the eye and seems quite inconspicuous considering its
importance.
The author has not mastered the vagaries of TEX (or TROFF) which
requires care in handling entry of some characters. For instance,
in the command lines, the "+" sign is gigantic (as it would appear
in a mathematical equation), whereas the minus "-" appears as a
minuscule hyphen when these two signs are prepended to the various
arguments and flags in the command lines. (In TROFF, the em dash
is entered as \- or \(em , not as a hyphen, and I presume a
similar escape may be required with TEX).
It seems to me that one of the virtues of word-processing equipment
should be that the author can correct and perfect the text much
more readily than when some overburdened typist has to retype pages
of complicated material. On this score, the book is an unfortunate
example of an author-produced work. If this is a difficulty with
TEX, I'm glad that I have access to TROFF!
2. Syntactical Conventions (Regular Expressions, etc.)
As I have already remarked, the author has chosen quite appropri-
ately a very simple writing style. The studies of Alphonse
Chapanis have clearly demonstrated that computer manuals should be
written as simply as possible and that even people with advanced
degrees prefer a manual written at grade-school level to the more
abstract and passive style of "scientific" writing that is often
used. However, even when simple words and sentence construction is
used, those words must be carefully selected and examined for pos-
sible ambiguous meanings. Furthermore, key ideas must be
translated from their formal terminology into the simpler language
rather than slurred over. On this point, I was bothered by much of
the author's writing. I shall give below some examples to illus-
trate what I mean. Some of this would immediately be corrected by
a good copy editor. (But I'm told that publishers are today
increasingly printing author's manuscripts without editing -- and
this at a time when the price of books has become outrageous!). In
this case, the buyer must complain.
One idea that runs through all of the UNIX system commands and
languages is the notion of a regular expression and pattern match-
ing. To present a meaningful discussion of the metasymbols such
as the "*", the notion of strings of characters and matching
seems to me to be indispensable. Because these preliminary ideas
were not first developed the author makes the statement on page 41:
The metacharacter "*", or star, is used to indicate that
a character followed by the "*" is to stand for any char-
acters following.
whereas it stands when used in a regular expression for any number
(including none) of repetitions of the character that it follows.
Then in the next section the author states that:
The metacharacters "[ ]" allow you to specify a number of
characters that you may want to recognize when performing
an operation.
This suggest that a number (like 5 or 7) is to be specified,
whereas what is indeed intended is "any one of a set of charac-
ters".
It is this kind of sloppy language that has replaced the very care-
fully considered definitions and text used in the UNIX Manual pages
in all too much of the book. The matter is made worse by the
author's misuse of quotation marks: he writes
"$ and ^" instead of "$" and "^"
and doesn't distinguish between literals and variables. And, on
page 53, the reference to the parent directory is printed with a
space between the two dots ( . ./B ) rather than two successive
characters ( ../B ). In UNIX, this could produce disastrous
results in some commands. For some reason, there is no space
separating a word and the following left parenthesis in many places
(but not everywhere). In printing the protection mode, repeated
hyphens (viz. -rw-------) have been collapsed into a single em
dash, much to the confusion of the reader. On page 8, "control"
is abbreviated as "cntrl", whereas "<ctrl>-d" is used to logout.
On page 67, the author states that it is a good habit to leave a
blank after the output redirection (e.g. > file ), whereas the
legal redirection does not use this blank (viz. >file). Even
though some UNIX shells may tolerate this space, the TOOLS will
not, so it is a good habit NOT to leave this space.
The discussion on pages 77 and 78 on comparing two files illus-
trates the errors that confuse the reader. From the example at the
bottom of the page, I quote:
"The simplest usage of the compare command is without
the use of options. It will stop and print out the first
occurrence of a difference between the two files. We
have two files "aa and bb" which contain:
file aa file bb
1 1 2 1 1 1 1 1 1 1
2 2 1 2 2 2 2 2 2 2
Notice that the differences are line 1 column 3 and
line 2 column 3.
user -> cmp aa bb <r>
UNIX -> aa bb differ: char 3, line 1
-> $ "
Because of the space character between the numerals 2 and 1, the
two files differ in character location 5 (rather than 3). (In
fact, in the next example on this same page where the character
count is obtained by using the "-l" option, the "5" agrees
exactly with the ascii character 62 that is displayed.)
I will continue with this detailed examination for a few more pages
(I read carefully all of the chapters up to Chapter 9, and believe
these comments are representative of much of the book).
The "Summary:" on page 80 is:
We demonstrated the value of the remove command in
chapter 4; however, as you can see we have expanded it to
the point that it could be very dangerous if not used
properly. Thus before using it you should always be
aware of the directory that you are in and certain that
the pattern you are using is correct. The time that it
takes to do this will be rewarded many times over by not
having to go to backup tapes to recover things you
accidentally deleted.
Aside from my quibble that the remove command has a "use" rather
than a "value" (which word can be confused with commands that do in
fact return a "value"), I noted that "pattern" has thus far not
been defined or discussed. Furthermore, this paragraph is more of
a comment or a warning rather than a "summary". However, it is
typical of the summary paragraphs on most of the other sections.
On the next page, the backslash is omitted in the statement that:
Parentheses must be "escaped", that is to say that
a " " must precede both the "(" and ")".
And in the description of the "-type c" argument of the "find"
command, it is said to be
True if the type of file is c for character file.
but nothing is said about other types of files where the variable
c is one of b, c, d, or f. Here the failure to distinguish
between variables and literals confuses the reader.
On page 100 in discussing "background" commands the statement is
made:
"Remember that not all commands can run in the back-
ground. It is not difficult to determine which ones can
and which ones cannot be executed as background
processes." {How?} "For example it would make no sense
to run the editor in the background mode when you are
trying to edit a file." {Why not? I have used editor
scripts in the command ed file < script & }
And in the discussion of the metacharacter "*" on page 103, the
author states that
The use of "*" indicated that one or more characters
are involved. Many times you will want to find names
that are similar except for one character in a particular
position. In this case you can use the symbol "?".
Whereever {sic} it appears in a name, it means that that
exact position in the name is to be ignored.
This statement would seem to mean that "b*" matches at least a
2-character name, whereas * in fact can be null (i.e. no charac-
ter). And on the next page the list of metasymbols is shown as "(
< > * ? fi & )". I can only assume that the ligature "fi" is a
misprinting of "[". etc. etc.
3. Conclusion
>From the discussion given above, I regret that this book can not
serve as a substitute or replacement for the V-7 Documentation. We
need a good introductory tutorial, but it must be much more care-
fully written than this. The market still exists for such a book.
Perhaps Gauthier will undertake to produce it. His general
approach is sound; it is in its detailed execution that it fails.