Prev: python styles: why Use spaces around arithmetic operators?
Next: parsing different xml messages
From: Steven W. Orr on 10 Aug 2010 10:07
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
From: Cameron Simpson on 10 Aug 2010 23:08
On 10Aug2010 10:07, Steven W. Orr <steveo(a)syslang.net> wrote:
| 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.
|
| 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.

No, only interactive shells use the .bashrc.

Still, you're quite right that envvars belong in the .bash_profile.
..bashrc is for trivial setup stuff relevant only to interactive shells
(for example history settings and interactive aliases).

| 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 Very Wrong. (RedHat do this test - it is bogus - if I set $PS1
in my profile it breaks badly.) Instead, test $-:

case $- in *i*) echo INTERACTIVE ;; *) echo BATCH ;; esac

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

"googol", surely?

The reason .bashrc gets overused for envars, aside from ignorance and
propagated bad habits, is that in a GUI desktop the setup sequence is
often a bit backwards. A conventional terminal/console login means you
get a login shell that sources your .{bash_}profile. And from there one
would start a GUI and all the .profile stuff has been run Once, as it
should be. But when the login itself is a GUI the various terminals get
started _before_ the .profile stuff gets sourced, because the terminal
is started by the desktop manager. Once common "fix" for this is to
make all new terminals run login shells. Ugh, but it does work. But it
they're not login shells, people stuff everything into their .bashrc
because the .profile doesn't get sourced. And so the common awful setup
you're bemoaning.

Cheers,
--
Cameron Simpson <cs(a)zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

For us, Zettai Zetsumei Toshi is an allegory for relations between the sexes,
and it works especially well at this because we don't speak Japanese. She
will say things, and we have no idea what the hell is going on, and then
we'll select from a list of responses, but we have no idea which one is the
right one, and then they're all wrong. It works on a lot of levels.
- Tycho @ _Penny_Arcade_
From: Cameron Simpson on 10 Aug 2010 23:16
On 11Aug2010 13:08, I wrote:
| On 10Aug2010 10:07, Steven W. Orr <steveo(a)syslang.net> wrote:
[...]
| | 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.
|
| No, only interactive shells use the .bashrc.

And then I read more closely and saw this in "man bash":

Bash attempts to determine when it is being run by the remote shell
daemon, usually rshd. If bash determines it is being run by rshd,
it reads and executes commands from ~/.bashrc, if that file exists and
is readable. It will not do this if invoked as sh. The --norc option
may be used to inhibit this behavior, and the --rcfile option may be
used to force another file to be read, but rshd does not generally
invoke the shell with those options or allow them to be specified.

Frankly, bash's startup behaviour is so corrupt (well, capricious anway)
that I despair of it; I use zsh when possible. It also tries to be all
things to all people, but is a bit saner. (And it doesn't hardwire ^W
either!)

Cheers,
--
Cameron Simpson <cs(a)zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

To be positive: To be mistaken at the top of one's voice.
Ambrose Bierce (1842-1914), U.S. author. The Devil's Dictionary (1881-1906).
From: Nobody on 11 Aug 2010 20:28
On Wed, 11 Aug 2010 13:08:59 +1000, Cameron Simpson wrote:

> The reason .bashrc gets overused for envars, aside from ignorance and
> propagated bad habits, is that in a GUI desktop the setup sequence is
> often a bit backwards. A conventional terminal/console login means you
> get a login shell that sources your .{bash_}profile. And from there one
> would start a GUI and all the .profile stuff has been run Once, as it
> should be. But when the login itself is a GUI the various terminals get
> started _before_ the .profile stuff gets sourced, because the terminal
> is started by the desktop manager. Once common "fix" for this is to
> make all new terminals run login shells. Ugh, but it does work.

Er, not really. If you don't source your ~/.profile (etc) from e.g.
~/.xsession, GUI applications don't get to see the environment settings
therein. The environment isn't just for shells.

The reason why ~/.profile is only sourced by login shells is that it's
supposed to be sourced exactly once, by the initial process of a session,
i.e. the one from which all other programs descend. For a terminal-based
login, "login" (or sshd or whatever) starts the shell as a login shell
(with argv[0][0] == '-'), and the shell sets up the environment.

For a desktop login, there is no login shell, so something else has to set
up the environment. Simple enough; well, simple enough for anyone who
understands Unix, processes, sessions, etc. But apparently too complex for
the people who create desktop environments, who seem to think that the
environment is somehow specific to shells.

So you usually need to manually configure your session script (e.g.
~/.xsession for xdm) to set up the environment before the desktop
environment gets a look-in.

One caveat: if you set LD_LIBRARY_PATH, it will be unset when running a
setuid or setgid program. This is sometimes the case for terminal
emulators[1], in which case you need to have ~/.bashrc reinstate the
setting.

[1] Allocating a BSD-style pty requires root privilege, and writing
utmp/wtmp entries requires write permission on the file. Modern systems
have Unix98 ptys and a setgid helper program to manage the utmp/wtmp
entries, so there shouldn't be any need for xterm etc to be setuid or
setgid nowadays.

From: Cameron Simpson on 12 Aug 2010 00:16
On 12Aug2010 01:28, Nobody <nobody(a)nowhere.com> wrote:
| On Wed, 11 Aug 2010 13:08:59 +1000, Cameron Simpson wrote:
| > The reason .bashrc gets overused for envars, aside from ignorance and
| > propagated bad habits, is that in a GUI desktop the setup sequence is
| > often a bit backwards. A conventional terminal/console login means you
| > get a login shell that sources your .{bash_}profile. And from there one
| > would start a GUI and all the .profile stuff has been run Once, as it
| > should be. But when the login itself is a GUI the various terminals get
| > started _before_ the .profile stuff gets sourced, because the terminal
| > is started by the desktop manager. Once common "fix" for this is to
| > make all new terminals run login shells. Ugh, but it does work.
|
| Er, not really. If you don't source your ~/.profile (etc) from e.g.
| ~/.xsession, GUI applications don't get to see the environment settings
| therein. The environment isn't just for shells.

I think we're in violent agreement here. I arrange to do exactly that in
my own desktop setups.

However, the ones that ship with distros generally don't, possibly because a
shell-aborting error in the .profile (or unwanted interaction etc) will abort
the GUI login/desktop-setup.

Cheers,
--
Cameron Simpson <cs(a)zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

The Puritan hated bear-baiting, not because it gave pain to the bear, but
because it gave pleasure to the spectator. - Macaulay, History of England
First  |  Prev  | 
Pages: 1 2 3
Prev: python styles: why Use spaces around arithmetic operators?
Next: parsing different xml messages