You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If script currently evaluated by sh-to-mod sub-command or source-sh modulefile command relies itself on module to load some modulefiles, the environment variables intended for Modules internal use are reported.
Such environment variables (LOADEDMODULES, _LMFILES_ and __MODULES_*) should be filtered-out to get a consistent result not reporting/setting these internal variables.
The text was updated successfully, but these errors were encountered:
It occurred to me that multiple (chained) invocations of sh-to-mod should produce the same modules code, i.e., be idempotent up to sorting, and therefore that should be a good unit test even if more internals are added in the future. I haven’t thought through yet if it’s dispositive, though.
It occurred to me that multiple (chained) invocations of sh-to-mod should produce the same modules code, i.e., be idempotent up to sorting, and therefore that should be a good unit test even if more internals are added in the future. I haven’t thought through yet if it’s dispositive, though.
@mgsternberg Could you elaborate more on that point by giving an example (that I could reproduce on my side) of the behavior you currently get.
If script currently evaluated by
sh-to-mod
sub-command orsource-sh
modulefile command relies itself on module to load some modulefiles, the environment variables intended for Modules internal use are reported.Such environment variables (
LOADEDMODULES
,_LMFILES_
and__MODULES_*
) should be filtered-out to get a consistent result not reporting/setting these internal variables.The text was updated successfully, but these errors were encountered: