views:

496

answers:

4

When I execute environment commands, such as env, set and unset, something happens, but what?

set hello='hello world!'
unset find

What do you do with the commands? Are the changes permanent or temporary? Where can you see the changes? I am an Ubuntu-newbie.

+3  A: 

The changes are temporary. They persist only in the current shell. When you set an environment variable in your ~/.profile or ~/.bash_profile (just use the one that already exists, use ls -a ~ to see), they will be effectively permanent, as these files are "sourced" every time you open up a new shell.

For instance, if you added:

export HELLO="world"

To your ~/.profile, that variable would become available every time you open a new shell (you can refresh your current shell with source ~/.profile). You could test it with:

$ echo $HELLO
world

Environment variables are used for scripts all over your system. You can do things like set your favourite editor, e.g.:

export EDITOR="nano"

One useful thing you can do is set your prompt string, e.g.:

Bill:~$ export PS1="\u is awesome$ "
Bill is awesome$ ls
Bill is awesome$ du -h
Bill is awesome$ ...etc...
Aupajo
A: 

You can find information about the variables here: https://help.ubuntu.com/community/EnvironmentVariables

Masi
+1  A: 

Each process that is created gets its own environment which lives as long as the process. Your shell is just like any other process. Its environment is its own.

If you type 'set' with no arguments, you'll see what exists. Many of these settings are there to control program behavior.. your search path, desired X11 display, home directory (if not /home/yourname), etc.

The use is really whatever you need it to be. Any time you need to store some useful bit of information (such as long list of command line options to some program) into a variable that other applications can read, or that you can access from the shell, use the environment.

For instance:

USUAL_CONFIGURE_OPTS="--prefix=/home/charlie --sysconfdir=/home/charlie/tmp-etc"
./configure $USUAL_CONFIGURE_OPTS --and-additional-arguments

Edit:

As a programmer, I read the environment to determine the user's preferences and obey them. For instance, the variable POSIXLY_CORRECT influences the output of my programs if it is set. The environment is where the user tells programs how to behave. It also happens, the environment is a handy place for the user to store useful bits, as I described above.

Again (responding to your comment), every program that is executed is a process. A process gets its own address space (own memory), its environment is stored in that space. This means, the environment is specific to that process and lives only as long as the process itself.

Edit 2:

I think that I now fully understand your question. If someone says 'virtual environment', they are just noting that the environment resides in the application's address space, which is mapped by the kernel as virtual memory (some pages might be in physical memory, some might be in swap, shared dynamic objects, etc).

No process can access another's environment unless the process explicitly creates a map to that specific region and shares it with another process. Again, a process' address space is completely private and isolated from other processes. Environmental variables live within that address space, otherwise, the process could not access or manipulate them.

Tim Post
I understood from Unix Power Tools that you can consider almost everything in Linux text. In a later chapter, it added that the statement is not totally true. So I am confused by your use of the term 'process'. Processes can send signals, they are text and -- how are they really defined?
Masi
@UnixBasics, each newly created process (a program that is run) gets its own address space in memory. Its completely isolated from any other process. Process A can't read process B's memory, unless shared memory is explicitly set up. Each process' environment is their own.
Tim Post
@tinkertim Thank you for your explanation! When programmers speak about 'virtual' environment variables, what do they mean? Process A has an exact place in virtual memory, which other programs can access (but not accessing A's real(?) memory). Are the env.vars shared or just virtual env.vars of A?
Masi
@UnixBasics, Virtual memory consists of many things, real memory, swap, etc. Memory that is given to a process might exist in several places, yet the process is oblivious to this. Each process' memory is private, unless that process explicitly shares it. Env vars are typically not shared.
Tim Post
I am sorry for my inexact phrases, like 'virtual environmet variable'. I just mean the environment varible of the process that has virtual memory. Are the definitions still valid?
Masi
@UnixBasics, yes. All applications use memory that the kernel gives them, that memory might reside in one of a few places (as I noted), hence virtual memory. As the environment resides in the applications address space, it subsequently resides in virtual memory.
Tim Post
@tinkertim Are groups in the "/etc/groups/"-folder for sharing environment variables between programs?
Masi
@UnixBasics, no. This is really getting far into the fundamentals of UNIX and no longer a programming question.
Tim Post
@tinkertim Great thanks!
Masi
A: 

Just as with the argument list, there is a section of memory allocated for the process that stores environment variables. I believe it is a \0 separated, unsorted list of KEY=VALUE pairs.

This bit of memory is copied with every fork() and not erased by exec() so any changes are copied into child processes.

The Unix shells do not write variables into this environment variable memory until export is used. That is the difference between shell variables and environment variables.

In the bash shell, "x=2" does not set an environment variable. "export x=2" or "x=2; export x" does.

Zan Lynx