A few words about Bash scripting

Bash is… the middle man between the user and the system.

I’ve been scripting in Bash for more than 20 years and I can’t imagine doing sysadmin tasks without it.

I used to say “You don’t need to be a sysadmin to learn Bash but you’re not sysadmin without advanced Bash skills”. I’ve met a lot of sysadmins on my path, some were less experienced than others but all of them were scripting in Bash on daily basis, constantly improving their scripting skills.

A lot of scripters aren’t satisfied with their coding style which is often a mix of few different styles – this is to be expected as the courses/tutorials/cheat sheets
available online are explaining the same subjects differently, sometimes demonstrating the use of inappropriate method backed up with working sample code, naturally, the sample code works just fine, acting as proof of being the right method – that’s how bad habits are born.

While the above could be avoided by learning Bash from the official manual exclusively, it’s rarely the case, especially for people new to Bash as the manual isn’t really newbie-friendly.

In this post, I’ll describe some core principles. Applying such rules should help you to write good scripts that can be executed across multiple servers.

 

 

1. Make a list of external utilities (anything that’s not native Bash) used by your script and perform validation.

An example of the most basic utility – ‘tar’ – it’s most probably installed on the host you’re writing the script but even the most basic utilities might be missing (for example – CentOS8 minimal install comes without tar by default) and lack of validation could lead to unexpected results, sometimes dangerous, depending on what the script does next, so, instead of:

validate first:

 

or go as far as starting from checking for ‘which’ utility, most major distributions come with ‘which’ installed but if a server is compromised or someone (accidentally) deleted it – it’s worth checking:

 

It’s best to place all these tests inside a function that will be called before anything else runs:

 

 

2. Make the script noisy.

While the script is a work in progress you need to know what’s going on during execution, debugging messages with certain variables dump will save a lot of time, naturally, there’s no need to dump simple variables containing static values (i.e. version=’12.3′), limit the noise to dynamic variables containing other variables and/or utility output:

assume the $dupes variable is used few times in the script, one inside nested ‘validate_inventory()’ function, which itself is inside ‘process_hosts()’ function:

A trivial way to gather valuable info each time the script is tested via execution. Once the script is finished, the debug lines can be either deleted/commented out or enabled via – for example – –verbose/-v switch.

 

 

3. Look for a native alternative where possible.

It’s not only a good way to learn something new about Bash, doing stuff natively where possible reduces the need for using external tools, let’s take port probing as an example:

 

Leave a Reply

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