modules-interest — Discussion forum for modules usage.

Re: [Modules] "module load" behavior in module 3.2.10/4.5.2

[Paul M. <pau...@gm...>]

A "guess" is module switch also implies a definition of conflict/require
When you don't specifically name the module being removed, it isn't defined as a conflict.

I suspect if you use:
	module switch intel/2020 intel/2020
You will get a similar error.

On 4/20/2023 7:18 AM, Jens-Olaf Beismann wrote:
> Merci beaucoup, Xavier,
> 
> that works! Just to clarify: the documentation says
> 
> "switch [options] [modulefile1] modulefile2
>     Switch loaded modulefile1 with modulefile2. If modulefile1 is not specified,
>     then it is assumed to be the currently loaded module with the same root
>     name as modulefile2."
> 
> My understanding is that
> 
> module switch intel/2020
> 
> should be equivalent to
> 
> module switch intel intel/2020
> 
> but with the latter I get
> 
> Loading intel/2020
>    ERROR: Conflicting 'jotest/1.0' is loading
> 
> Loading jotest/1.0
>    WARNING: Load of switched-on intel/2020 failed
>    ERROR: Load of requirement 'intel/2020' failed
> 
> Does that mean that "modulefile1" in the switch command also has to be a fully qualified modulefile name?
> 
> Viele Grüße,
> 
> Jens-Olaf
> ---
> Dr. Jens-Olaf Beismann          Benchmarking Expert
> High Performance Computing      NEC Deutschland GmbH     https://www.nec.com/en/global/solutions/hpc/
> Tel: +49 431 2372063 (office)  +49 152 22851521 (mobile)
> ---
> NEC Deutschland GmbH, Fritz-Vomfelde-Straße 14, D-40547 Düsseldorf
> Geschäftsführer: Yuichi Kojima
> Handelsregister Düsseldorf, HRB 57941, VAT ID DE129424743
> 
>> -----Original Message-----
>> From: Xav...@CE... <Xav...@CE...>
>> Sent: 20 April 2023 11:46
>> To: mod...@li...
>> Subject: Re: [Modules] "module load" behavior in module 3.2.10/4.5.2
>>
>> Hello Jens-Olaf,
>>
>> Starting version 4.2, load and unload commands inside modulefile
>> imply definition of requirement or conflict.
>>
>> "module unload intel" means unload intel + conflict intel
>> "module load intel/2020" means load intel/2020 + prereq intel/2020
>>
>> Option --not-req allows to skip requirement/conflict definition. It
>> is available starting version 4.7.0.
>>
>> With version 4.5.2, changing these two commands into:
>>
>> module switch intel/2020
>>
>> Should do what you expect.
>>
>> Regards,
>> Xavier
>>
>>
>> On Thu, 2023-04-20 at 07:33 +0000, Jens-Olaf Beismann wrote:
>>> Good morning,
>>>
>>> one of our customers observed a different behavior of commands in a
>>> module file when using it with either modules version 3.2.10 or
>>> version 4.5.2.
>>>
>>> The module file (called jotest/1.0 for testing purposes) contains
>>> these lines
>>>
>>> module unload intel
>>> module load intel/2020
>>>
>>> Among the available modules we only have
>>>
>>> intel/2020(default)
>>>
>>> i.e. there is no other module file in the "intel" directory.
>>>
>>> Now "module load jotest" works fine with version 3.2.10, i.e.
>>> afterwards intel/2020 and jotest/1.0 are loaded (independent of
>>> intel/2020 being loaded before or not).
>>>
>>> With version 4.5.2, however, we get this error
>>>
>>> % module load jotest
>>> Loading intel/2020
>>>    ERROR: Conflicting 'jotest/1.0' is loading
>>>
>>> Loading jotest/1.0
>>>    ERROR: Load of requirement 'intel/2020' failed
>>>
>>> We are still struggling to understand the actual reason for the
>>> error issued for "module load intel/2020" and therefore didn't yet
>>> find a way to achieve the desired result with 4.5.2. Any hints
>>> would be highly appreciated, in particular we'd like to understand
>>> if there's something conceptionally wrong with the unload/load
>>> sequence in "jotest/1.0".
>>>
>>> Thank you and best regards,
>>>
>>> Jens-Olaf
>>> ---
>>> Dr. Jens-Olaf Beismann          Benchmarking Expert
>>> High Performance Computing      NEC Deutschland GmbH
>>>
>> https://urldefense.com/v3/__https://www.nec.com/en/global/solutions/hpc/__;!
>> !BQNorrFsuw!jqIK5XPEUH9M-
>> Qpos2HurfTaXpctaqrq85lXUniaoHC4_HezU8EBPw9YFbySi1dkptwGQ1wXsjc-
>> nwk8LQLWGhsecJ4EKHg26uA$[nec[.]com]
>>> Tel: +49 431 2372063 (office)  +49 152 22851521 (mobile)
>>> ---
>>> NEC Deutschland GmbH, Fritz-Vomfelde-Straße 14, D-40547 Düsseldorf
>>> Geschäftsführer: Yuichi Kojima
>>> Handelsregister Düsseldorf, HRB 57941, VAT ID DE129424743
>>>
>>>
>>> _______________________________________________
>>> Modules-interest mailing list
>>> Mod...@li...
>>>
>> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/mod
>> ules-interest__;!!BQNorrFsuw!jqIK5XPEUH9M-
>> Qpos2HurfTaXpctaqrq85lXUniaoHC4_HezU8EBPw9YFbySi1dkptwGQ1wXsjc-
>> nwk8LQLWGhsecJ4EHnwZjLI$[lists[.]sourceforge[.]net]
>>
>> _______________________________________________
>> Modules-interest mailing list
>> Mod...@li...
>> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/mod
>> ules-interest__;!!BQNorrFsuw!jqIK5XPEUH9M-
>> Qpos2HurfTaXpctaqrq85lXUniaoHC4_HezU8EBPw9YFbySi1dkptwGQ1wXsjc-
>> nwk8LQLWGhsecJ4EHnwZjLI$[lists[.]sourceforge[.]net]
> 
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

-- 
--------------------------------------------------------
The views and opinions expressed above are strictly
those of the author(s).  The content of this message has
not been reviewed nor approved by any entity whatsoever.
--------------------------------------------------------
Paul FM         Info: http://paulfm.com/~paulfm/
--------------------------------------------------------

Re: [Modules] "module load" behavior in module 3.2.10/4.5.2

[Jens-Olaf B. <Jen...@EM...>]

Merci beaucoup, Xavier,

that works! Just to clarify: the documentation says

"switch [options] [modulefile1] modulefile2
   Switch loaded modulefile1 with modulefile2. If modulefile1 is not specified,
   then it is assumed to be the currently loaded module with the same root
   name as modulefile2."

My understanding is that

module switch intel/2020

should be equivalent to

module switch intel intel/2020

but with the latter I get

Loading intel/2020
  ERROR: Conflicting 'jotest/1.0' is loading

Loading jotest/1.0
  WARNING: Load of switched-on intel/2020 failed
  ERROR: Load of requirement 'intel/2020' failed

Does that mean that "modulefile1" in the switch command also has to be a fully qualified modulefile name?

Viele Grüße,

Jens-Olaf
---
Dr. Jens-Olaf Beismann          Benchmarking Expert
High Performance Computing      NEC Deutschland GmbH     https://www.nec.com/en/global/solutions/hpc/
Tel: +49 431 2372063 (office)  +49 152 22851521 (mobile)
---
NEC Deutschland GmbH, Fritz-Vomfelde-Straße 14, D-40547 Düsseldorf
Geschäftsführer: Yuichi Kojima
Handelsregister Düsseldorf, HRB 57941, VAT ID DE129424743

