103.1 Lesson 2

So just how do we identify the current values for each of our environment variables? One way is through the env command:

You will get a lot of output — much more than what is included in the above excerpt. But for now note the PATH entry, which contains the directories where your shell (and other programs) will look for other programs without having to specify a complete path. With that set, you could run a binary program that lives, say, in /usr/local/bin from within your home directory and it would run just as though the file was local.

Let us change the subject for a moment. The echo command will print to the screen whatever you tell it to. Believe it or not, there will be many times when getting echo to literally repeat something will be very useful.

But there is something else you can do with echo. When you feed it the name of an environment variable — and tell it that this is a variable by prefixing the variable name with a $ — then, instead of just printing the variable’s name, the shell will expand it giving you the value. Not sure whether your favorite directory is currently in the path? You can quickly check by running it through echo:

You can add your own custom variables to your environment. The simplest way is to use the = character. The string to the left will be the name of your new variable, and the string to the right will be its value. You can now feed the variable name to echo to confirm it worked:

But did it really work? Type bash into the terminal to open a new shell. This new shell looks exactly like the one you were just in, but it is actually a child of the original one (which we call the parent). Now, inside this new child shell, try to get echo to do its magic the way it did before. Nothing. What’s going on?

A variable you create the way we just did is only going to be available locally — within the immediate shell session. If you start up a new shell — or close down the session using exit — the variable will not go along with you. Typing exit here will take you back to your original parent shell which, right now, is where we want to be. You can run echo $myvar once again if you like just to confirm that the variable is still valid. Now type export myvar to pass the variable to any child shells that you may subsequently open. Try it out: type bash for a new shell and then echo:

All this may feel a bit silly when we are creating shells for no real purpose. But understanding how shell variables are propagated through your system will become very important once you start writing serious scripts.

Want to know how to clean up all those ephemeral variables you have created? One way is to simply close your parent shell — or reboot your computer. But there are simpler ways. Like, for instance, unset. Typing unset (without the $) will kill the variable. echo will now prove that.

If there is an unset command, then you can bet there must be a set command to go with it. Running set by itself will display lots of output, but it is really not all that different from what env gave you. Look at the first line of output you will get when you filter for PATH:

What is the difference between set and env? For our purposes, the main thing is that set will output all variables and functions. Let us illustrate that. We will create a new variable called mynewvar and then confirm it is there:

Now, running env while using grep to filter for the string mynewvar will not display any output. But running set the same way will show us our local variable.

Now is as good a time as any other to introduce you to the problem of special characters. Alphanumeric characters (a-z and 0-9) will normally be read literally by Bash. If you try to create a new file called myfile you would just type touch followed by myfile and Bash will know what to do with it. But if you want to include a special character in your filename, you will need to do a bit more work.

To illustrate this, we will type touch and follow it by the title: my big file. The problem is that there are two spaces there between words which Bash will interpret. While, technically, you would not call a space a “character,” it is like one in the sense that Bash will not read it literally. If you list the contents of your current directory, rather than one file called my big file, you will see three files named, respectively, my, big, and file. That is because Bash thought you wanted to create multiple files whose names you were passing in a list:

The spaces will be interpreted the same way if you delete (rm) the three files all in one command:

Now let us try it the right way. Type touch and the three parts of your filename but this time enclose the name in quotation marks. This time it worked. Listing the directory contents will show you a single file with the proper name.

There are other ways to get the same effect. Single quotes, for instance, work just as well as double quotes. (Note that single quotes will preserve the literal value of all characters, while double quotes will preserve all characters except for $, `, \ and, on certain cases, !.)

Prepending each special character with the backslash will “escape” the specialness of the character and cause Bash to read it literally.