Red Hat Bugzilla – Bug 111483
/etc/profile.d scripts run by /etc/bashrc
Last modified: 2014-03-16 22:40:44 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; Linux i686; U) Opera 7.23 [en]
Description of problem:
Actually, this is more in the way of a question than a bug report
(though I do consider the behaviour undesirable). Having googled
extensively and checked the RedHat manuals, I can find no mention of
why /etc/bashrc runs the scripts in /etc/profile.d (in the case that
they haven't already been run by /etc/profile).
I noticed this because of a 3rd party /etc/profile.d script that
added something to an environment variable. Of course, every time a
subshell is spawned, this causes the variable to be expanded, which
is undesirable. I filed a bug report with patch to the maintainer of
the RPM in question, but it still seems reasonable to wonder why
something called "profile", which one expects, by analogy with .
profile, /etc/profile and .bash_profile to be run only in login
shells, is being run in all shells.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start bash, not as a login shell.
Actual Results: The /etc/profile.d scripts are run.
Expected Results: I would've expected them to be run only in a login
It's a really really old change. ISTR it was done for uniformity of
all interactive shells, for example, xterms, etc.
Since you've not closed the bug, I'm guessing you at least admit the
possibility that it might be a problem?
Just as a suggestion, here's my view on what should happen: because
/etc/profile and .bash_profile aren't run in every xterm either
(unless you use the -ls option) I've either set a default of -ls, or
caused my environment to be set up by .Xclients or somewhere else in
the login process (at the moment I don't use xdm, kdm or whatever, so
it's simply a question of logging in and running startx; all my X
clients therefore inherit my login environment).
Some solution like this is cleaner as it doesn't break assumptions
about the function of profile.d scripts, while still giving the
expected effect in xterms (not to mention other applications started
directly by the window manager).
At this point, I don't think we're going to change this.