1. The shell environment
This lesson is about the shells and corresponding shell scripts. We already talked about shells in the 101 part of the course, but we just scratched the surface here. We want to deepen the whole thing a little bit. When a user logs onto a linux system the first thing that is started is a shell. To repeat from on course 101 there are several different shells. For example sh or Bash or Ash. Which shell is started for? User is specified in the Etsy password file. We take a quick look at the file and we can see here for last user, Thomas. He uses the Bin Bash here. Here is my personal user, also Bin Bash and so on.
When a shell is started it usually runs through several configuration files or scripts which in turn determine which programs should be started automatically in the background or which environment variables should be set automatically with these configuration files. A distinction is made between global files so those that are applied globally for each user and user related files so the configuration files that are intended to apply exclusively to a respective user. As always, we can find the global configuration files in the Etsy directory and the user related configuration files are of course in the home directory of the respective user.
In general, there are four different types of shells the login share, the non login shell, the interactive shell and the non interactive shell. When you log into your linux system you are automatically locked into a login shell. This is the shell that runs in the background on every linux system. With the key combination Control alt and f seven you can log out of the shell and with Control altf two you can log in again. I would now press ctrl alt f seven and then the screen would go black because we are locked out of the main shell. Let’s try it out. See, the screen is black. We are locked out and with Control, alt and f two we come back.
Even if you dial into another server with ssh, you will automatically be taken to a login shell. The non login shell does not require a separate log in. If we only start our terminal, then we have opened such a non login shell. We can work with it without having to log in again. Then there is the interactive shell. This would be, for example, an undershell or child shell in the terminal. So in this non login shell here with Bash, for example, we open a subshell in which we are now automatically then we would have opened the interactive shell. In that case, now we are back in the non login shell. And last but not least there is the non interactive shell.
There you cannot log in manually and you cannot work on it manually. Often it is a script that is processed in a shell without being able to hand over any commands. It is important to note that these types of shells exist because they use different configuration files. The global configuration file for the login share and we see what is known a bash script here the heading also says systemwide dot profile file for the born shell and born compatible shells bash, ksh and Ash. We do not have to be able to understand the script for the exam. What we need to know is that the script sets environment variables for the logins shell and also loads further files which in turn set environment variables or execute other scripts.
For example, starts certain programs automatically or similar. In this script we find for example a reference to the directory at cProfile d and we will now look at this directory and we see that this directory contains various share scripts that are called when the login shell is started. So every script that is within this directory is called when the shell is started. Again, we do not need to know which scripts these are and what exactly they do for the exam. We only have to know that these scripts exist and that they are in the etsy profile d directory. But of course we can look at such a file for example d and then this one for example and we see that this file only has two lines.
So this file is about checking that the character set is set to utf eight. Another important configuration file for the login shell is the file bash profile that is located in the home directory of a user and the environment variables for the log and shell are also assigned here. Why is this file in a user’s directory? You can use this to influence the login shell, but only for the relevant user and not system wide.I’m using ubuntu here and unfortunately the bash underscores Profile, that how it is written. Profile file does not exist here or no longer exist. Instead it is simply called profile on current ubuntu systems.
So let’s take a look at the file with cat and then profile and we see here for example the umas value can be set or different paths are set here, et cetera. But also here we do not have to know what the script is doing exactly, we just have to know that it exists and what options are available. So we would have completed the important configuration files and scripts for the login share. Now we come to the nonloginshare. So our terminal here, this is our non login shell. Completely different files apply to the shell, but the purpose is the same as for the login shells. So when we open a new login shell, scripts are loaded again in the background.
Sorry, I wanted to say so when we open a new non login share, it is a non login share here. Then scripts are loaded again in the background. The first script that is processed and that applies systemwide is at cbash bashrc as always, we don’t have to analyze this file and be able to pinpoint what it’s doing. We just need to know that it exists, where it is and what it is for. Nevertheless, let’s take a quick look at it. It cat at crc again, environment variables are set, paths are set and so on. This file is only found on debian systems. By the way, this file is not used on redhead based systems. The corresponding configuration file for Bash from the user’s point of view is the file bashrc.
So let’s take a look at it virc and here is our file. Several things can be set here. For example, we see the socalled his size here the value is set to 1000. Here the Historic says how many commands we enter into the terminal are saved in the history. Various aliases are defined here. For example, the alias ll here alias ll alias lasl and this is stored here. Which means that every user can store their own aliases here or change existing ones. If you want to include additional scripts that are supposed to adapt the shell, you would only include them in this file. Here you can display the aliases directly in the shell here, just the command alias and we see which aliases are configured and stored in this file.
There are also the files Bash underscore Login and Bash underscore logout. The Bash underscore login file can be used to load scripts or set variables when a shell is started. However, this can just as easily be done with the bashrc file. The Bash log out file or the script is run through when you log out of the shell. This file is often used, for example when the screen should be cleared after logging out. So for example, cache catdosh logout when leaving the console, clear the screen to increase privacy and then there is little script which clears the screen. Talked a little bit about variables in this lesson, but I think we will clarify what exactly that is in the next video.
2. Variables
This video is about the environment variables. First of all, it is important to know that there are systemwide environment variables and user environment variables. The systemwide environment variables are valid for all users and all programs and are set in four different files. Not always in all files, but there are four files in which that can be specified. These are the files at c profile and at cbes bashrc, which we know from the last lesson. Then we also have the directory at cProfile d. So the directory in which individual scripts can be stored and environment variables can also be set for this. The fourth option is the etsy environment file, which we haven’t discussed yet.
The etsy environment file is not available on every system, but it is on my Ubuntu. So we will take a quick look cat at the environment. And here we just see the path variable and the path variable that is stored here. The user environment variables are only valid for the corresponding user and these are stored in the user specific files, so always in the corresponding home directory. So the files bashrc bash underscore login and profile, including the files that we saw in the last video that we have already discussed. So let’s take a look at a few variables. The variable home for example, contains the path to the user’s home directory echo echo dollar home and we see here that is the path to my home directory.
Let’s look at another variable. A very important one would be path echo dollar path and here is our path variable. This variable contains the paths in which the system should search. If we enter a command in the terminal without setting a path, we see that we have specified several paths here. For example user local sbin and the colon at this point separates the individual parts. Then next we have user local bin, again a separation colon, then user ESPIN separation, user bin separation sbin bin user games, user local games and snap bin. For example, we can simply use the chmod command in the terminal no matter where we are in the directory tree.
Theoretically we would have to enter binch mod so that the system knows which directory the chmod command is in. However, the bin directory is stored in the path variable here, which is why we do not have to enter the entire path if we want to use the command. The system knows the path variable and knows that it has to look into the directories that are stored in the past variable. If we were to move chmode now, for example into my home directory, then we could no longer call the command without specifying a path precisely because my home directory is not stored in the path variable. If we want to set our own variable, we can do it in different ways.
We just create a simple variable called test with the content 15 for example, which works as follows test equals 15. So we have created a variable called test and assigned the value 15 to it. So let’s output the content of the variable and check whether it worked. Echo dollar test and we see that the content of the test variable is 15, so it works. But this variable is now only available in this terminal. If we, for example open a subterminal or a completely different terminal and close this one, then this variable test is lost. We can try it out. I will open a new bash here. Now we are in new bash and we enter the echo command again. So echo dollar test and we don’t get a result here. So this variable was not inherited into subshare in which we are now.
We leave the sub shell again with exit and are back in the previous bash. Now we delete the variable that we just created with the unset command unsett test and we now check whether the variable is really deleted. Echo test and we no longer have a result. So it is no longer there. In order to make the variable available for subshells, we have to export it. That means we create the variable exactly as before and also use the command export. So export tests equals 15. Echo dollar test the variable is there again and we now open the sub shell again and we execute the command echo again. Echo test and this time we see a value here. So the variable was inherited into the subshell.
Although we used export, this file is only valid for the current session. If we close the terminal, then the variable is also deleted.We can try that out at this point. I close the terminal. Now I open a new one so echo dollar and test and we see that the variable no longer exists. How can we make a variable permanently available? By adding it to the files we discussed earlier and in the last lesson. Since this is a Socalled nonloging shell, we have to enter it in the Etsy beshrc file. If this variable is to be valid system wide or in the beshrc file. If it should only valid for a specific user, all environment variables of the system can be displayed.
For this we use the command print NF or just NF. So print NF and here we see the environment variables that are set. And now I just enter NF and have exactly the same result. NF is of course the short form for environment. NF can also be used using the I option, which stands for Ignore environment. So we can issue a command that ignores all environment variables. Sh can be shown wonderfully with the shell. So we change the shell to the sh shell n and we can see all the environment variables. Here I leave sh with exit and I’m back in bash. Now I start the sh shell with the no environment variables so nfi and then sh.
Back in the sh I ask the environment variables again with NF and we see that apart from one variable that contains my home directory and that must always be there, all other variables are gone. There is another important option for NF. That is the option U, with which only a single variable can be removed. We can test that again. I’m creating a test variable with export test two equals test text. We now say that we start the sh shell and the environment variables should all be taken over except for the variable test two. So NF is the option u. Test two and then sh. Now we check the environment variables again with NF. And here we got all our variables.
And now we check if our variable is available with grab and then grab test two. And there is no result here because of N and the option U. Precisely. This variable was not passed. Last but not least we come to the source command, which can be used to load a function file into a shell script or into a current shell. What does that mean exactly? We have already discussed a few things on the subject of variables. What we have not yet discussed is that there is also the possibility of defining variables in a file and calling them from there. So let’s create a new file VI variable. And then this line here follows first bin bash. We will go into this line in more detail in a later video.
First of all, it is important to know that this expression must always be present in the first line of bear scripts, so that the system knows that it is a bear script. Now we can define individual variables. For example variable one equals variable one. Variable two equals variable 20. Okay, we save the file and leave VI. And of course we haven’t set a variable yet. We will check that with echo variable one. And here we get the result variable one. And there is no result because we have only written this variable to a file. So to load the variables that are in this file, we use the source command source variable. And now the variables should be loaded. This can be checked with again. Echo dollar variable sorry, variable one.
And here we have variable one wrong spelling. I see. Sorry for that. And echo dollar variable two. Here too we have the result variable two. So the system has set the variables that were stored in the variable N file. Instead of the source command. We can also just use a dot. I will show this by creating a second file. For example variable two NF and then, just as I said, we can or we have just done that with source source variable then and at this point we are doing it with a dot two. And now the variable three should also be present. Echo dollar variable three. And here too we have a result. And as I said, whether you use source or a dot is completed. Irrelevant at this point. Both ways work.
