Bug 449286 - /etc/profile doesn't export PATH after reading profile.d
/etc/profile doesn't export PATH after reading profile.d
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: setup (Show other bugs)
9
All Linux
low Severity medium
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-01 15:30 EDT by Jay Levitt
Modified: 2008-12-04 08:18 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-02 20:17:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jay Levitt 2008-06-01 15:30:36 EDT
Description of problem:

/etc/profile does things in this order:
1. some stuff
2. export PATH
3. source anything in /etc/profile.d

That means that if PATH doesn't happen to get exported again later, anything
that sets it in profile.d loses.  (The convention in profile.d seems to be to
simply set PATH, not export it; see e.g. ccache.sh, krb5-devel.sh,
krb5-workstation.sh.  Although, see counterexample: qt.sh.)

Version-Release number of selected component (if applicable):
2.6.14-1.fc9

How reproducible:
100%

Steps to Reproduce:
1. Add something to /etc/profile.d that sets PATH
2. Delete everything else that might set it later (exercise left for reader)
3. See it not in PATH
  
Actual results:


Expected results:


Suggested fix: 
1. move export statement to end of /etc/profile
2. see if that breaks something
Comment 1 Ondrej Vasik 2008-11-18 07:13:05 EST
Built in rawhide as setup-2.7.4-2.fc11 with exporting of PATH after processing /etc/profile.d scripts.
Comment 2 Fedora Update System 2008-11-18 10:31:39 EST
setup-2.6.18-1.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/setup-2.6.18-1.fc9
Comment 3 Fedora Update System 2008-11-19 09:50:40 EST
setup-2.6.18-1.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update setup'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-9727
Comment 4 Fedora Update System 2008-12-02 20:17:40 EST
setup-2.6.18-1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 5 Chris Schanzle 2008-12-03 23:13:20 EST
I'm sorry, I just noticed this from the changelog after the update.

I do not believe the original reporter is correct, nor does the fix really have any effect.  Once a shell variable is marked to be exported, it will be exported with whatever its current value is.  I.e., the value can be changed at any time, and the new value will be sent to subprocesses.  Exporting again adds no value.

Short test:
$ export foo=bar
$ /usr/bin/env | egrep foo
foo=bar

$ foo=qwer
$ /usr/bin/env | egrep foo
foo=qwer

As a student, did the experiment suggested:

cd /etc/profile.d/
mkdir .hidden
egrep -l PATH * | xargs mv -vt .hidden
echo 'PATH=/foo:$PATH' > foo.sh
su - $USER
echo $PATH | grep foo
/home/schanzle/bin:/foo:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/bin:/usr/bin

[I munge /etc/profile by commenting out the test for $EUID=0, so that all users get sbin dirs.]

I think the OP may have been confused by how he tested; opening a new shell by just typing "bash" or often, a new terminal window, doesn't change PATH as expected.  Using 'su -' will clear out the environment; "bash -l" will gradually grow the PATH with redundant apppend/prepends.

In the name of correctness, propose this change be reverted.  I'd be happy to open a new bug if that is more correct (I can't re-open this one).
Comment 6 Ondrej Vasik 2008-12-04 03:42:31 EST
(In reply to comment #5)
> In the name of correctness, propose this change be reverted.  I'd be happy to
> open a new bug if that is more correct (I can't re-open this one).

Thanks for chiming and informations, I got confused - you are right - no need for second export. I will revert that change in rawhide, but as it is only cosmetic issue with actually no harm, I guess there is no need to change it back in F-9 ... No need for additional bugzilla for that rawhide change... feel free to add any comments if you feel that F-9/F-10 update is necessary. Changing resolution to NOTABUG.
Comment 7 Jay Levitt 2008-12-04 08:18:34 EST
(In reply to comment #5)
> Once a shell variable is marked to be exported, it will be
> exported with whatever its current value is.  I.e., the value can be changed at
> any time, and the new value will be sent to subprocesses.  Exporting again adds no value.

As Johnny Carson said: "I did not know that."

I have no idea what problem I originally attributed to the lack of "late export", but I certainly can't reproduce it now, and your step-by-step example proves it.  (For even more clarity, I changed 'PATH=/foo:$PATH' to 'PATH=/foo-`date +"%H_%M_%S"`:$PATH', so you can see exactly which invocation of foo.sh is making it into the PATH.)

I suspect I ran into some situation where some package goes through the "fake-out" sequence you mention - bash without the -l flag - and is missing its /etc/profile.d-set path, but having no failcase, I agree - this isn't a bug.

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