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
Built in rawhide as setup-2.7.4-2.fc11 with exporting of PATH after processing /etc/profile.d scripts.
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
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
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.
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).
(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.
(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.