How to capture all the environment variables from shell?

Steven W. Orr steveo at syslang.net
Tue Aug 10 10:07:23 EDT 2010


On 8/2/2010 4:33 AM, Thorsten Kampe wrote:
> * Tim Chase (Mon, 26 Jul 2010 21:42:24 -0500)
>> 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...
> 
> ~/.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


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



More information about the Python-list mailing list