Environment Variables

From COMP15212 Wiki
Revision as of 10:02, 5 August 2019 by gravatar W81054ch [userbureaucratinterface-adminsysopPHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) (1 revision imported)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Depends on Shell

Processes have an environment supported by the operating system, including environment variables. This is a mapping from variable names to values, both of which are strings. Environment variables are used to define various ‘background’ conditions in which processes operate; they are used as a form of interprocess communication although in this sense they are more like extra arguments which can be passed (“exported”) to child processes.

A number of environment variables are held by a shell: you can create your own, too, as a shell typically initialises itself from a configuration file; you can add them interactively as well, although this is rather tedious… It is also a common Unix ploy to set up particular environment variables in scripts to define where to find files, libraries etc. in a particular session.

In bash, environment variables are referenced for their value by placing a $ in front of their name. For example, in bash:

echo $X

would print the value of the environment variable X on standard output. If that variable did not already exist, it would be first created with the empty string as its value, so the effect would be to produce a blank line.

We could give X a value, for example

X="Hollow Weld"
echo $X

would print the string “Hollow Weld” on standard output.

Aside: you must not put spaces around the equals sign of such an assignment in bash.

X = "Hollow Weld"

would mean: invoke a command called X, with two arguments, the first of which is an equals sign… This may seem odd, but on the other hand, why should bash effectively enforce a rule that you cannot have an equals sign as the first character of your first argument to a command?   Thought: how could you invoke a program whose name is “X=10”?!

Try (e.g.)

echo $LOGNAME

for yourself.

Special parameters

In bash, environment variables are a specific kind of the more general idea of parameters. Environment variables have names, whereas the other parameters are identified using special characters. For example, $$ yields the process ID of the running bash process.

$ echo $$
26129

And another example, ${!} yields the process ID of the most recently invoked background process.

$ echo $$
26129
$ firefox &
[1] 12921
$ echo ${!}
12921

In a shell script,

$1

is the first command line parameter, etc.

Exporting and child processes

When a process forks a child process, the child does not inherit all the environment variables of its parent. Let us illustrate:

$ echo $$
26129
$ echo $X

$ X=100
$ echo $X
100
$ X=101
$ echo $X
101
$ bash
$ echo $$
26160
$ echo $X
 
$ exit
$ echo $$
26129

The child process, 26160, did not inherit the value of X (101) from its parent process 26129.

However, we can mark variables for export:

$ echo $$
26129
$ export X
$ bash
$ echo $$
26256
$ echo $X
101
$ exit
$ echo $$
26129

That time it did inherit X!

Try it yourself. (You are unlikely to get the same process IDs as above though!)

We can assign a value and mark for export in one go:

$ export PRINTER=lffrmp

Special variables

There many environment variables that have special meaning, including but not limited to the following. (Some of these are set and maintained by bash, others are more widely interpreted.)

PATH

The list of directories which will be searched for the existence of a program if such is invoked without a path name.

For example

$ echo $PATH 	/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/X11R6/bin:/home/john/bin:.

So, which file will be loaded and run if we invoke the command ls?

$ which ls
/bin/ls

Thus it must be the case that there is no executable file called “ls” in the directory /usr/local/bin, otherwise that would have been found first.

HOME

The user’s home directory.

SHELL

The user’s default shell.

$ echo $SHELL
/bin/bash
PWD

The current working directory. (This is bash specific.)

RANDOM

Each time you ask for this value it is (probably) different!

$ echo $RANDOM
15573
$ echo $RANDOM
24679

(This is bash specific.)

LINES and COLUMNS

“LINES” is number of lines there are in the terminal in which bash is running. (This is bash specific.)

“COLUMNS” is the same as LINES, except columns.

$ echo $LINES $COLUMNS
87 80

(This is bash specific.)

MANPATH

When you run the man command, where should it look? E.g.

