Hi Frank,
It seems to be an issue at the shell initialization level. When the
shell of the user is initializing on the machine, it should source
user shell config, which calls global shell config, which evaluates
scripts in /etc/profile.d.
If dash does not do that, a solution may be to set user's shell to
something else (bash, etc).
If you do not have the ability to change such system configuration,
you may adapt the batch scheduler to launch a script of your own
prior running the job script.
In such script, you may initialize the module environment by either:
source /usr/share/modules/init/$shell
or
eval "$(modulecmd $shell autoinit)"
Cheers,
Xavier
On Fri, 2025-02-07 at 08:36 +0100, Frank Thommen wrote:
> 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
>
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
|