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 #!/usr/bin/python import os print os.environ['G_BROKEN_FILENAMES'] 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 still there. 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 nervous. :) Fixed in 2.5.37-1.