Bash Scripting – Best Practices

1. Use a portable shebang


instead of

bash can have various locations Eg.: /sbin/bash , /usr/local/bin/bash , /usr/bin/bash

Note: This applies for other scripting languages as well, not only for bash .

2. Perform “Sanity Checks”

Sanity checks are run-time tests  that protect the script from running in unsuitable environments .

Before running the actual code of your script, do some checks to assure that nothing unexpected will happen .

Don’t forget to include meaningful error messages if one of the sanity checks fails.

Examples of common checks performed in bash scripts:

2.1 Test if the script is being run by the desired user

2.2 Test if you have read / write access in certain locations

2.3 Test if the programs are in $PATH

If you are planning to use an “non-standard command”, don’t forget to test its existence first (in this way you can safely rely on it):

3. Clean up after yourself

It’s a very common for bash scripts to write data in temporary files . Sometimes those temporary files can become rather large (or numerous).

By using trap we will be able to trigger our cleanup function when certain conditions are met .

4. Make good use of stdout and stderr .

It’s always a sign of good taste, to echo informational messages to stdout and errors to stderr .

5. Use “$var” (double quotes) when working with file variables .

In bash file names are dangerous strings that contain all kinds of “dangerous characters” like spaces, newlines or tabs .


Let’s create a file called: “a file with spaces”:

Now let’s keep this filename in a bash variable called $var1:

If we use the variable name without quotes and we try to test the file existence, we will encounter errors:

So the right approach to avoid those kind of issues if tho use the double quotes:

Why was the error produced in the first place ? Beacause “[” is actually a program that expects a predefined number of arguments . Because of the spaces (in the first example) “[” was actually receiving more arguments than was expecting .

5. Choose your suitable returning codes

If you want to know more about this issue, please take a look to this article: Please, don’t use exit(-1) by Renato Cunha .

Other things you might want to take in consideration

  • Include your name, the creation date, and some form of contact info (forum, irc, etc.) ;
  • Describe when and how is your script supposed to be used ;
  • Don’t give your script a cryptic name . Come with something descriptive . If you cannot find anything descriptive enough, at least come with something nice or funny ;
  • Don’t forget to add use the .sh suffix – otherwise things can get pretty confusing and the user will have to open up the file to see what kind of script he’s using .

4 thoughts to “Bash Scripting – Best Practices”

  1. Thanks for you kind feedback Dear Robot, unfortunately the art of writing maintainable English sentences is still a mystery for me.

    PS: Should I change the captcha plugin ? Was it to easy for you ?

  2. I always test my commands in a loop with $ while [ 1 ]; do time cmd; sleep 0.5s; done to and compare it to other alternative . You’ll be surprised of some results… I hardly ever use ${#FOO} to get the length of a string anymore, I always user $ echo -n "$FOO" | wc -c, which tunrns out is up to x3 faster. And The same with $ myCmd <<< "$FOO", takes twice as long to run as $ echo -n "$FOO" | myMcd.

Leave a Reply

Your email address will not be published. Required fields are marked *

Are we human, or are we dancer *