Minor fixes

Author: ellysh

manuscript/BashScripting/scripts-features.md

@@ -542,7 +542,7 @@ Listing 3-9 shows the corrected version of the backup script. It handles an arbi
 {caption: "Listing 3-9. The script with an arbitrary number of input parameters", line-numbers: true, format: Bash}
 ![`make-backup.sh`](code/BashScripting/make-backup.sh)
 
-Bash has an alternative variable for `$@`. It is called `$*`. If you put it in double-quotes, Bash interprets its value as a single word. It interprets the `$@` variable as a set of words in the same case.
+Bash has an alternative variable for `$@`. It is called `$*`. If you put it in double quotes, Bash interprets its value as a single word. It interprets the `$@` variable as a set of words in the same case.
 
 Here is an example to explain the difference between the `$@` and `$*` variables. Suppose you call the backup script this way:
 {line-numbers: false, format: Bash}

manuscript/BashScripting/tools.md

@@ -85,7 +85,7 @@ Bash complains that you have passed too many parameters to `cd`. This command ex
 
 You have two option to suppress the word splitting mechanism:
 
-1. Enclose the path in double-quotes:
+1. Enclose the path in double quotes:
 {line-numbers: false, format: Bash}
 ```
 cd "/c/Program Files"
@@ -116,14 +116,14 @@ Figure 3-3 shows that this command still fails.
 {caption: "Figure 3-3. Result of the `cd` command"}
 ![cd result](images/BashScripting/cd-unexpected-token.png)
 
-This is the same error message as Bash has printed when launching Notepad++ in Figure 3-1. This problem happens because of the parentheses. They are part of the Bash syntax. It means that the shell treats them as a language construct. We met this problem when grouping conditions of the `find` utility. Escaping or double-quotes solves this issue too. Here are possible solutions for our case:
+This is the same error message as Bash has printed when launching Notepad++ in Figure 3-1. This problem happens because of the parentheses. They are part of the Bash syntax. It means that the shell treats them as a language construct. We met this problem when grouping conditions of the `find` utility. Escaping or double quotes solves this issue too. Here are possible solutions for our case:
 {line-numbers: true, format: Bash}
 ```
 cd /c/Program\ Files\ \(x86\)
 cd "/c/Program Files (x86)"
 ```
 
-Using double-quotes is simpler than escaping. Apply them to launch the Notepad++ this way:
+Using double quotes is simpler than escaping. Apply them to launch the Notepad++ this way:
 {line-numbers: false, format: Bash}
 ```
 "/c/Program Files (x86)/Notepad++/notepad++.exe"

manuscript/BashScripting/variables.md

@@ -136,7 +136,7 @@ The `rm` utility deletes all files ending in `file.txt`. The globbing mechanism
 rm report_file.txt myfile.txt msg_file.txt
 ```
 
-When referencing a variable, always apply the double-quotes. They prevent unwanted Bash expansions. The quotes solve problems of both our examples:
+When referencing a variable, always apply double quotes. They prevent unwanted Bash expansions. The quotes solve problems of both our examples:
 {line-numbers: true, format: Bash}
 ```
 filename1="my file.txt"
@@ -203,7 +203,7 @@ Here Bash tries to find and insert the variable called "prefix_". It happens bec
 cp "${prefix}_${name}" ~
 ```
 
-If you prefer to use the short form of the expansion, you have another option. Enclose each variable name in the double-quotes. Then Bash will not confuse them and nearby text. Here is an example:
+If you prefer to use the short form of the expansion, you have another option. Enclose each variable name in double quotes. Then Bash will not confuse them and nearby text. Here is an example:
 {line-numbers: false, format: Bash}
 ```
 cp "$prefix"_"$name" ~

manuscript/BashShell/commands-info.md

@@ -41,7 +41,7 @@ echo 123
 
 The dollar sign before a word tells Bash that it is a variable name. The interpreter handles it differently than a regular word. When Bash encounters a variable name in a command, it checks its variable list. If the name presents there, Bash inserts the variable value into the command. Otherwise, the interpreter places an empty string there.
 
