Automating a repetitive task tends to make the bash developer happy: instead of typing endless commands over and over again, a script just does the job repeatedly. Bash is ideal for such automation. This series will help you get started!
What is it Bash automation?
The Bash shell is a powerful Linux shell that enables in-depth automation of repetitive tasks. The Bash Linux shell is not only a prime alternative to DevOps, databases and test engineers alike, Instead, every day users can benefit from slowly and steadily increasing bash skills.. Bash is also a programming and programming language that grows on you. I've been actively coding in Bash since 2012 and I have used it much longer.
Bash also lends itself to many different application domains and use cases.. As an example, you can easily use it for Big Data handling and, surprisingly, seems to lend itself extremely well to this task due to the large number of word processing tools available in it, or available as easy-to-install packages. It is also very suitable for scheduling and maintaining backups and databases., or for handling large file storage solutions, web server automation and much more.
One thing I have found is that every time the next problem occurs, a little research on a search engine or the multiple Stackoverflow websites, will quickly provide not only a solution to the problem, but a possibility to grow and learn. This is an experience very equivalent to that of a person learning to be an editor.. vi where the same goes; whenever there is an obstacle, the answer is close.
This miniseries consists of three parts of which is the first, and in it we will see the basics of automation and Bash scripting.
The case!
You might wonder what kind of title is that?. And I would be right, unless you were talking to an experienced Linux developer. They would smile at best. That's because the first two letters of a well-written bash script would always be, well, ¡Shebang!
There are two characters, namely #! which can be placed on top of a script, which tells the interpreter which interpreter can, should and will be used to process the script in question. It happens that this symbol as a whole is called The case like an everything.
Because, to expand on our previous statement: the first line of a well-written Bash script should begin with #!/bin/bash to indicate to the shell (whatever shell is being used, could be, as an example, bash O sh O zsh) that we want the binary /bin/bash (our Bash shell) to run this code.
Let's put this into practice, defining a small script test.sh as follows:
#!/bin/bash
echo 'Hello CloudSavvyIT Readers!'
You can create this script using your favorite text editor, which would preferably be an editor that uses only monospaced fonts such as we, push, nano or some plain text based editor on your Linux desktop, and preferably avoiding things like a word processor like OpenOffice Writer, etc., since they can write unwanted extra binary data or characters in our script. In other words; we need to use plain text.
Once this script is defined, we make it executable by running chmod +x test.sh on the command line. Then we can start the script by simply calling its name with the prefix ./: ./test.sh
Input parameters
As soon as you start writing scripts, you will probably find that you want to pass input parameters to the script. One way to do this is to use the simple positional parameters that are available in Bash by default.. Let's take a look at an example script test2.sh, that we define in the next way:
#!/bin/bash
echo "${1}"
Here we have used the positional parameter ${1}. This variable will reflect the first word (separated by default space) that was passed to our script, unless an appointment 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 first positional parameter (${1}). The result is that hello repeats itself to us.
This is because when the script was started, the variable ${1} (O $1 even though I recommend always putting quotes around variable names) was set to the value of the first positional parameter; the first word or string in quotes after the script name.
Then we pass hello world, despite this, this just echoed hello Back to us. The reason is simple; the second word (separated by default by a space) looks like the second positional parameter and, because, boots up as ${2} in the script, no ${1}.
We circumvent this behavior by putting quotes around the input when we pass 'Hello CloudSavvyIT Readers!'. Single or double quotes would have worked, even when its operation is different, more on this in the next part of this series. The result is that our first positional parameter ${1} is stated in the full text Hello CloudSavvyIT Readers!, and so it echoes the same thing to us.
For more information on variables, our posts Bash functions and Local variables and Export of variables in Bash: the posts why and how may also be of interest.
Ending
In this post, we reviewed the first set of basics of automation and bash scripting. We learned what Bash and Shebang automation is, and how to start passing input variables to our scripts.
En Bash Automation and Scripting Basics (Part 2), we analyze variable quotes and more. to enjoy!
