Going on, we will talk about text editors. This is not that important to you if you are not a software engineer or someone other than a “regular” Linux user, like an aspiring information security expert or a “wannabe” system administrator. If you are just using Linux instead of Windows for everyday things, you don’t need this material, in my opinion.
I wanted to list out all files related to the user environment and write a short description when each of them is read. By read, I mean “the file is read and its contents are interpreted as commands which are executed.” Why would this be useful? Just so that you have seen the file name at least once, so that when it pops out in some tutorial, you have a vague idea about what it is used for. Of course, Google the name of the file to be sure what it does, but having some general context doesn’t hurt.
Here we go…
Files read by login shells:
/etc/profile
/etc/profile.d
~/.profile
~/.bash_profile
~/.bash_login
Note that .bash_profile and .bash_login may not exist in your home directory (they don’t exist in my home directory).
Files read by interactive shells:
/etc/bash.bashrc
~/.bashrc
As stated in one of the previous articles I wrote, write all of the changes of your environment to ~/.bashrc.
You may wonder what is the difference between the files in the etc directory and the home (~) directory. If you modify the files in the etc directory your changes apply to the entire system (to all users), while if you modify the files in your home directory the changes apply only to your user. (“Diff between /etc/profile and ~/.bash_profile,” n.d.) Hence the suggestion to modify .bashrc in your home directory, since then it only applies to you.
Also, a word of caution – it is always a good idea to copy the files you are modifying (using cp for example) so that you can rename them to the original file name if something goes awry with the modified version.
I refer you again to read the superbly written answer here: (“Why is /etc/profile not invoked for non-login shells?,” n.d.)
Let’s talk about shell variables today. Shell variables are temporary variables specific to the shell you are currently running. (Ward, 2014) Think of it like this – shell variables are temporary, environment variables are permanent.
Here is an example of setting and printing out the contents of a shell variable:
mislav@mislavovo-racunalo:~$ VARIABLE=stuff
mislav@mislavovo-racunalo:~$ echo $VARIABLE
stuff
If I try to print the contents of VARIABLE in another shell, I get:
mislav@mislavovo-racunalo:~$ echo $VARIABLE
What’s that I get? An empty line. Because in another shell (in another Terminal window), the variable VARIABLE doesn’t exist.
Hope you learned something useful!
References
Ward, B. (2014). How Linux Works: What Every Superuser Should Know (2nd ed.). No Starch Press. Pages 21-22
If you want to make permanent changes to your environment, here is how to do it:
In virtually all use cases, you should modify .bashrc file located in your home directory (i.e. /home/mislav/.bashrc). The reason for that is that both login shells and interactive non-login shells read these files explicitly (and execute the commands within them). (“Why is /etc/profile not invoked for non-login shells?,” n.d.)
Here are some lines I have added (appended) to my .bashrc file (in /home/mislav/.bashrc):
These are the lines I added. They add certain directories to my PATH variable. The general syntax for adding to my PATH variable is:
export PATH=$PATH:newPath
where newPath is a path (or multiple paths delimited by a colon) where I want to look for executables. The $PATH get substituted for the contents of the variable PATH.
When writing this article, I found myself Googling quite a lot to make sure I really understood what files were read by what kinds of shells. A really great read on this is found here: (“Why is /etc/profile not invoked for non-login shells?,” n.d.). The main thing I got from the aforementioned reference is to place all of my changes in .bashrc, but it is such a great answer that I would urge you to read it if you have the time.
Today we will talk about two properties (or classifications) of a shell. The first is whether a shell is interactive or non-interactive and the second is whether the shell is login or non-login.
Let me preface this by saying that I was hesitant about going into this topic. I was thinking like this: “Is this really essential for someone learning about Linux?”. I concluded that it is. Why? Because these different shell properties do pop up from time to time and I think that they are important because they help you understand how Linux handles shell-related things (such as establishing the environment, for example).
Before we begin, let’s remind ourselves what a shell is. A shell is a program that runs commands. (Ward, 2014) I (and most likely, you) am using bash (which stands for Bourne-again shell). You can have multiple instances of shell running on your computer. Just open up two or more Terminal instances – each one of those is a separate shell. (“Is each terminal window of Bash a separate shell?,” n.d.)
Interactive shells expect the user to be able to interact with the shell (as in the user enters some input to the shell via keyboard). Non-interactive shell assumes that shell is probably run from an automated process and it can’t expect interactivity, nor can it expect that anyone will see its output; its output will most likely be written to a file. (“What is the difference between interactive shells, login shells, non-login shell and their use cases?,” n.d.) This makes sense – you will not always want to interact with your shell via keyboard or you will want to have your shell running without you being present, so there are these two types.
In order to explain the difference between login and non-login shells, let me first explain why do these two types exist. Login shells exist to do some things only once (such as set your HOME variable, which contains the path to your users home directory). (“What is the intended purpose of a login shell?,” n.d.) How do login shells do these things, exactly? By reading certain files. Non-login shells are all the shells that don’t read the certain files that login shells read. We will talk more about these files in another post, but for now just understand this:
Interactive shells exist for when you want to interact with your shell (via keyboard)
Non-interactive shells exist for when you don’t want to interact with your shell (you want it to run without your supervision)
Login shells exist to do some things only once (i.e. set your HOME variable and run some things which should only be run once)
Non-login shells exist for all other usages after the login shell has done all of the things that have to be done once
Every shell can be either value on both of the dimensions. That means that a shell can be:
login and interactive
login and non-interactive
non-login and interactive
non-login and non-interactive
This needn’t concern you that much. Just know that every shell that is run via Terminal is an interactive, non-login shell.
I think that this is all you need to know. An optional reading which explains in more detail the usage of all 4 types of shell listed above in the list is (“Why do we have login, non-login, interactive, and non-interactive bash shells?,” n.d.)
Hope you found this useful! As I mentioned at the beginning, this will be necessary for some later understandings.
If you ever want to modify environment variables (and you may sometimes) or some tutorial you find on the World Wide Web advises you to do so, it is useful to know what is going on.
When modifying environment variables, you are, in most cases, adding something to already existing environment variables. Here is how to do it: (modeled after (Ward, 2014))
The commands we are focusing on here are VARIABLE=value and export VARIABLE. Those commands introduce a new variable named VARIABLE with the value value and export VARIABLE places variable VARIABLE in the environment.
The changes you just made to your environment are non-permanent. Meaning, when you close your Terminal window, the variable VARIABLE will disappear from the environment. There is a way to make these changes permanent, but it is a topic for another post.
Hope you learned something useful!
References
Ward, B. (2014). How Linux Works: What Every Superuser Should Know (2nd ed.). No Starch Press. Pages 21-22
Let’s talk about a special kind of environment variable – the PATH variable, also known as the command path. (Ward, 2014) This variable stores all the places your operating system will look for executables. (“How to set your $PATH variable in Linux,” n.d.) To recall, executables are a type of a command (executable is another name for an “ordinary” program (just like Firefox)). What this means is that every time you modify or append something to your PATH variable, you are, in essence, telling the operating system: “Look for the executable in this directory as well”. If you have multiple directories containing the same executable, the operating system will take the first one it finds.
I put $ in front of PATH to get the contents of the PATH variable. Here we see that all the folders where to look for executables are separated with a colon. So the structure of the PATH variable looks like this: path1:path2:path3
This is convenient for the operating system because it tells the operating system where to look for executables. Otherwise, it would have to search through the entire computer looking for your executable. Yikes! Better help the good ol’ operating system by telling it where to look for.
Today we will talk about a special kind of operating system variables. As we already know, the operating system (and other computer programs) use variables, which are places in computer memory that store values relevant to a computer program. A special kind of operating system variables are environment variables. Let’s explain what “environment variables” mean.
Environment variables are the variables that the operating system passes to your shell programs. (Ward, 2014) What that means is that when you run your shell program, it has access to the environment variables. A shell program then uses those environment variables to read its configuration and options from them.
Here are some examples of environment variables I got by running printenv, which is used to print all (or a part of) your environment. (“PRINTENV(1),” n.d.)
Here we can see SHELL and SESSION_MANAGER as names of my environment variables, while the strings right of the equal sign are the values of the variables.
Takeaway: Environment variables are passed by the operating system to your shell programs and they store configuration and options that shell programs take into account when they are executed.
Let’s talk about variables. What are those? Variables, generally speaking, are a part of your computer memory which hold different values at different times, depending on the execution of a computer program. We are talking about some “regular” program here (like Firefox). So I can have a variable called number_of_open_tabs and it can be equal to 5 and if I close one tab, then number_of_open_tabs equals 4. The takeaway is that variables hold some values which are relevant for a computer program. Every variable has a name (i.e. number_of_open_tabs) and a value (i.e. 4).
OK, OK. But what does that have to do with the operating system? Well, the operating system has its own variables. Those variables are relevant for the operation of the operating system.