errata

Unix Unleashed, 2nd ed. Errata

Here is the errata that I've compiled for the two chapters that I helped create for Unix Unleashed, 2nd ed. If you find any other errors in either chapter 17 or 19, please let me know.
p. XLVI (unnumbered)
URL to homepage is wrong. The right version is now out of date. Please note that my new site is at http://www.interhack.net/people/cmcurtin/
Chapter 17 (Title)
I disagree with the idea of "programming web pages." In reality, we're not programming pages, we're programming applications.
p. 615 (How CGI Works)
"Web client (browser)" should be "Web client (usually a browser)". Anyone who has run a site of any size knows how many hits actually are from robots, rather than browsers.
p. 616
The term "HTML script" appears on this page. It doesn't really make sense; HTML is only markup, which defines what the text looks like. "Script" generally applies to programs that are written in interpreted languages. To be a programming language, there must be a facility for such things as loops.
p. 622 (Design Considerations)
There is reference here to "client-side CGI." CGI is a protocol that defines an interface between a web server and programs that run on the server machine. By definition, then, CGI is only a server-side technology. It's safe to assume that you never saw the phrase "client-side CGI". (And I, for one, would be happy if you would.)
p. 622
There is an example of a server-side include. The closing of the tag should be -->, not an arrow pointing right.
p. 627 (Output Types)
The end of the page shows a dash on the first line after the Content-type header. This is wrong; that should be a blank line. In Perl, this could be written as print "Content-type: text/html\n\n"
p. 628
"MIME is explained in Chapter 16 of volume 2" should say "this volume" or "Internet Edition" instead of "volume 2".
p. 629 (CONTENT-TYPE)
The Content-type HTTP header is usually passed from server to client. The only time that the client passes that header to the server is in the event of a POST operation.
p. 631 (Netscape Cookies)
Nix the use of the word "another" in the sentence "Cookies are another way..." This part originally was written for chapter 19, after the discussion of maintaining state information via query strings. It was duplicated here in Chapter 17, since this discussion really applies to CGI programming in general, not just with Perl.
p. 634 (References to CGI Resources)
Some publishers have a very annoying habit of referring only to their own books. This is unfortunate, because it greatly limits what readers can learn on the referenced subject. I recommend looking at O'Reilly's CGI Programming Book and the CGI Programming OpenFAQ.
p. 634
See my earlier discussion of "client-side CGI".
Chapter 19 (Title)
One doesn't program CGIs; one programs CGI applications.
p. 658
"himself or herself". This is not what I wrote. I wrote "himself." It was decided that in order to be more politically correct, the masculine pronoun couldn't remain there by itself. Nevermind the fact that in English, it is grammatically correct to use the masculine form of a word when the gender is undefined. It is not grammatically correct, however, to use both forms (as it appears here) or the feminine form, as it appears on p. 630. Writing things in grammatically incorrect ways to appease the small minority who insist on being "politically incorrect" at any cost is absolutely ridiculous.
p. 664
Replace "Telnet" with "telnet(1)".
p. 668
Code snippets aren't lined up properly. Compare the alignment to the snippets on p. 666.
p. 669
Last paragraph, "later" specifically means p. 680. Unfortunately, the stuff on p. 680 is an exact duplicate of some of what appears in Chapter 17.
p. 671
Code snippets aren't aligned properly again.
p. 671
-expires code snippet didn't display (replaced by tabular175).
p. 671
raw_cookie() paragraph should say "cookie" instead of "magic cookie". This one is actually my fault. Sorry.
p. 673
Replace "e-mail" with "email". Quit hyphenating the word, already.
p. 673
More code alignment problems.
p. 674
Replace "bold text" with " bold text ".
p. 675
([cw]) should be (©).
p. 675, 678, 680, and 681
Still more code alignment problems.
Overall, the chapters I helped on look decent. I'm disappointed in the number of errors that made it all the way to print. I believe that this is because MacMillan insists on using the wrong tools for the job at hand. Specifically, they insist that everything come to them in the braindead format of Microsoft Word. Standardizing on a proprietary application is asinine. Instead, it makes more sense to standardize on protocols and open interchange formats. Then, we can all use the right tools for the job, and share our information in ways that anyone, regardless of the type of computer they use, can benefit.

The sheer number of typographical errors here seems to underscore my point. MacMillan, despite having an army of people trying to manually process everything and offset the deficiencies of braindead tools like Word, was unable to produce a book that went more than several pages without a typographical or production error.

Markup languages are incredibly important for the purpose of sharing information. Markup languages seperate various levels of headings, body text, special symbols, etc., so that they can be viewed properly, without regard to the deployment environment. Another nice thing about markup languages is that they can easily be converted from one markup language to another, by using just a few lines of Perl or some other programming language.

The world wide web would not have been the revolution that it was if it required a special application that was written by one organization. Nevertheless, a great number of people seem unable to learn a lesson from this fact. This is sad, and I hope a temporary situation.


Matt Curtin
Last modified: Thu Dec 25 20:17:06 EST 1997