Author: Joe Barr
Several years ago the same argument was raging in the Austin LUG. The LUG was going to provide instructors for an adult continuing education class at a local high school. The students would be motivated individuals new to computers in general, not just to Linux. Most were recruited for the Linux class from an introduction to computers class. Some Luggites said teach them on Mandrake and never let them leave the GUI. Others said that would be silly, and insisted that not only could the students learn to use the CLI, they should.
The class was a great success. Not only did it have a very high completion rate, and it was topped off with a visit by Jon “maddog” Hall, who just happened to be in Austin to give a keynote at a computer show. By the way, in the end, the curriculum included shell programming. The curriculum was developed by Dr. Phil Carinhas and is still available online.
What is a shell, anyway?
A shell is a command interpreter. It takes the human readable commands (like grep and cat and ls) entered by the user and passes them on to the kernel for execution. According to daemonnews.org, the first shell — called sh — was written by Steve Bourne in 1974 at Bell Labs. Several other Unix shells have appeared since then. The most popular shell on Linux is bash, which stands for “Bourne Again Shell.”
I’ve read elsewhere on the net that the term shell derived from the fact that Unix is a multi-user system, so each user needed a “shell” for privacy and protection. Whether or not that’s true, I don’t know. Neither do I know if the term “shell” originated on another OS and migrated to Unix. I do know that the source code for Bourne’s first version of sh refers to itself as the “Unix shell.”
Each user on Linux gets his own “shell.” She may have multiple terminal windows open and active, but they are all running in the same shell. To bring it into the context of this column, the CLI (“command line interface”) is where the user meets the shell.
Enough arguing, already
Let’s save our arguments for the scripts, shall we? Four of them, as a matter of fact. If you don’t know already, data passed to the executing program on the command line is called an argument.
They say Texas weather is variable, so we will make it so. Using your fave text editor, enter the following five lines and save it as a file named texasweather:
# this script predicts the weather in Texas
clear
echo "This is your argumentative Texas forecast for: "
date
echo "$1 is expecting heavy $2 today, while $3 will be $4."
Now, line by line, let’s look at what we have.
1. Line one begins with a #, and is ignored by the shell when the script is executed. It’s only purpose is to remind us humans what we intended this script to do in the first place.
2. The second line consists of the clear command. It clears the screen in your terminal window.
3. The third line, which begins with the echo command, does nothing except to print (display on the terminal) the text contained in quotes which follows it.
4. The fourth line consists of the date command which does exactly what the name suggests.
5. The last line is punched full of arguments. Four of them, to be exact. Each $x (where x is a 1, 2, 3, or 4) tells the shell to expect an argument on the command line to take its place at execution time.
Now let’s see see what happens when we execute the script. Try this from the CLI in the directory where you saved the script:
./texasweather
Permission denied?
What’s this? The darn shell won’t execute my own script for me? That’s right, and be thankful for that, noobie. Otherwise Linux would be nearly as bad a security hell-hole as Windows. Think back to what we learned about permissions a few weeks ago. Some files give us permission to read them, others to write them, and still others to execute them. Let’s see what permissions our brand new script has. Enter this:
ls -al texasweather
It should show permissions which give the owner (that would be you) read and write permission, with group and world only getting read permission. What to do?
We could use the chmod command to give ourselves permission to execute the script, but there is another way. Let’s use it. We’ll have the shell execute it. Enter this from the command line:
sh texasweather
You should see something like this:
This is your argumentative Texas forecast for:
Thu Mar 11 08:03:14 CST 2004
is expecting heavy today, while will be .
Hmmm. It seems our arguments are not very convincing. The problem may be solved by applying the boomerang theory: “if you want your boomerang to come back, why first you’ve got to throw it.” We need to include the four arguments we told the shell would be there on the command line. Let’s try it again like this:
sh texasweather Dallas sleet Austin clear
That should produce this:
This is your argumentative Texas forecast for:
Thu Mar 11 08:15:55 CST 2004
Dallas is expecting heavy sleet today, while Austin will be clear.
Plenty more where that came from
If you’re a noobie and you’ve made it this far, congratulations. Feel free to pat yourself on the back. You are now authorized to mention during your next visit to the coffee pot that you would like to stay and chat, but you’ve got to get back to your shell programming.
There are literally tons of shell scripts available for you to find, study, and use on the Internet. Google for “+Linux +shell +scripts” and you’ll see what I mean. Remember, CLI for noobies is just going to take you far enough that you can wiggle your toes in the water. But don’t let anyone tell you that you can’t earn a blackbelt in shell programming, because you most certainly can.
