"eselect env update" behaves differently from "env-update". Path elements are accumulated in profile.env and are not deleted, even if they are removed from the files in env.d. The following session illustrates the problem: # echo INFOPATH=foo >/etc/env.d/99test # env-update; . /etc/profile >>> Regenerating /etc/ld.so.cache... # echo $INFOPATH /usr/share/info:[...]:foo [O.K.] # echo INFOPATH=bar >/etc/env.d/99test # env-update; . /etc/profile >>> Regenerating /etc/ld.so.cache... # echo $INFOPATH /usr/share/info:[...]:bar [O.K.] # rm /etc/env.d/99test # env-update; . /etc/profile >>> Regenerating /etc/ld.so.cache... # echo $INFOPATH /usr/share/info:[...] [O.K.] # echo INFOPATH=foo >/etc/env.d/99test # eselect env update; . /etc/profile Regenerating /etc/ld.so.cache... # echo $INFOPATH /usr/share/info:[...]:foo [O.K.] # echo INFOPATH=bar >/etc/env.d/99test # eselect env update; . /etc/profile Regenerating /etc/ld.so.cache... # echo $INFOPATH /usr/share/info:[...]:foo:bar [This should contain "bar" only.] # rm /etc/env.d/99test # eselect env update; . /etc/profile Regenerating /etc/ld.so.cache... # echo $INFOPATH /usr/share/info:[...]:foo:bar [Should contain neither "foo" nor "bar".] # env-update; . /etc/profile >>> Regenerating /etc/ld.so.cache... # echo $INFOPATH /usr/share/info:[...] [O.K.]
Still the same in 1.0.9.
I observe the same. I tried to use "do_action env update &> /dev/null" in gnat.eselect module, but that pulls in active enc settings (like active PATH, ADA_INCLUDE_PATH, etc) which essentially breaks functionality of gnat.eselect module. This can be worked around by using env-update directly inside the gnat.eselect, however this is flagged "incorrect" in the eselect documentation (in developer-guide.html), plus it only makes sense to use eselect's own modules where possible. I could provide a gnat specific extra test case, but the one above is way more simple and represents the issue well enough (short version: add "do_action env update &> /dev/null" to the end of do_set and do_update functions of gnat.eselect module and try switching from e.g. x86_64-pc-linux-gnu-gnat-gcc-4.2 to x86_64-pc-linux-gnu-gnat-gcc-4.1 (gnat-gcc-4.1.2 and gnat-gcc-4.2.0 would need to be installed) and then do ". /etc/profile" in some shell without running env-update first and then check PATH and ADA_INCLUDE_PATH vars. They should not contain old (but that were active at the moment of running eselect gnat set or env update) values (4.1 when activating 4.2 or vice verse). I also upped the severity one notch, as eselect is an important package and env is a central its module and this is indeed a major issue for any package trying to utilize this functionality. George
Looks like the problem is in lib/config.bash, function load_config(). The ${key} variable misses a local declaration; so if it is not set in the config file, then its value will happily be taken from the environment. Attached patch should fix the problem.
Created attachment 121363 [details, diff] Patch for eselect-1.0.9
Created attachment 121365 [details, diff] Patch for eselect-1.0.9 Quotation marks are not neccessary here.
george: Can you confirm if the patch fixes the problem for you?
Sorry for the delay, got carried out by other stuff. Yes, this fixes it. Thanks! Now we only need this fix to be picked up :). George
Changed summary since the problem is not in env.eselect, but in config.bash.
Fixed as of 1.0.10
