|
From: David C B. <dc...@hl...> - 2013-06-18 23:47:21
|
Nope. In your modules file you just put:
setenv SOME_VAR "Value"
When you 'module load', it gets created.
When you 'module unload' it is removed.
On Jun 18, 2013, at 12:10 PM, "Mark E. Hamilton" <mh...@sa...> wrote:
> Thanks. One of the things that has bugged me is that setting environment
> variables is not a reversible operation. (The use/unuse behavior
> misbehaves the same way, IMO.)
>
> I reread the man pages about setenv/unsetenv, and it I must be missing
> something obvious. It seems that I would have to so something like this:
>
> if { [module-info mode load] } {
> if { [info exists env(SOME_VAR)]} {
> setenv OLD_SOME_VAR $env(SOME_VAR)
> } else {
> setenv OLD_SOME_VAR ""
> }
> setenv SOME_VAR "some new value"
> } elseif { [module-info mode remove] }
> unsetenv SOME_VAR $env(OLD_SOME_VAR)
> setenv OLD_SOME_VAR ""
> }
>
> in order to not lose the initial value of SOME_VAR on unload. This seems
> overly complex, and the use of unsetenv just to get a setenv on unload
> is very non-obvious. What about something like this?
>
> setenv variable value [backup_variable]
>
> where backup_variable is set with the current value of variable, and
> then when setenv becomes unsetenv its value is used in that statement.
>
>
> FWIW, I normally use this online man page,
>
> http://modules.sourceforge.net/man/modulefile.html
>
> since it's the first one that comes up in a Google search, but it's
> clearly somewhat dated. Is there a more up-to-date online man page?
>
>
> On 06/14/13 11:34, R.K. Owen wrote:
>> Looking at the code, and this appears to be the "correct" behavior.
>>
>> I think this is a feature that could be added similar to the "unsetenv"
>> command, and have added a feature request to track this and given my
>> track record it should appear in the next release in about November.
>>
>> So the way you would use this new feature you may need to save the old
>> path in an env.var. In the following example I omit all that:
>>
>> module unuse /oldpath /somepath
>>
>> where it does the normal behavior of unusing /oldpath on load and then
>> using the optional /somepath when unloading.
>> My thinking is that you don't always want to reuse the old path when
>> unloading a module and this gives you the option to do so.
>> The other way is to add an option, say, --restore that would reuse the
>> old path on unload.
>> Maybe, I'll implement both.
>>
>> R.K. Owen
>>
>>
>> On Fri, Jun 14, 2013 at 8:09 AM, Mark E. Hamilton <mh...@sa...
>> <mailto:mh...@sa...>> wrote:
>>
>> Hi,
>>
>> We have a number of product-specific modulefiles paths added to
>> MODULEPATH by the .modulespath file. I've created a modulefile (modeled
>> on the use.own modulefile) that does a 'module unuse' of one of those
>> default paths, and a 'module use' of a different set of modulefiles.
>>
>> % module show use.sierra.test
>> -------------------------------------------------------------------
>> /ascldap/users/mhamilt/test_modules//use.sierra.test:
>>
>> module-whatis Some message.
>> module use /projects/sierra/modules.refactor/linux_rh6
>> module unuse /projects/sierra/linux_rh6/modules
>> -------------------------------------------------------------------
>>
>> What is happening is that when I load that module it does the use/unuse
>> tango correctly, but when I unload it the 'new' path is unused, but the
>> 'old' path is not used, so I end up with none of the modules in
>> MODULEPATH.
>>
>> % echo $MODULEPATH | tr : '\n' | grep sierra
>> /projects/sierra/linux_rh6/modules
>> % module load use.sierra.test
>> % echo $MODULEPATH | tr : '\n' | grep sierra
>> /projects/sierra/modules.refactor/linux_rh6
>> % module unload use.sierra.test
>> % echo $MODULEPATH | tr : '\n' | grep sierra
>> %
>>
>> Initially the use.sierra.test modulefile was in the /projects path I was
>> unusing; I moved it to a separate path to ensure that was not the cause
>> of this problem, and the behavior didn't change.
>>
>> Is this intended behavior? This is using version 3.2.10, but I get the
>> same behavior with 3.2.6.
>>
>> --
>> ----------------
>> Mark E. Hamilton
>> GAITS, Inc.
>> Sandia National Laboratories, NM.
>> 505-844-7666 <tel:505-844-7666>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Modules-interest mailing list
>> Mod...@li...
>> <mailto:Mod...@li...>
>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>>
>>
>>
>> _______________________________________________
>> Modules-interest mailing list
>> Mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>
>
> --
> ----------------
> Mark E. Hamilton
> GAITS, Inc.
> Sandia National Laboratories, NM.
> 505-844-7666
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
|