> -----Original Message-----
> From: Xav...@CE... <Xav...@CE...>
> Sent: 20 April 2023 11:46
> To: mod...@li...
> Subject: Re: [Modules] "module load" behavior in module 3.2.10/4.5.2
> 
> Hello Jens-Olaf,
> 
> Starting version 4.2, load and unload commands inside modulefile
> imply definition of requirement or conflict.
> 
> "module unload intel" means unload intel + conflict intel
> "module load intel/2020" means load intel/2020 + prereq intel/2020
> 
> Option --not-req allows to skip requirement/conflict definition. It
> is available starting version 4.7.0.
> 
> With version 4.5.2, changing these two commands into:
> 
> module switch intel/2020
> 
> Should do what you expect.
> 
> Regards,
> Xavier
> 
> 
> On Thu, 2023-04-20 at 07:33 +0000, Jens-Olaf Beismann wrote:
> > Good morning,
> >
> > one of our customers observed a different behavior of commands in a
> > module file when using it with either modules version 3.2.10 or
> > version 4.5.2.
> >
> > The module file (called jotest/1.0 for testing purposes) contains
> > these lines
> >
> > module unload intel
> > module load intel/2020
> >
> > Among the available modules we only have
> >
> > intel/2020(default)
> >
> > i.e. there is no other module file in the "intel" directory.
> >
> > Now "module load jotest" works fine with version 3.2.10, i.e.
> > afterwards intel/2020 and jotest/1.0 are loaded (independent of
> > intel/2020 being loaded before or not).
> >
> > With version 4.5.2, however, we get this error
> >
> > % module load jotest
> > Loading intel/2020
> >   ERROR: Conflicting 'jotest/1.0' is loading
> >
> > Loading jotest/1.0
> >   ERROR: Load of requirement 'intel/2020' failed
> >
> > We are still struggling to understand the actual reason for the
> > error issued for "module load intel/2020" and therefore didn't yet
> > find a way to achieve the desired result with 4.5.2. Any hints
> > would be highly appreciated, in particular we'd like to understand
> > if there's something conceptionally wrong with the unload/load
> > sequence in "jotest/1.0".
> >
> > Thank you and best regards,
> >
> > Jens-Olaf
> > ---
> > Dr. Jens-Olaf Beismann          Benchmarking Expert
> > High Performance Computing      NEC Deutschland GmbH
> >
> https://urldefense.com/v3/__https://www.nec.com/en/global/solutions/hpc/__;!
> !BQNorrFsuw!jqIK5XPEUH9M-
> Qpos2HurfTaXpctaqrq85lXUniaoHC4_HezU8EBPw9YFbySi1dkptwGQ1wXsjc-
> nwk8LQLWGhsecJ4EKHg26uA$[nec[.]com]
> > Tel: +49 431 2372063 (office)  +49 152 22851521 (mobile)
> > ---
> > NEC Deutschland GmbH, Fritz-Vomfelde-Straße 14, D-40547 Düsseldorf
> > Geschäftsführer: Yuichi Kojima
> > Handelsregister Düsseldorf, HRB 57941, VAT ID DE129424743
> >
> >
> > _______________________________________________
> > Modules-interest mailing list
> > Mod...@li...
> >
> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/mod
> ules-interest__;!!BQNorrFsuw!jqIK5XPEUH9M-
> Qpos2HurfTaXpctaqrq85lXUniaoHC4_HezU8EBPw9YFbySi1dkptwGQ1wXsjc-
> nwk8LQLWGhsecJ4EHnwZjLI$[lists[.]sourceforge[.]net]
> 
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/mod
> ules-interest__;!!BQNorrFsuw!jqIK5XPEUH9M-
> Qpos2HurfTaXpctaqrq85lXUniaoHC4_HezU8EBPw9YFbySi1dkptwGQ1wXsjc-
> nwk8LQLWGhsecJ4EHnwZjLI$[lists[.]sourceforge[.]net]

Re: [Modules] "module load" behavior in module 3.2.10/4.5.2

[<Xav...@CE...>]

Hello Jens-Olaf,

Starting version 4.2, load and unload commands inside modulefile
imply definition of requirement or conflict.

"module unload intel" means unload intel + conflict intel
"module load intel/2020" means load intel/2020 + prereq intel/2020

Option --not-req allows to skip requirement/conflict definition. It
is available starting version 4.7.0.

With version 4.5.2, changing these two commands into:

module switch intel/2020

Should do what you expect.

Regards,
Xavier


On Thu, 2023-04-20 at 07:33 +0000, Jens-Olaf Beismann wrote:
> Good morning,
> 
> one of our customers observed a different behavior of commands in a
> module file when using it with either modules version 3.2.10 or
> version 4.5.2.
> 
> The module file (called jotest/1.0 for testing purposes) contains
> these lines
> 
> module unload intel
> module load intel/2020
> 
> Among the available modules we only have
> 
> intel/2020(default)
> 
> i.e. there is no other module file in the "intel" directory.
> 
> Now "module load jotest" works fine with version 3.2.10, i.e.
> afterwards intel/2020 and jotest/1.0 are loaded (independent of
> intel/2020 being loaded before or not).
> 
> With version 4.5.2, however, we get this error
> 
> % module load jotest
> Loading intel/2020
>   ERROR: Conflicting 'jotest/1.0' is loading
> 
> Loading jotest/1.0
>   ERROR: Load of requirement 'intel/2020' failed
> 
> We are still struggling to understand the actual reason for the
> error issued for "module load intel/2020" and therefore didn't yet
> find a way to achieve the desired result with 4.5.2. Any hints
> would be highly appreciated, in particular we'd like to understand
> if there's something conceptionally wrong with the unload/load
> sequence in "jotest/1.0".
> 
> Thank you and best regards,
> 
> Jens-Olaf
> ---
> Dr. Jens-Olaf Beismann          Benchmarking Expert
> High Performance Computing      NEC Deutschland GmbH     
> https://www.nec.com/en/global/solutions/hpc/
> Tel: +49 431 2372063 (office)  +49 152 22851521 (mobile)
> ---
> NEC Deutschland GmbH, Fritz-Vomfelde-Straße 14, D-40547 Düsseldorf
> Geschäftsführer: Yuichi Kojima
> Handelsregister Düsseldorf, HRB 57941, VAT ID DE129424743
> 
> 
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

[Modules] "module load" behavior in module 3.2.10/4.5.2

[Jens-Olaf B. <Jen...@EM...>]

Good morning,

one of our customers observed a different behavior of commands in a module file when using it with either modules version 3.2.10 or version 4.5.2.

The module file (called jotest/1.0 for testing purposes) contains these lines

module unload intel
module load intel/2020

Among the available modules we only have

intel/2020(default)

i.e. there is no other module file in the "intel" directory.

Now "module load jotest" works fine with version 3.2.10, i.e. afterwards intel/2020 and jotest/1.0 are loaded (independent of intel/2020 being loaded before or not).

With version 4.5.2, however, we get this error

% module load jotest
Loading intel/2020
  ERROR: Conflicting 'jotest/1.0' is loading

Loading jotest/1.0
  ERROR: Load of requirement 'intel/2020' failed

We are still struggling to understand the actual reason for the error issued for "module load intel/2020" and therefore didn't yet find a way to achieve the desired result with 4.5.2. Any hints would be highly appreciated, in particular we'd like to understand if there's something conceptionally wrong with the unload/load sequence in "jotest/1.0".

Thank you and best regards,

Jens-Olaf
---
Dr. Jens-Olaf Beismann          Benchmarking Expert
High Performance Computing      NEC Deutschland GmbH     https://www.nec.com/en/global/solutions/hpc/
Tel: +49 431 2372063 (office)  +49 152 22851521 (mobile)
---
NEC Deutschland GmbH, Fritz-Vomfelde-Straße 14, D-40547 Düsseldorf
Geschäftsführer: Yuichi Kojima
Handelsregister Düsseldorf, HRB 57941, VAT ID DE129424743

Re: [Modules] Problem after updating from 5.1.1 to 5.2.0

[Xavier D. <xav...@gm...>]

Hello Ralf,

In /usr/local.nfs/Modules/latest/init/bash, there should be a line like:

eval "$(${_mlre:-}/usr/bin/tclsh
'/usr/local.nfs/Modules/5.2.0/libexec/modulecmd.tcl' bash autoinit)"

Could you change it into something like:

eval "$(${_mlre:-}/usr/bin/tclsh
'/usr/local.nfs/Modules/5.2.0/libexec/modulecmd.tcl' bash -D autoinit
2>modules_autoinit_debug.log)"

And send me the modules_autoinit_debug.log file that will be produced
after trying to connect with NoMachine.

Regards,
Xavier

Le ven. 24 mars 2023 à 11:58, Aumüller, Ralf
<Ral...@ip...> a écrit :
>
> Hello,
>
> after updating from 5.1.1 to 5.2.0 we have the following problem:
>
> - When logging in via SSH, everything works as expected
>
> - When I try to connect per NoMachine client I get an error from Nomachine.
> Locking in the logs and doing some debugging it appears that the following
> init-command ". /usr/local.nfs/Modules/latest/init/bash" removes the default
> paths from PATH. Before the command is executed the PATH is
> "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin". After the
> command PATH is just "/usr/local.nfs/Modules/5.2.0/bin". And then the rest of
> our setup fails and NoMachine fails to.
>
> Any idea whats wrong?
>
> Thank You and best regards,
> Ralf
>
>
> Info:
> - OS is Ubuntu 20.04
> - Self-compiled modules
> - Our self-compiled modules are installed below /usr/local.nfs/Modules as e.g.
> 5.2.0 or 5.1.1. The symlink latest points to the module-version to execute.
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

[Modules] Problem after updating from 5.1.1 to 5.2.0

[Aumüller, R. <Ral...@ip...>]

Hello,

after updating from 5.1.1 to 5.2.0 we have the following problem:

- When logging in via SSH, everything works as expected

- When I try to connect per NoMachine client I get an error from Nomachine.
Locking in the logs and doing some debugging it appears that the following 
init-command ". /usr/local.nfs/Modules/latest/init/bash" removes the default 
paths from PATH. Before the command is executed the PATH is 
"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin". After the 
command PATH is just "/usr/local.nfs/Modules/5.2.0/bin". And then the rest of 
our setup fails and NoMachine fails to.