$ echo $MANPATH
 	/usr/java/jdk1.6.0_22/man:/usr/local/share/man:/usr/share/man:/usr/man::/opt/teaching/man:/opt/common/man
EDITOR

Some applications use this to start a text editor of your choice. E.g.:

$ export EDITOR=nano
$ less some-text-file.txt
<<Now press `v' and you will be in `nano` editting that file!>>

In this example we know that less invokes the default “EDITOR”; this allows you to customise the behaviour of this standard utility.

LANG

This is part of the ‘locale’ for the user. What language?

$ echo $LANG
en_GB
$ locale
LANG=en_GB
LC_CTYPE="en_GB"
LC_NUMERIC="en_GB"
LC_TIME="en_GB"
LC_COLLATE="en_GB"
LC_MONETARY="en_GB"
LC_MESSAGES="en_GB"
LC_PAPER="en_GB"
LC_NAME="en_GB"
LC_ADDRESS="en_GB"
LC_TELEPHONE="en_GB"
LC_MEASUREMENT="en_GB"
LC_IDENTIFICATION="en_GB"
LC_ALL=

For example, LC_COLLATE affects sorting for many programs, including ls.

$ mkdir try-sort
$ cd try-sort
$ touch a B
$ export LC_COLLATE="en_GB"
$ ls
a  B
$ export LC_COLLATE=C
$ ls
B  a

Capital letters have a lower character code than upper case, as we can see from:

$ man ascii | egrep "^  *Oct|^  *0.*(A|b)$" | cut -c50-
    Oct   Dec   Hex   Char
    101   65    41    A
    142   98    62    b

obviously!

HOSTNAME

Automatically set to the name of the current host. (This is bash specific.)

Local (user) parameters

In a similar way to finding your home directory, software may have its own location which may benefit from parameterisation. Consider some tool like our own Komodo debugger. Here are some details abstracted from the start-up script:

CADTOOLS5=/opt/cadtools5
 
case $LINUX_VER in
3.10*) KMD_HOME=$CADTOOLS5/KMD_SL7.3 ;;
*)  KMD_HOME=$CADTOOLS5/KMD ;;
esac
 
export KMD_HOME
export KMD_DIR=$KMD_HOME/custom
export LD_LIBRARY_PATH=$KMD_HOME/lib

Here, first, the file-store supporting the current set of CAD tools is established; this can be updated and moved with a single edit. (If you look inside the actual script there are options on the value of this variable.) Within the tools the origin of the particular tool is derived – with a trap for different OS versions – (and exported). From that point two other environment variables are derived, the second being a (short) search path telling the binary where to look for any dynamic libraries it needs.


Also refer to: Operating System Concepts, 10th Edition: Chapter 20.4.1.2, pages 787-788


Articles on Concepts
About this resource • Application Binary Interface (ABI) • Arrays • Atomicity • Boot • Cache • Cacheability • Caching • Concepts • Containers • Context • Context Switching • Deadlock • Direct Memory Access (DMA) • Environment Variables • Exceptions • File Attributes • Fragmentation • Hypervisor • Interrupts • Operation Ordering • PATH • Pointers • Process Scheduling • Processes • Processor Privilege • Queues • Real Time • Reentrancy • Relocatable Code • Spooling and Buffering • Synchronisation • Thrashing • Threads • Virtual Memory • Virtualisation
Articles on User
"Everything is a File" • Application Binary Interface (ABI) • Arrays • Boot • Buffer Overflow • Containers • Daemons • Disk Partition • Dynamic Memory Allocation • Emulator traps • Environment Variables • Errors • Exceptions • File Attributes • File Locking • File Permissions • Introduction to Operating Systems • Journalling File System • Links • Locks • Man(ual pages in Unix) • Memory Mapped Files • Monitoring • Network File System (NFS) • PATH • Pipes • Pointers • Relocatable Code • Reset • SETUID • Shell • Sockets • Spooling and Buffering • Streams • Structures • Superuser • System Calls • Unix Signals • User • Using Peripherals