Table of Contents
This course is structured with the following students in mind:
A "newbie" to shell scripting, OR
A user who wants a refresher on a particular aspect of shell scripting.
For Category 1 users I suggest you work through each section, do all the relevant exercises and Labs.
If you fall into Category 2 above, then just look up the section you need a refresher on, do the examples below each section to drive the point home and move on.
The Lab (project) is designed to get you into the groove of writing shell scripts and is, in essence, an example of the practical application of the shell script.
You will learn an immense amount from doing the exercises and Labs, and you should have a great deal of fun too. In the Labs, we begin by building a really simple script and progress to a script that you will want to show your friends... but don't. Unless they're Linux nuts too, they'll think you're just weird!!!!
Finally, for those geeks out there, (or those of you who think you're too clever for this sort of stuff), there are additional challenge sequences.
For example, where the "wannabe-geeks" build a simple menu system, you must build a menu system with the "ncurses" library. This may mean reading up on the dialog package, figuring out how it works and then implementing it. I have included in the appendices explanations of the challenge sequences. Look out for the challenge sequences and really pull out all the stops!
Oh, a final word of warning. If you haven't noticed already, Unix and Linux people have a pretty wacky sense of humor. I'm no exception. If you find some of my jokes and quips in this course offensive, you're definitely taking this whole Linux thing WAY TOO SERIOUSLY. Take a chill pill and re-read it and relax!
Pencil and Paper
Yes. I know these two concepts are foreign to some of you, but hey, give an old codger like me a break.
To have logged onto your favorite Linux distribution as a user (with your username).
We don't at this stage need to be logged in as root.
Note | |
---|---|
At some time during this course you will need to log in as root. If you get to that point and are not the system administrator for the machine you are working on, then you may need to build your very own Linux machine. Any system administrator in their right mind would NEVER give you the root password. Of course, if you are the system administrator, you already have the root password! |
In order to learn to be a great system administrator, and "shell script-er", you MUST be. . . . .
LAZY.
Yes, that's right, LAZY. Say it, and again. Once more. Good!!!
Why? Because, if you are anything like me, you want to spend your time doing things you love, not the mundane boring stuff that will leave you feeling like you've really had to work hard!
If you're lazy, you will think of simpler, better, faster and more efficient ways of getting through your day's tasks, look efficient, get many pats on the old' back, or taps on the old' head and leave work feeling like you're just the smartest person around.
Next, if you REALLY want to learn to script, NEVER do manually, what you can do by using a script. Script everything!!!!
So, let's get scripting. But first, what is a shell?
The shell, in UNIX and Linux is the equivalent of a command interpreter in Windows. Its job is to accept commands, as typed by the user on the command line, and interpret each of those commands, acting on it however necessary. The shell is a little like DOS operating system in many ways; the only difference being that it's like DOS on steroids. I hope that over the remainder of this course you will you will understand this sentiment.
For example typing:
ls -l |
on the command line produces some output. How does UNIX know to call the ls command? How does it know to interpret the -l as a switch? What about the output? How does the command output know to come to the screen? By chance? Nope. Nothing in Linux happens by chance!
The shell does these things!
What about a shell script?
A shell script is in essence, a whole bunch of shell commands entered together in a file. A little like the DOS batch file, where many shell commands are grouped together to perform some function(s).
What if we wanted to run two commands over and over again? Say,
free |
and
df -h |
One way of doing it would be to type the commands in over and over again. More work!!! Of course it is. We are looking at means of sticking to adage 1.1, not so? So, we could get clever and type both commands on a single line, separated by a semi-colon
free;df -h |
We've reduced our finger-work, but not by much. Again the better way of doing this is to put both these commands into a file. For our example we will call this file mycmds.sh:
riaan@debian:/tmp> vi mycmds.sh <To create the script> riaan@debian:/tmp> chmod +x mycmds.sh riaan@debian:/tmp> ./mycmds.sh total used free shared buffers cached Mem: 321628 317836 3792 0 14644 88536 -/+ buffers/cache: 214656 106972 Swap: 506480 1060 505420 file system Size Used Avail Use% Mounted on /dev/hda1 5.5G 3.5G 2.1G 63% / tmpfs 158M 4.0K 158M 1% /dev/shm riaan@debian:/tmp> |
Then all we have to do it execute it, and voila , we have "created a new command", aka mycmds.sh. Now each time, we merely need to run the script and the commands are executed together.