Bash reference manual feedback

[David Apps]

I hope that you are well.

Thank you for your work on this great software.

I have some feedback about the document at:
http://www.gnu.org/software/bash/manual/bash.html
> the Bash shell (version 5.1, 21 December 2020).

I do not know how you prefer to receive feedback.

When I quote the document, I begin the line with "> ".

When my feedback is about a specific part of the document, I try to 
show the section of the document that my feedback is about. I begin the 
line with "h# ", where "#" is a number that shows the HTML heading 
level.

I try to number my feedback in case that makes it easier to refer to. 
For example, you might want to tell me if some items show that I have 
misunderstood something.

1. The document uses both "readline" and "Readline". I do not know 
whether there is a subtle distinction that I am missing. If not, 
perhaps the document could use the same version of the name throughout.

2. The document uses "may" to mean more than one thing. Perhaps use 
alternatives to "may" or use "may" to mean only one thing to make the 
meaning clearer.

h4 3.5.8.1 Pattern Matching

> it might be equivalent to ‘[aBbCcDdxXyYz]’, for example.

3. [aBbCcDdxYyZz] or [aAbBcCdxXyYz] might be more likely.

h3 4.1 Bourne Shell Builtins

> If the -T option is enabled, source inherits any trap on DEBUG; if it 
is not, 
> any DEBUG trap string is saved and restored around the call to source, 
> and source unsets the DEBUG trap while it executes. 
> If -T is not set, and the sourced file changes the DEBUG trap, 
> the new value is retained when source completes. 
... 
> This builtin is equivalent to source.

4. Perhaps it would be clearer to explain that "."and "source" are 
equivalent before mentioning "source" here.

h4 4.3.2 The Shopt Builtin

> sourcepath

> If set, the source builtin uses the value of PATH to find the 
directory 
> containing the file supplied as an argument. This option is enabled 
by default.

5. Perhaps change "the source builtin uses" to "the . or source 
builtins use" or "the source (but not the .) builtin uses" (as 
appropriate).

h3 5.2 Bash Variables

> Expanded and executed similarlty to BASH_ENV (see {Bash Startup 
Files})

6. Perhaps change "similarlty" to "similarly".

h3 6.3 Interactive Shells

> • {Interactive Shell Behavior}| |What changes in a interactive shell?

7. Perhaps change "a interactive" to "an interactive".

h3 6.11 Bash POSIX Mode

> 32. When expanding the ‘*’ special parameter in a pattern context 
where 
> the expansion is double-quoted does not treat the $* as if it were 
> double-quoted.

8. Perhaps adding a comma or changing the wording would make this 
clearer.

h3 6.12 Shell Compatibility Mode

> * the shell does not print a warning message if an attempt is made to
> use a quoted compound assignment as an argument to declare (declare -a
> foo=’(1 2)’). Later versions warn that this usage is deprecated

9. It is probably unhelpful to use the "’" character here.

h3 7.2 Job Control Builtins

> Supplying the -f option, when job control is enabled,
> forces wait to wait for each pid or jobspec to terminate before
> returning its status, intead of returning when it changes status.

10. Perhaps change "intead" to "instead".

h4 8.2.1 Readline Bare Essentials

> (Depending on your configuration, the Backspace key be set to delete
> the character to the left of the cursor and the DEL key set to delete
> the character underneath the cursor, like C-d,
> rather than the character to the left of the cursor.)

11. Perhaps change  "key be set" to key might be set" or "key may be 
set" or something else.

h4 8.2.3 Readline Killing Commands

> Kill from the cursor the start of the current word, or,
> if between words, to the start of the previous word.

12. Perhaps change "cursor the" to "cursor to the".

h4 8.3.1 Readline Init File Syntax

> Variable Settings

> Key Bindings

13. Perhaps make these into subheadings.

> The bind -p command displays Readline function names and bindings in a
> format that can put directly into an initialization file.

14. Perhaps change "can put" to "you can put" or "can be put" or "can 
go".

h4 8.4.7 Keyboard Macros

> Print the last keboard macro defined in a format suitable for the

15. Perhaps change "keboard" to "keyboard".

h4 8.4.8 Some Miscellaneous Commands

> A negative count searches for previous occurrences.

> A negative count searches for subsequent occurrences.

16. Perhaps change "negative count" to "negative argument", because 
this is what the rest of the document uses.

h3 8.7 Programmable Completion Builtins

> -E, and both take precedence over -I

17. Perhaps add a period to the end of the sentence.

h3 8.8 A Programmable Completion Example

> The -o bashdefault option brings in the rest of the "Bash default"
> completions – possible completion that Bash adds to the default
> Readline set.

18. Perhaps change "possible completion" to "possible completions".

h3 9.2 Bash History Builtins

> When any of the -w, -r, -a, or -n options is used,
> if filename is given, then it is used as the history file.

19. Perhaps change this to: 
"When you use the filename argument with the -w, -r, -a, or -n options, 
Bash uses that file as the history file."

h4 9.3.3 Modifiers

> If new is is null, each matching old is deleted.

20. Perhaps change "is is" to "is".

h3 10.1 Basic Installation

> bash-4.2$ ./configure --help

21. Perhaps remove the prompt string.

h3 10.3 Compiling For Multiple Architectures

> If you have to use a make that does not supports the VPATH variable,

22. Perhaps change "supports" to "support".

h3 10.5 Specifying the System Type

> but need to determine by the type of host Bash will run on.

23. Perhaps change "need" to "needs" or "need to determine by" to 
"determines from".

h3 10.8 Optional Features

> libintl library instead ofthe version in lib/intl.

24. Perhaps change "ofthe" to "of the".

> * Bash implements the ! keyword to negate the return value of a
> pipeline (see {Pipelines}). Very useful when an if statement needs to
> act only if a test fails. The Bash ‘-o pipefail’ option to set will
> cause a pipeline to return a failure status if any command fails.

25. Should this be 2 separate list items?

> Commands specified with an RETURN trap are executed before execution

26. Perhaps change "an" to "a".

Thank you.

David