Any idea whats wrong?

Thank You and best regards,
Ralf


Info:
- OS is Ubuntu 20.04
- Self-compiled modules
- Our self-compiled modules are installed below /usr/local.nfs/Modules as e.g. 
5.2.0 or 5.1.1. The symlink latest points to the module-version to execute.

Re: [Modules] Adding year to module logging

[Xavier D. <xav...@gm...>]

Hi David,

This module logging setup relies on the log service configured on the
machine. This service automatically records the full date time.

In the example provided in the cookbook the default output returned by the
journactl command does not mention the year, but you can ask this command
to report you this information.

For instance, by adding the --output=short-full option, you get more details

$ journalctl --output=short-full -q -t module
Thu 2022-04-28 08:29:10 CEST myhost module[2175071]: { "user": "myuser",
"cmd": "module", "args": "use --append /usr/local/Modules/modulefiles" }
Thu 2022-04-28 08:29:10 CEST myhost module[2175072]: { "user": "myuser",
"cmd": "module", "args": "autoinit" }

Regards,
Xavier

Le ven. 3 févr. 2023 à 17:39, David Carlson via Modules-interest <
mod...@li...> a écrit :

> Hi All,
>
> The cluster that I work at recently implemented the module logging setup
> described in the cookbook
> <https://modules.readthedocs.io/en/latest/cookbook/log-module-commands.html?highlight=logging#log-module-command-1>.
> Thank you for this, it was very helpful!
>
> One question - I noticed that the Month, day, and time are reported in the
> output.  However the year is not.
>
> Could anyone provide advice on how we would update our sitconfig.tcl file
> to include the year along with the date and time?
>
> Thank you!
> Dave
>
> --
>
>
> ......................................................
>
> *Dave Carlson | **Computational Scientist*
>
>
> *Institute for Advanced Computational ScienceGenomics Core Facility*
>
> dav...@st...
>
> [image: Stony Brook University logo]
> <http://www.stonybrook.edu/>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>

[Modules] Adding year to module logging

[David C. <dav...@st...>]

Hi All,

The cluster that I work at recently implemented the module logging setup
described in the cookbook
<https://modules.readthedocs.io/en/latest/cookbook/log-module-commands.html?highlight=logging#log-module-command-1>.
Thank you for this, it was very helpful!

One question - I noticed that the Month, day, and time are reported in the
output.  However the year is not.

Could anyone provide advice on how we would update our sitconfig.tcl file
to include the year along with the date and time?

Thank you!
Dave

-- 


......................................................

*Dave Carlson | **Computational Scientist*


*Institute for Advanced Computational ScienceGenomics Core Facility*

dav...@st...

[image: Stony Brook University logo]
<http://www.stonybrook.edu/>

Re: [Modules] Some "setenv" are not performed

[Paul M. <pau...@gm...>]

I think we need to verify a few things (to make sure we aren't making any incorrect assumptions).

And, I am not trying to insult your inteligence, but these questions have to be re-asked (even if it seems they were answered) just to make sure.

Are you really testing with bash (or is it a bash-like shell - like ksh)?
It is possible (if someone else set up the machine, or by some configuration error) that the bash command actually starts a compatible shell.
What do you get when you run:
bash --version

Can you tell us the OS distribution version of modules (what is the exact name of the package used to install it)?

Also, can you determine what version of tcl the module command is compiled with (run ldd against the binary) - it might not be the same as the version used by tclsh.


What happens if you source the files directly from your shell (do you get any errors, if you do that is probably the issue).  One error that would cause a problem is if one of the files being sourced was not readable by you (causing an error that would terminate the eval).

Does the shell you are testing with, support the source command (bash should, but others might not).
It could be the puts command is getting a command not found, and failing the entire "eval"

Also, the sourced files are likely BASH specific, they may be causing an error when they are sourced by the shell you are testing with (or they may have errors in the files), thereby causing the whole eval to fail.

It could also be that you need to add a \n to the puts command (at the start of the string, the module puts may be before it and could be missing the last newline).  Or it may need one at the end (perhaps due to the tcl compile options of the module binary).


It would actually be helpful to use "module display" (with the test shell) so you can see what the module is sending to the shell through eval.

And, once you get it working, you should consider updating to the latest release of modules (for one, it is no longer a binary - but rather a tclsh script).   The 3.2.10* versions that come with many Linux Distributions (including openSUSE which I mainly use) - is really old and basically unsupported.



On 1/31/2023 1:10 PM, Hernan Cervantes wrote:
> When I comment out the lines with "puts stdout", the variable GMXBIN is set
> correctly. I do not know why. The files being sourced do not use or modify
> that variable.
> 
> Now a message, "puts stderr", is shown to the user source manually.
> 
> 
> 
> 
> On Fri, Jan 27, 2023 at 6:41 PM Jesse Lucas via Modules-interest <
> mod...@li...> wrote:
> 
>> I can't reproduce the problem using your provided modulefile.
>>
>> Perhaps try...
>>
>> modulecmd sh load modelagem/example
>>
>> ...to see what commands are actually being sourced by the shell and in
>> what order.
>>
>> Nothing in your bash setup's $PROMPT_COMMAND that would be unsetting
>> $GMXBIN?
>>
>> What version of Environment Modules are you using?
>>
>> -J
>>
>>
>> On Fri, Jan 27, 2023 at 3:29 PM Hernan Cervantes <her...@gm...>
>> wrote:
>>
>>> Hi there,
>>>
>>> I'm a new user, I have written some modulefile, but one environment variable is not being set in any way!
>>>
>>> the environment-module version is 3.2.10
>>>
>>> TCL_VERSION="8.5"
>>> TCL_PATCH_LEVEL="8.5.13"
>>>
>>> installed in a CentOS 7.9 computer.
>>>
>>> the modulefile content is:
>>> ==============
>>> #%Module 1.0
>>>
>>> set modulefilename "GROMACS"
>>> set modulefilever "5.1.5"
>>>
>>> # On load print component name and version being loaded
>>> if { [ module-info mode load ] } {
>>>     puts stderr "Loading modeling program $modulefilename version $modulefilever"
>>> }
>>>
>>> # On `module unload` print component module and version being removed
>>> if { [ module-info mode ] == "unload" || [module-info mode ] == "remove" } {
>>>      puts stderr "Removing $modulefilename version $modulefilever"
>>> }
>>>
>>> module-whatis "module whatis"
>>>
>>> ##########################################################
>>> # This is the real configuration part. We save the Gromacs
>>> # things in separate vars, so we can remove them later.
>>> # If you move gromacs, change the first line.
>>> ##########################################################
>>> set GMXPREFIX /opt/softwares/gromacs-5.1.5
>>> setenv GMXPREFIX $GMXPREFIX
>>>
>>> set GMXBIN $GMXPREFIX/bin
>>> setenv GMXBIN $GMXBIN
>>> setenv GMXBIN $GMXBIN
>>>
>>> set GMXLDLIB $GMXPREFIX/lib64
>>> setenv GMXLDLIB $GMXLDLIB
>>>
>>> set GMXMAN $GMXPREFIX/share/man
>>> setenv GMXMAN $GMXMAN
>>>
>>> set GMXDATA $GMXPREFIX/share/gromacs
>>> setenv GMXDATA $GMXDATA
>>>
>>> set GROMACS_DIR $GMXPREFIX
>>> setenv GROMACS_DIR $GROMACS_DIR
>>>
>>> prepend-path LD_LIBRARY_PATH $GMXLDLIB
>>> prepend-path PKG_CONFIG_PATH $GMXLDLIB/pkgconfig
>>> prepend-path PATH $GMXBIN
>>> prepend-path MANPATH $GMXMAN
>>>
>>> puts stderr "GMXBIN = $GMXBIN"
>>> if { [ file exist $GMXBIN/gmx-completion.bash ] } {
>>>      puts stdout "source $GMXBIN/gmx-completion.bash"
>>> }
>>>
>>> set namepat $GMXBIN/gmx-completion-*.bash
>>> foreach cfile [ glob $namepat ] {
>>>      puts stdout "source $cfile"
>>> }
>>>
>>> setenv GMXBIN $GMXBIN
>>> setenv GMXBIN $GMXBIN
>>> setenv GMXBIN $GMXBIN
>>> setenv GMXBIN $GMXBIN
>>> setenv GMXBIN $GMXBIN
>>> setenv GMXBIN $GMXBIN
>>> setenv GMXBIN $GMXBIN
>>> ===============
>>>
>>> the session transcription, in a bash shell, is:
>>> ======================
>>> [teste02@gfmm01 ~]$ echo $GMXBIN
>>>
>>> [teste02@gfmm01 ~]$  module load modelagem/example
>>> Loading modeling program GROMACS version 5.1.5
>>> GMXBIN = /opt/softwares/gromacs-5.1.5/bin
>>> [teste02@gfmm01 ~]$ echo $GMXBIN
>>>
>>> =====================
>>>
>>> What am I doing wrong?
>>>
>>> Thanks in advance.
>>>
>>> Hernán Cervantes
>>>
>>> _______________________________________________
>>> Modules-interest mailing list
>>> Mod...@li...
>>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>>>
>> _______________________________________________
>> Modules-interest mailing list
>> Mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>>
> 
> 
> 
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

-- 
--------------------------------------------------------
The views and opinions expressed above are strictly
those of the author(s).  The content of this message has
not been reviewed nor approved by any entity whatsoever.
--------------------------------------------------------
Paul FM         Info: http://paulfm.com/~paulfm/
--------------------------------------------------------

Re: [Modules] Some "setenv" are not performed

[Hernan C. <her...@gm...>]

When I comment out the lines with "puts stdout", the variable GMXBIN is set
correctly. I do not know why. The files being sourced do not use or modify
that variable.

Now a message, "puts stderr", is shown to the user source manually.




On Fri, Jan 27, 2023 at 6:41 PM Jesse Lucas via Modules-interest <
mod...@li...> wrote:

> I can't reproduce the problem using your provided modulefile.
>
> Perhaps try...
>
> modulecmd sh load modelagem/example
>
> ...to see what commands are actually being sourced by the shell and in
> what order.
>
> Nothing in your bash setup's $PROMPT_COMMAND that would be unsetting
> $GMXBIN?
>
> What version of Environment Modules are you using?
>
> -J
>
>
> On Fri, Jan 27, 2023 at 3:29 PM Hernan Cervantes <her...@gm...>
> wrote:
>
>> Hi there,
>>
>> I'm a new user, I have written some modulefile, but one environment variable is not being set in any way!
>>
>> the environment-module version is 3.2.10
>>
>> TCL_VERSION="8.5"
>> TCL_PATCH_LEVEL="8.5.13"
>>
>> installed in a CentOS 7.9 computer.
>>
>> the modulefile content is:
>> ==============
>> #%Module 1.0
>>
>> set modulefilename "GROMACS"
>> set modulefilever "5.1.5"
>>
>> # On load print component name and version being loaded
>> if { [ module-info mode load ] } {
>>    puts stderr "Loading modeling program $modulefilename version $modulefilever"
>> }
>>
>> # On `module unload` print component module and version being removed
>> if { [ module-info mode ] == "unload" || [module-info mode ] == "remove" } {
>>     puts stderr "Removing $modulefilename version $modulefilever"
>> }
>>
>> module-whatis "module whatis"
>>
>> ##########################################################
>> # This is the real configuration part. We save the Gromacs
>> # things in separate vars, so we can remove them later.
>> # If you move gromacs, change the first line.
>> ##########################################################
>> set GMXPREFIX /opt/softwares/gromacs-5.1.5
>> setenv GMXPREFIX $GMXPREFIX
>>
>> set GMXBIN $GMXPREFIX/bin
>> setenv GMXBIN $GMXBIN
>> setenv GMXBIN $GMXBIN
>>
>> set GMXLDLIB $GMXPREFIX/lib64
>> setenv GMXLDLIB $GMXLDLIB
>>
>> set GMXMAN $GMXPREFIX/share/man
>> setenv GMXMAN $GMXMAN
>>
>> set GMXDATA $GMXPREFIX/share/gromacs
>> setenv GMXDATA $GMXDATA
>>
>> set GROMACS_DIR $GMXPREFIX
>> setenv GROMACS_DIR $GROMACS_DIR
>>
>> prepend-path LD_LIBRARY_PATH $GMXLDLIB
>> prepend-path PKG_CONFIG_PATH $GMXLDLIB/pkgconfig
>> prepend-path PATH $GMXBIN
>> prepend-path MANPATH $GMXMAN
>>
>> puts stderr "GMXBIN = $GMXBIN"
>> if { [ file exist $GMXBIN/gmx-completion.bash ] } {
>>     puts stdout "source $GMXBIN/gmx-completion.bash"
>> }
>>
>> set namepat $GMXBIN/gmx-completion-*.bash
>> foreach cfile [ glob $namepat ] {
>>     puts stdout "source $cfile"
>> }
>>
>> setenv GMXBIN $GMXBIN
>> setenv GMXBIN $GMXBIN
>> setenv GMXBIN $GMXBIN
>> setenv GMXBIN $GMXBIN
>> setenv GMXBIN $GMXBIN
>> setenv GMXBIN $GMXBIN
>> setenv GMXBIN $GMXBIN
>> ===============
>>
>> the session transcription, in a bash shell, is:
>> ======================
>> [teste02@gfmm01 ~]$ echo $GMXBIN
>>
>> [teste02@gfmm01 ~]$  module load modelagem/example
>> Loading modeling program GROMACS version 5.1.5
>> GMXBIN = /opt/softwares/gromacs-5.1.5/bin
>> [teste02@gfmm01 ~]$ echo $GMXBIN
>>
>> =====================
>>
>> What am I doing wrong?
>>
>> Thanks in advance.
>>
>> Hernán Cervantes
>>
>> _______________________________________________
>> Modules-interest mailing list
>> Mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>

Re: [Modules] Some "setenv" are not performed

[Jesse L. <je...@bl...>]

I can't reproduce the problem using your provided modulefile.

Perhaps try...

modulecmd sh load modelagem/example

...to see what commands are actually being sourced by the shell and in what
order.

Nothing in your bash setup's $PROMPT_COMMAND that would be unsetting
$GMXBIN?

What version of Environment Modules are you using?

-J


On Fri, Jan 27, 2023 at 3:29 PM Hernan Cervantes <her...@gm...> wrote:

> Hi there,
>
> I'm a new user, I have written some modulefile, but one environment variable is not being set in any way!
>
> the environment-module version is 3.2.10
>
> TCL_VERSION="8.5"
> TCL_PATCH_LEVEL="8.5.13"
>
> installed in a CentOS 7.9 computer.
>
> the modulefile content is:
> ==============
> #%Module 1.0
>
> set modulefilename "GROMACS"
> set modulefilever "5.1.5"
>
> # On load print component name and version being loaded
> if { [ module-info mode load ] } {
>    puts stderr "Loading modeling program $modulefilename version $modulefilever"
> }
>
> # On `module unload` print component module and version being removed
> if { [ module-info mode ] == "unload" || [module-info mode ] == "remove" } {
>     puts stderr "Removing $modulefilename version $modulefilever"
> }
>
> module-whatis "module whatis"
>
> ##########################################################
> # This is the real configuration part. We save the Gromacs
> # things in separate vars, so we can remove them later.
> # If you move gromacs, change the first line.
> ##########################################################
> set GMXPREFIX /opt/softwares/gromacs-5.1.5
> setenv GMXPREFIX $GMXPREFIX
>
> set GMXBIN $GMXPREFIX/bin
> setenv GMXBIN $GMXBIN
> setenv GMXBIN $GMXBIN
>
> set GMXLDLIB $GMXPREFIX/lib64
> setenv GMXLDLIB $GMXLDLIB
>
> set GMXMAN $GMXPREFIX/share/man
> setenv GMXMAN $GMXMAN
>
> set GMXDATA $GMXPREFIX/share/gromacs
> setenv GMXDATA $GMXDATA
>
> set GROMACS_DIR $GMXPREFIX
> setenv GROMACS_DIR $GROMACS_DIR
>
> prepend-path LD_LIBRARY_PATH $GMXLDLIB
> prepend-path PKG_CONFIG_PATH $GMXLDLIB/pkgconfig
> prepend-path PATH $GMXBIN
> prepend-path MANPATH $GMXMAN
>
> puts stderr "GMXBIN = $GMXBIN"
> if { [ file exist $GMXBIN/gmx-completion.bash ] } {
>     puts stdout "source $GMXBIN/gmx-completion.bash"
> }
>
> set namepat $GMXBIN/gmx-completion-*.bash
> foreach cfile [ glob $namepat ] {
>     puts stdout "source $cfile"
> }
>
> setenv GMXBIN $GMXBIN
> setenv GMXBIN $GMXBIN
> setenv GMXBIN $GMXBIN
> setenv GMXBIN $GMXBIN
> setenv GMXBIN $GMXBIN
> setenv GMXBIN $GMXBIN
> setenv GMXBIN $GMXBIN
> ===============
>
> the session transcription, in a bash shell, is:
> ======================
> [teste02@gfmm01 ~]$ echo $GMXBIN
>
> [teste02@gfmm01 ~]$  module load modelagem/example
> Loading modeling program GROMACS version 5.1.5
> GMXBIN = /opt/softwares/gromacs-5.1.5/bin
> [teste02@gfmm01 ~]$ echo $GMXBIN
>
> =====================
>
> What am I doing wrong?
>
> Thanks in advance.
>
> Hernán Cervantes
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>

Re: [Modules] Some "setenv" are not performed

[Paul M. <pau...@gm...>]

You should use different names for the variables you set with set, as setenv also changes them (in the module environment).
My suggestion, is use lowercase for the internal variables (set ) and uppercase for those you set with setenv.

Or, you could eliminate most of the set lines, since setenv also sets those variables (and additionally sets them in the shell).


This is from the man page for 3.2.10  (the binary version, if you are using the tclsh version, check you  man page).

      setenv variable value
               Set environment  variable  to  value.   The  setenv  command  will  also  change  the  process'
               environment.   A  reference  using Tcl's env associative array will reference changes made with
               the setenv command.  Changes made using Tcl's env associative array will NOT change the  user's
               environment  variable  like  the setenv command.  An environment change made this way will only
               affect the module parsing process.   The  setenv  command  is  also  useful  for  changing  the
               environment prior to the exec or system command.  When a modulefile is unloaded, setenv becomes
               unsetenv.  If the environment variable had been defined it will be  overwritten  while  loading
               the  modulefile.   A subsequent unload will unset the environment variable - the previous value
               cannot be restored!  (Unless you handle it explicitly ... see below.)


Unfortunately, that old version doe not have a pushenv command (which works differently).


On 1/27/2023 2:29 PM, Hernan Cervantes wrote:
> Hi there,
> 
> I'm a new user, I have written some modulefile, but one environment
> variable is not being set in any way!
> 
> the environment-module version is 3.2.10
> 
> TCL_VERSION="8.5"
> TCL_PATCH_LEVEL="8.5.13"
> 
> installed in a CentOS 7.9 computer.
> 
> the modulefile content is:
> ==============
> #%Module 1.0
> 
> set modulefilename "GROMACS"
> set modulefilever "5.1.5"
> 
> # On load print component name and version being loaded
> if { [ module-info mode load ] } {
>     puts stderr "Loading modeling program $modulefilename version $modulefilever"
> }
> 
> # On `module unload` print component module and version being removed
> if { [ module-info mode ] == "unload" || [module-info mode ] == "remove" } {
>      puts stderr "Removing $modulefilename version $modulefilever"
> }
> 
> module-whatis "module whatis"
> 
> ##########################################################
> # This is the real configuration part. We save the Gromacs
> # things in separate vars, so we can remove them later.
> # If you move gromacs, change the first line.
> ##########################################################
> set GMXPREFIX /opt/softwares/gromacs-5.1.5
> setenv GMXPREFIX $GMXPREFIX
> 
> set GMXBIN $GMXPREFIX/bin
> setenv GMXBIN $GMXBIN
> setenv GMXBIN $GMXBIN
> 
> set GMXLDLIB $GMXPREFIX/lib64
> setenv GMXLDLIB $GMXLDLIB
> 
> set GMXMAN $GMXPREFIX/share/man
> setenv GMXMAN $GMXMAN
> 
> set GMXDATA $GMXPREFIX/share/gromacs
> setenv GMXDATA $GMXDATA
> 
> set GROMACS_DIR $GMXPREFIX
> setenv GROMACS_DIR $GROMACS_DIR
> 
> prepend-path LD_LIBRARY_PATH $GMXLDLIB
> prepend-path PKG_CONFIG_PATH $GMXLDLIB/pkgconfig
> prepend-path PATH $GMXBIN
> prepend-path MANPATH $GMXMAN
> 
> puts stderr "GMXBIN = $GMXBIN"
> if { [ file exist $GMXBIN/gmx-completion.bash ] } {
>      puts stdout "source $GMXBIN/gmx-completion.bash"
> }
> 
> set namepat $GMXBIN/gmx-completion-*.bash
> foreach cfile [ glob $namepat ] {
>      puts stdout "source $cfile"
> }
> 
> setenv GMXBIN $GMXBIN
> setenv GMXBIN $GMXBIN
> setenv GMXBIN $GMXBIN
> setenv GMXBIN $GMXBIN
> setenv GMXBIN $GMXBIN
> setenv GMXBIN $GMXBIN
> setenv GMXBIN $GMXBIN
> ===============
> 
> the session transcription, in a bash shell, is:
> ======================
> [teste02@gfmm01 ~]$ echo $GMXBIN
> 
> [teste02@gfmm01 ~]$  module load modelagem/example
> Loading modeling program GROMACS version 5.1.5
> GMXBIN = /opt/softwares/gromacs-5.1.5/bin
> [teste02@gfmm01 ~]$ echo $GMXBIN
> 
> =====================
> 
> What am I doing wrong?
> 
> Thanks in advance.
> 
> Hernán Cervantes
> 
> 
> 
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

-- 
--------------------------------------------------------
The views and opinions expressed above are strictly
those of the author(s).  The content of this message has
not been reviewed nor approved by any entity whatsoever.
--------------------------------------------------------
Paul FM         Info: http://paulfm.com/~paulfm/
--------------------------------------------------------

[Modules] Some "setenv" are not performed

[Hernan C. <her...@gm...>]

Hi there,

I'm a new user, I have written some modulefile, but one environment
variable is not being set in any way!

the environment-module version is 3.2.10

TCL_VERSION="8.5"
TCL_PATCH_LEVEL="8.5.13"

installed in a CentOS 7.9 computer.

the modulefile content is:
==============
#%Module 1.0

set modulefilename "GROMACS"
set modulefilever "5.1.5"

# On load print component name and version being loaded
if { [ module-info mode load ] } {
   puts stderr "Loading modeling program $modulefilename version $modulefilever"
}

# On `module unload` print component module and version being removed
if { [ module-info mode ] == "unload" || [module-info mode ] == "remove" } {
    puts stderr "Removing $modulefilename version $modulefilever"
}

module-whatis "module whatis"

##########################################################
# This is the real configuration part. We save the Gromacs
# things in separate vars, so we can remove them later.
# If you move gromacs, change the first line.
##########################################################
set GMXPREFIX /opt/softwares/gromacs-5.1.5
setenv GMXPREFIX $GMXPREFIX

set GMXBIN $GMXPREFIX/bin
setenv GMXBIN $GMXBIN
setenv GMXBIN $GMXBIN

set GMXLDLIB $GMXPREFIX/lib64
setenv GMXLDLIB $GMXLDLIB

set GMXMAN $GMXPREFIX/share/man
setenv GMXMAN $GMXMAN

set GMXDATA $GMXPREFIX/share/gromacs
setenv GMXDATA $GMXDATA

set GROMACS_DIR $GMXPREFIX
setenv GROMACS_DIR $GROMACS_DIR

prepend-path LD_LIBRARY_PATH $GMXLDLIB
prepend-path PKG_CONFIG_PATH $GMXLDLIB/pkgconfig
prepend-path PATH $GMXBIN
prepend-path MANPATH $GMXMAN

puts stderr "GMXBIN = $GMXBIN"
if { [ file exist $GMXBIN/gmx-completion.bash ] } {
    puts stdout "source $GMXBIN/gmx-completion.bash"
}

set namepat $GMXBIN/gmx-completion-*.bash
foreach cfile [ glob $namepat ] {
    puts stdout "source $cfile"
}

setenv GMXBIN $GMXBIN
setenv GMXBIN $GMXBIN
setenv GMXBIN $GMXBIN
setenv GMXBIN $GMXBIN
setenv GMXBIN $GMXBIN
setenv GMXBIN $GMXBIN
setenv GMXBIN $GMXBIN
===============

the session transcription, in a bash shell, is:
======================
[teste02@gfmm01 ~]$ echo $GMXBIN

[teste02@gfmm01 ~]$  module load modelagem/example
Loading modeling program GROMACS version 5.1.5
GMXBIN = /opt/softwares/gromacs-5.1.5/bin
[teste02@gfmm01 ~]$ echo $GMXBIN

=====================

What am I doing wrong?

Thanks in advance.

Hernán Cervantes

Re: [Modules] How to check whether initrc has been read successfully?

[Hiweed M. <hiw...@ho...>]

Hi ,

       All the files are local to the same PC laptop disk, not located to NFS.
 
      For the second question, I am not fully understanding what you mean.
      The two files(/etc/profile.d/modules.sh and /etc/profile.d/modules.csh) are just two links as I showed in above emails.

      If need more info, please feel free to let me know.

Thanks,
BR/HM
________________________________
From: Zhéxué M. Krawutschke <sys...@ro...>
Sent: Monday, January 16, 2023 12:37 PM
To: Environment Modules usage and discussion. <mod...@li...>
Subject: Re: [Modules] How to check whether initrc has been read successfully?


Hi there again,

Thank you very much for the message and I apologise for only now getting back to you.

I first installed the packages: tcl tcl-dev dejagnu less.

I configure & compile "MODUL ENVIRONMENT" with the following parameters:

./configure --prefix=/usr/local/Modules/Release_5 --etcdir=/usr/local/Modules/Module.Base/etc --enable-versioning --enable-color --with-tcl --with-python=/usr/bin/python3 --with-modulepath=/HumanBrain.Projects/xCloud/HumanBrain.Modules --disable-dotmodulespath --enable-color --enable-auto-handling


After the "make && make install" I add the following 2 links to "/etc/profile.d":
ln -s /usr/local/Modules/Release_5/5.2.0/init/profile.csh modules.csh
ln -s /usr/local/Modules/Release_5/5.2.0/init/profile.sh modules.sh

After that, I can log in to the TTY console as well as via SSH and do not receive any error messages. What does not work properly is the work under X-Window.

The "-etcdir" parameter takes a lot of configuration work away from you, because otherwise you would have to do this every time in the directory of the new version & I only have 1 place.....
...so your configuration should also work, with the specified directories.

Question:
Are these directories "local" or rather connected to the server via NFS, etc.?

What do the two files that can be found under "etc" look like?
Best regards



Z. Matthias

On Dienstag, Jan. 10, 2023 at 12:43 AM, Hiweed Mandriva <hiw...@ho...<mailto:hiw...@ho...>> wrote:
Hi there,

Thanks for your reply.


I flow the steps according to the URL https://modules.readthedocs.io/en/latest/INSTALL.html

./configure --prefix=$HOME/INSTALL/Modules --with-tcl=$HOME/INSTALL/tcl/latest/lib/

Just now, I re-try to create the link under /etc/profile.d/ and remove the $HOME/INSTALL/Modules/init/bash in ~/.bashrc , then re-boot the system.

      lrwxrwxrwx   1 root root    40 Jan 10 06:47 modules.csh -> /home/u/INSTALL/Modules/init/profile.csh
      lrwxrwxrwx   1 root root    39 Jan 10 06:47 modules.sh -> /home/u/INSTALL/Modules/init/profile.sh

If I open the default terminal under the Ubuntu machine, it says 'module : command not found' when run 'module list'.
But if I login via ssh-client from windows to ubuntu, both 'module list' and 'module avail' works as expected.

I look into the file /etc/profile.d/modules.sh, it firstly checks the shell type and  then , run ~/INSTALL/Modules/init/bash or sh.

Finally, I just remove links /etc/profile.d/modules.sh and /etc/profile.d/modules.csh. And put $HOME/INSTALL/Modules/init/bash in ~/.bashrc. Everything works well under local terminal of Ubuntu machine or login via ssh.

I think the root-cause is about whether source INSTALL/Modules/init/bash takes effect.

Still needs further analysis about why the links under /etc/profile.d/ does not work.


Thanks,
BR/HM


Ubuntu machine:
 lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.1 LTS
Release:        22.04
Codename:       jammy



________________________________
From: Zhéxué M. Krawutschke <sys...@ro...>
Sent: Monday, January 9, 2023 4:17 PM
To: Environment Modules usage and discussion. <mod...@li...>
Subject: Re: [Modules] How to check whether initrc has been read successfully?


Hey there,
did yo create the link under /etc/profile.d/ ???

like:

        ln -s /usr/local/Modules/Release_5/5.2.0/init/profile.csh modules.csh

ln -s /usr/local/Modules/Release_5/5.2.0/init/profile.sh modules.sh

Did you can run „ml avail“ ? If yes, can you share your „initrc“ please?
AND last question: With which „configure“ - statement did you compile it?

Bes regards


Z. Matthias




On Montag, Jan. 09, 2023 at 3:33 PM, Hiweed Mandriva <hiw...@ho...<mailto:hiw...@ho...>> wrote:

Hi there,

I build modules and install to $HOME/INSTALL/Modules
And I add some 'module add' commands in $HOME/INSTALL/Modules/etc/initrc, but it seems that commands in initrc does not take effect

Just wonder how can I check if initrc take effect?

Thanks,
// HM
_______________________________________________
Modules-interest mailing list
Mod...@li...
https://lists.sourceforge.net/lists/listinfo/modules-interest
_______________________________________________
Modules-interest mailing list
Mod...@li...
https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] How to check whether initrc has been read successfully?

