Red Hat Bugzilla – Bug 20893
BASH /etc/profile and ~/bash_profile Not Read
Last modified: 2008-05-01 11:37:59 EDT
RedHat 7.0 Problem: The PATH variable, nor any other variable, can be set from /etc/profile nor ~/.bash_profile Testing: 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.
bero@redhat.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 manpage: 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 $BASH_ENV. 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.