The errata list is a list of errors and their corrections that were found after the product was released.
The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.
| Version |
Location |
Description |
Submitted by |
Date submitted |
| Printed |
Page 1
throughout section 10.4 |
All these comments relate to section 10.4
Locate was not introduced, as such, on BSD. Woods's "fast find" was actually called
"find". "find" was renamed to locate when standards porocessed mandated that "find
foo" should have the same effect as "find foo -print", which was an incompatible
change and so the old "find" functionality had to be renamed to "locate".
The advice in the advice box is just wrong. GNU updatedb runs as "nobody" or
"daemon", not root. If not, throw away your Linux distribution. slcoate also
doesn't store any kind of permissions information in its database. At all.
The find 'o*' example is wrong, too (i.e. testing it would have shown this). It's an
elementary mistake:
$ find 'o*'
/usr/bin/find: o*: No such file or directory
$ find o*
oevre
one
onus
organ
otto
Contrary to the text, it isn't even going to be resticted to this directory. You
probably wanted this:-
find . -maxdepth 1 -name 'o*'
The find -perm construct checks file mode, not accessibility. It takes no account of
ACLs and so forth, so that description is inaccurate. To check accessibility use
"find -readable" etc. (but those predicates are available only in find 4.3.x).
The usage "find ... -perm +..." is deprecated; see the documentation for an
explanation.
"If the number is unsigned, then only files of exactly that size match"
Not true -
$ find . -maxdepth 1 -size 1G
.
./smallfile
$ ls -ld . smallfile
drwxr-x--- 2 youngman eng 4096 Aug 9 18:51 .
-rw-r----- 1 youngman eng 1 Aug 9 18:51 smallfile
Again, see the documentation for why.
The simple find script should set $IFS; then it would cope better with whitespace.
In fact the example could do with better quoting.
|
Anonymous |
|
| Printed |
Page 27
2nd paragraph |
Mac OS X 10.5 Leopard includes the locale command.
|
Anonymous |
|
| Printed |
Page 34
table 3-1 |
for interval expression, it is not a BRE and should be a ERE. On fedora core 7 and centOS, need a grep -E to make it work.
|
Anonymous |
|
| Printed |
Page 34
table 3-1 |
The preceding errata for page 34, table 3-1, which claims that an interval expression "\{n,m\}" is an ERE, rather than a BRE as the book states, is incorrect. I don't know why the preceding commenter's test failed, but the listed notation is widely documented as BRE notation.
|
Colin Howell |
Jul 04, 2011 |
| PDF |
Page 34
7th paragraph of Table 3-1 |
The printed version correctly shows BRE, while the PDF says ERE (even though it is repeated in paragraph 10 of the Table.)
|
Jonathan Knight |
Mar 04, 2013 |
| PDF |
Page 90
11th paragraph |
current:
sed -e 's=/.*= =' \
-e 's=^\([^:]*\):\(.*\) \([^ ]*\)=\1:\3, \2=' <$USER | sort >$PERSON
should be
sed -e 's=/.*= =' \
-e 's=^\([^:]*\):\(.*\) \([^ ]*\) =\1:\3, \2=' <$USER | sort >$PERSON
An white space should be added after the -e 's=^\([^:]*\):\(.*\) \([^ ]*\)
|
Anonymous |
Aug 13, 2013 |
| ePub |
Page 95
|
I'm not sure how the page number helps since the page number on an iPad is dependent on the device's size and orientation and font size, etc. but my observation is in the "matching single characters" section of the "basic regular expressions" section.
It says that "\ matches a literal literal backslash". Perhaps I'm just misunderstanding but when I try out a regex it requires a backslash preceding the backslash to escape it.
|
Anonymous |
Jul 04, 2017 |
| Printed |
Page 100
First listing/output |
The output of iso8859-1-to-html is shown to be identical to its input, i.e. no HTML entities appear to be generated (which was the whole point of the example.) I'm guessing that the entities that should have been printed were actually rendered as the correct characters as part of the DocBook processing.
|
Anonymous |
|
| Printed |
Page 100
First listing/output |
The output of iso8859-1-to-html is shown to be identical to its input, i.e. no HTML entities appear to be generated (which was the whole point of the example.) I'm guessing that the entities that should have been printed were actually rendered as the correct characters as part of the DocBook processing.
|
Anonymous |
Jul 19, 2008 |
| Printed, ePub |
Page 113
Parameter Expansion Example - 3rd & 5th paragraphs |
reminder="Time to go to the dentist!"
Should be single quotes, not double:
reminder='Time to go to the dentist!'
Else otherwise the shell will try to interpret the ! when enclosed in double quotes.
|
kgunders |
Sep 26, 2013 |
| Printed, ePub |
Page 118
Section 6.1.3 Arithmetic Expansion |
In Table 6-4 and text following: The "equal" operator should be "==" (no space between the successive equal signs).
|
kgunders |
Sep 26, 2013 |
| Printed |
Page 152
Tip box at bottom of page |
(Also in the current Safari Books Online version)
Just an aberrant apostrophe: "many commercial Unix Bourne shell's don't support it" should be "many commercial Unix Bourne shells don't support it".
|
Anonymous |
Jul 21, 2008 |
| PDF |
Page 183
Last paragraph, last line |
The last line on the page, a line from the 'pathfind' program reads:
test "x$envvar" = "xPATH" && envvar=OLDPATH
I believe it should instead be:
test "x$envvar" = "x$PATH" && envvar=$OLDPATH
As we compare 'envvar' not to the expansion-less string value "xPATH" but to the string value "x$PATH". i.e. the value of the PATH variable with an "x" prefixed. Also, we want to set 'envvar' to the value of the OLDPATH variable, not to the string "OLDPATH".
Note: I found this possible error in the PDF version with ISBN 978-0-596-00595-5, which I purchased as part of a Humble Book Bundle.
|
Solt Budavári |
Aug 27, 2017 |
| Printed |
Page 287
code of $HOME/html2xhtml.sed |
s:</[Hh][Tt][Mm][LL]>:</html>:g
s:</[Hh][Tt][Mm][Ll]>:</html>:g
should actually be:
s:<[Hh][Tt][Mm][Ll]>:<html>:g
s:</[Hh][Tt][Mm][Ll]>:</html>:g
The 1st line is hanlding </HTML> instead of the openning <HTML> tag.
The 2nd line handle the closing </HTML> tag properly,
Also, the original code would fail to convert <Html> to <html> because of the typo [LL] instead of [Ll]
|
Anonymous |
|
| Printed |
Page 302
md5sum line under Example 10-2 |
The example's code says:
md5sum "$@" /dev/null 2> /dev/null |
Shouldn't this line be:
md5sum "$@" 2> /dev/null |
If not, why is the first instance of "/dev/null" needed?
|
Alfredo Alvarenga |
Nov 26, 2018 |
| Printed |
Page 309
11.2 |
u1.passwd and u2.passwd are identical in the ZIP file posted on this oreilly.com.
u1.passwd is a copy of u2.passwd and must be edited to show the UIDs and GIDs shown
in Example 11-1.
|
Anonymous |
|
| Printed, PDF |
Page 314
Example 11-4, 21st line |
This is the line:
uidlist[i] = id
Change to:
uidlist[i] = 0 + id
Because id contains a string, the above change is required to convert the string to a number when assigning to the uidlist array. Without this change, the expression "j < uidlist[i]" in the for loop might not always produce the desired result (since it is comparing a number to a string, instead of a number to a number).
|
aphilipp |
Apr 21, 2015 |
| Printed, PDF |
Page 399
5th paragraph, 2nd line |
Change "affect" to "effect".
|
aphilipp |
Apr 21, 2015 |
| Printed |
Page 433
3rd line |
It looks as if the output of the manual page composed for the `pathfind` command wasn't actually eval'ed for the printing of this book because in the third line of code on page 433, which reads,
envvar [ files-or-patterns ]
as the very end of the SYNOPSIS section heading in the man page's troff source differs from the half-size example on page 432. On the figure of the supposed output of this troff source, we see that this piece of code actually seems to produce
envvar [ file(s) ]
which, obviously, is not quite a match to the input.
|
Anonymous |
|