How to read and set environment and shell variables in LINUX?

Administration of Linux systems is impossible without knowledge and mastery of methods for managing program environment variables. However, the situation is complicated by the large number of different types of variables and the presence of several configuration files with different priorities located in different places. Knowing the peculiarities of this segment will help to simplify and speed up the process of system management. Let's consider these points in more detail and demonstrate the work with variables on specific examples.

Organization of the command execution environment in Linux systems

User interaction with a Linux system usually takes place through a command prompt or shell that interprets commands entered from a terminal or scripted commands and executes them. To enable such "communication", a separate user session is formed each time, which has its own peculiarities. For example, it may concern the user profile or system settings. When initializing a new session, it reads the values of the parameters set in the configuration files and opens a session with the corresponding properties.

The values of program environment parameters are fixed with the help of variables, which can be conditionally divided into global and local ones. The former usually include environment variables, the values of which become available to all running programs and child processes of the shell. Local variables relate to the work of the current shell only and are usually used to store the characteristics of the current shell and the user. Their values are not passed to subordinate actions. They are called replaceable shells.

The general convention is to distinguish any variable from other types of shell language constructs by using only uppercase characters in its name.

To view or change variable values, a certain set of commands specific to each variable type is used. The main sets of variables of each type and working with them will be discussed below.

Variable environments and working with them

Let's consider the most frequently used variables in the Administrator's work.

• TERM - sets the type of terminal used;
• PATH - defines the list of directories to search for executable files;
• PWD - stores information about the current working directory of the user;
• HOME - stores information about the current user's home directory;
• USER - stores the name of the current authorized user of the system;
• SHELL - stores data about the name and location of the current command prompt;
• LANG - language settings and character encoding.

To view the values of environment variables, there is the printenv command. They can be printed either all at once or individually. For example, let's consider the list of available variables in the system. To do this, let's type in the terminal:

$ printenv

As a result, we have a rather large list. Let's select from it only the main variables that we specified earlier:

SHELL=/bin/bash
PWD=/root
HOME=/root
LANG=en_US.UTF-8
TERM=xterm
USER=root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

You can verify that all output values are correct for the purpose of the corresponding variable.

Now let's output the value of only one specific variable, e.g. LANG:

$ printenv LANG

The result is the same, so the command works correctly.

The same result regarding the output of the total list can also be obtained with the env command. Let's check it:

$ env

The result is the same list in the same format. However, unlike the previous command, the env construct cannot output individual parameters, only a list. But it is more functional and can modify already set values of system parameters as well as user created parameters.

The general syntax for setting a user-created parameter would be as follows:

env VAR="znachennya" <command> <arguments of command>

Interchangeable shells and their use

Here is a list of some of the more commonly used shell parameters:

• BASH_VERSION - stores the current version of bash, which is output in a convenient format;
• HOSTNAME - stores the current hostname;
• SHELLOPTS - stores a list of options that can be set using the set command
• BASHOPTS - stores the list of options that were used during bash execution
• PS1 - stores information about the current configuration of the command line prompt of the user's work session;
• UID - stores the identifier of the current user.

The values of system parameters can be viewed using the echo command. For example, let's consider the current version of the shell. To do this, type in the terminal:

$ echo $BASH_VERSION

So, the current version of bash is 5.1.16.

The bash tools provide a wide range of possibilities for working with user variables. For example, to create a new variable, just type in the terminal:

$ NEW_VAR=' Testing bash '

To view its contents, you can use the set command, and yes, the echo command as well:

$ set | grep NEW_VAR

$ echo $NEW_VAR

You can verify that this works and a variable has been created that is available to the environment within the current shell. But we should not forget that it is only local, as mentioned above. To make sure of this, let's try to apply to it the command designed to work with global level parameters:

$ printenv | grep NEW_VAR

As you can see, the command output is missing, which indicates that the specified variable is not considered as a global variable.

Another way to make sure that the created variable is local is to check whether its values are passed to child processes.

Let's start a slave shell inside the current shell and try to view the contents of the created variable:

$ bash
$ echo $NEW_VAR

You can see that the output is empty, indicating that the variable value has not been passed to the child process, which means it is local.

Let's exit the child process:

$ exit

Interrelation of environment and shell variables and their joint use

For the convenience of work, the developers have provided a relationship between both types of variables, which allows you to export one type of variable to another. For example, let's try to make the variable we created global. To do this, type the following command:

$ export NEW_VAR

Now let's check its status using the printenv command:

$ printenv | grep NEW_VAR

As a result, we got the output of the command, which shows that the status of the variable has changed - it has become global.

At the same time, let's check the possibility of passing the value to child processes:

$ bash
$ echo $NEW_VAR

You can verify that the values are being transferred. Therefore, the export mechanism is reliable and can be used when needed.

Now let's try to export a value from the bash child shell. To do this, type in the terminal:

$ export VAR_EXP=" Testing bash "

Let's see if it has gone global:

$ printenv | grep VAR_EXP

Yes, VAR_EXP is a global variable.

Exit the child shell to see if its value has been passed to the parent bash shell:

$ exit
$ echo $VAR_EXP

You can see that there is no output, which means that the value of the child shell variable cannot be passed to the parent process, but only to the child. This is the way it should be, because the existing mechanism makes it impossible for programs to influence the working environment from which they were launched.

There is also the opposite way - downgrading the variable status to the local level. Let's demonstrate it with the following command:

$ export -n NEW_VAR

Let's run a check:

$ printenv | grep NEW_VAR

As you can see, its status has changed - it has become local. To confirm this, type the following command:

$ set | grep NEW_VAR

The developers also provide for the invalidation of any variable set earlier. The unset command exists for this purpose. Let's try to unset NEW_VAR:

$ unset NEW_VAR

Let's run a check:

$ echo $NEW_VAR

There is no output, which means that the NEW_VAR variable is invalidated.

Automatically setting variable values for different kinds of sessions in Bash

As already mentioned, when creating a new working session, bash selects information about its setup from several configuration files. Therefore, it is enough to insert the necessary parameters into a certain file and the shell will automatically receive the data necessary to create a working session with the desired configuration. This is the main means of automation.

The only problem is to look at the different configuration files depending on the type of session, the main ones being a user authenticated session and a non-logon session. However, it can be solved if you have a clear understanding of the principles and sequence of how the shell reads the data.

The first thing to know is that the configuration files intended for a user authenticated session are always the source of data for the files intended for an unauthenticated session. And, therefore, in case you want to configure a user environment that would be available for both types of sessions, it is enough to set the necessary parameters in the user's ~/.bashrc file. For example, let's show how the necessary parameters can be set there. To do this, let's open the specified file of our system with an editor:

$ nano ~/.bashrc

As we can see, the required parameters with their values can be inserted even into bash control constructs such as loops or conditional statements, which makes the formation of the working session environment quite flexible. This case of customization is the most common.

After making and saving the necessary changes, the file is closed. To make the settings take effect as soon as possible, just execute the following command:

$ source ~/.bashrc

If we need to set a number of system-wide parameters, then it is best to use the following configuration files:

$ nano /etc/profile

$ nano /etc/environment

$ nano /etc/bash.bashrc

By setting the right settings in them, we can ensure that bash sessions with the configurations we want are started and automatically generated in the future, without spending any more personal or work time.