remove test change

[wiki.git] / doc / safe-shell.mdwn

diff --git a/doc/safe-shell.mdwn b/doc/safe-shell.mdwn
index ff2dde840b9bb467c44209a2e641e2cf4a58d19e..4b6efbd590e61c57ce2c08391fd881451bfd89b4 100644 (file)
--- a/doc/safe-shell.mdwn
+++ b/doc/safe-shell.mdwn
@@ -17,9 +17,9 @@ One of shell's chief advantages is that it's easy to call out to the huge
 variety of command-line utilities available. Much of that functionality will be
 available through libraries in Python or other languages. For the handful of
 things that aren't, you can still call external programs. In Python, the
-[subprocess](http://docs.python.org/2/library/subprocess.html) module is very
+[subprocess](https://docs.python.org/2/library/subprocess.html) module is very
 useful for this. You should try to avoid passing `shell=True` to `subprocess` (or using `os.system` or similar functions at all), since that will run a shell, exposing you to many of the same issues as plain shell has. It also has two big advantages over shell — it's a lot easier to avoid
-[word-splitting](http://www.gnu.org/software/bash/manual/html_node/Word-Splitting.html) or similar issues, and since calls to subprocess will tend to be relatively uncommon, it's easy to scrutinize them especially hard. When using `subprocess` or similar tools, you should still be aware of the suggestions in "Passing filenames or other positional arguments to commands" below.
+[word-splitting](https://www.gnu.org/software/bash/manual/html_node/Word-Splitting.html) or similar issues, and since calls to subprocess will tend to be relatively uncommon, it's easy to scrutinize them especially hard. When using `subprocess` or similar tools, you should still be aware of the suggestions in "Passing filenames or other positional arguments to commands" below.
 
 ## Shell settings
 
@@ -33,7 +33,7 @@ In dash, `set -o` doesn't exist, so use only `set -euf`.
 
 What do those do?
 
-### [`set -e`](http://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html)
+### [`set -e`](https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html)
 
 If a command fails, `set -e` will make the whole script exit, instead of just
 resuming on the next line. If you have commands that can fail without it being
@@ -41,22 +41,22 @@ an issue, you can append `|| true` or `|| :` to suppress this behavior —
 for example `set -e` followed by `false || :` will not cause your script to
 terminate.
 
-### [`set -u`](http://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html)
+### [`set -u`](https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html)
 
 Treat unset variables as an error, and immediately exit.
 
-### [`set -f`](http://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html)
+### [`set -f`](https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html)
 
 Disable filename expansion (globbing) upon seeing `*`, `?`, etc..
 
 If your script depends on globbing, you obviously shouldn't set this. Instead,
 you may find
-[`shopt -s failglob`](http://www.gnu.org/software/bash/manual/html_node/The-Shopt-Builtin.html) useful, which causes globs that don't get expanded to cause
+[`shopt -s failglob`](https://www.gnu.org/software/bash/manual/html_node/The-Shopt-Builtin.html) useful, which causes globs that don't get expanded to cause
 errors, rather than getting passed to the command with the `*` intact.
 
-### [`set -o pipefail`](http://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html)
+### [`set -o pipefail`](https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html)
 
-`set -o pipefail` causes a pipeline (for example, `curl -s http://sipb.mit.edu/
+`set -o pipefail` causes a pipeline (for example, `curl -s https://sipb.mit.edu/
 | grep foo`) to produce a failure return code if any command errors. Normally,
 pipelines only return a failure if the last command errors. In combination with
 `set -e`, this will make your script exit if any command in a pipeline errors.
@@ -65,9 +65,9 @@ pipelines only return a failure if the last command errors. In combination with
 
 Whenever you pass a variable to a command, you should probably quote it.
 Otherwise, the shell will perform
-[word-splitting](http://www.gnu.org/software/bash/manual/html_node/Word-Splitting.html)
+[word-splitting](https://www.gnu.org/software/bash/manual/html_node/Word-Splitting.html)
 and
-[globbing](http://www.gnu.org/software/bash/manual/html_node/Filename-Expansion.html),
+[globbing](https://www.gnu.org/software/bash/manual/html_node/Filename-Expansion.html),
 which is likely not what you want.
 
 For example, consider the following:
@@ -94,7 +94,7 @@ script received. Do that with:
     wrapped-command "$@"
 
 See ["Special Parameters" in the bash
-manual](http://www.gnu.org/software/bash/manual/html_node/Special-Parameters.html)
+manual](https://www.gnu.org/software/bash/manual/html_node/Special-Parameters.html)
 for details on the distinction between `$*`, `$@`, and `"$@"` — the first
 and second are rarely what you want in a safe shell script.
 
@@ -112,6 +112,14 @@ Another approach is to prefix each filename with `./`, if the filenames are expe
 
 TODO: mumble `mktemp`?
 
+## Use [ShellCheck](https://www.shellcheck.net/) to check for bugs
+
+The [ShellCheck](https://www.shellcheck.net/) linter automatically catches a number of the above mistakes and more.  Run it regularly, ideally with integration into your editor and your test suite, and address all of its diagnostics.  Even warnings that might sound unimportant could be obscuring important bugs.
+
+## Other resources
+
+Google has a [Shell Style Guide](https://google.github.io/styleguide/shell.xml). As the name suggests, it primarily focuses on good style, but some items are safety/security-relevant.
+
 ## Conclusion
 
 When possible, instead of writing a "safe" shell script, *use a higher-level