Red Hat Bugzilla – Bug 56822
/etc/profile not being executed by bash
Last modified: 2007-04-18 12:38:28 EDT
Description of Problem:
The /etc/X11/xdm/Xsessions script executes sub-scripts with the command:
exec -l $SHELL -c <script-name>
This way, bash (2.05a and earlier) does not run as a login shell and skips the /etc/profile.
Removing the "-c" switch fixes the problem. The bash man page states that exec -l should invoke the command with a dash in $0, but with -c bash replaces $0 with the name of the script _before_ deciding wether it's being invoked as a login shell or not.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Use xdm or kdm to start an X11 session
2. open a terminal emulator
3. observe that $PS1 and other environment variables have not been set as specified by /etc/profile and /etc/profile.d/* scripts.
$PS1 is unset in gnome-terminal, xterm and others (unless the terminal emulator itself executes its own shell as a login shell)
The value of $PS1 should be set at login time and propagate down to child processes.
I can reproduce this in a 7.3 install.
If you want a login shell in xterm or other terminal while running
X, you must invoke the terminal with the appropriate commandline option
to have it invoke bash as a login shell. The default and correct
behavior of all terminals started in X sessions is to invoke a shell
as a subshell. That is why terminals have a commandline option to
specify a login shell.
So, I don't consider this a bug, unless I'm totally misunderstanding
what it is that you're saying. If so, please clarify.
(On a side note: Please when entering bug reports, do so with single
spacing, and not double spacing. Also hit enter after 60 characters
or so, so that the bug report is readable. Viewing this bug report
even at 1600x1200 in mozilla shows a huge mess of doublespaced lines
which scroll way off the right side of my monitor.)
I've actually realized that /etc/profile and the scripts in /etc/profiles.d/ are actually
executed after Xsessions. All variables are correctly set in terminal emulators,
EXCEPT for $PS1. It seems the value of $PS1 set by /etc/profile is forgotten
when the login shell created by /etc/X11/xdm/Xsessions execs the ~/.Xclients
This is quite annoying because I set the prompt for all users in
/etc/profile/zzz_prompt.sh. Works fine for console logins, bug all I get
when I open an xterm (or konsole or gnome-terminal) is the default
bash prompt (PS1 is unset).
That is not a bug. When you open an xterm, you are opening a bash
subshell, and /etc/profile and profile.d are explicitly *not* sourced.
If you want that behavior, then you want a login shell, as a login shell
by definition sources the profile/profile.d, but a non-login shell does
not. Invoke xterm with the proper commandline option to tell it to use
a login shell, and you will get the desired behaviour.
Closing bug report as NOTABUG. Everything is working as it should.
I know how bash sources its startup files in the normal and login cases. However,
$PS1 should be set in the login shell invoked by Xstartup and, since $PS1 it being
exported in the profile script, it should be inherited by all the processes spawned
within the X session and eventually reach every bash ran by xterm.
Instead, I see that $PS1 is already lost in ~/.Xclients.
As an additional test, I tried setting the prompt again in .Xclients and it
to every subshell, including xterm shells. Therefore, Xsessions must be
responsible for clearing it and is the place that needs a fix.
Please note that only $PS1 is reset. $PATH and other variables retain
their values. The bash manual does not mention this magic behavior...
I think bash probably unsets PS1 in non-interactive shells.
So you want to set PS1 in "/etc/bashrc" or "~/.bashrc" for
interactive non-login shells.