That flow is fairly common.
Basically, you need to get the environment alias 'module' to be defined
so you need your script to source things.
The common thing is to:
source ~/.bash_profile
On default RHEL-based systems this will also call ~/.bashrc which in
turn calls ~/etc/bashrc
The
Hi,
My environment is this:
* Users are using "bash" as the default shell
* A sample of one of my environment modules is this:
#%Module1.0
##
## modules modulefile
##
## modulefiles/modules. Generated from modules.in by configure.
##
set ModulesVersion "3.2.10"
proc ModulesHelp {
We also use the lmod system. We found that besides the user's shell, it
also depends on how you install it. I.e. need to be active for general
shell and not just for login shells (bashrc vs. profile). Also, for e.g.
/bin/sh, it might not read any init file at all.
As we might have different module
On our slurm clusters the module system (Lmod) works without extra init
in job scripts due to the environment-forwarding in slurm. "module" in
the submitting context (in bash) on the login node is an "exported"
function and as such makes it across.
/Peter
On Fri, 22 Jan 2021 10:41:06 +
Gestió
On our clusters, we typically find that an explicit source of the
initialization dot files is need IF the default shell of
the user submitting the job does _not_ match the shell being used to run
the script. I.e., for sundry historical and other reasons,
the "default" login shell for users on our
