Understanding Linux shells

A Linux administrator's primary working environment is the command line which is, to be more precise, a command language interpreter. That is to say in much the same way as a computer language like C or Java, the interpreter will translate your commands into terms your operating system can understand, allowing them to be executed. Technically speaking every command line is a shell. A relatively independent compute environment bound by it's own set of rules and restrictions. Of course, a shell exists within the computer and network that spawned it, but can also be given unique characteristics. Bash which stands for Bourne Shell, perhaps the best known Linux command language interpreter, is the one we'll use for this course. Of course, there's nothing stopping you from switching between different interpreters. Typing "sh" by the way will open a new shell using the sh environment. As you can see, the sh shell isn't currently set to provide as descriptive a command prompt as bash.

Typing "Exit" will drop us back into our original bash shell. Typing "Exit" once again would close the window altogether.

While the terminal command line is the most visible place we use these tools, and the place where we'll do most of our learning in these courses. In administration terms, they're usually most productively utilized as parts of scripts.

Bash scripts are effectively executable text files containing commands that automate processes harnessing some extremely sophisticated resource manipulation tools. We'll talk more about scripting later in this series. For now, it's enough to know that everything we'll discuss here, as useful as it is, will prove even more useful later.

Let's talk about some of the more basic command line tools. Typing "Echo," followed by some text will cause that text to be output on the next line. Nothing too exciting.

Let's try "echo $USER," and see what's printed to the screen. So user it would seem is a pre-existing system variable that contains the name of the current user. And the dollar sign tells bash that the following text string is a name of a variable, rather than just text to be printed.

Typing "echo $user" in lower case by the way won't work. Bash is generally very case sensitive. We could however add a new variable using "user=myname" and then run echo again, "echo $USER." This time the new value of user is printed. Where do these system variables come from? The "set" command when run without argument will output a list of all current shell variables and functions. Note how user is the last, meaning most recent, value in the list. Interestingly some of these variables will actually change dynamically. So for instance, the pwd, which stands for present work directory, right now is /home/ubuntu. But if I change directories to say, /etc and run set again, you'll see the value of pwd has followed us. Typing pwd in lowercase in the command line will by the way display our current work directory. Another system variable that's often really useful is uname. Although you could probably have figured out that we're using Linux on your own. Adding a "-a" to that however will output the Linux kernel version our system architecture and the current date and time.

Let's review. Your command line exists within a shell of which bash and sh are two examples. Commands can be executed from the command line or through scripts. Echo will print a string or the value of a variable to the screen. You can create new variables using name=value.

Working with Linux environment variables

Set has many command line arguments but I believe that simply being aware of its role as a reporter of shell variables is enough for the LPI exam. Unset will, when followed by the name of a variable, remove that value. Let's run "unset user" using lowercase. And then run set again. Our original value of user has been removed, although we can still see a trace of it's existence in this _=user. If we were to exit this shell and start a new one even that trace would no longer be there.

Like set, running env without arguments will display environment variables. However, unlike set env will not display functions. Also unlike set env will not include a variable until it's been exported to the environment. From that point however the variable would be available to child processes. Let's illustrate that. We'll create a variable called "stuff" and give it the value of hello. Running set will display our new value. Running env on the other hand comes up with nothing. Even when we grep for stuff specifically. Now if we type bash we'll find ourselves in a new shell session. One level below our original shell. And at this level our stuff variable fails to show up even for set.

Let's exit this shell and now back in our home shell we'll run set again. Stuff is right there where it's always been. Now let's export the stuff variable using export followed by the variable name.

Now running env again and grepping for stuff shows us that stuff is part of the environment. We'll open a new lower level bash shell and run "echo $stuff." And what do you know, the value of stuff has followed us down to this new child shell.

To review, "set" contains functions and variables even before they've been exported. Running env will only display exported variables. Exporting a value with the export command will make the variable available to child shell sessions.

Using man, the Linux help documentation resource

One of the most basic needs you'll probably encounter in your shell work is access to useful and contextual help. Did that command require a -a or --append? Was the a supposed to be upper or lower case? How is that command actually spelled? Linux comes with a very complete help system called man. Typing man, followed by the name of the command you're working with will usually return a manual page describing the use and function of the particular command. This simple man page nicely shows us how man pages break down including sections for name, synopsis, description, author, bug information, copyright and related sources.

Note the number one at the top of the page indicating the page type. There are nine page types in the man system, as illustrated here. The LPI exam will actually expect you to be familiar with these types and their corresponding numbers. Man bash is a huge man file that has a lot to teach you about how shells work. If there doesn't seem to be a man page for a very basic command like unset you'll probably find it within man bash, which can be searched by hitting the forward slash and entering a string.

If you can't remember the precise name of a command, which can make finding the right man page a bit of a challenge you can use apropos.

Finally, past commands that you've executed remain accessible to you through history. Typing history alone will display previous commands in reversed order. You can search the record by running history with grep. Or read the hidden .bash_history file itself, which can be edited. I can't tell you how many times history has made my job and my life so much easier.