Shell Scripting vs Programming, part 3 – Special Things

Spread the love

When you talk about shell programming, or any kind of programming for that matter, you are going to deal with variables on different levels. In the shell, you have the built-in variables you saw earlier, and you can assign variables as well. For instance, without writing a script, type this line at your shell (command-line) prompt:

   hours=24

Then type this:

   echo "There are $hours hours in a typical day"

The system responds with this:

   There are 24 hours in a typical day.

You access that variable by putting a dollar sign ($) in front of it. If you just enter that line in a shell script (not the hours=24 line), made that script executable and ran it, you would get this:

   There are in a typical day.

The shell script did not pick up the $hours variable. In order for the shell script to know about the variable “hours,” you need to export it. There are two ways to do this. One is to assign the variable as you did and then type the command export hours. You can also put the whole thing on one line and save yourself some keystrokes.

   export hours="24"

Running the script now displays a much more intelligent message about how many hours are really in a day.

Aside from user-assigned variables, the script can make use of environment variables. These are variables set for you at login time by the system. Some of these are sometimes overwritten by the .bash_profile file in the user’s home directory or the global /etc/profile. A common one to see modified is the PATH variable, which lists the possible search paths for executables. Check your own $HOME/.profile or $HOME/.bash_profile file for the references to PATH.

   PATH=$PATH:$HOME/bin:/usr/local/bin
   export PATH

As you can see, you can modify an environment variable by referencing it in your assignment. The second line exports PATH and a number of other variables so that they are available to you in any shell and any environment in which you might work. To have a look at your environment variables, type this command:

env

Special Characters

Certain characters mean very specific things to the shell. Following is a sample of what you will encounter.

Character Description
$ Highlights the beginning of a variable’s name
# Comment character
? Matches a character
* Matches any number of characters
. Sources or tells the shell to execute the filename that follows
Defines a string
Defines even special characters as part of a string
` Executes what is inside the ticks
\ Escapes the character that follows
[ ] Lists a range of characters inside the brackets

The dollar sign ($) is one that you have already seen. It indicates the beginning of a variable name. You’ve also see the comment character (#) and later, I will discuss some of its special properties. The question mark (?) and the asterisk (*) perform similar functions in that they are used for matching characters. The asterisk will match any number of characters while the question mark matches only a single character. If you wanted to match two characters only, you could use two question marks (??). To match three characters, you can use three question marks (???), and so on.

First and foremost, I want to talk about the backslash (\). When a backslash is put in front of a special character, it stops the shell from interpreting that special character. Here’s a simple and, I think, effective demonstration. At your shell prompt, type this command:

   echo *

Did you get a listing of every file in your directory separated by spaces? That’s what I thought. Try it again, but this time put a backslash in front of the asterisk.

   echo \*

Notice that the shell now echoes a single asterisk. Anytime you want to use a special character like those in the shell, but you don’t want them treated in any way special, front them with the backslash (which I suppose is a kind of special treatment).

You Can Quote Me on That

Ah, quotes. I have lots of favorites. One of them is “I want to live forever or die trying,” which is something Spider Robinson said but I wish I had. Sorry, different kind of quote.
Of course, I should be talking about what quotes mean to the shell. Double quotes (“”) tell the shell to interpret what is inside them as a string. This is the way you define variables or echo text back to the terminal.

   my_variable="This is a double quote \" inside my double quotes."

You’ll notice that I put a double quote inside my double quotes, but escaped the character with a backslash. If I were to type echo $my_ variable, this is what I would get:

   This is a double quote " inside my double quotes.

Single quotes (‘) would seem, on the surface, to do the same thing as double quotes, but they do have another important function. Let’s set a couple of variables and build a little shell script.

   os_name="Linux"
   os_desc="way cool"
   echo "$os_name is $os_desc."
   Linux is way cool.

That’s more or less what you would expect here. Now, let’s put single quotes around that echo command and see the difference.

   echo '$os_name is $os_desc.'
   os_name is $os_desc.

Hmm…it would seem that single quotes stop the shell from interpreting dollar signs as indicators of variable names. Now, how about those back ticks? Back ticks (`), or back quotes, are special in that they execute what is inside them. For instance, if you had a shell script that echoed “The current date and time information is . . . ” and you wanted to have that something or other filled in, you would want the output of the date command. Here’s one way of doing this:

   the_date=`date`
   echo "The current date and time information is $the_date."

Another, easier way to do this is to put the back-quoted date command inside the echo line itself.

   echo "The current date and time information is `date`."

This is where I’m going to leave it for today.

Please comment if the mood takes you, either in the comment form below or directly on Google Plus, You can also comment here on Facebook and add me to your circles or friend list if you haven’t already done so; oh yeah, if you’re on Twitter, follow me there. Also, make sure you sign up for the mailing list over here so that you’re always on top of what you want to be on top of.  And a final request, please share this article with your favorite Linux and FOSS group or news site; I would sincerely appreciate it. Until next time . . .

A votre santé! Bon appétit!

Liked it? Take a second to support Cooking With Linux on Patreon!
Become a patron at Patreon!