Automation of a repetitive task tends to bring joy to the Bash developer: instead of typing endless commands again and again, a script simply does the work repetitively. Bash is ideal for such automation. This series will get you started!

What Is Bash automation?

The Bash shell is a powerful Linux shell which allows in-depth automation of repetitive tasks. Not only is the Bash Linux shell a prime choice for DevOps, database and test engineers alike, every day users can benefit from slowly learned, ever-increasing Bash skills. Bash is also a scripting and coding language that grows on you. I have been actively coding in Bash since 2012 and have used it much longer then that.

Bash also lends itself to many different application domains and use cases. For example, you can easily use for Big Data handling, and surprisingly it seems to lend itself extremely well to this task due to the myriad of text processing tools available within it, or available as easy to install packages. It is also very suited for backup and database scheduling and maintenance, or handling large file storage solutions, automating web servers and much more.

One thing I have found is that whenever the next problem presents itself, a little research in a search engine, or the various Stackoverflow websites, will quickly yield not only a solution to the problem, but an opportunity to grow and learn. This is a very similar experience to a person learning the editor

        vi
    

where the same holds; whenever a problem presents itself, the solution is nearby.

This mini series consisting of three parts of which is the first, and in it we will look at Bash automation and scripting basics.

Shebang!

You may be wondering what sort of a title that is. And you would be right, unless you were talking to a seasoned Linux developer. They would smile at best. That is because the two first letters of a well-written Bash script would always be, well, Shebang!

There are two characters, namely

        #!
    

that can be placed at the top of a script, which indicate to the shell what interpreter can, should, and will be used to process the script at hand. It happens to be that this symbol as a whole is called Shebang as a whole.

Thus, to expand on our previous statement: the first line of a well-written Bash script should start with

        #!/bin/bash
    

to indicate to the shell (whatever shell is being used, it could be for example

        bash
    

or

        sh
    

or

        zsh
    

) that we want the binary

        /bin/bash
    

(our Bash shell) to execute this code.

Let's put this into practice, by defining a small script

        test.sh
    

as follows:

#!/bin/bash
    
    
            echo 'Hello CloudSavvyIT Readers!'
    
    
            

You can create this script by using your favorite text editor, which preferably would be an editor which uses only monospace fonts like vi, vim, nano or some plain text based editor in your Linux Desktop, and preferably avoiding things like a word processor like OpenOffice Writer etc. as they may write extra unwanted binary data or characters to our script. In other words; we need to use plain text.

Once this script is defined, we make it executable by executing chmod +x test.sh at the command line. Then we can start the script simply by calling it's name prefixed with ./: ./test.sh

Input Parameters

As soon as you start writing scripts, you will likely find that you want to pass input parameters to the script. One way of doing so is to use the simple positional parameters which are available in Bash by default. Let's have a look at an example script test2.sh, which we define as follows:

#!/bin/bash
    
    
            echo "${1}"
    
    
            

Here we have used the positional parameter ${1}. This variable will reflect the first word (separated by space by default) which was passed to our script, unless quotation is used. Let's see how this works:

After making our script executable again with chmod +x test2.sh we execute the same and pass a single word hello as the first positional parameter (${1}). The result is that hello is echoed back to us.

This is because when the script was started, the variable ${1} (or $1 though I recommend to always put quotes around variable names) was set to the value of the first positional parameter; the first word or quoted string after the script name.

Next we passed hello world, however this echoed only hello back to us. The reason is simply; the second word (as separated by default by a space) is seen as the second positional parameter and is thus initialized as ${2} in the script, not ${1}.

We circumvented this behavior by putting quotes around the input when we passed 'Hello CloudSavvyIT Readers!'. Single or double quotes would both have worked, though their operation differs, more on this in the next part of this series. The result is that our first positional parameter ${1} is set to the full text Hello CloudSavvyIT Readers!, and thus the same is echoed back to us.

If you would like to learn more about variables, our Bash Functions and Local Variables and Exporting Variables in Bash: the Why and How articles may be of interest too.

Wrapping up

In this article, we reviewed the first set of Bash automation and scripting basics. We learned what Bash automation and a Shebang is, and how to start passing input variables to our scripts.

In Bash Automation and Scripting Basics (Part 2) we look at variable quoting and more. enjoy!