mod-to-sh sub-command¶
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.
mod-to-sh
could be send as the opposite of sh-to-mod
. The
former transforms a modulefile into shell code whereas the latter transforms
shell code into a modulefile.
Configuration¶
None.
Sub-command properties¶
General properties:
- Shortcut name: none
- Accepted option:
--force
,--icase
,--auto
,--no-auto
- 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 (
load
mode)
Arguments expected:
- 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 mod-to-sh
sub-command.
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 mod-to-sh
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 modulecmd.tcl
. So
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 mod-to-sh
result.
Shell code produced for mod-to-sh
is filtered to only contain environment
changes of designated modulefiles and not the Modules-specific environment
context (like LOADEDMODULES
or _LMFILES_
environment variables).
mod-to-sh
sub-command automatically adjusts the verbosity
configuration option to the silent
mode. As produced shell code is sent
to the message channel, it should not mix with report messages. Setting
verbosity to silent
disables loading messages or reportWarning
,
reportError
and puts stderr
messages defined in
modulefiles. verbosity
is not changed if set to trace
mode or
any higher mode (debugging).
module-info command¶
As mod-to-sh
leads to modulefile evaluation, the module-info
command
modulefile command returns the mod-to-sh
string
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.