|
From: Thomas M. P. <pa...@um...> - 2025-02-06 22:29:13
|
The purpose of environmental modules (and lua modules and any similar package) is to set up the environment for a package. Commands (as opposed to shell functions or aliases) entered at the shell command line are executed in a subshell, and therefore cannot affect the environment of the parent shell (changes to the environment only affect the subshell and any of its descendents). See https://askubuntu.com/questions/53177/bash-script-to-set-environment-variables-not-working . So environmental modules basically consists of two parts, the modulecmd command which for a load subcommand figures out the modulefile to process and outputs to STDOUT the list of commands to set the environmental variables (in the proper format for the requested shell). The second part is a shell function or alias or similar which invokes the appropriate modulecmd command and evaluates the output. Because the shell function runs in the main (i.e. parent) shell and not. a subshell, the environment changes have effect in the calling shell. As someone else mentioned, the simplest solution is to just source the appropriate initialization file to get the module shell function/alias defined in your batch job. Usually something like "source ~/.profile" or similar will do the trick. If you insist on doing it without that, something like eval $(modulecmd bash load foo) On Thu, Feb 6, 2025 at 4:19 PM Frank Thommen <f.t...@dk...> wrote: > Dear all, > > is there a way to use (shell) scripts instead of shell functions for all > the required Environment Modules functionalities? > > In our cluster, shell functions are currently not inherited by cluster > jobs from the users' local environments, leading to a non-functional > (better: non-existent) `module` command within the batch jobs, which > breaks many of our established pipelines. I considered to implement the > required shell functions as plain shell scripts, but in contrast to > Environment Modules 3.x, where there was just a single shell function, > there is now a loooong list of functions. Implementing them all as > scripts would require to check each of them after each Environment > Module upgrade, to be sure to always use up-to-date code. That's too > much overhead on the admin side. > > Question: Is there way to convert the shell functions into scripts, > which does not conflict with the Environment Modules' design and which > could also be integrated into automated Environment Modules updates > (Debian Linux using `apt`)? > > Side question: Why are the Environment Modules' functions implemented as > shell functions instead of plain shell scripts? > > I'm grateful for all ideas and pointers. > > Cheers, Frank > > > _______________________________________________ > Modules-interest mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modules-interest > -- Tom Payerle DIT-ACIGS/Mid-Atlantic Crossroads pa...@um... 5825 University Research Park (301) 405-6135 University of Maryland College Park, MD 20740-3831 |
