Why?

On the one hand, you need to be very careful with BASH – the language is very peculiar and it is easy to do something without error handling, unreadable and unsupported.

At the same time, it is very effective in many scenarios.

I have an internal rule - if it can be stacked in several screens, and especially complex functionality is not used, then you can stay on BASH. If not, then you need to use something else. For example, Python.

File header

About all my scripts start like this:

#!/usr/bin/env bash
#
# Some script description.
#
set -eEuo pipefail
cd "$(dirname "$0")"
set -x

I’ll explain line by line:

  1. Explains to the kernel that you need to run the env application, and already it will find the bash application on the way. This is useful for cases where multiple ‘bash` interpreters are installed on the system.
  2. Next, a brief description of the script.
  3. set -euo pipefail says to crash on errors, otherwise they are ignored (which is hardly a good idea)
  4. cd "$(dirname "$0")" – goes to the current script folder (quite often it is necessary that there is a certain current folder that depends on the position of the script, and not some random one)
  5. sets says to print the command text before execution – actually creates the execution log, which is convenient

Is there something else?

At one time I wanted to make a very large description of how to process different types of files on BASH (json, xml, csv), etc., but this will certainly violate the main principle - to use BASH to a minimum.

So if you need something else, it’s easy to find it online, and if you need a lot of things, then it’s better not to do so.