How to capture all the environment variables from shell?
Peng Yu
R_HOME is set in my shell (bash). But os.environ doesn't have it. I'm
not sure what it does when os module is imported. But it seems that
os.environ doesn't capture all the environment variable from the
shell. Could anybody let me know what is the correct way to inherent
all the environment variables form the shell?
$ echo $R_HOME
/opt/R-2.11.1
$ cat main.py
#!/usr/bin/env python
import os
print os.environ['R_HOME']
$ ./main.py
Traceback (most recent call last):
File "./main.py", line 5, in <module>
print os.environ['R_HOME']
File "/opt/Python-2.6.5/lib/python2.6/UserDict.py", line 22, in __getitem__
raise KeyError(key)
KeyError: 'R_HOME'
--
Regards,
Peng
Chris Rebert
You need to "export R_HOME" in bash (probably in your .bashrc or
.bash_profile). See
http://www.ibm.com/developerworks/library/l-bash.html#N10074
Cheers,
Chris
--
http://blog.rebertia.com
Rhodri James
> R_HOME is set in my shell (bash). But os.environ doesn't have it. I'm
> not sure what it does when os module is imported. But it seems that
> os.environ doesn't capture all the environment variable from the
> shell. Could anybody let me know what is the correct way to inherent
> all the environment variables form the shell?
os.environ does capture all the environment that the shell passes to it.
In this case, you haven't exported R_HOME, so the shell doesn't export
it, so os.environ has no chance to capture it.
rhodri@gnudebst:~$ HELLO=world
rhodri@gnudebst:~$ echo $HELLO
world
rhodri@gnudebst:~$ export HELLO
rhodri@gnudebst:~$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.environ['HELLO']
'world'
--
Rhodri James *-* Wildebeest Herder to the Masses
Cameron Simpson
| R_HOME is set in my shell (bash). But os.environ doesn't have it. I'm
| not sure what it does when os module is imported. But it seems that
| os.environ doesn't capture all the environment variable from the
| shell. Could anybody let me know what is the correct way to inherent
| all the environment variables form the shell?
|
| /opt/R-2.11.1
| $ cat main.py
| #!/usr/bin/env python
|
| import os
|
| print os.environ['R_HOME']
| $ ./main.py
| Traceback (most recent call last):
| File "./main.py", line 5, in <module>
| print os.environ['R_HOME']
| File "/opt/Python-2.6.5/lib/python2.6/UserDict.py", line 22, in __getitem__
| raise KeyError(key)
| KeyError: 'R_HOME'
Sounds like R_HOME is not exported.
Try these in your shell:
set | grep R_HOME
export | grep R_HOME
Then, presuming it shows only in the first command:
export R_HOME
and then try your python script again.
Cheers,
--
Cameron Simpson <c...@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/
It is an approved maxim in war, never to do what the enemy wishes you to
do, for this reason alone, that he desires it. - Napoleon
Steven W. Orr
Please! Never export anything from your .bashrc unless you really know what
you're doing. Almost all exports should be done in your .bash_profile
--
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net
Tim Chase
> Please! Never export anything from your .bashrc unless you
> really know what you're doing. Almost all exports should be
> done in your .bash_profile
Could you elaborate on your reasoning why (or why-not)? I've
found that my .bash_profile doesn't get evaluated when I crank up
another terminal window, while my bashrc does. Thus I tend to
put my exports in my ~/.bashrc so they actually take effect in my
shell...
-tkc
Steven D'Aprano
> Please! Never export anything from your .bashrc unless you really know
> what you're doing. Almost all exports should be done in your
> .bash_profile
Would you like to explain why, or should we just trust you?
--
Steven
Nobody
Ideally, whichever program spawns the terminal window should have all of
the environment settings from your ~/.profile (although you may have
to explicitly source it from e.g. ~/.xsession), so it shouldn't be
necessary to export them again.
Using ~/.bashrc is a band-aid in case your desktop session doesn't already
have your environment settings. But it only works for shells (and only for
bash shells, and only for interactive bash shells), while your environment
settings should be available to everything, regardless of whether it was
spawned from an interactive bash shell or from some other program.
Also, if you update environment variables with e.g.:
export PATH=$PATH:/usr/local/bin
any nested shells end up getting multiple updates.
Steven W. Orr
> On 07/26/10 21:26, Steven W. Orr wrote:
>> Please! Never export anything from your .bashrc unless you
>> really know what you're doing. Almost all exports should be
>> done in your .bash_profile
>
> Could you elaborate on your reasoning why (or why-not)? I've found that
> my .bash_profile doesn't get evaluated when I crank up another terminal
> window, while my bashrc does. Thus I tend to put my exports in my
> ~/.bashrc so they actually take effect in my shell...
>
>
>
I'm happy to elaborate, but people should feel free to stop me if they're not
interested. The topic is bash:
When you log in you get your .bash_profile and not the .bashrc. Subshells get
the .bashrc and not the .bash_profile. If you set your envvars in your
.bash_profile then you don't need to reset them in subshells because they all
get inherited. (Inheritance of envvars is, after all, the reason that they are
envvars and not just local variables.)
The way you get your .bashrc to happen at login time is that you have to make
it happen yourself. In your .bash_profile, just say this:
. ~/.bashrc
The one time that you should set an envvar in your .bashrc is when you are not
an interactive shell. In that case you can set your PATH var in your .bashrc
by first testing to see if you're interactive: In your .bashrc just say:
[[ -z "$PS1" ]] && set_PATH_cmds
# Of course, note that set_PATH_cmds is not a subprocess. It has to
# be either a PATH= or function that accomplishes the same thing.
This solves the problem of things like
ssh somemachine cmd
where cmd is something that you would only find on your PATH if you properly
logged in.
As far as X goes, I am starting from the premise that your X session will be
set up to cause your .bash_profile to happen at login time.
One last note: If you say something like
export PATH=$PATH:/usr/local/bin
then re-sourcing your .bash_profile will cause your PATH value to double up.
That's why I set my PATH variable explicitly.
After that, I encourage people to set up their PATH variables so that they are
broken into four distinct sections in the following order. (The idea is to
make your stuff override the system supplied stuff.) (The stuff below is just
an example.)
USERPERSONAL=~/bin:~/share/bin
MACHINESPECIALS=/usr/local/bin:/usr/local/share/bin
OPTIONALADDONS=/opt/Adobe/Reader9/bin:/opt/openoffice.org3/program
VENDORPATHS=/bin:/usr/bin:/usr/X11R6/bin
PATH=${USERPERSONAL}:${MACHINESPECIALS}:${OPTIONALADDONS}:${VENDORPATHS}
Thorsten Kampe
~/.bash_profile is only evaluated for login shells and ~/.bashrc only
for non-login shells. Thus it's recommended to keep ~/.bash_profile
empty (except a source statement for .bashrc) and put all your settings,
aliases, exports, etc. in .bashrc.
Thorsten
Steven W. Orr
Sorry. Dead wrong. Please reread the above comment I wrote. If you set your
environment variables in the .bashrc then you completely lose the ability of
environment variables to be inherited by sub-shells. Again, envvars should be
set in the .bash_profile, most everything else should be set in the .bashrc, and
the .bashrc should be sourced into the .bash_profile to solve the problem that
you thought you were solving.
After that, and again, be aware that the .bashrc alone is executed for login
shells *which are not interactive*. for example:
ssh somemachine 'echo Hello'
This command will *not* go through the .bash_profile but it will go through the
.bashrc. This means that for cases like this, we want to check to see if the
bash process is interactive or not inside the .bashrc and then do the right thing.
========<Inside your .bashrc>=======
[[ -z "$PS1" ]] && setPATHHere
========<EOInside your .bashrc>=======
This is not needed for the above degenerate case, but it is needed if the
command in question is kept in a directory that you normally find in a place
that is part of your personal login PATH. E.G., If myprog lives in ~/bin then
ssh somemachine myprog
will fail unless you use the above construct.
Hopefully, I'll only have to re-explain this another google times...
--
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net steve orr