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: