environment variable

[cdevers at pobox.com (Chris Devers)]

On Sun, 18 Apr 2004, D.E. Chadbourne wrote:

> Chris Devers wrote:
> ...
> > Have you tried reading the error, and setting $JAVA_HOME ? :-)
> >
> >     $ echo $JAVA_HOME
> >     $
> >
> >     $ export JAVA_HOME="/Library/Java/Home"
> >     $
> >
> >     $ echo $JAVA_HOME
> >     /Library/Java/Home
> >     $
> >
> > Make sense?
>
> this looks very cool but unfortunately i have no idea how to use echo in
> the way you suggest.  yes i'm lost.

I'm not doing anything fancy -- `echo $ENV_VAR` just outputs whatever
value $ENV_VAR might have. In this case, the first echo statement
demonstrates that the environment variable is undefined; after setting
the variable with the `export` command, the second echo statement shows
that the variable is now defined.

Strip out the dollar signs and you should be able to paste these lines
into a Bash shell to see for yourself how it works, getting back similar
results as you do so.

But as Jerry said, this isn't quite the right way to do it. If you just
need to set the variable for your current shell session, then doing it
this way is sufficient, but if you need it to work for all of your
shells then the export statement needs to be in a file like ~/.bashrc,
~/.profile, or /etc/profile.

Once you've edited the right config file -- ~/.profile is probably a
good choice (unless you're adamant about using root shells, in which
case you may as well use /etc/profile to make the setting global to all
users on your system, including root), but it really isn't so important
which one gets the statement -- you can load the changed sessions for a
currently open shell with a

    $ source ~/.profile

or

    $ . ~/.profile

which does the same thing. Shells started after making the change should
pick up the setting, and if you log out & back in again then everything
should be all set (but if you don't want to lose state with all your
open windows, the above lines are less drastic than logging out).

> so i peeked at env;
>
> [eric at mathPlayPen eric]$ env
> SSH_AGENT_PID=4672
> HOSTNAME=mathPlayPen
> <snip>
> PATH=/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/eric/bin
> </snip>
> [eric at mathPlayPen eric]$
>
> so is PATH= where i should see a "JAVA_HOME" reference?

No.

Do you get what an environment variable is? It's a variable set such
that all programs within the scope of the current environment can share
the setting defined by that variable. (And if the concept of 'scope'
doesn't make sense, any intro programming book could explain it better
than I can.)

So. Setting JAVA_HOME inside PATH makes no sense: programs looking for
the $JAVA_HOME environment variable won't look for it nested inside
another variable, and programs looking for the $PATH environment
variable may well break at the malformed syntax you're introuducing.

PATH and JAVA_HOME need to be separate variables.

The `env` command is a tool for seeing what variables are currently
defined. If you do a command like this:

    $ env | grep JAVA_HOME
    JAVA_HOME=/Library/Java/Home
    $

You should get a result similar to what I get back here, but with a path
that makes more sense for your computer. If you get back this:

    $ env | grep JAVA_HOME
    $

Then $JAVA_HOME is undefined, and you need to set it with `export...`.

Clearer?

> my bash profile looks like this;
>
> [snip --chd]
>
> could i just type in a change to this text file?

Yes, that should work well. The line you use would be exactly what you
would use at an interactive shell:

    export JAVA_HOME=/opt/j2sdk_nb/j2sdk1.4.2/jre/bin

Or you could do it as a two-liner, like this:

    JAVA_HOME=/opt/j2sdk_nb/j2sdk1.4.2/jre/bin
    export JAVA_HOME

But I'm not really sure what the point of that would be in this context.

The general idea is that in the Bourne shell, you can declare a locally
scoped variable by using a command like this:

    VAR="some value"

Local variables here exist for the life of either the current command
line (e.g. `FOO=bar; grep $FOO /path/to/baz >~/$FOO.out`) or the current
shell script, and are unavailable beyond that lifetime & scope. However,
you can promote that variable to a global environment variable that is
available to the parent of the current command or script by exporting it
in one of two ways -- prefixing the declaration with `export` (in shells
or in shell scripts), or by using `export VAR` to promote a variable
that came up earlier in a given shell script (e.g. ~/.bashrc):

    VAR="some value"
    export $VAR

    export VAR="some value"

Clearer now?



-- 
Chris Devers