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 |
| Safari Books Online |
1
6.3 online edition, 1/2 way down page. |
The script code for pushd/popd introducing the "+n" option does not work the same as for the builtins, despite the text saying so. The problem is with how DIR_STACK is rotated. If you use these functions and your stack is like this:
~/one ~/two ~/three ~
Then you execute "pushd +1", you get this:
~/two ~/one ~/three ~
This is not a stack rotation and the builtins don't do this.
In the function pushd(), we have:
...
if [ $(echo $1 | grep '^+[0-9][0-9]*$') ]; then
# case of pushd +n: rotate n-th directory to top
let num=${1#+}
getNdirs $num
DIR_STACK="$target$stackfront$DIR_STACK"
cd $target
echo "$DIR_STACK"
...
The line reassigning DIR_STACK is wrong and should be:
DIR_STACK="$target$DIR_STACK$stackfront"
This fixes the problem.
|
Robert Clark |
| Printed |
Page 7
2nd paragraph |
Change "has two options and one argument" to "two options and two arguments".
|
Anonymous |
| Printed |
Page 9
Table 1-1 |
I don't know what page the mistake is on since I'm reading the book online at safari.oreilly.com, but the
mistake is in Table 1-1. The fouth sample command shows "cd/usr/lib", then the fifth sample command shows
that "cd .." will take you to "/home". It will actually take you up one directory to "/lib" instead.
|
Anonymous |
| Printed |
Page 43
3rd paragraph from the bottom |
change "2fa" (in bold) to "2Fa"
|
Anonymous |
| Printed |
Page 50
3rd and 5th paragraphs, and Table 2-18 |
That which should be printed as a double quote:
"
is instead rendered as a double quote inside a left- and right-caret:
<">
This problem occurs on:
the second double-quote character in line 4 of paragraph 3,
the second and third ones in paragraph 5 line 4,
the first and only double-quote in para. 5 line 5,
and twice again in the 5th (body) line of Table 2-18.
|
Anonymous |
| Printed |
Page 82
10th (last) paragraph |
The first sentence of this paragraph ends, "... what happens when you type alice &."
It should read, "... what happens when you type source alice &."
The point to this example is to show that these commands are equivalent:
alice,
source alice &
|
Anonymous |
| Printed |
Page 82
last sentence |
This sentence refers to an example of 3 ways to invoke a shell script named "alice"
Item a: source alice
Item b: alice
Item c: source alice &
The last sentence on page 82 begins, "It turns out that the only significant
difference between .c and .b is that you have control of your terminal or workstation
while the command runs"
This sentence should read something like, "it turns out that the only significant
difference between .a and the other two examples is that with the latter two you
retain control of your terminal or workstation while the command runs"
|
Anonymous |
| Printed |
Page 83
Errata for Figure 4-1. |
In this case the correction on the Errata page is wrong and the text of the book is
correct.
Item b in Figure 4-1 is incorrect as the correction states. However, Item c is
correct on page 83. It does not need to be changed.
Item c reads (correctly): source alice &
The purpose of this example is to show that the commands in Item b and Item c are
equivalent. They are:
alice
source alice &
both spawn new shells
|
Anonymous |
| Printed |
Page 93
first paragraph |
the phrase that reads "or to -10 if it's not" should read "or to 10 if it's not"
|
Anonymous |
| Printed |
Page 135
3rd para |
I am using version '3.2.25(16)-release' of bash in Cygwin. When running the code in Task 5-6 on page 135 I
get the following error:
./test: line 5: [: to many arguments
The variable $path in needs to be quoted in the while test.
while [ $path ]; do
must be
while [ "$path" ]; do
|
Anonymous |
| Printed |
Page 167
3rd paragraph starting with "The second variation..." |
This is not technically an error, but rather a point of confusion. When using a
heredoc, with the variation <<- the ending label can also be indented. Unfortunately,
your example format does not point this out. EOF starts in column1.
It's not just newbies that are confused about this. For example, the CD-ROM that
Prentice Hall distributes with their book "Unix Shells by example" Fourth edition
|
Anonymous |
| Printed |
Page 189
code listing after second paragraph |
[ $(grep \t* $cmd) ]
This has two major errors related to grep. One is that you can't simply pass \t to grep either in a script or from the command line. The other is that cmd is not a file but a command line read from the rules file. Grep either processes a file given as a command argument or stdin; it does not process a string passed as an argument. A minor error is that you should be looking for tab as the first character, not simply any tab on the line. I propose the following replacement:
[ "$( echo $cmd | grep $'^\t' )" ]
|
David McCracken |
| Printed |
Page 224
5th paragraph |
This paragraph talks about the noexec option:
"The last option is noexec, which reads in the shell script and checks for syntax
errors, but doesn't execute anything. It's worth using if your script is
syntactically complex (lots of loops, command blocks, string operators, etc.) and the
bug has side effects (like creating a large file or hanging up the system)."
The problem is that the last sentence is missing the single word: "also" which should
be inserted after the word "It's". This is actually a serious omission because it
totally changes the reader's perception of the command (or at least this
reader's perception).
Without that word, the sentence sounds like the noexec option is only useful for
detecting logical errors, when in fact I believe the primary reason for the option is
to detect syntactical errors. I believe a secondary reason is to monitor
program flow which can be used to detect logical errors, such as the author
mentioned. However, the lack of one word totally changes the meaning of the sentence
to me.
|
Anonymous |
| Printed |
Page 237
Code example in paragraph 'Breakpoints' |
The following line in function _setbp:
elif [ $(echo $1 | grep '^[0-9]*') ]; then
should be
elif [ $(echo $1 | grep '^[0-9][0-9]*') ]; then
|
Anonymous |
| Printed |
Page 237
Code at 70% from top |
_linebp=( $(echo $( (for i in ${_linebp [*]} $1 ; do echo $i ; done ) | sort -n) ))
This statement is excessively complicated. The outer echo and its requisite command substitution, "$(echo ...)", is not needed. It converts the line-by-line output of sort into a space-delimited list presumably for the benefit of the interpreter's assignment to array _linebp. However, the interpreter doesn't need this help. It uses the same parsing mechanism for the assignment list as for echo. Additionally, the for loop doesn't need parentheses for piping to sort. The interpreter treats it as a single command anyway because of the low precedence of the pipe operator. A functionally equivalent but simpler statement is:
_linebp=( $( for i in ${_linebp [*]} $1 ; do echo $i ; done | sort -n) )
|
David McCracken |
| Printed |
Page 252
Code in first paragraph |
script=$(file * | grep 'shell script' | cut -d: -f1)
In theory, this produces a list of file names delimited by ':'. However, cut (at least as of version 6.12 and in this context) does not honor its output delimiter. It is supposed to use the same delimiter for output as for input by default but instead it prints each file name on a separate line. It does this even with the --output-delimiter option set to ":". The for f in $scripts then fails because the IFS character is still ':' but the list is delimited by newline. Replacing the cut command with awk -F: -v ORS=: '{print $1}' enables the script to run correctly.
|
David McCracken |
| Printed |
Page 013147572X
contains a related error which prevents their examples from working. |
i.e. see /quigley_unix_files/chap14/Ex_14.56-14.68/mainprog. The standard variation
<< is used instead of <<- but the ending terminator is indented causing the rest of
the script to be echoed.
Their discussion of here docs and example 13.89 (pp. 852) points out that the ending
label as well as the input can be indented as long as the <<- format is used.
|
Anonymous |
