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.