tcar_setModuleEnvironment.sh(1)
===============================
Name
----
tcar_setModuleEnvironment.sh - Initiate module environments.
Synopsis
--------
*tcar_setModuleEnvironment [-m "MODULE_NAME"] [-t "MODULE_TYPE"] [-g MODULE_ARGUMENT] ...*
Description
-----------
[[options]]
Options
-------
The *tcar_setModuleEnvironment* function accepts the following
options:
-m ::
This option specifies the name of the module you want to load.
-t::
This option specifies the type of the module you want to load.
Modules can be one of the following types:
+
top-module;;
This modules are stored in the first level of Modules directory.
This type of modules initiate module environments for specific
tasks so it can be called from anywhere inside *centos-art.sh*
script.
sub-module;;
This modules are stored from the second-level of Modules directory
on. This type of modules can be executed from top-modules,
sub-modules, or sib-modules but never the *centos-art.sh* file
itself.
sib-module;;
This modules are stored from the second-level of Modules directory
on. This type of modules can be executed from sub-modules or
sib-modules, but never top-modules or the *centos-art.sh* file
itself.
-g::
This option specifies the module-specific option you want to pass
for processing in the module environment you are about to execute.
Generally, module-specific options are passed through
*centos-art.sh* command-line but you may need to pass them
internally in some cases (e.g., you are executing a top-module
from a sub-module). If you need to pass more than one option, then
you need to put the -g option before each option you want to pass.
Bugs
----
In the very beginning of *tcar_setModuleEnvironment* function, it used
just non-array variables and it worked fine for top-module and sub-module
processing, however when it was needed to do sibling processing, it
didn't work as expected. The failure was produced because a wrong
variable assignment when tried to set the path of the next module to
load. There was not a clean way to ``remember'' what was the base
directory of the parent directory, so it ended up using the last
loaded module base directory which made impossible to load a sibling
module. The *tcar_setModuleEnvironment* function as implemented in
version 0.5 of The CentOS Artwork Repository, fixes this issue
replacing non-array variables by array variables which can remember
module information.
See also: https://centos.org.cu/bugs/[https://centos.org.cu/bugs/]
Author
------
The *centos-art.sh* script has received contribution from the
following people:
* Alain Reguera Delgado <mailto:al@centos.org.cu[al@centos.org.cu]>, 2009-2013
Copyright
---------
Copyright (C) 2009-2013 The CentOS Artwork SIG
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or (at
your option) any later version.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
// vim: set syntax=asciidoc: