Bug 20893 - BASH /etc/profile and ~/bash_profile Not Read
Summary: BASH /etc/profile and ~/bash_profile Not Read
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: bash (Show other bugs)
(Show other bugs)
Version: 7.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-11-15 04:08 UTC by Need Real Name
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-11-15 14:00:02 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Need Real Name 2000-11-15 04:08:12 UTC
RedHat 7.0

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.

Comment 1 Bernhard Rosenkraenzer 2000-11-16 10:28:15 UTC
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.

Comment 2 kumar1 2001-01-16 20:22:26 UTC
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.

Comment 3 dkaplan 2001-01-28 23:48:33 UTC
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.

Comment 4 Bradd W. Szonye 2001-04-04 00:13:38 UTC
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.

Comment 5 Bradd W. Szonye 2001-04-04 00:42:29 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.