Errata

The two lines(counting from the bottom of page, Line 9 & 10

Line 10: ..foo .a .normal_dot_file
Line 9: normal_dot_file

To me, the above two lines should not be there(should not exist).
Am I wrong?

Note from the Author or Editor:
You are correct, thanks for the report. I'm not sure how those lines got in there, possibly a copy&paste error. But they should both be removed.

For clarity, here is the correct example, with a 'touch' line added at the top:

$ touch ..foo .a .normal_dot_file normal_file

$ ls -a
. .. ..foo .a .normal_dot_file normal_file

$ ls -d .??*
..foo .normal_dot_file

$ ls -d .[!.]*
.a .normal_dot_file

$ ls -d .[!.]* .??* | sort -u
..foo
.a
.normal_dot_file

The printf output in the last example on page 32 is wrong.

It has three spaces between the "=" and the "1.93" but there should be only one.

The book output is:

GigaHerz = 1.93

The correct output is:
GigaHerz = 1.93

Note from the Author or Editor:
Correct, thanks! Well, actually (using 2x __ since spaces get squashed):
-GigaHerz = __1.93
+__GigaHerz = 1.93

That is, the 2 "extra" spaces move from before "1.93" to before "GigaHerz".

The code is correct, the displayed output is wrong. Fixed in SVN 731332.

the web address is incorrect.
http://www.comptechdoc.org/os/linux/usersguide/linux_ugfilesup.html
should be
http://www.comptechdoc.org/os/linux/usersguide/linux_ugfilesp.html

_ugfilesup.html should not have the 2nd u just before p.html.

Note from the Author or Editor:
Remove extra 'u' as noted.

There should be no space between the "-" and the "p"

read - p "answer me this " ANSWER
read -p "answer me this " ANSWER

Note from the Author or Editor:
Remove extra space.

Add \n inside quotes in both printf statements, e.g,

... $CHOICE\n"
... color.\n"

Replace:
directorylist="Finished $(ls /)"
with
directorylist="Finished $(for i in /*;do [ -d "$i" ] && echo $i; done)"

Code specifies incorrect case of variable name in two places

if [ "$choice" != "n" ]; then
...
if [ "$choice" = "y" ]; then

should be

if [ "$CHOICE" != "n" ]; then
...
if [ "$CHOICE" = "y" ]; then

Note from the Author or Editor:
Wow, how have we missed that one for so long!? Thanks!

Note to production: fixed in SVN 798322.

Very first sentence, in the animal trap "warning" message:

Change "Some older scripts may use s to disable"
to
"Some older scripts may use stty -echo to disable"

Note from the Author or Editor:
OO.o manuscript contained "Some older scripts may use stty to disable...", note "stty" and not just "s". But I like Stuart Cooper's more specific version better.

So please change to: "Some older scripts may use <command>stty -echo</command> to disable..."

if (( $? )); then rm * ; fi

Should be:
if (( $? == 0 )); then rm * ; fi
or:
if (( ! $? )); then rm * ; fi

In the line beginning "When we quoted..." the reference is referred to as "{$1}". It should be "${1}"

Note from the Author or Editor:
Change to ${1} as noted.

The script if test clause is doing the opposit the author meant it to do, which is to have a verbose
output when -v is an argument
Instead of: if (( VERBOSE == 0 ))
The script should read: if (( VERBOSE == 1 ))

Note from the Author or Editor:
Change instance in "if" statement to "if (( VERBOSE == 1 ))" as noted.

On page 105 we are given:
mv "${FN}" "${FN/.bad/.bash}"
even though this kind of substitution is not anchored the example given on page 106 : "subaddon.bad would leave us with subashdon.bad" is wrong this would have only occured if the line on page 105 read:
mv "${FN}" "${FN/bad/bash}" (without the "." period characters).

The outcome for the example given on page 106 from the line that is actually printed on page 105 would have resulted in subaddon.bash which is what we would have needed.

Note from the Author or Editor:
I agree, nice catch.

To fix:
1) On pg 105, add comment and remove the dots in the mv example at bottom:
mv "${FN}" "${FN/.bad/.bash}"
becomes
# Not anchored, don't do this
mv "${FN}" "${FN/bad/bash}"

2) On pg 106, at end of 1st para add:
Using a dot anchored expression like this would work in the example case:
# Anchored, so this is better, but TEST first
mv "${FN}" "${FN/.bad/.bash}"

It reads:
dashes -c= 50
dashes -cx
whereas it should have read:
dashes -c = 50
dasshes -c x

Note from the Author or Editor:
Agree, should add a space after the "-c" part to read:

dashes -c = 50
dashes -c x

It mentions in "see also"
? help getopts
? help getopt

There is only getopts AFAIK, at-least in my bash (version 4.1.10(4)-release)

Note from the Author or Editor:
Confirmed, 'getopts' is correct; 'getopt' is my mistake. I very much fear I was thinking of Perl when I added that one. :-/

"help getopt" (note, no 's') should be removed.

This is an errata to an errata I just confirmed.

In the previous one I said that the echo lines were OK because they had double-quotes, but they don't.

Note from the Author or Editor:
Correct:

mkdir "$PRIV1" || { echo "Unable to mkdir '$PRIV1'" ; exit 4; }
mkdir "$PRIV2" || { echo "Unable to mkdir '$PRIV2'" ; exit 5; }

minus sign '-' should be used
instead of figure dash '&#8210;' within the code itself,
in getopts_example

sample code from website encounters an error too.

