Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |