Bug 578922

Summary:	modules prepend-path corrupts environment variables during load and unload by removing the empty path
Product:	[Fedora] Fedora	Reporter:	Edgar Hoch <edgar.hoch>
Component:	environment-modules	Assignee:	Orion Poplawski <orion>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	12	CC:	dakingun, orion
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-12-03 16:28:14 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Edgar Hoch 2010-04-01 18:33:52 UTC

Description of problem:
Using "module load mpich2-x86_64" changes environment variable MANPATH in a way that most manual pages will not be found anymore.

We set MANPATH to something like ":/usr/local/our/path:/more/of/our/paths".
Then MANPATH contains the empty path (the ":" at the beginning) which will be interpreted by man to substitude the default MANPATH of the system which will be constructed using /etc/man.config .

But the modules specific tcl command "prepend-path" used in modulefiles removes the empty path. The result is that "man" doesn't find most of the system commands anymore.

The same behavior of "prepend-path" is to other environment variables like LD_LIBRARY_PATH, PATH, etc.
The same problem may have "append-path" and "remove-path" - please also check these modules specific tcl commands when checking the code.


Version-Release number of selected component (if applicable):
environment-modules-3.2.7b-7.fc12.x86_64
mpich2-1.2.1p1-1.fc12.x86_64

mpich2 is used as an example and test case because it contains
/usr/share/Modules/modulefiles/mpich2-x86_64
which contains prepend-path declarations
and the module is loaded by default in /etc/profile.d/mpich2.sh
(which it should not do - I think this needs another bug report).


How reproducible:
Always.

Steps to Reproduce:
I will show three test cases.
Each will start with environment variables set to a definite value depending on the test case,
then the module is loaded and unloaded.
After that I show the values of the variables (starting with a hash "# ").

The expected result should be that after the load and unload command the environment variables has the same value as before.
But this is true only in the case of a nonempty variable with not the empty path at the beginning.


Test cases using bash:

echo "First case: empty variables:"
unset MANPATH LD_LIBRARY_PATH
echo -e "# MANPATH=$MANPATH\n# LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
module load mpich2-x86_64
echo -e "# MANPATH=$MANPATH\n# LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
module unload mpich2-x86_64
echo -e "# MANPATH=$MANPATH\n# LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
module load mpich2-x86_64
echo -e "# MANPATH=$MANPATH\n# LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
module unload mpich2-x86_64
echo -e "# MANPATH=$MANPATH\n# LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
echo "Actual result: MANPATH is not empty."
echo "Expected result: Both variables are be empty."
echo "This is an error."

# MANPATH=/usr/share/man:/usr/local/share/man
# LD_LIBRARY_PATH=


echo "Second case: variables with path without colon at the beginning:"
export MANPATH=/my/first/path:/other/directory LD_LIBRARY_PATH=/my/library:/other/libs
echo -e "# MANPATH=$MANPATH\n# LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
module load mpich2-x86_64
echo -e "# MANPATH=$MANPATH\n# LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
module unload mpich2-x86_64
echo -e "# MANPATH=$MANPATH\n# LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
module load mpich2-x86_64
echo -e "# MANPATH=$MANPATH\n# LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
module unload mpich2-x86_64
echo -e "# MANPATH=$MANPATH\n# LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
echo "Actual result: Both variables contain there initial value."
echo "Expected result: Both variables contain there initial value."
echo "This is ok."

# MANPATH=/my/first/path:/other/directory
# LD_LIBRARY_PATH=/my/library:/other/libs


echo "Third case: variables with path with colon at the beginning:"
export MANPATH=:/my/first/path:/other/directory LD_LIBRARY_PATH=:/my/library:/other/libs
echo -e "# MANPATH=$MANPATH\n# LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
module load mpich2-x86_64
echo -e "# MANPATH=$MANPATH\n# LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
module unload mpich2-x86_64
echo -e "# MANPATH=$MANPATH\n# LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
module load mpich2-x86_64
echo -e "# MANPATH=$MANPATH\n# LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
module unload mpich2-x86_64
echo -e "# MANPATH=$MANPATH\n# LD_LIBRARY_PATH=$LD_LIBRARY_PATH"
echo "Actual result: Both variables contain there initial value but without the colon at the beginning."
echo "Expected result: Both variables contain there initial value."
echo "This is an error."

