Bug 136859 - inconsistent processing of /etc/profile.d/
inconsistent processing of /etc/profile.d/
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: setup (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2004-10-22 15:02 EDT by Sean Dilda
Modified: 2014-03-16 22:49 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-27 13:55:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Fix this bug for FC3 version (568 bytes, patch)
2004-10-27 10:27 EDT, Sean Dilda
no flags Details | Diff

  None (edit)
Description Sean Dilda 2004-10-22 15:02:25 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
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.
Comment 1 Bill Nottingham 2004-10-23 00:15:14 EDT
If you replace /etc/bashrc with the FC3 version, does it behave?
Comment 2 Sean Dilda 2004-10-27 10:27:10 EDT
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.
Comment 3 Bill Nottingham 2004-10-27 13:55:04 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.