Note from the Author or Editor:
I can't tell the difference in the printed version, but will fix the example script.

The code snippet 2 & 3 in bold that trims white space using a simple pattern match doesn't actually do so.
while read; do echo "~~${REPLY## }~~"; done < whitespace
while read; do echo "~~${REPLY%% }~~"; done < whitespace

At its best, it will remove one space and leave the rest. So if you input the first snippet something like,
~~ This line has leading spaces.~~
It will print,
~~ This line has leading spaces.~~
Note, there are 2 leading spaces in input and 1 leading space in output.

Note from the Author or Editor:
Prod: Note, this errata says "bash Cookbook: Rough Cuts Version" but it is really "bash Cookbook 2nd edition" print, page 328 as noted. The repo is now updated, see 4667f09.

Wow, that's a great catch, thank you! It _seems_ to work using our `whitespace` file example, but you are correct, it does not.

To make it work, we need `shopt -s extglob` which we mention later but did not use here, and `+( )` to match one *or more* spaces.

Here's a more clear example:
```
# Make sure extended pattern matching operators are off (unset)
$ shopt -u extglob

# Fail: Leading SPACE only, original = removes only 1 space
$ while read; do echo "~~${REPLY## }~~"; done < <(echo -e "Zero leading\n One leading\n Two leading\n Three leading")
~~Zero leading~~
~~One leading~~
~~ Two leading~~
~~ Three leading~~

# Fail: Leading SPACE only, modified, requires: shopt -u extglob (which is not set)
$ while read; do echo "~~${REPLY##+( )}~~"; done < <(echo -e "Zero leading\n One leading\n Two leading\n Three leading")
~~Zero leading~~
~~ One leading~~
~~ Two leading~~
~~ Three leading~~


# Fail: Trailing SPACE only, original = removes only 1 space
$ while read; do echo "~~${REPLY%% }~~"; done < <(echo -e "Zero trailing\nOne trailing \nTwo trailing \nThree trailing ")
~~Zero trailing~~
~~One trailing~~
~~Two trailing ~~
~~Three trailing ~~

# Fail: Trailing SPACE only, modified, requires: shopt -u extglob (which is not set)
$ while read; do echo "~~${REPLY%%+( )}~~"; done < <(echo -e "Zero trailing\nOne trailing \nTwo trailing \nThree trailing ")
~~Zero trailing~~
~~One trailing ~~
~~Two trailing ~~
~~Three trailing ~~


# Enable extended pattern matching operators
$ shopt -s extglob

# Works: Leading SPACE only, modified, requires: shopt -u extglob
$ while read; do echo "~~${REPLY##+( )}~~"; done < <(echo -e "Zero leading\n One leading\n Two leading\n Three leading")
~~Zero leading~~
~~One leading~~
~~Two leading~~
~~Three leading~~

# Works: Trailing SPACE only, modified, requires: shopt -u extglob
$ while read; do echo "~~${REPLY%%+( )}~~"; done < <(echo -e "Zero trailing\nOne trailing \nTwo trailing \nThree trailing ")
~~Zero trailing~~
~~One trailing~~
~~Two trailing~~
~~Three trailing~~


# The originals will STILL FAIL to remove more than 1 space
$ while read; do echo "~~${REPLY## }~~"; done < <(echo -e "Zero leading\n One leading\n Two leading\n Three leading")
~~Zero leading~~
~~One leading~~
~~ Two leading~~
~~ Three leading~~

$ while read; do echo "~~${REPLY%% }~~"; done < <(echo -e "Zero trailing\nOne trailing \nTwo trailing \nThree trailing ")
~~Zero trailing~~
~~One trailing~~
~~Two trailing ~~
~~Three trailing ~~
```

In alias wgetdir line:
replace: --non-verbose
With: --no-verbose

\$0 in wrong place:

current:
{ print \"$HOSTNAME\", \$0 }"

correct:
{ print \$0, \"$HOSTNAME\" }"

Hi
Bad ed script:
----cut----
1
i
Header 1
Header 2
.
w
q
----end----

This should by:
----cut----
1i
Header 1
Header 2
.
w
q
----end----

and next:
ed -s file <ed_script

Explanation:
1 in first line is alias 1p (default commant - print)

Option -s turn off only diagnostic data.

Best
sjd
(lover of ed editor :-)

Note from the Author or Editor:
Nice catch! I learned something new, thanks.

My script does work, but not quite the way I thought it did. The corrected script is better and more accurate.


REPLACE top of ed script as follows:
---- begin cut here ----
$ cat ed_script
1
i
---- end cut here ----

WITH:
---- begin cut here ----
$ cat ed_script
1i
---- end cut here ----


REPLACE entire para beginning:
---- begin cut here ----
The 1 in the ed script means to...
---- end cut here ----

WITH:
---- begin cut here ----
The 1p in the ed script means to go to the first line and then go into insert mode, and the next two lines are literal. A single . all by itself on a line exits insert mode, w writes the file and q quits. The -s suppresses diagnostic output specifically for use in scripts.
---- end cut here ----

Missing leading 'n' in:

>> file Direct file descriptor n to file; append...


correct:

n>> file Direct file descriptor n to file; append...

Table A-10, I/O redirection, is missing an entry for the 'Here strings' operator, <<<, which is referenced at various other points in the book.

Note from the Author or Editor:
Confirmed. After "<< label Here-document." add:
<<< word Here-string.

This example is not suitable for enterprise or multiuser access (see the "More Resources" section in the
Preface [for clarity add: "of this appendix").