|
From: Frank T. <f.t...@dk...> - 2025-02-07 07:36:38
|
Hi Thomas, yes, I realize this in the meantime. It was too late yesterday and I apparently I had too little coffee ;-). Since there is no way around sourcing or using a shell function, we will have to think about how to implement this as user friendly as possible and how to integrate it into our batch system. Cheers, Frank On 06.02.25 23:13, Thomas M. Payerle wrote: > 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 <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.thommen@dkfz- > heidelberg.de <mailto: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... <mailto:Modules- > int...@li...> > https://lists.sourceforge.net/lists/listinfo/modules-interest > <https://lists.sourceforge.net/lists/listinfo/modules-interest> > > > > -- > Tom Payerle > DIT-ACIGS/Mid-Atlantic Crossroads pa...@um... <mailto:pa...@um...> > 5825 University Research Park (301) 405-6135 > University of Maryland > College Park, MD 20740-3831 > > > _______________________________________________ > Modules-interest mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modules-interest |
