From: utzoo!decvax!cca!whh.jhu@Brl-Bmd@sri-unix Newsgroups: net.unix-wizards Title: Book Review: USING THE UNIX SYSTEM Article-I.D.: sri-unix.2564 Posted: Sun Aug 8 22:54:52 1982 Received: Mon Aug 9 05:31:55 1982 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, ) 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 "-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 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.