bash Idioms

Appendix. The bash Idioms Style Guide

This is a copy of the points in Chapter 11 but without the commentary and examples. There’s also a Markdown file in the examples directory so you can download and tweak it as desired, then render or include it as needed using pandoc or some other tool. Get the code from the book’s GitHub page.

The bash Idioms Style Guide Is Not Portable

This bash Idioms style guide is specifically for bash, so it is not portable to POSIX, Bourne, Dash, or other shells. If you need to write for those shells, you will need to test and tweak this guide to account for the supported syntax and feature of those shells.

Be especially careful in Docker or other containers where /bin/sh is not bash and /bin/bash may not even exist! This applies to Internet of Things and other constrained environments such as industrial controllers. See “bash in Containers” and “Shebang!”.

Readability

Readability of your code is important! Or as Python says, readability counts. You only write it once, but you (and others) will probably read it many times. Spend the extra few seconds or minutes thinking about the poor clueless person trying to read the code next year…it’s very likely to be you. There’s a balance and a tension between abstraction (Don’t Repeat Yourself) and readability:

• KISS (Keep It Simple, Stupid!).

• Readability: don’t be “clever,” be clear.

• Good names are critical!

• Always use a header.

• If at all possible, emit something useful for -h, --help, and incorrect ...