|
From: Frank T. <f.t...@dk...> - 2025-02-07 07:32:57
|
Thank you Paul. I understand the mechanism of shell initialization ;-), however that would either require, that each user explicitely sources /etc/profile.d/modules.sh (which is not very user friendly and conflicts with how it worked so far [1]), or that we implement the shell initialization centrally in the job starter code (which would be yet an other piece of code to be maintained by the cluster administration and which comes with additional complexity, due to the involved batch system) But you are absolutely right, that executable scripts won't work, as we need to modify the current environment (which of also answers the side question...silly me). Cheers, Frank [1] so far we were using a Red Hat based Linux distribution in the cluster, where /bin/sh is just a /bin/bash with slight behavioural changes. In this setup the inheritance of exported shell functions (`declare -fx ...`) worked perfectly. But we are migrating to a Debian-based setup, where /bin/sh is a "real" sh which doesn't know about how to export shell functions. That's why we are getting problems now. On 06.02.25 22:36, Paul Markfort wrote: > You could use aliases instead of functions, but that won't solve the issue. > You can use scripts, but you have to source them (or they won't modify > the running shell's environment). > > What you need is to have the modules environment initialized as part of > the job startup. > This should be easily done by sourcing one file that sets up (like a > login script) the job environment, including running the module > initialization commands. > > Think of it like starting an ssh session (it does not inherit any of the > environment from the process that submits the job, the environment has > to be completely set up in the job). > > > On 2025-02-06 3:18 PM, Frank Thommen 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 > |