[Paul M. <pau...@gm...>]

And you want to make sure NOT to invoke module initialization for root, as this could negatively affect your system's overall performance.


On 1/16/2023 2:35 PM, Sternberg, Michael G. via Modules-interest wrote:
> If module(1) availability differs between GUI and CLI, then module initialization on your system differs by type of shell invocation, meaning non-interactive vs. interactive vs. login vs. remote.
> 
> For diagnostics, from a terminal in an X11 session where "module list" currently fails, run:
> 
> 	xterm -ls
> 
> If "module list" _does_ work in the resulting new window, then your distro has shells configured to read /etc/profile.d/* for login shells only, which has been the historic default.
> 
> 
> To rectify, your choices are:
> 
> (a) Have your X11 terminal flavor always invoke shells as login shells, not merely interactive shells. Consult the terminal application's preferences or its man page. For xterm specifically, add to your ~/.Xresources file or your distro's equivalent under /etc/ :
> 
> 	XTerm*loginShell:      true
> 
> One way to actually pick up and test this change is to end and re-start your entire X11 session.
> 
> 
> (b) Have the module initialization done for shells invoked as _non-login_ shell [and this not be needlessly repeated if it _is_ a login shell.]  To this end, search for "etc/" in the shell's man page; for  bash(1), see section "INVOCATION".
> 
> It is not quite trivial to hook this in correctly for all shell implementations offered, to all local users, in all invocation types, and remain so across system updates/re-installations.
> 
> 
> 
> With best regards,
> 

-- 
--------------------------------------------------------
The views and opinions expressed above are strictly
those of the author(s).  The content of this message has
not been reviewed nor approved by any entity whatsoever.
--------------------------------------------------------
Paul FM         Info: http://paulfm.com/~paulfm/
--------------------------------------------------------

Re: [Modules] How to check whether initrc has been read successfully?

[Sternberg, M. G. <ste...@an...>]

If module(1) availability differs between GUI and CLI, then module initialization on your system differs by type of shell invocation, meaning non-interactive vs. interactive vs. login vs. remote.

For diagnostics, from a terminal in an X11 session where "module list" currently fails, run:

	xterm -ls

If "module list" _does_ work in the resulting new window, then your distro has shells configured to read /etc/profile.d/* for login shells only, which has been the historic default.


To rectify, your choices are:

(a) Have your X11 terminal flavor always invoke shells as login shells, not merely interactive shells. Consult the terminal application's preferences or its man page. For xterm specifically, add to your ~/.Xresources file or your distro's equivalent under /etc/ :

	XTerm*loginShell:      true

One way to actually pick up and test this change is to end and re-start your entire X11 session.


(b) Have the module initialization done for shells invoked as _non-login_ shell [and this not be needlessly repeated if it _is_ a login shell.]  To this end, search for "etc/" in the shell's man page; for  bash(1), see section "INVOCATION".

It is not quite trivial to hook this in correctly for all shell implementations offered, to all local users, in all invocation types, and remain so across system updates/re-installations.



With best regards,
-- 
Michael Sternberg, Ph.D.
Principal Scientific Computing Administrator
Center for Nanoscale Materials
Argonne National Laboratory




> On Jan 16, 2023, at 06:37, Zhéxué M. Krawutschke <sys...@ro...> wrote:
> …
> After the "make && make install" I add the following 2 links to "/etc/profile.d":
> ln -s /usr/local/Modules/Release_5/5.2.0/init/profile.csh modules.csh
> ln -s /usr/local/Modules/Release_5/5.2.0/init/profile.sh modules.sh
> 
> After that, I can log in to the TTY console as well as via SSH and do not receive any error messages. What does not work properly is the work under X-Window. 
> …
> Z. Matthias

Re: [Modules] How to check whether initrc has been read successfully?

[<sys...@ro...>]

Hi there again,

Thank you very much for the message and I apologise for only now getting back to you.

I first installed the packages: tcl tcl-dev dejagnu less.

I configure & compile "MODUL ENVIRONMENT" with the following parameters:

./configure --prefix=/usr/local/Modules/Release_5 --etcdir=/usr/local/Modules/Module.Base/etc --enable-versioning --enable-color --with-tcl --with-python=/usr/bin/python3 --with-modulepath=/HumanBrain.Projects/xCloud/HumanBrain.Modules --disable-dotmodulespath --enable-color --enable-auto-handling

After the "make && make install" I add the following 2 links to "/etc/profile.d":
ln -s /usr/local/Modules/Release_5/5.2.0/init/profile.csh modules.csh
ln -s /usr/local/Modules/Release_5/5.2.0/init/profile.sh modules.sh

After that, I can log in to the TTY console as well as via SSH and do not receive any error messages. What does not work properly is the work under X-Window.

The "-etcdir" parameter takes a lot of configuration work away from you, because otherwise you would have to do this every time in the directory of the new version & I only have 1 place.....
...so your configuration should also work, with the specified directories.

Question:
Are these directories "local" or rather connected to the server via NFS, etc.?

What do the two files that can be found under "etc" look like?
Best regards

Z. Matthias

> On Dienstag, Jan. 10, 2023 at 12:43 AM, Hiweed Mandriva <hiw...@ho... (mailto:hiw...@ho...)> wrote:
> Hi there,
>
> Thanks for your reply.
>
>
> I flow the steps according to the URL https://modules.readthedocs.io/en/latest/INSTALL.html
>
> ./configure --prefix=$HOME/INSTALL/Modules --with-tcl=$HOME/INSTALL/tcl/latest/lib/
>
> Just now, I re-try to create the link under /etc/profile.d/ and remove the $HOME/INSTALL/Modules/init/bash in ~/.bashrc , then re-boot the system.
>
>       lrwxrwxrwx 1 root root 40 Jan 10 06:47 modules.csh -> /home/u/INSTALL/Modules/init/profile.csh
>       lrwxrwxrwx 1 root root 39 Jan 10 06:47 modules.sh -> /home/u/INSTALL/Modules/init/profile.sh
>
> If I open the default terminal under the Ubuntu machine, it says 'module : command not found' when run 'module list'.
> But if I login via ssh-client from windows to ubuntu, both 'module list' and 'module avail' works as expected.
>
> I look into the file /etc/profile.d/modules.sh, it firstly checks the shell type and then , run ~/INSTALL/Modules/init/bash or sh.
>
> Finally, I just remove links /etc/profile.d/modules.sh and /etc/profile.d/modules.csh. And put $HOME/INSTALL/Modules/init/bash in ~/.bashrc. Everything works well under local terminal of Ubuntu machine or login via ssh.
>
> I think the root-cause is about whether source INSTALL/Modules/init/bash takes effect.
>
> Still needs further analysis about why the links under /etc/profile.d/ does not work.
>
>
> Thanks,
> BR/HM
>
>
> Ubuntu machine:
> lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu 22.04.1 LTS
> Release: 22.04
> Codename: jammy
>
>
>
>
> From: Zhéxué M. Krawutschke <sys...@ro...>
> Sent: Monday, January 9, 2023 4:17 PM
> To: Environment Modules usage and discussion. <mod...@li...>
> Subject: Re: [Modules] How to check whether initrc has been read successfully?
>
>
> Hey there,
> did yo create the link under /etc/profile.d/ ???
>
> like:
>
> ln -s /usr/local/Modules/Release_5/5.2.0/init/profile.csh modules.csh
>
>
> ln -s /usr/local/Modules/Release_5/5.2.0/init/profile.sh modules.sh
>
>
>
> Did you can run „ml avail“ ? If yes, can you share your „initrc“ please?
> AND last question: With which „configure“ - statement did you compile it?
>
> Bes regards
>
>
> Z. Matthias
>
>
>
>
> > On Montag, Jan. 09, 2023 at 3:33 PM, Hiweed Mandriva <hiw...@ho... (mailto:hiw...@ho...)> wrote:
> >
> > Hi there,
> >
> > I build modules and install to $HOME/INSTALL/Modules
> > And I add some 'module add' commands in $HOME/INSTALL/Modules/etc/initrc, but it seems that commands in initrc does not take effect
> >
> > Just wonder how can I check if initrc take effect?
> >
> > Thanks,
> > // HM
> >
> >
> >
> > _______________________________________________
> > Modules-interest mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modules-interest
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] How to check whether initrc has been read successfully?

[Hiweed M. <hiw...@ho...>]

Hi there,

Thanks for your reply.


I flow the steps according to the URL https://modules.readthedocs.io/en/latest/INSTALL.html

./configure --prefix=$HOME/INSTALL/Modules --with-tcl=$HOME/INSTALL/tcl/latest/lib/

Just now, I re-try to create the link under /etc/profile.d/ and remove the $HOME/INSTALL/Modules/init/bash in ~/.bashrc , then re-boot the system.

      lrwxrwxrwx   1 root root    40 Jan 10 06:47 modules.csh -> /home/u/INSTALL/Modules/init/profile.csh
      lrwxrwxrwx   1 root root    39 Jan 10 06:47 modules.sh -> /home/u/INSTALL/Modules/init/profile.sh

If I open the default terminal under the Ubuntu machine, it says 'module : command not found' when run 'module list'.
But if I login via ssh-client from windows to ubuntu, both 'module list' and 'module avail' works as expected.

I look into the file /etc/profile.d/modules.sh, it firstly checks the shell type and  then , run ~/INSTALL/Modules/init/bash or sh.

Finally, I just remove links /etc/profile.d/modules.sh and /etc/profile.d/modules.csh. And put $HOME/INSTALL/Modules/init/bash in ~/.bashrc. Everything works well under local terminal of Ubuntu machine or login via ssh.

I think the root-cause is about whether source INSTALL/Modules/init/bash takes effect.

Still needs further analysis about why the links under /etc/profile.d/ does not work.


Thanks,
BR/HM


Ubuntu machine:
 lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.1 LTS
Release:        22.04
Codename:       jammy



________________________________
From: Zhéxué M. Krawutschke <sys...@ro...>
Sent: Monday, January 9, 2023 4:17 PM
To: Environment Modules usage and discussion. <mod...@li...>
Subject: Re: [Modules] How to check whether initrc has been read successfully?


Hey there,
did yo create the link under /etc/profile.d/ ???

like:

        ln -s /usr/local/Modules/Release_5/5.2.0/init/profile.csh modules.csh

ln -s /usr/local/Modules/Release_5/5.2.0/init/profile.sh modules.sh

Did you can run „ml avail“ ? If yes, can you share your „initrc“ please?
AND last question: With which „configure“ - statement did you compile it?

Bes regards


Z. Matthias




On Montag, Jan. 09, 2023 at 3:33 PM, Hiweed Mandriva <hiw...@ho...<mailto:hiw...@ho...>> wrote:

Hi there,

I build modules and install to $HOME/INSTALL/Modules
And I add some 'module add' commands in $HOME/INSTALL/Modules/etc/initrc, but it seems that commands in initrc does not take effect

Just wonder how can I check if initrc take effect?

Thanks,
// HM
_______________________________________________
Modules-interest mailing list
Mod...@li...
https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] How to check whether initrc has been read successfully?

[<sys...@ro...>]

Hey there,
did yo create the link under /etc/profile.d/ ???

like:
ln -s /usr/local/Modules/Release_5/5.2.0/init/profile.csh modules.csh
ln -s /usr/local/Modules/Release_5/5.2.0/init/profile.sh modules.sh

Did you can run „ml avail“ ? If yes, can you share your „initrc“ please?
AND last question: With which „configure“ - statement did you compile it?

Bes regards

Z. Matthias

> On Montag, Jan. 09, 2023 at 3:33 PM, Hiweed Mandriva <hiw...@ho... (mailto:hiw...@ho...)> wrote:
>
> Hi there,
>
> I build modules and install to $HOME/INSTALL/Modules
> And I add some 'module add' commands in $HOME/INSTALL/Modules/etc/initrc, but it seems that commands in initrc does not take effect
>
> Just wonder how can I check if initrc take effect?
>
> Thanks,
> // HM
>
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

[Modules] How to check whether initrc has been read successfully?

[Hiweed M. <hiw...@ho...>]

Hi there,

I build modules and install to $HOME/INSTALL/Modules
And I add some 'module add' commands in $HOME/INSTALL/Modules/etc/initrc, but it seems that commands in initrc does not take effect

Just wonder how can I check if initrc take effect?

Thanks,
// HM

[Modules] Module cache

[Xavier D. <xav...@gm...>]

Hello All,

Happy `module switch year/2023` everyone.

Work on next version (5.3) has started some weeks ago. First feature
finished is the module cache mechanism:

  https://modules.readthedocs.io/en/latest/MIGRATING.html#module-cache

A cache file can be built under each modulepath with new `cachebuild`
sub-command. When available, it is used by module search mechanism
rather walking through modulepath directory. I/O operations are saved
and processing time is reduced.

Options are available to optimize cache read/write buffer size
(cache_buffer_bytes), ignore cache file (--ignore-cache) and expire
cache file (cache_expiry_secs).

Regards,
Xavier

[Modules] SC22

[Xavier D. <xav...@gm...>]

Hello All,

If you are participating to #SC22, come to say hi on CEA booth (2004).
I will be happy to chat about Modules. I should be present on booth
today (from 11am to 12am and 2pm to 3pm) and tomorrow (from 4pm to
5pm).

Regards,
Xavier

Re: [Modules] Modules 5.2.0 released

[Xavier D. <xav...@gm...>]

Hello Paul,

Many thanks for your feedback.

Regarding "module source" it is named this way to remind of the source
command available on shell: content of the script is ingested in
current environment without tracking and undo. "module source" treats
modulefiles like bare script and it is intended that there is no
revert capabilities.

"module load" on its side implies tracking and revert capabilities.

There is already a "sneak load" feature available with the
"hidden-loaded" tag. When applied to loading module, this module is
not reported in the loaded module list unless the --all option is
given:
https://modules.readthedocs.io/en/latest/MIGRATING.html#hiding-loaded-modules

For the "unconditionally load" mechanism, I have plans for a "reload
already loaded module" feature, that should match what you describe.

Best regards,
Xavier

Le jeu. 10 nov. 2022 à 18:44, Paul Markfort <pau...@gm...> a écrit :
>
> Just installed it, seems to work well.
>
> I like that bash and zsh init scripts no longer export variables/functions.
>
> I see you made this change to the source command in 5.2 (which is wonderful):
> * Make source sub-command accepts modulefile specification as argument. If argument does not correspond to a file path, search it among available modulefiles. (fix issue #424)
>
>
> And, as I think about it, maybe source as a command is a bad thing - as it doesn't really say what the command does (and it is confusing with the tcl source command).
>
> Maybe the command should be loadsu  - short for load Sneakily and Unconditionally (which is what source really does).
> Sneakily - it doesn't update any values that say it is loaded.
> Unconditionally - it loads the module, even if it is already loaded.
>
> So maybe these two commands should be added:
>         loadu - Load Unconditionally (module loads, even if already loaded - not the same as force).
>         loadsu - Load Sneakily and Unconditionally
>
>         unloadsu - should be a no-op
>         unloadu - should be the same as unload
>         source - should become a depreciated alias for loadsu
>
> Or perhaps --sneaky and --uncond(itionally) should be options to the load command.
>
>
> Since these are just wild thoughts, I leave it up to you to determine if these changes would be a good idea.
>
>
> Anyway:
>
> It is nice to not have to change the init/bash and init/zsh scripts when I install modules.
> And to only have to make one very minor change to modulecmd.tcl to use the source command in module files:
>
> That is, remove "source" (actually " - source" from this block:
>
>   # some commands can only be called from top level, not within modulefile
>        switch -- $command {
>           path - paths - autoinit - help - prepend-path - append-path -\
>           remove-path - is-loaded - is-saved - is-used - is-avail -\
>           info-loaded - clear - sh-to-mod - edit - refresh - source - state -\
>           lint - mod-to-sh - reset - stash - stashpop - stashrm - stashshow -\
>           stashclear - stashlist {
>              knerror "${msgprefix}Command '$command' not supported$tryhelpmsg"
>           }
>        }
>
> By changing it to:
>
>   # some commands can only be called from top level, not within modulefile
>        switch -- $command {
>           path - paths - autoinit - help - prepend-path - append-path -\
>           remove-path - is-loaded - is-saved - is-used - is-avail -\
>           info-loaded - clear - sh-to-mod - edit - refresh - state -\
>           lint - mod-to-sh - reset - stash - stashpop - stashrm - stashshow -\
>           stashclear - stashlist {
>              knerror "${msgprefix}Command '$command' not supported$tryhelpmsg"
>           }
>        }
>
>
>
>
>
>
> On 11/8/2022 12:15 AM, Xavier Delaruelle wrote:
> > Hello All,
> >
> > Modules 5.2 is out! As usual many new features added: Optional
> > requirements, Linting modulefiles, mod-to-sh sub-command, Initial
> > environment, Stashing environment and Siteconfig hook variables.
> >
> > Details on the major changes included in this new release are provided
> > in the MIGRATING document. The list of all changes made in this new
> > version are described in the NEWS document.
> >
> >   http://modules.readthedocs.io/en/stable/MIGRATING.html
> >   http://modules.readthedocs.io/en/stable/NEWS.html
> >
> > The tarball of this new version can be downloaded at:
> >
> >   http://downloads.sourceforge.net/modules/modules-5.2.0.tar.gz
> >
> > The zipball to install this new version on Windows platform can be
> > downloaded at:
> >
> >   http://downloads.sourceforge.net/modules/modules-5.2.0-win.zip
> >
> > If you encounter any issue, please let us know by creating a ticket on
> > the project bug tracker at:
> >
> >   https://github.com/cea-hpc/modules/issues
> >
> > I would like to thanks all of you who improve Modules by reporting
> > bugs or sharing new ideas and more specifically Adrien Cotte, Jan
> > Macku and Lukáš Zaoral for their contribution to this new version.
> >
> > Best regards,
> > Xavier
> >
> >
> > _______________________________________________
> > Modules-interest mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modules-interest
> >
>
> --
> --------------------------------------------------------
> The views and opinions expressed above are strictly
> those of the author(s).  The content of this message has
> not been reviewed nor approved by any entity whatsoever.
> --------------------------------------------------------
> Paul FM         Info: http://paulfm.com/~paulfm/
> --------------------------------------------------------
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] Modules 5.2.0 released

[Paul M. <pau...@gm...>]

Just installed it, seems to work well.

I like that bash and zsh init scripts no longer export variables/functions.

I see you made this change to the source command in 5.2 (which is wonderful):
* Make source sub-command accepts modulefile specification as argument. If argument does not correspond to a file path, search it among available modulefiles. (fix issue #424)


And, as I think about it, maybe source as a command is a bad thing - as it doesn't really say what the command does (and it is confusing with the tcl source command).

Maybe the command should be loadsu  - short for load Sneakily and Unconditionally (which is what source really does).
Sneakily - it doesn't update any values that say it is loaded.
Unconditionally - it loads the module, even if it is already loaded.

So maybe these two commands should be added:
	loadu - Load Unconditionally (module loads, even if already loaded - not the same as force).
	loadsu - Load Sneakily and Unconditionally

	unloadsu - should be a no-op
	unloadu - should be the same as unload
	source - should become a depreciated alias for loadsu

Or perhaps --sneaky and --uncond(itionally) should be options to the load command.


Since these are just wild thoughts, I leave it up to you to determine if these changes would be a good idea.


Anyway:

It is nice to not have to change the init/bash and init/zsh scripts when I install modules.
And to only have to make one very minor change to modulecmd.tcl to use the source command in module files:

That is, remove "source" (actually " - source" from this block:

  # some commands can only be called from top level, not within modulefile
       switch -- $command {
          path - paths - autoinit - help - prepend-path - append-path -\
          remove-path - is-loaded - is-saved - is-used - is-avail -\
          info-loaded - clear - sh-to-mod - edit - refresh - source - state -\
          lint - mod-to-sh - reset - stash - stashpop - stashrm - stashshow -\
          stashclear - stashlist {
             knerror "${msgprefix}Command '$command' not supported$tryhelpmsg"
          }
       }

By changing it to:

  # some commands can only be called from top level, not within modulefile
       switch -- $command {
          path - paths - autoinit - help - prepend-path - append-path -\
          remove-path - is-loaded - is-saved - is-used - is-avail -\
          info-loaded - clear - sh-to-mod - edit - refresh - state -\
          lint - mod-to-sh - reset - stash - stashpop - stashrm - stashshow -\
          stashclear - stashlist {
             knerror "${msgprefix}Command '$command' not supported$tryhelpmsg"
          }
       }






On 11/8/2022 12:15 AM, Xavier Delaruelle wrote:
> Hello All,
> 
> Modules 5.2 is out! As usual many new features added: Optional
> requirements, Linting modulefiles, mod-to-sh sub-command, Initial
> environment, Stashing environment and Siteconfig hook variables.
> 
> Details on the major changes included in this new release are provided
> in the MIGRATING document. The list of all changes made in this new
> version are described in the NEWS document.
> 
>   http://modules.readthedocs.io/en/stable/MIGRATING.html
>   http://modules.readthedocs.io/en/stable/NEWS.html
> 
> The tarball of this new version can be downloaded at:
> 
>   http://downloads.sourceforge.net/modules/modules-5.2.0.tar.gz
> 
> The zipball to install this new version on Windows platform can be
> downloaded at:
> 
>   http://downloads.sourceforge.net/modules/modules-5.2.0-win.zip
> 
> If you encounter any issue, please let us know by creating a ticket on
> the project bug tracker at:
> 
>   https://github.com/cea-hpc/modules/issues
> 
> I would like to thanks all of you who improve Modules by reporting
> bugs or sharing new ideas and more specifically Adrien Cotte, Jan
> Macku and Lukáš Zaoral for their contribution to this new version.
> 
> Best regards,
> Xavier
> 
> 
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

-- 
--------------------------------------------------------
The views and opinions expressed above are strictly
those of the author(s).  The content of this message has
not been reviewed nor approved by any entity whatsoever.
--------------------------------------------------------
Paul FM         Info: http://paulfm.com/~paulfm/
--------------------------------------------------------

[Modules] Modules 5.2.0 released

[Xavier D. <xav...@gm...>]

Hello All,

Modules 5.2 is out! As usual many new features added: Optional
requirements, Linting modulefiles, mod-to-sh sub-command, Initial
environment, Stashing environment and Siteconfig hook variables.

Details on the major changes included in this new release are provided
in the MIGRATING document. The list of all changes made in this new
version are described in the NEWS document.

 http://modules.readthedocs.io/en/stable/MIGRATING.html
 http://modules.readthedocs.io/en/stable/NEWS.html

The tarball of this new version can be downloaded at:

 http://downloads.sourceforge.net/modules/modules-5.2.0.tar.gz

The zipball to install this new version on Windows platform can be
downloaded at:

 http://downloads.sourceforge.net/modules/modules-5.2.0-win.zip

If you encounter any issue, please let us know by creating a ticket on
the project bug tracker at:

 https://github.com/cea-hpc/modules/issues

I would like to thanks all of you who improve Modules by reporting
bugs or sharing new ideas and more specifically Adrien Cotte, Jan
Macku and Lukáš Zaoral for their contribution to this new version.

Best regards,
Xavier