And here we are, ready for our first demonstration.
We're going to be working in the git repository that we created earlier.
We'll create a subdirectory to house our shell scripts.
We're going to be adding a new info script.
We'll be using sed to make edits through to this file,
and we'll see how we can add that shebang line.
We can add our permissions.
We can combine git add and git commit together so we can
create shortcuts at our command line.
And when you're ready, we will get going.
And look at this, I welcome you to the glorious command line,
and a command line where we're going to take our
skills just a little bit further.
We can take a look at what we're going to be working with by moving into
the comptia‑automation and the shellscripting directory.
This is the repository that we had originally downloaded,
provided with the course, and you can see the sample files.
Now these are the completed files that we're working
with with our shellscripting section,
but it gives you some ideas and some help as you go along.
But we want to check with the info script where we're
going to go with our info script.
We can go through and execute it,
and you can see then we're able to print out
various information about our system,
and we'll see how we can generate this information
and use it within our scripts.
For the moment, we want to be working within our own Git repository,
the myproject that we had created earlier.
We can always go through and check the git status,
and we can see that we are working on the branch master
and everything is clean and ready to go.
Now ideally we don't develop code within our master branch.
The master branch could be downloaded by anyone,
and we don't want to have it saved back to our master
until we know that we are good to go.
So we can go through and check out a new development branch.
I'm just going to call this shellscripting.
So ‑b then allows us to check out a new branch.
We switched to that branch, but I could always check it with git status.
And we are working in that branch, so, again,
we know we're good to develop code.
The first thing I'm going to do is create myself a
subdirectory that we can put our shell scripts in.
Moving into that directory then, I can create my new script.
So we're going to use whichever text editor we're
happy with at the command line, I'm using vim,
and we're going to call it info.sh.
Now the extension doesn't really matter,
and truly, in Linux file naming, there is no such thing as an extension,
it's just one file name,
but putting the .sh at the end of the name gives us a good
indication that this is a shell script file.
When we're ready to start editing, we can put in some very simple commands.
The first thing I'm going to do is just echo out some cleartext.
Echo is a built‑in command that is used to print to screen,
and we're just going to use it then to print some header and footer information.
I can paste that down so we've got the same header and footer.
Using the command hostname, we return the host's name,
but hostname ‑I will return IP addresses associated with the host,
and I can return the kernel version or release number using uname ‑r,
so the script is used to gather system information.
Now I can execute it straightaway with the bash
command without doing anything else, so bash and info.sh.
So we've opened the file in bash.
These were just bash commands, so we were able to execute those commands.
Bash ‑x is also useful, where we can use it to debug scripts.
There's nothing really to debug here, but we can see the progress of our script,
but this is particularly useful when we're using conditional statements,
so we know the path that we've taken.
It would also be more convenient that we can execute this as a standalone file,
so the first thing that we need to do is make sure that
we've got the execute permission.
So the chmod, or the change mode command,
a+x, so we're adding the execute permission to all blocks,
so that's made the file executable.
Linux also does have a command call file that we can always go
through and check the file type by reading text information or
header information about the file.
If I take a look at my info.sh at the moment,
file info.sh, we just see that it's an ASCII text file.
Remember I said the extension doesn't really exist,
so .sh doesn't mean anything to the system.
If we want this then to be understood as being a bash shell script,
we add in a shebang.
Now we can edit the file directly, but as I pointed out in the slides,
being able to use our stream editor allows me to non‑interactively edit a file,
which is useful across many systems or across many files.
So I'm going to go through and say at line 1,
insert the shebang, the interpreter that we want to use. That's all in quotes,
so bash doesn't deal with anything inside of the quotes,
so we'll pass through to sed, uninterrupted by our shell.
The file, of course, is info.sh, and we can see it now looks okay,
but we've only printed to the screen, we haven't edited the file.
This is always a good starting point to make sure that our command is working,
but to run the edit now that we know it's working,
we just add in the ‑i, so we don't get anything coming back,
but we have now edited our file.
If I check now with the file command,
we can see that adding in the shebang has told the system what type
of file it is so we know which interpreter to use.
Now that our file is executable and has the interpreter set,
we're able to execute it locally from the same directory with a relative path,
so ./info.sh, and that all looks good.
If we're executing it from with inside of another script,
very often it's a good idea to make sure the full path is included.
So we're able then to access it through our home/vagrant/myproject,
and then of course the shellscripting,
add info.sh file, so this way we can execute it from anywhere
in the file system and it is going to work.
So using the full path rather than the relative path means then it
can be accessed from anywhere in the file system.
Now the last thing that we need to look at is saving this
information back into our repository database.
We can do this, as we've seen, using the git and add command.
For any new files, we still need to go through and do a git add. We can go dot,
so from this directory down, we can run our git commit
and we can put a simple commit message.
The more descriptive this is, the better when we start looking at our history.
I'm just going to go in and say added a new info.sh file.
Now we have to go through the long hand for any new file that we've added,
but for files that we've changed,
and let's go through and just imitate this by adding in a
little bit of information to the file.
I'm just going to add in maybe an extra equal sign in our header and footer.
Now that we've edited an existing file,
I can use a little bit of a shortcut using the Git commit and then ‑a.
This only works with files that existed before,
but we can add them in without having to run it separately.
So we can say that we've added the footer,
so we've very easily been able to then go through
and run the two commands together. So good to know, and a shortcut there if you want to use it.