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.
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.
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.
Do not unset environment variable when running the unsetenv modulefile
command during an unload evaluation with no value to restore provided.
With this change, the unsetenv command acts like the remove-path command
on unload mode.
No error is raised when evaluating in `display` mode a modulefile without
a value specified for the variant it defines. This change helps to learn
all the variant a modulefile defines. As a result, the unspecified
variant is not instantiated in the ModuleVariant array variable.
Fixes#406.
When initializing Modules, evaluate the initrc configuration file in
addition to the the modulespath configuration file and not instead of
this file. initrc is evaluated after modulespath file.
Both configuration files are only evaluated if the current environment
if found unset, in other words when the MODULEPATH and LOADEDMODULES
environment variables are both found unset or empty.
As initrc is evaluated after modulespath, it has the ability to undo
what was done by modulespath, especially if it restores a module
collection.
When initializing Modules, refresh the loaded modules in case some user
environment is already configured. This is especially useful when
starting a sub-shell session as it ensures that the loaded environment
in parent shell will be correctly inherited, as the `refresh`
sub-command re-applies the non-persistent environment configuration
(i.e., shell alias and function that are not exported to the sub-shell).
If a refresh has to be attempted, loaded environment is parsed. In case
this environment is inconsistent, an error code is returned but this
error is trapped and initialization evaluation continues without
launching the refresh process. No error message is reported to avoid
noise on the full shell session initialization. The user will get the
error message as soon as he will launch the next module command that
parse the loaded environment.
Fixes#86.
Evaluate the modulefile commands resulting from the `source-sh`
evaluation through the current modulefile Tcl interpreter. This way the
modulefile commands are evaluated according to the current modulefile
evaluation mode.
For compatibility with Modules 3.2, module-info mode returns true if
tested against the `nonpersist` string and currently in `refresh`
evaluation mode.
Restore the refresh sub-command as it worked in version 3.2: not
anymore an alias on the reload sub-command but an evaluation of each
loaded module (in their loaded order) in 'refresh' mode.
`refresh` evaluation mode only execute the modulefile commands
generating volatile environment changes like set-alias and set-function.
variant and source-sh commands should also be enabled to ensure a
modulefile evaluation that regenerates the expected volatile environment
changes.
`refresh` evaluation mode does not require that the modulefile commands
triggering environment variable changes (setenv, unsetenv, append-path,
etc) to operate as the targetted variables should already be set as the
refreshed modules are loaded. Same goes for the x-resource and system
modulefile commands. Configuring these commands as 'no operation' for
this refresh mode should not disrupt the modulefile evaluation.
refresh sub-command does not accept any argument and cannot be called
within modulefile or sourced or initilization module script (initrc).
When the evaluation of a refreshed modulefile fails, the environment
changes prior this evaluation is restored. Then refresh evaluation
continue on the remaining loaded modules.
Fix unuse sub-command when sereval modulepaths are specified as a single
argument (i.e., `/path/to/dir1:/path/to/dir2`). Enabled modulepaths were
not correctly detected when specified this way.
The append-path, prepend-path and remove-path sub-commands are always
called from a top level context. The reference counter associated
with each entry in targeted environment variable is now ignored so:
- a "module prepend/append-path" will not increase the reference counter
of a path entry already defined unless if the duplication mode is
enabled
- a "module remove-path" will remove specified paths whatever their
reference counter value.
When the use and unuse sub-commands are called from a top level context,
ignore the reference counter associated to each entry in the MODULEPATH
environment variable. This way a "module use" called from top context
will not increase the reference counter of a path entry already defined
and a "module unuse" called from top context will remove specified paths
whatever their reference counter value.
Add the '--ignore-refcount' option to the add-path and unload-path
procedures (parsed by parsePathCommandArgs procedure). When set this
option makes the reference counter value ignored.
Which means on add-path that the reference counter of each path element
passed is not increased unless if the duplication mode is enabled.
On unload-path it means that the reference counter is not take into
account and each path element is removed (even if the reference counter
is greater than 1).
Update cmdModuleUse and cmdModuleUnuse to pass all the paths specified
respectively for addition or removal to the underlying environment
management procedure (respectively add-path and unload-path).
Gather in a dedicated procedure named isTopEvaluation the test to know
if current evaluation is made at top level.
"Top level" is either: (1) at the modulecmd level (module command
written by user in terminal or script) or (2) during the evaluation of
rc or modulefile by a source or autoinit sub-command triggered from
modulecmd level or (3) during the evaluation of global rc file.
(2) and (3) are considered "extended" top evaluation contexts.
When an element is added to a path-like variable through the
append-path or prepend-path modulefile commands, add this element to the
associated reference counter variable only when this element is added
multiple times to the path-like variable. When an element is removed
from a path-like variable, this element is removed from the reference
counter variable when its counter is equal to 1.
Exception is made when element is an empty string: in this case element
is added to the reference counter variable even if only added once to
the path-like variable in order to distinguish between an empty path-like
variable and a path-like variable containing an empty string as single
element.
Rename the environment variables used to record the reference count of
each element in path-like environment variables. A `__MODULES_SHARE_`
prefix is applied to the name of these variables instead of the
`_modshare` suffix to indicate they are intended for Modules internal
use of only.
It also helps with DYLD_* environment variables where using a
suffixed-variable led to warning messages on OS X.
Exclude the Modules-specific variables (like LOADEDMODULES) from the
reference counting mechanism. As a result no <VAR>_modshare variable is
set in user environment for these variables. Exception is made for
MODULEPATH environment variable that still benefit from the mechanism.
This change is made as the reference counting mechanism is useless for
all Modules-specific variables except for MODULEPATH. Either the entries
are unique (same module cannot be loaded twice in LOADEDMODULES) or
duplicate elements are allowed (same modulefile could be used twice by
virtual modules in _LMFILES_). Also each entry in the __MODULES_LM*
variables uses as prefix the loaded module name the entry is associated
to.
Also set loaded or auto-loaded tag on the module designation including
variants, as tags to export in __MODULES_LMTAG variable are those set on
the variant designation.
Record the 'auto-loaded' tag for loaded modules that have been loaded
automatically, rather recording this state in a specific environment
variable __MODULES_LMNOTUASKED.
Extract the usage message report from cmdModuleHelp and cmdMlHelp
procedures and create standalone procedures respectively reportUsage and
reportMlUsage.
When usage message has to be printed, the appropriate procedure can be
fetched from the report side and not from the sub-command side.
