UNIX Power Tools, 2nd Edition
By Jerry Peek, Tim O'Reilly, and Mike Loukides


Following are the changes made in the 1/01 reprint.


Here's the key to the markup:

        [page-number]: serious technical mistake
        {page-number}: minor technical mistake
        <page-number>: important language/formatting problem
        (page-number): language change or minor formatting problem
        ?page-number?: reader question or request for clarification


[325] In the first paragraph:

"Here's how to do it"

now reads:

"Here's how to do it in both the Bourne-type and C-type shells"


[325]
"and pipes them to a shell"

now reads:

"and pipes them to a Bourne shell"


[325] After "...if you aren't sure what files you'll be renaming" the 
following text has been added:

Single quotes around the filenames are strongest; we use them in the 
Bourne-type shell version. Unfortunately, csh and tcsh don't allow 
$ inside double quotes (") unless it's the start of a shell variable 
name. So the C shell version puts double quotes around the filenames--
and the Bourne shell version uses single quotes, like this:


[891] In section 45.36, second paragraph, the following text has been
added after "(like modify some file, access a printer, etc.)":

To really do this right, the program needs 
to both test for the lockfile and create it (if it doesn't exist) in 
one atomic operation. If the test-and-set operation isn't 
atomic--for instance, if a program tests for the lockfile in one command 
and then creates the lockfile in the next command--there's a chance that 
another user's program could do its test at the same precise moment 
between the first program's (non-atomic) test and set operations. The 
technique in this article lets you make a lockfile atomatically from a 
shell script.

Note:
This technique doesn't work for scripts run as the superuser root. 
It depends on the fact that a standard user can't write a file without 
write permission. But root can write any file whether it has 
write permission or not. If there's a chance that root might run your 
script, you might want to add a test of the UID--by running the 
id command, for instance--and be sure that the UID isn't 0 (the 
superuser's).


[892] After the line "Once the first edmaster removes the lockfile,
the second edmaster can create the lockfile and do its editing
of config" the following text has been added:

(Note that some editors--for instance, nvi-1.79 under Linux--
automatically get a write and/or read lock before you edit a file.)


[892] After the line "The rest of the shell script keeps its normal
mask" the following text has been added:

And, if the redirection fails (because the lockfile exists), only the 
subshell will abort--not the parent shell running the script.