-I> Enclosing variable names in double-quotes is a [good practice](https://www.tldp.org/LDP/abs/html/quotingvar.html). This way, you avoid potential errors. There is an example. Bash replaces the variable name by its value. The value contains [**control characters**](https://en.wikipedia.org/wiki/Control_character). The interpreter handles these characters. As a result, the inserted variable's value differs from one that is stored in memory. This effect leads to incorrect behavior of the program. Double-quotes prevent Bash from processing strings.
+I> Enclosing variable names in double quotes is a [good practice](https://www.tldp.org/LDP/abs/html/quotingvar.html). This way, you avoid potential errors. There is an example. Bash replaces the variable name by its value. The value contains [**control characters**](https://en.wikipedia.org/wiki/Control_character). The interpreter handles these characters. As a result, the inserted variable's value differs from one that is stored in memory. This effect leads to incorrect behavior of the program. Double quotes prevent Bash from processing strings.
 
 Let's come back to the `echo` command that prints the `PATH` variable. Figure 2-22 shows this output.
 

manuscript/BashShell/extra-features.md

@@ -658,7 +658,7 @@ Here `xargs` constructs the following call of the `cp` utility:
 cp -t ~/tmp test file.txt
 ```
 
-The command copies the `test` and `file.txt` files to the `~/tmp` path. However, none of these files exists. The reason for the error is the word splitting mechanism. Bash splits lines in words by the spaces. You can disable the mechanism by double-quotes. Here is an example for our command:
+The command copies the `test` and `file.txt` files to the `~/tmp` path. However, none of these files exists. The reason for the error is the word splitting mechanism. Bash splits lines in words by the spaces. You can disable the mechanism using double quotes. Here is an example for our command:
 {line-numbers: false, format: Bash}
 ```
 ls ~ | xargs -I % cp -t ~/tmp "%"

manuscript/BashShell/file-system.md

@@ -496,7 +496,7 @@ The first step is preparing the correct `find` call for searching the files. You
 find / -path "*/doc/bash/*" -name "*.html"
 ```
 
-When you pass the glob pattern to the `find` utility, always enclose it in double-quotes. The quotes do the same as the backslash before parentheses. They prevent Bash from expanding the patterns. Instead, Bash passes them to the `find` utility.
+When you pass the glob pattern to the `find` utility, always enclose it in double quotes. The quotes do the same as the backslash before parentheses. They prevent Bash from expanding the patterns. Instead, Bash passes them to the `find` utility.
 
 Figure 2-17 shows the result of our `find` call. You can see that it found HTML files correctly.
 
@@ -675,7 +675,7 @@ Using a text editor for checking dozens of files takes too much effort and time.
 grep "free software" /usr/share/doc/bash/README
 ```
 
-The first parameter of the utility is a string for searching. Always enclose it in the double-quotes. This way, you prevent Bash expansions and guarantee that the utility receives the string unchanged. Without the quotes, Bash splits the phrase into two separate parameters. This mechanism of splitting strings into words is called [**word splitting**](http://mywiki.wooledge.org/WordSplitting).
+The first parameter of the utility is a string for searching. Always enclose it in double quotes. This way, you prevent Bash expansions and guarantee that the utility receives the string unchanged. Without the quotes, Bash splits the phrase into two separate parameters. This mechanism of splitting strings into words is called [**word splitting**](http://mywiki.wooledge.org/WordSplitting).
 
 The second parameter of `grep` is a relative or absolute path to the file. If you specify a list of files separated by spaces, the utility processes them all. In the example, we passed the `README` file path only.
 
@@ -726,7 +726,7 @@ echo ~/*
 
 Run these commands. The first one lists files and subdirectories of the current directory. The second command does the same for the home directory.
 
-Do not enclose search patterns in double-quotes. Here is an example of the wrong command:
+Do not enclose search patterns in double quotes. Here is an example of the wrong command:
 {line-numbers: false, format: Bash}
 ```
 grep "free software" "*"