Within our last clip, we saw how we could use variables,
variables that we created.
However, we don't have to create all of our variables.
If we take a look inside of the etc/os‑release file,
we're going to be able to see that it's made up of pre‑populated variables.
We can source those variables,
read them into our current shell using the command source, and
then we can make use of those variables.
What we're going to take a look at now is how we can extend our
script using the built‑in command source so we can import those
variables to give added functionality.
Come on,
let's look at what we're going to do. And here we are on our
glorious command line and we're just about to embark on a journey
where we're going to make use of some variables created in our
etc/os‑release file. So we can see we've got our NAME= "Ubuntu",
VERSION="20.04, and so on.
This is just a shell script, but all it's doing is populating variables.
We can read these variables into our current
environment by using the source command.
So if we go through and run source and then our file name, don't
forget about the escape and dot to recall your last argument,
we've then read that into our current environment rather than
just executing the script.
If we had executed the script, it would run in its own
bash shell that it was executing in.
We can check then our variables and we can use tab completion with our
variables, so like PR, that shows me PRETTY_NAME and PRIVACY_POLICY. We want the
PRETTY_NAME, and we can see then that we're working on Ubuntu 20.04. We can put
this same operation into our existing script.
I'm going to begin by printing out some of those variables.
We can add the source command in later.
So as we then go through,
I can echo out a little bit of standard text, so I might then go through and
open up my quotes and put in OS for our operating system, and then we can
make use of that variable that we just looked at, our $ and then our
PRETTY_NAME. But we also have the code release such as our focal, so I can
then go through and echo out, and whatever we want to put in here, I'm just
going to put let's say SHORT:, and then it's going to be $ and then our
VERSION_CODENAME.
If you just need to check on the variables, nothing's stopping you going back to
check in that file. And, of course, this has got our variable information, but
we've got to read those variables into the script.
Now it doesn't really matter where I put my source command, so long as it's
before I use the variable, so I'm just putting it towards the top of the
script, and we have that same command source to read in the file
etc/os‑release. Once we're ready with that,
we can go through and save our changes, and, of course, we want to check that
it's going to execute okay, and we can see now that we've got the additional
lines OS and SHORT. So this is now looking good.
And to be honest,
we're now finished with this script, so this script can be made
available to my main branch. But don't forget,
I still have to go through the process of committing it.
If I check my status, we can see that we've got the modified info.sh.
If the file's already in the project,
I can run my git commit with a ‑a, add the m for the commit message, and we
could say then add in the os release information. With our changes committed,
we're now ready to consider merging our development branch back into our master
branch so I can then go through and do a git checkout. To merge into the master,
we must be working on the master.
We also need to make sure that we're in the top‑level
directory, and we can then do a git status.
We can see then that we're in our master branch, and we can then go
through and run our git merge, and then specify the development branch
we want to merge, and mine was shellscripting.
So I can then choose git merge shellscripting. Those changes
then will be pushed into our master branch.
We're still working on our master branch, and we can continue to
work in our master branch, and we can see now that we have our
shellscripting directory and the info.sh, and this is now
available to anybody who needs it.
We can go through and look at our branches,
we've still got all of the branches that we've had, so master,
shellscripting, and the previous branch that we had, dev, they're all
still there. We could delete them, but I'm going to keep at least my
shellscripting branch because we're going to be developing more shell
scripts, so we can then go through and do a git checkout, and then
shellscripting.
So we switch back to that branch so we can continue our
development from where we left off. But our master branch is now up to date.