While discussing the Linux Shell Environment in this video, we're going to touch on three topics. How to control environment profiles for both login and non-login shell sessions. How to identify and create shell variables, aliases and functions. And a brief look at how you can execute multiple contingent commands.

Whenever you find yourself at the command line of a Linux terminal, you're inside what is commonly called a shell session. It's important to be aware, however, that not all shell sessions are created equal, and that you can control the environment parameters of your shell through various configuration files. These files will determine things like which flavor of shell, like bash or sh, will be used, what color scheme if any will be displayed, and what information will be included in the command prompt.

Linux shell session types

First of all, we'll divide shell session types into two broad categories, login, and non-login. When you SSH into a remote server or sit at a terminal attached to a non-gui computer, you'll be required to provide some kind of authentication information before you're given access. These sessions are called login shells. When, on the other hand, you open a terminal window from inside a GUI desktop session, you won't normally need to authenticate. So it's considered a non-login shell.

Why should we care? Because the configuration files used to control shell properties for login sessions are not the same as those read by non-login sessions. A login shell will first read and apply the contents of /etc/profile, and then look in the user's home directory for each of bash_profile, bash_login, and .profile in that order. The parameters included in the first of these files that's found will be applied. The environments for non-login shell sessions are set based on both the system-wide values in the /etc/bash.bashrc file and the .bashrc file in the user's home directory. You can edit the settings in any of these files, but you should also know that doing it wrong can sometimes lead to rather unexpected results.

The dot at the beginning of these files tells the system that they're hidden. Had I used ls without the -a to list the directory contents, these wouldn't have shown up. There is actually an unconnected use of the dot, that all the same happens to be very closely related to our discussion. If you want to change profiles in the middle of a shell session, you can type say . space .bashrc, which will activate the parameters of the .bashrc file. You can similarly use source.bashrc to accomplish the same thing.

You should also be aware that the .bashlogout file controls how shell sessions end. Typically, the file will instruct Linux to clear the shell screen on exit out of security considerations. While this isn't directly related to shell sessions as such, the LPIC exam expects that you'll also be familiar with the /etc/skel directory. Files and directories that you place in skel, which is short for skeleton, will be copied to the home directories of all new user accounts that you create. This could be a great place to create a single company guide, or policy document that will automatically show up in all new accounts.

Let's review. Shell environments are controlled by profile configuration files. For login sessions, Linux will read /etc/profile, and then the first of bash_profile, bashlogin, and profile. For non-login sessions, /etc/bash-bashrc comes first, and then bashrc. Source, or the dot can be used to tell Linux to switch to a different profile. And bash_logout controls shell behavior at exit.

Understanding Linux shell variables

The truth is that we've already touched on shell variables in this series once in the introduction, and again in the Working on the Command Line video from the fourth course. So we'll rather briefly cover this topic, focusing mainly on a couple of details we haven't yet seen.

You can create a variable that's unique to your current shell using something like user=myname. Echo $user will print the value of user to the screen. Export will pass a variable to all child shells within the current one. Set without any command line arguments will print all current shell variables and functions. Env, again without arguments, will list only variables. Unset will remove a particular value.

Now we'll move on to material that we haven't yet covered. Alias can create a local customized command, complete with it's own arguments. Alias on it's own will list all current aliases. Note the alias, alert. It's a little script that will send an alert notification to your desktop upon completion of a task. All you need to do to run alert, is to add it to the end of your command after a semicolon, and it will execute when the command itself returns a success code.

Let's try creating our own alias. Suppose, from time to time, I need to remind myself of which time zone my computer is set to. I'll run alias followed by the name of the alias I'd like to create, print tz in my case. Then within quotation marks, I'll simply type the commands I'd like to run, separated by semicolons. Once that's done, I can type my alias name and the operation will execute. Removing an alias works using unalias.

You can also create mini programs that you can run from the command line using function. Here's an example that will accept user input through the $1 input variable, and then, using ls -l, list the files and directories that match the input. You can remove a function using unset -f and the function name.

To briefly review, you can create a system variable using name=value. Export variable name will make the variable globally accessible. Unset variable name will delete the variable. You can create an alias that will run a series of commands, and unalias will remove the alias, as will exiting the shell. You can create a mini command line launched script using function, and unset-f will remove the function.

Scripting contingent commands using lists

You can execute more than one command in a sequence using what are called lists. Now there's no command called list so don't look for details using man list. If you do want to read up on lists, enter the bash man file, and search using the forward slash for lists. In any case, using lists allows you to link the executions together. So for instance, you can make a command contingent on the successful completion of a previous command.
Let's use ls to list all the files in this directory, but grep for only those files that contain stuff in their file names. There's obviously only one of those. Then by adding two ampersand symbols, we'll cat the contents of the file only if the ls operation was successful. However, suppose I change the grep string to stug. Since there is no stug file, the ls operation will fail, and the shell won't get to the cat command.

If, on the other hand, I would use a semicolon rather than two ampersands, I'll be telling the shell to execute the second command regardless of whether the first command was successful or not. Thus, the file stuff is printed to the screen. That's because semicolon just acts to tell the shell that these are two separate commands. You can get a similar effect, but for a different reason, using two pipe symbols. This one works because two pipes has the effect of or. Using or, however, will mean that only one of the two commands can execute. Therefore, if we change the commands so that the ls operation does execute, then the file will be listed through ls, but not displayed through cat.

Let's review what we've learned about lists. Two ampersands will execute the command to the right only if the first command succeeds. Two pipes will execute the command to the right only if the first command fails. And a semicolon will execute both commands in all cases.