tcar_setModuleEnvironment(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: