In-depth explanation of environment variables and configuration files in CentOS

Preface

The CentOS environment variable configuration file system is a hierarchical system, which is similar to other multi-user application system configuration files. There are global, user, and shell configuration files. In addition, different levels sometimes have inheritance relationships.

This article will introduce in detail the relevant content about CentOS environment variables and configuration files. Let's take a look at the detailed introduction.

What are environment variables

The bash shell uses a feature called environment variables to store information about your shell session and working environment. That is, it allows data to be stored in memory so that scripts running in a program or shell can access them.

In bash shell, environment variables are divided into two categories:

• Global variables
• Local variables

Global Environment Variables

Global environment variables are visible to the shell session and all spawned subshells. Local variables are visible only to the shell that created them.

To view global variables, you can use the env or printenv command.

[root@dev ~]# env
HOSTNAME=localhost
TERM=linux
SHELL=/bin/bash
HISTSIZE=1000
SSH_CLIENT=10.0.100.17 56344 22
SSH_TTY=/dev/pts/0
USER=root


[root@dev ~]# 
[root@dev ~]# printenv
HOSTNAME=localhost
TERM=linux
SHELL=/bin/bash
HISTSIZE=1000
SSH_CLIENT=10.0.100.17 56344 22
SSH_TTY=/dev/pts/0
USER=root


[root@dev ~]# printenv TERM
linux

Use environment variables by using $ + variable name.

[root@dev ~]# echo $HOME
/root

System environment variables are generally written in uppercase letters to distinguish them from environment variables of ordinary users.

Local environment variables

As the name implies, local environment variables are visible only within the process in which they are defined. The set command displays all environment variables set for a particular process, including local variables, global variables, and user-defined variables.

[root@dev ~]# set
BASH=/bin/bash
BASHOPTS=checkwinsize:cmdhist:expand_aliases:extquote:force_fignore:hostcomplete:interactive_comments:login_shell:progcomp:promptvars:sourcepath
BASH_ALIASES=()
BASH_ARGC=()
BASH_ARGV=()
BASH_CMDS=()
BASH_LINENO=()
BASH_SOURCE=()
BASH_VERSINFO=([0]="4" [1]="1" [2]="2" [3]="1" [4]="release" [5]="x86_64-redhat-linux-gnu")
BASH_VERSION='4.1.2(1)-release'
COLORS=/etc/DIR_COLORS
COLUMNS=165

User Defined Variables

Once you have started a bash shell, you can create local variables that are visible within that shell process. The subshell created by the process cannot read the local variables of the parent shell.

[root@dev shell]# sh a.sh

2
twenty two
2
[root@dev shell]# cat a.sh
#!/bin/bash

a=1;
export b=2;

sh b.sh

echo $b;


[root@dev shell]# cat b.sh
#!/bin/bash

echo $a;
echo $b;
b=22;
echo $b;
[root@dev shell]# sh a.sh 

2
twenty two
2

Users can export variables to make them global variables so that subshells can also read them. When the subshell modifies the variable, the parent shell is not affected.

If you set an environment variable in a subshell, what if you want to read it in the parent shell?

One usage scenario is: multiple execution scripts rely on a common environment configuration, which is written in an env.sh script. How can other execution scripts read the variables in env.sh? Exporting variables in a subshell does not affect the parent shell.

The source command (from the C Shell) is a built-in command of the bash shell. The dot command, which is a dot symbol (from the Bourne Shell), is another name for source. Both commands take a script as an argument which will be executed as the environment of the current shell, i.e. a new subprocess will not be started. All variables set in the script will become part of the current shell.

[root@dev shell]# cat c.sh
. ./env.sh
source ./profile.sh

echo $env;
echo $profile;
[root@dev shell]# cat env.sh
env='test';
[root@dev shell]# cat profile.sh 
profile="dev";
[root@dev shell]# sh c.sh 
test
dev

If you want to delete the environment variable

unset var_name

Setting global environment variables

From the above, we can know that if we want to use common environment variables in this process and the child process. This can be achieved by using the source command to read the same environment variable script. This is a user-defined scheme. But often, we don't know the source of the global environment variable we need to read, so we need a default environment variable to read the file.

When you log into your Linux system, the bash shell starts as a login shell. The login shell reads from 5 different startup files

• /etc/profile
• $HOME/.bash_profile
• $HOME/.bashrc
• $HOME/.bash_login
• $HOME/.profile

/etc/profile

The /etc/profile file is the default main startup file for the bash shell. As long as you log in to the Linux system, bash will execute the commands in the /etc/profile startup file.

[root@dev shell]# cat /etc/profile
# /etc/profile

# System wide environment and startup programs, for login setup
# Functions and aliases go in /etc/bashrc

# It's NOT a good idea to change this file unless you know what you
# are doing. It's much better to create a custom.sh shell script in
# /etc/profile.d/ to make custom changes to your environment, as this
# will prevent the need for merging in future updates.

pathmunge () {
 case ":${PATH}:" in
  *:"$1":*)
   ;;
  *)
   if [ "$2" = "after" ] ; then
    PATH=$PATH:$1
   else
    PATH=$1:$PATH
   fi
 esac
}


if [ -x /usr/bin/id ]; then
 if [ -z "$EUID" ]; then
  # ksh workaround
  EUID=`id -u`
  UID=`id -ru`
 fi
 USER="`id -un`"
 LOGNAME=$USER
 MAIL="/var/spool/mail/$USER"
fi

# Path manipulation
if [ "$EUID" = "0" ]; then
 pathmunge /sbin
 pathmunge /usr/sbin
 pathmunge /usr/local/sbin
else
 pathmunge /usr/local/sbin after
 pathmunge /usr/sbin after
 pathmunge /sbin after
fi

HOSTNAME=`/bin/hostname 2>/dev/null`
HISTSIZE=1000
if [ "$HISTCONTROL" = "ignorespace" ] ; then
 export HISTCONTROL=ignoreboth
else
 export HISTCONTROL=ignoredups
fi

export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE HISTCONTROL

# By default, we want umask to get set. This sets it for login shell
# Current threshold for system reserved uid/gids is 200
# You could check uidgid reservation validity in
# /usr/share/doc/setup-*/uidgid file
if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
 umask 002
else
 umask 022
fi

for i in /etc/profile.d/*.sh ; do
 if [ -r "$i" ]; then
  if [ "${-#*i}" != "$-" ]; then
   . "$i"
  else
   . "$i" >/dev/null 2>&1
  fi
 fi
done

unset i
unset -f pathmunge

This file will read all *.sh files under /etc/profile.d/ and load variables by clicking the command (source). That is, the variables defined in /etc/profile and /etc/profile.d/*.sh are global system environment variables.

$HOME/.bash_profile

The startup files under $HOME are all user-specific startup files that define the user's environment variables. /etc/profile is the system's environment variables for all users.

The shell executes the first file it finds in the following order and ignores the rest:

• $HOME/.bash_profile
• $HOME/.bash_login
• $HOME/.profile

.bashrc is called through .bash_profile.

[root@dev shell]# cat ~/.bash_profile 
# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
  . ~/.bashrc
fi

# User specific environment and startup programs

PATH=$PATH:$HOME/bin

export PATH

Summarize:

Put the system global environment variables to be set, such as JAVA_HOME, in the /etc/profile.d/ directory and define them in the form of *.sh scripts.

Well, the above is the full content of this article. I hope that the content of this article will have certain reference learning value for your study or work. If you have any questions, you can leave a message to communicate. Thank you for your support of 123WORDPRESS.COM.