Unix Unleashed, 2nd ed. Errata

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.

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.