Hello, and welcome to this Pluralsight presentation.
My name is Andrew Mallett, and in this module, we're going to take a look
at implementing Linux automation by making use of shell scripts. As we
work our way through this module, we're going to be understanding what
goes into a shell script, and we'll be working with the Bash shell. We'll
be taking a look at loops,
conditional statements, using variables, using built‑in commands
within our scripts, such as the echo command.
We can take a look at redirection and other common utilities
that we might make use of within our scripts.
Now,
all that shell scripts are, as if I can say all that they are, they're a
group of commands gathered together into a text file.
This text file is then executed, and all of those commands then can be run
reliably and repeatedly. We can use many different shells for scripting,
but we'll be taking a look at the Bash shell.
Now working with any of our files,
we can maintain version control using Git repos. To continue our
learning of Git and really put it into practice, we're going to be
working with our existing Git repo that we created.
Also, some of the sample files can be obtained from the originally downloaded
CompTIA automation repo that I've provided for this course.
Now we're going to begin by creating our first shell script, and we're
going to try and avoid doing a Hello World script,
I promise.
So we can move into our project directory where we had
previously created our Git repository.
Now if we are developing new information, then we probably should go through
and create a new development branch. We can create ourselves a subdirectory
below my project to house our shell scripts.
And then we can create a simple script Here we're looking at info.sh.
We're using a couple of header and footer lines
with just a whole load of equals.
We can recall the hostname. We can recall the IP addresses, and we can use
uname ‑r to recall the kernel release or our kernel version.
We can execute it using the bash command, so bash info.sh. And once
we're happy, we can add it to our staging area and commit it. To make
the script a little bit more standalone, we can go through and take a
look at the file command.
This identifies the type of file, and we'll see
that it's just an ASCII text file.
If we add to it a line called a shebang, the shebang identifies
the interpreter to be used for the script.
It starts as a comment, but we'll see that it is read by the system. To
insert the line, obviously, we could just edit the file, but certainly
if we needed to work across multiple files, it's worth getting to know
the sed command. Here the ‑i option is looking at an in place edit. 1i
is saying at line one,
insert a new line. Then we have the line to insert, and that's the
shebang. And we're working with the file info.sh.
Now when we check our file,
we'll see that it's still an ASCII text file, but it is a bash
executable. Of course, the execute permission is still not set, so
I can go through and add the execute permission. And now we're able
to execute it as a standalone file without having to use the bash
command in front.
We're using a relative path here, so within our current
directory dot, we're going to find the file info.sh. Once we
are satisfied with our changes,
we can go through and add and commit in the same way as we've seen
before, but there is a shortcut that we can use.
If I use git commit ‑a, we will automatically add all changed files
that haven't been added to our project so far.
So it's a little bit of a shortcut, but there's no way I can
check my staging area before committing changes.
So this is a little bit of a shortcut. You might want to
use it; you might prefer to do it,
the more longhand method so you have a little bit more checks along the way.
But there you go. We're just about ready, and you know the best way to really
ready yourself, and that is with hands on practice.
These demonstrations truly are designed with you in mind.
So if you follow along with the demonstration, your learning is going to be long lasting.