Produce shell code of environment changes made by loading designated modulefiles and send this content to the report message channel. User views the produced shell code as output.
Shortcut name: none
Expected number of argument: 2 to N
Accept boolean variant specification: yes
Parse module version specification: yes
Fully read modulefile when checking validity: yes
Sub-command only called from top level: yes
Lead to modulefile evaluation: yes (
First argument should be a supported shell name
like bash or fish
An error is produced if an unsupported shell is specified
It defines the language that sub-command will use to produce shell code
After the first argument, comes the modulefile specification
Multiple modulefiles can be specified
With advanced version specifiers and variants
It defines the modulefiles to load
mod-to-sh loads designated modulefile(s) and instead of rendering the
corresponding environment changes to the stdout channel, the shell code is
sent to the message report channel (stderr).
Target shell is changed, from the one specified as argument to
modulecmd.tcl script to the one specified as argument to
Once shell code is produced and sent to the message channel (stderr), target
shell defined for
modulecmd.tcl is restored to get on the regular
code channel (stdout) the evaluation status. For instance for sh shell:
test 0 if successful,
test 0 = 1 otherwise.
Shell code produced by
mod-to-sh is only sent to message channel. It is
not sent to the code channel.
modtosh_real_shell state is introduced and set by
sub-command. When defined, shell code rendering procedure knows if code should
be sent to the message channel and then cleared, not to be rendered on code
channel. This state contains the target shell of
shell rendering procedure can restore target shell then produce the final
shell code to render (evaluation status).
Modulefile evaluation is made like a regular
module load. Thus if
specified modulefile is already loaded, its corresponding environment changes
will not appear on the
Shell code produced for
mod-to-sh is filtered to only contain environment
changes of designated modulefiles and not the Modules-specific environment
_LMFILES_ environment variables).
mod-to-sh sub-command automatically adjusts the
configuration option to the
silent mode. As produced shell code is sent
to the message channel, it should not mix with report messages. Setting
silent disables loading messages or
puts stderr messages defined in
verbosity is not changed if set to
trace mode or
any higher mode (debugging).
mod-to-sh leads to modulefile evaluation, the
command modulefile command returns the
when used in a modulefile evaluated through this sub-command. It can also be
queried against this command name string to return Boolean value depending if
mod-to-sh is the sub-command currently running.