The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".
The following errata were submitted by our customers and approved as valid errors by the author or editor.
| Version |
Location |
Description |
Submitted By |
Date submitted |
Date corrected |
|
Page Example 9-6: fiddle-ifs.sh
function Read_A_File |
The Read_A_File function declares a local variable for the file to be read, expecting it as the first parameter:
function Read_A_File {
local file="$1"
...
But this variable is never used and the file read is obtained from the global variable IFS_TEST_FILE:
...
done < $IFS_TEST_FILE
...
I think it would be more flexible to use the parameter:
...
done < $file
...
and invoke the function that way:
...
Read_A_File $IFS_TEST_FILE
...
Note from the Author or Editor:
Great catch, thank you. You're correct, the code was supposed to be exactly as you describe, but we goofed it up. I've fixed it in the book code and the example code on Github.
* ORA: [master 73586a0] fiddle-ifs.sh: fix Read_A_File per errata 190293
* Github: [main de93a9d] fiddle-ifs.sh: fix Read_A_File per errata 190293 |
Miguel Macías |
Feb 11, 2023 |
|
|
Page Example 9-3
fancy_mapfile.sh |
In the notes of the script fancy_mapfile.sh (Example 9-3) it is indicated (note 2) that
node_count="$(cat $HOSTS_FILE | wc -l)"
is not a “useless use of cat” (since it prevents the filename from appearing in the wc output). But as it is insisted in many other parts of the book, it would be faster and more efficient to avoid the execution of such a command:
node_count="$(wc -l < $HOSTS_FILE)"
Don't you think?
Note from the Author or Editor:
Another great catch, thank you again. Redirecting STDIN+ is simpler, more efficient, and more consistent with the rest of the book and our goals.
I've fixed it in the book code and the example code on Github.
* ORA: [master 241ebeb] fancy_mapfile.sh/ch09: change "cat" to "<" per errata 190326
* Github: [main d1e940f] fancy_mapfile.sh: change "cat" to "<" per errata 190326 |
Miguel Macías |
Feb 12, 2023 |
|
|
Page 4
Under "Closing Compound Commands" |
"A quirk of bash requires a specific syntax for how you close the
compound command. It must end with either a semicolon or a
newline before the closing brace. If you use a semicolon, there
needs to be whitespace before the brace so that the brace can be
recognized as a reserved word (otherwise it gets confused with the
closing brace of shell variable syntax, as in ${VAR}, for example)."
Whitespace between a semicolon and a closing brace is not required. I haven't found any construct in which the brace can be confused with shell variable syntax. The semicolon, like a newline, is enough to let the shell know that the "}" is a full token.
Of course whitespace is a good idea anyway for legibility.
For example, this is valid (the space after the opening brace is required):
```
{ echo ${USER};}
```
Tested with bash 3.0, 5.1.16, and 5.3-beta.
Note from the Author or Editor:
I agree I can't make a problem happen either. Carl can't either, and he wrote that part. He says:
'Now that I think about it, though, I remember having problems with: { ... ;} in cases like the if-less if statement. I thought, just now, it might be a matter of which version of bash, but I just tried a 3.2 version and it worked. Hmmmmm.... I know I saw that problem somewhere and the "fix" was to add the space. Too long agon. Well, maybe we just drop the "If you use..." sentence.'
I agree and have removed that sentence. |
Keith Thompson |
Jan 20, 2025 |
|
|
Page 17
Paragraphs 2..3 |
"""
Unlike other languages, in bash until is just ! while, or “execute block while criteria exit status is not zero”:
until <CRITERIA>; do <BLOCK>; done
### Same:
! while <CRITERIA>; do <BLOCK>; done
"""
`until` is equivalent to `while !`, not `! while`.
`! while` is also legal, but it negates the return status of the loop without affecting the meaning of the loop condition.
Note from the Author or Editor:
Yes, you've got us, nice catch. `help until` is pretty clear too, with "Execute commands as long as a test does not succeed." In fact in my simple testing `! while` has the opposite practical effect of `until`, though as you say for different reasons.
Corrected in: [master edc9122] ch02: corrected "while !" discussion of "until" per errata 202809 |
Keith Thompson |
Mar 01, 2025 |
|
|
Page 26
Near bottom of code block |
There is a missing single quote in `echo '` in the line after callout 15. Somehow I managed to accidentally delete it while doing copyediting revision. It is already fixed in the electronic versions and in the examples on Github, but the first print edition had already gone to the printer when I caught it.
|
JP Vossen |
Mar 26, 2022 |
|
|
Page 34
Suffix removal table |
In the table of examples showing the various ways to remove from the right side of the string, the filename "img.1231.jpg" gets abbreviated to "img.1234" instead of "img.1231".
Note from the Author or Editor:
Correct, thanks for catching that. I've changed both instances of the slightly odd "1231" to "1234" to match the answer in the repo, since that seems a simpler and more expected pattern.
[master fdd190f] ch04:includes/suffix.csv: "1231" vs. "1234" bugfix per errata from Andy Lester |
Andy Lester |
Jul 07, 2022 |
|
|
Page 37
Middle of table of parameter expansions |
${var:-default} is listed twice, with two different definitions. The second occurrence should be ${var:=default}.
Note from the Author or Editor:
Nice catch, thank you! I have fixed that in the repo and pushed the fix to O'Reilly and Github. |
Macon Gambill |
Apr 16, 2022 |
|
|
Page 43
code example for case statement. |
According to bash error message: "continue: only meaningful in a `for', `while', or `until' loop".
Tested on bash version 5.2.15
That means the keyword "continue" will not work on case statement/conditional constructs.
Note from the Author or Editor:
Nice catch, thanks. I'm not sure how that incorrect `continue` got in there, and that example is only in the text, it is not in the examples directory which have automated tests.
I've fix that in the repo and also clarified the behavior of _n_ or _y_. |
Andy |
Aug 18, 2024 |
|
| PDF |
Page 64, 68
# Delete the entire list |
From Keith Thompson:
PDF page 64
> `# Delete the entire list`
> `unset -v mylist`
...
> Delete the entire list. Beware of unset because there’s a subtle
> catch. If you happen to have a file with the same name as a variable,
> globbing can hurt you, and you can clobber unexpected things. To avoid
> that, it’s best to quote your variable. Its even safer to use -v to
> force unset to treat your argument as a shell variable, like unset -v
> 'list'.
I don't believe globbing would be an issue. `unset -v mylist` refers
only to the variable `$mylist`; the existence of a file called "mylist"
is irrelevant, and `unset -v "mylist"` doesn't help.
The only thing the `-v` does is avoid unsetting a function `mylist`
if there is no variable `$mylist`. For most purposes, a simply
`unset mylist` should be just fine (though the `-v` is more explicit).
Same with `unset -v myhash` on page 68.
Note from the Author or Editor:
You're right, this actually has nothing to do with files or globbing, I remembered the problem wrong. The point *should* be to use `-v` or `-f` to be explicit that you intend to unset a *variable* or a *function*, respectively. I have updated and clarified that in commit 3349a2d. |
JP Vossen
|
Aug 31, 2025 |
|
|
Page 71
4th paragraph |
The $$RANDOM should be $RANDOM.
Note from the Author or Editor:
That's correct, we had an extra `$` in the harder to read one-liner in the comments, arguably proving that it is harder to read and debug. :-)
Nice catch, thank you.
Fixed in: [master 88f8386] ch07: corrected bad $$RANDOM per errata 203253 |
Steve Siano |
Jul 25, 2025 |
|
|
Page 85-86
`read` commands |
From Keith Thompson: two problems with the `read` examples: missing `IFS` and missing trailing ; in 2 places.
Under "One more try:" it should say:
```
grep '^nobody' /etc/passwd | { \
IFS=':' read user shadow uid gid gecos home shell; \
echo "$user | $shadow | $uid | $gid | $gecos | $home | $shell"; \
}
```
Note that I've also added a semicolon at the end of the third line.
Note from the Author or Editor:
2021-10-24 d2b25899 = has it right, but in one line!
2022-02-16 db60acc3 = an editor breaking up my too-long line broke it and we missed that:
-$ grep '^nobody' /etc/passwd | { IFS=':' read user shadow uid gid gecos home shell; \
- echo "$user | $shadow | $uid | $gid | $gecos | $home | $shell"; }
+$ grep '^nobody' /etc/passwd | { \
+ read -d':' user shadow uid gid gecos home shell; \
+ echo "$user | $shadow | $uid | $gid | $gecos | $home | $shell" \
+ }
2022-04-30 e426ee9b adds the IFS line back per a previous errata from Macon Gambill 2022-04-30
I fixed 2025-07-04 in 00762dfc as:
```
$ grep '^nobody' /etc/passwd | { \
IFS=':' read user shadow uid gid gecos home shell; \
echo "$user | $shadow | $uid | $gid | $gecos | $home | $shell"
}
```
|
JP |
Jul 19, 2025 |
|
|
Page 86
Top of page (pipeline starting with grep) |
The first example on page 86 is identical to the last example on page 85, meaning it won't produce the expected output if executed as shown. I imagine the intent was to remove the -d':' argument from the read command and instead use prefix assignment to set IFS to ':', e.g.:
grep '^nobody' /etc/passwd | { \
IFS=':' read user shadow uid gid gecos home shell; \
echo "$user | $shadow | $uid | $gid | $gecos | $home | $shell"; }
Note from the Author or Editor:
You are correct. I've upgraded this one to serious because as written it not only does not work, but it's not at all clear why if fails.
I've committed a fix to the book code, but this one is not in the example code so that is unchanged. |
Macon Gambill |
Apr 24, 2022 |
|
|
Page 130
second item under the first bullet point |
> And unless you are using ~=, in which case you can't quote the regular expression!
"~=" should be "=~"
Note from the Author or Editor:
Thanks! This is in the a style guide file that is included in 2 places, and used to generate the `bash_idioms_style_guide.html` and `bash_idioms_style_guide.md` docs. I've fixed it in the ORA Git and on Github. |
Patrick Brinich-Langlois |
Sep 18, 2022 |
|
|
Page 141
first sentence |
"~=" is used instead of "=~"
Note from the Author or Editor:
Thanks! This is in the a style guide file that is included in 2 places, and used to generate the `bash_idioms_style_guide.html` and `bash_idioms_style_guide.md` docs. I've fixed it in the ORA Git and on Github. |
Patrick Brinich-Langlois |
Sep 18, 2022 |
|