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): 3.20-1 How Reproducible: always 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. Actual Results: $PS1 is unset in gnome-terminal, xterm and others (unless the terminal emulator itself executes its own shell as a login shell) Expected Results: The value of $PS1 should be set at login time and propagate down to child processes. Additional Information:
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 script. 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.