Prev: python styles: why Use spaces around arithmetic operators?
Next: parsing different xml messages
From: Tim Chase on 26 Jul 2010 22:42
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...

-tkc



From: Steven D'Aprano on 26 Jul 2010 23:01
On Mon, 26 Jul 2010 22:26:27 -0400, 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

Would you like to explain why, or should we just trust you?


--
Steven
From: Nobody on 27 Jul 2010 06:21
On Mon, 26 Jul 2010 21:42:24 -0500, Tim Chase 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...

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.

From: Steven W. Orr on 27 Jul 2010 23:31
On 07/26/10 22:42, quoth Tim Chase:
> 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...
>
> -tkc
>
>

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}

--
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

From: Thorsten Kampe on 2 Aug 2010 04:33
* 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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: python styles: why Use spaces around arithmetic operators?
Next: parsing different xml messages