# MANPATH=/my/first/path:/other/directory
# LD_LIBRARY_PATH=/my/library:/other/libs


I expect that a sequence of module load and unload commands should set the environment in the state as it was before the start of the load-unload sequence.

This is also true for MANPATH as setting it to a default value of "/usr/share/man:/usr/local/share/man" (see first test case) blocks using /etc/man.config by "man" - and the resulting system path from /etc/man.config is much bigger as the default used with environment-module.



Additional info:
I have tested the problem with the empty path at the beginning of the variables.
When looking at the code please check if the same problem also exists with the empty path at the end of the variables and using "append-path" instead of "prepend-path" - it may be implemented in a similar way.

Comment 1 Edgar Hoch 2010-04-01 19:54:13 UTC

I want to remark that the described problem is only solved if the path modifying commands preserve the empty path in the environment variable if it was there before. That means that the variable should contain the empty path both after the module load and after the module unload command!

Here is a more detailed description about the expected behaviour of "prepend-path".
The appropriate behaviour should have "append-path" in the case where the empty path is at the end of value of the variable.

Assume the following command in a modulesfile:
prepend-path  LD_LIBRARY_PATH /path/to/prepend/library
prepend-path  MANPATH       /path/to/prepend/man

Then the values should change by module load and module unload in this way:

Start value -> value after module load -> value after module unload

LD_LIBRARY_PATH (and other variables):
"" (empty or unset variable) -> "/path/to/prepend/lib" -> ""
"/my/lib:/other/lib" -> "/path/to/prepend/lib:/my/lib:/other/lib" -> "/my/lib:/other/lib"
":/my/lib:/other/lib:" -> "/path/to/prepend/lib::/my/lib:/other/lib:" -> ":/my/lib:/other/lib:"
":" -> "/path/to/prepend/lib:" -> ":"

In the last case I am not sure if "/path/to/prepend/lib::" after module load would also be ok?


MANPATH and any environment path variable where the empty path has a special meaning (like in TEXINPUTS for LaTeX for example) are special cases where an unset variable or an empty value means the same as an empty path (and will be replaced by a system or default path by the application).
In this case an empty or unset variable should be considered as the variable contains the empty path already.

"" (empty or unset variable) -> "/path/to/prepend/man:" -> ""
"/my/man:/other/man" -> "/path/to/prepend/man:/my/man:/other/man" -> "/my/man:/other/man"
":/my/man:/other/man:" -> "/path/to/prepend/man::/my/man:/other/man:" -> ":/my/man:/other/man:"
":" -> "/path/to/prepend/man:" -> ":"

In the last case I am not sure if "/path/to/prepend/man::" after module load would also be ok?

I'm not sure if all environment variables can be handled like the MANPATH case?
If this would be acceptable and if it doesn't matter if the variable value contains two empty paths consecutively, then the following rule may be possible:

"prepend-path" may simply add the /path/to/prepend/man followed by a colon to the path when module load is called. To undo the operation when module unload is called simply remove the added path and one colon if there exists one after the removed path.

The similar behaviour should have "append-path" for the empty path at the end of the value of the variable.


Another possible solution may be to mark some environment variables whether to preserve empty paths and consider unset variables or empty values as empty paths or not. But this makes it necessary that environment-modules hast a big list of nearly any usually used environment variable, and the user can declare the type of his own variables.

You may also create additional commands or add options to existing commands to control if empty paths should preserved and unset variables or empty values should considered as empty paths.

I'm not sure which will be the best solution - what do you think?

Comment 2 Deji Akingunola 2010-04-02 03:10:56 UTC

environment-modules-3.2.7b-7.fc12 currently in updates-testing already has a fix.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update environment-modules'

*** This bug has been marked as a duplicate of bug 569826 ***

Comment 3 Orion Poplawski 2010-04-02 03:17:09 UTC

Deji - This is a different issue.  I've forwarded to the environment modules mailing list.  We'll see what that turns up.

Comment 4 Orion Poplawski 2010-04-20 22:31:12 UTC

No response on the modules list unfortunately.  Edgar - could you follow up on this upstream?  There's nothing in the Fedora package in this area that would be different than the default behavior.

Comment 5 Bug Zapper 2010-11-03 18:05:12 UTC

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 6 Bug Zapper 2010-12-03 16:28:14 UTC

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.