Bug 449286

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.