Red Hat Bugzilla – Bug 20893
BASH /etc/profile and ~/bash_profile Not Read
Last modified: 2008-05-01 11:37:59 EDT
Problem: The PATH variable, nor any other variable, can be set
from /etc/profile nor ~/.bash_profile
Several hours have been spent confirming this issue that arose during a
typical installation of the Sun JDK. The java binary could not be
launched despite the inclousion of the binary location in the path
variable. Several other programs also will not launch despite inclusion
in the path. Test varibales setup also do not execute despite confirming
that the variables are being exported and syntactically correct.
/etc/bashrc -- OK executes properly on login
/etc/profile -- FAILS on login
~/.bashrc -- OK executes properly
~/.bash_profile -- FAILS on login
If the exact same PATH statement is placed in bashrc or .bashrc and
exported in exactly the same manner, the PATH is properly exported and
updated --confirmed through echo $PATH from the bash prompt.
The problem only arises if the user attempts to add additional PATH
configuration information -- for example, to facilitate execution of a new
application. The standard installation info allows proper operation of
the RedHat 7.0 distro which is probably why this was missed.
No obvious syntactic problems are evident.
This is actually the intended behavior.
If both /etc/bashrc and /etc/profile exist, bashrc is executed by bash. /etc/profile can be used for non-bash shells.
~/.bashrc is executed in a shell that is not a login shell, such as xterms.
~/.bash_profile is executed in login shells, such as the shells on a real vc.
See the man page for further information.
I recently observed the same problems as this person... /etc/profile is not
executed on login. The resolution to this doesn't handle this problem. However,
I have investigated it further. It seems the problem only crops up if you use
KDM as the graphical login. If you use the text login, there is no problem. I
think this has to do with KDM only starting bash in non-interactive mode.
I have basically the same problem. It may be a feature, but no one notified
that it was changing. My scripts used to work just fine, I installed 7.0 and it
took me until now to figure out exactly why my scripts werent being run.
email@example.com commented: "If both /etc/bashrc and /etc/profile exist, bashrc
is executed by bash. /etc/profile can be used for non-bash shells."
Not according to the bash(1) manpage. It says, "When bash is invoked as an
interactive login shell, or as a non-interactive shell with the --login option,
it first reads and executes commands from the file /etc/profile, if that file
exists." There is no mention of /etc/bashrc in the bash manpage at all. I'm
still working to determine what really does happen; however, either your remark
or the manpage is incorrect.
After some testing, I've determined that bash does behave according to the
For a login shell, bash sources /etc/profile, then ~/.bash_profile.
For a non-login interactive shell, bash sources ~/.bashrc.
For a non-login, non-interactive shell, bash sources the script found in
The only way that bash should read /etc/bashrc is if one of the other
initialization scripts explicitly sources it. The default scripts (from
/etc/skel) do that. However, if you remove those lines from your ~/.bashrc, bash
won't see /etc/bashrc at all.
One thing users should be aware of: bash will ordinarily only see /etc/profile
and ~/.bash_profile once, when you first log in (on a console, through X, or
with "su -"). After that, it will only read ~/.bashrc, and only for interactive
shells (ie., not for scripts). If you have explicitly sourced /etc/bashrc, it
will see that too, and if you have set $BASH_ENV (perhaps with
BASH_ENV=~/.bashrc), it will also work for non-interactive shells.