[lug] Idea for a new tutorial....maybe???

[Tkil]

most simply put, environment variables are name=value pairs that are
passed from a parent process to its child processes.  shells are the
most obvious users of them, but by no means the only ones; most of the
communication from web servers to CGI scripts is done with environment
variables.  to get an idea of how many are set, point your browser
window at:

   http://slinky.scrye.com/~tkil/cgi/headers

in a shell, there are "plain" variables, and then there are variables
that are "promoted" to being environment variables.  i don't recall if
there are ways to have environment variables that are not simultan-
eously available as plain variables as well, but there might be.

as a simple example, consider the following bash "transcript":

| $ foo="one"      # set "plain" variable "foo" to have value "one"
| $ bar="two"      # set "plain" variable "bar" to have value "two"
| $ export bar     # "promote" bar to be an environment variable.
| $ /bin/bash      # launch a child.
| $$ echo $foo     # since foo wasn't promoted by parent, it's not here.
| 
| $$ echo $bar     # but bar *is* visible.
| two

yes, i know that bash allows you to set+promote in one step.  csh and
its derivatives use set / setenv to do similar things, but i don't
recall if "setenv" will automatically call the corresponding "set" (or
whether you just end up falling through your "local" variables into
the environment variable set).  hm.  time for an experiment.

| % setenv foo two
| % echo $foo
| two
| % set foo=nothing
| % echo $foo
| nothing
| % csh
| %% echo $foo
| two

so this shows that csh can maintain it in both states at once; the
"local" value of $foo in the parent shell got set to "nothing", while
the environment value (which was passed on to the child shell)
retained the value "two".  fun fun.

try reading the man pages for "getenv", "setenv", "unsetenv",
"environ", and anything they refer to.

as others have pointed out, "setting up your environment" usually
refers to setting environment variables (and possibly also defining
aliases and functions) for your shells, both interactive and batch
(shell scripts).  the recent exchange with wayde allen indicates how
squirrelly this can get.

note that, while the concept of environment variables is quite simple,
the important thing is how they are *interpreted* by the parent and
child processes.  the CGI specification tells programmers how to
interpret the values that it gets.  most shells honor "PATH" for
looking up executables; it's an environment variable so that any
subproceses can also find executables.  note that csh does some magic
when you do "set path=(foo bar baz)"; behind the scenes, it sets PATH
so that shell scripts you call will still function:

| % setenv PATH foo:bar:baz
| % echo $PATH
| foo:bar:baz
| % set path=(one two three)
| % echo $PATH
| one:two:three

on my redhat linux box, "man 5 environ" reports a list of well-known
names and how their values are usually interpreted.  other important
names are LD_LIBRARY_PATH (man ldconfig), and most programs have their
own set; take a look at "man perlrun" to see which ones effect perl,
GNU 'ls' has a few that effect it ("LS_OPTIONS"?).

finally, the point of most environment variables is to do exactly what
you say:  define an environment.  as such, they should most often be
set exactly once, when you start the first process on a given
machine.  all the other processes you start there should inherit a
valid set of environment variables.  this means that you should do
most of your environment variable setup in those startup files that
are executed exactly once per login shell: you can go back to wayde's
thread for this, but basically that means ".login" for csh & friends,
and ".profile" for sh & derivatives.  

logging in via X (xdm, xgm) poses a special problem, but usually this
is fixed by having your .xsession file (or .xclients, or whatever your
system uses) source your .profile.  of course, you might want
different settings if you log into a graphical workspace or not.
the important thing is that the process which launches your new
processes (this might be the window manager, or it might be a control
panel / dock) should have all the environment for all the programs it
will set.  or you can farm that out, but i've never found the need to
get that fine-grained.

hopefully this has answered some of your questions.  the best ways to
learn more are to read the man pages, check out existing practice
(that is, see what others are doing), etc.

good luck,
t.