Change installation option --enable-silent-shell-debug-support to
disable it by default. Now the silent_shell_debug configuration option
enables to locally enable this feature from the initrc configuration
file.
Generate the silent_shell_debug code in module shell function during the
autoinit processing if the silent_shell_debug configuration option is
enabled.
Choice made at installation time may now be updated later on with the
silent_shell_debug configuration option. If enabled prior calling
autoinit (or enabled within initrc configuration file), the silent shell
debug code will be included in module shell function.
Change installation option --enable-quarantine-support to disable it by
default. Now the quarantine_support configuration option enables to
locally enable this feature from the initrc configuration file.
Convert the --enable-quarantine-support installation option in a
quarantine_support configuration option. When this option is enabled the
autoinit sub-command produces the module shell code with quarantine
mecahnism support. When disabled, code is generated without quarantine
support.
This way decision to have or not the quarantine mechanism code can also
be made in initrc configuration file. As a result
--enable-quarantine-support installation option new controls the default
behavior to generate or not the quarantine code, but this could now be
superseded in initrc configuration file.
Different setup cases are foreseen:
1. quarantine code has been included in module shell function, then
quarantine_support config is disabled
> config disablement is not effective as shell code is already set
2. quarantine code has not been included in module shell function,
then quarantine_support config is enabled
> config enablement is not effective as shell code is already set
3. during module initialization, quarantine_support config is enabled in
initrc
> shell code generated with quarantine code
4. during module initialization, quarantine_support config is disabled
in initrc
> shell code generated without quarantine code
5. during module initialization, quarantine_support config is enabled by
default or via env
> shell code generated with quarantine code
6. during module initialization, quarantine_support config is disabled by
default or via env
> shell code generated with quarantine code
Always set in modulecmd.tcl script the code to restore the user
environment set in quarantine by module shell function of shell
initialization script. Do not depend on the quarantinesupport
installation option to enable of disable this code in the main procedure
of the modulecmd.tcl script.
Thanks to the __MODULES_QUARANTINE_SET environment variable, we know
when to branch to execute the quarantine unhold code.
Introduce the __MODULES_QUARANTINE_SET environment variable to put back
when starting modulecmd.tcl run the environment set on hold by
initialization script (for autoinit calls) or by module shell function
(for regular calls).
This new environment variable is tested to apply quarantine unhold
mechanism instead of checking if the run_quarantine configuration option
is set and shell accurately supports the mecanishm. With this change it
is possible to enable or disable the quarantine support at module
initialization time (through initrc configuration file) instead of
freezing this configuration when building the modulecmd.tcl script.
Enforce use of the module magic cookie (i.e., `#%Module`) at the start of
global or user rc files, `initrc` configuration file or any scriptfile
passed for evaluation to the `source` sub-command. These files are not
evaluated and an error is produced if the magic cookie is missing or if
the optional version number placed after the cookie string is higher than
the version of the `modulecmd.tcl` script in use.
Note that version 3.2 of Modules was already enforcing the magic cookie
for the user/global rc files.
This enforced back globally to ensure people understand, especially for
the source sub-command, that the script is made for module and it is not
a shell script. It will also help to protect module from automatically
evaluating files with expected file name but unrelated content.
This commit among things reverts 3fe71c0d.
Remove the '1.0' in the #%Module magic cookie header of the generated
initrc configuration file. Users may define a more appropriate magic
cookie compatibility version.
When the loadedmodules installation option is set and if the module
initialization is triggered then the default module to load will emit a
message on stderr. Adapt the testsuite code, especially the _test_sub
procedure to automatically take this situation into account (no need to
set these load message in each expected stderr answer).
Raise error if more than 2 arguments are set on the unsetenv modulefile
command. Specific code need to be set here as we now use args for the
unsetenv procedure (to distinguish between no value to restore and an
empty string value to restore)
The rc_running state used to distinguish top evaluation from the rest is
useless for the initrc evaluation as the isTopEvaluation procedure
already recognized it as top evaluation as in this situation depth of
modulename state is 1 and above command name is source.
Report the modules loading and unloading during the `module` command
initialization (i.e., during the evaluation of the `initrc` configuration
file). These report messages are disabled when the `verbosity`
configuration option is set to `concise` or `silent`.
During a module `restore` or `source`, only report the module load and
unload directly triggered by these sub-commands. Load and unload
triggered by other modules are reported through the automated module
handling messages of the main modules.
Register the cmdModuleSource call made by cmdModuleAutoinit as a
`source` command call to benefit from the message report mechanism. Do
not apply the same for the cmdModuleSource call made by runModulerc as
those calls will be changed to execute-modulerc in the future.
Forbid use of `module source` command in modulefile or in an
initialization rc file, the `source` Tcl command should be used instead.
`source` module sub-command should only be called from the command-line.
Using 'module source' in a modulefile was a non-sense as it does not
provide any benefit than using the regular 'source' Tcl command. It also
implied to reverse the subcommand to the unsource one when unloading the
module.
