Red Hat Bugzilla – Bug 136859
inconsistent processing of /etc/profile.d/
Last modified: 2014-03-16 22:49:44 EDT
Changing a users shell between tcsh and bash can change when files
under /etc/profile.d/ get processed. This inconsistency can cause
several headaches for sysadmins.
The case in question is when someone uses ssh to launch a remote
command that isn't a shell script.
As an example, create the following file in your home directory:
[sean@head4 sean]$ cat env.py
Then ssh in and run it, like this: 'ssh <host> ./env.py' If your
shell is set to bash, it will traceback and say that os.environ
doesn't have the key 'G_BROKEN_FILENAMES'. If you shell is set to
tcsh, it'll print out '1'.
The problem seems to come from /etc/bashrc checking $SHLVL before
processing /etc/profile.d/*.sh Its trying to guess if its a login
shell (and if /etc/profile already processed the files). However, in
the case I outlined above, it guesses wrong.
If you replace /etc/bashrc with the FC3 version, does it behave?
Created attachment 105840 [details]
Fix this bug for FC3 version
I tried the /etc/bashrc from setup-2.5.35-1.noarch.rpm and the problem was
However, when I moved the /etc/profile.d/*.sh processing out of the 'if [
"$PS1" ]' it then started working as I'd expect. I included a patch of the
changes I made to the fc3 version of setup.
a) that looks obviously correct
b) that's changing behavior that's been that way for years. Makes me
Fixed in 2.5.37-1.