I had another couple of thoughts about this:
1) The Mac uses a 'magic' file to set the user's environment ~/.MacOSX/environment.plist
2) Windows uses the registry to set the user's environment
This feels correct to me. Bash (and the other shells) should have nothing to do with setting global (or user-wide) environment strings. Sure, the shells can change the environment - however the initial environment should be set elsewhere and I think that's about what /etc/environment does.
However somebody's modifying LD_LIBRARY_PATH between reading the file /etc/environment and user processes being started. Or maybe the parser for /etc/environment simply ignores LD_LIBRARY_PATH in a well-intended conspiracy with ldconfig.
In the file /etc/environment, I've added LD_LOVELY_PATH and LD_LIBRARY_PATH. LD_LOVELY_PATH survives startup. Somebody is removing LD_LIBRARY_PATH.
508 /home/rmills> cat /etc/environment usr/local/ sbin:/usr/ local/bin: /usr/sbin: /usr/bin: /sbin:/ bin:/usr/ games" PATH="/ usr/local/ lib" PATH="/ usr/local/ lib"
PATH="/
LD_LOVELY_
LD_LIBRARY_
509 /home/rmills>
I had another couple of thoughts about this: environment. plist
1) The Mac uses a 'magic' file to set the user's environment ~/.MacOSX/
2) Windows uses the registry to set the user's environment
This feels correct to me. Bash (and the other shells) should have nothing to do with setting global (or user-wide) environment strings. Sure, the shells can change the environment - however the initial environment should be set elsewhere and I think that's about what /etc/environment does.
However somebody's modifying LD_LIBRARY_PATH between reading the file /etc/environment and user processes being started. Or maybe the parser for /etc/environment simply ignores LD_LIBRARY_PATH in a well-intended conspiracy with ldconfig.