module man page on Oracle

Man page or keyword search:  
man Server   33470 pages
apropos Keyword Search (all sections)
Output format
Oracle logo
[printable version]

MODULE(1)			Modules package			     MODULE(1)

       module - command interface to the Modules package

       module [ switches ] [ sub-command ] [ sub-command-args ]

       module is a user interface to the Modules package.  The Modules package
       provides for the dynamic modification of	 the  user's  environment  via

       Each  modulefile contains the information needed to configure the shell
       for an application.  Once  the  Modules	package	 is  initialized,  the
       environment  can	 be  modified  on  a per-module basis using the module
       command which interprets modulefiles.  Typically	 modulefiles  instruct
       the  module command to alter or set shell environment variables such as
       PATH, MANPATH, etc.  modulefiles may be	shared	by  many  users	 on  a
       system and users may have their own collection to supplement or replace
       the shared modulefiles.

       The modulefiles are added to and removed from the  current  environment
       by  the user.  The environment changes contained in a modulefile can be
       summarized through the module command as well.	If  no	arguments  are
       given, a summary of the module usage and sub-commands are shown.

       The  action  for	 the  module  command to take is described by the sub-
       command and its associated arguments.

   Package Initialization
       The Modules package and the  module  command  are  initialized  when  a
       shell-specific  initialization  script  is sourced into the shell.  The
       script creates  the  module  command,  either  as  an  alias  or	 shell
       function,  creates  Modules environment variables, and if enabled to do
       so, a snapshot of the environment is saved as  either  (if  BEGINENV=1)
       $HOME/.modulesbeginenv  or  (if	BEGINENV=99) whatever $MODULESBEGINENV
       points to.

       The module alias or function executes the modulecmd program and has the
       shell  evaluate	the command's output.  The first argument to modulecmd
       specifies the type of shell.

       The initialization scripts are kept in $MODULESHOME/init/<shell>	 where
       <shell>	is  the	 name of the sourcing shell.  The sh, csh, tcsh, bash,
       ksh, and zsh shells are supported by modulecmd.	In  addition,  python,
       perl,  and  cmake  "shells" are supported, which writes the environment
       changes to stdout as python, perl, or cmake code.

       The perl module command is set up with:

	 use lib $ENV{'MODULESHOME'}."/init";
	 use perl;

       And the python module command is defined with:

	 import os;
	 if os.environ.has_key('PYTHONPATH'):
	    os.environ['PYTHONPATH'] +=':'+os.environ['MODULESHOME']+"/init";
	    os.environ['PYTHONPATH'] = os.environ['MODULESHOME']+"/init";

	 from python import module;

   Modulecmd startup
       Upon invocation modulecmd sources rc files which contain	 global,  user
       and   modulefile	 specific  setups.  These  files  are  interpreted  as
       modulefiles.  See modulefile(4) for detailed information.

       Upon invocation of  modulecmd  module  RC  files	 are  sourced  in  the
       following order:

	    Global RC file as specified by ${MODULERCFILE} or ${MODULESHOME}/etc/rc

	    User specific module RC file ${HOME}/.modulerc

	    All .modulerc and .version files found during modulefile seeking.

   Command line switches
       The   module  command  accepts  command	line  switches	as  its	 first
       parameter.  These  may  be  used	 to  control  output  format  of   all
       information  displayed  and the module behavior in case of locating and
       interpreting module files.

       All switches may be entered either  in  short  or  long	notation.  The
       following switches are accepted:

       --help, -H
	      Give some helpful usage information, and terminates the command.

       --version, -V
	      Lists  the  current  version  of	the  module  command, and some
	      configured option values.	 The command then  terminates  without
	      further processing.

       --force, -f
	      Force  active dependency resolution. This will result in modules
	      found on a prereq	 command  inside  a  module  file  being  load
	      automatically.   Unloading  module  files using this switch will
	      result  in  all  required	 modules  which	  have	 been	loaded
	      automatically  using the -f switch being unload.	This switch is
	      experimental at the moment.

       --terse, -t
	      Display avail and list output in short format.

       --long, -l
	      Display avail and list output in long format.

       --human, -h
	      Display short output of the avail and  list  commands  in	 human
	      readable format.

       --verbose, -v
	      Enable verbose messages during module command execution.

       --silent, -s
	      Disable verbose messages. Redirect stderr to /dev/null if stderr
	      is found not to be a tty. This is a  useful  option  for	module
	      commands	being  written	into .cshrc, .login or .profile files,
	      because some remote shells  (as  rsh(1))	and  remote  execution
	      commands (like rdist) get confused if there is output on stderr.

       --create, -c
	      Create  caches  for module avail and module apropos. You must be
	      granted write access to the ${MODULEHOME}/modulefiles/ directory
	      if you try to invoke module with the -c option.

       --icase, -i
	      Case  insensitive	 module	 parameter  evaluation. Currently only
	      implemented for the module apropos command.

       --userlvl <lvl>, -u <lvl>
	      Set the user level to the specified value. The argument of  this
	      option may be one of:

       novice, nov Novice

       expert, exp Experienced module user

       advanced, adv Advanced module user

   Module Sub-Commands
	      help   [modulefile...]
			     Print  the	 usage	of  each  sub-command.	 If an
			     argument is given, print the Module-specific help
			     information for the modulefile(s).

	      add    modulefile...
	      load   modulefile...
			     Load modulefile(s) into the shell environment.

	      rm     modulefile...
	      unload modulefile...
			     Remove modulefile(s) from the shell environment.

	      swap   [modulefile1] modulefile2
	      switch [modulefile1] modulefile2
			     Switch  loaded  modulefile1 with modulefile2.  If
			     modulefile1 is not specified, then it is  assumed
			     to	 be  the currently loaded module with the same
			     root name as modulefile2.

	      show    modulefile...
	      display modulefile...
			     Display   information   about   one    or	  more
			     modulefiles.   The	 display sub-command will list
			     the full path of the modulefile(s)	 and  all  (or
			     most)    of    the	   environment	 changes   the
			     modulefile(s) will make if loaded.	 (It will  not
			     display  any  environment	changes	 found	within
			     conditional statements.)

	      list	     List loaded modules.

	      avail [path...]
			     List all available	 modulefiles  in  the  current
			     MODULEPATH,  where	 the sorting order is given by
			     the LC_COLLATE locale environment variable.

			     All directories in the MODULEPATH are recursively
			     searched  for  files  containing  the  modulefile
			     magic cookie.

			     If an argument is given, then each	 directory  in
			     the  MODULEPATH is searched for modulefiles whose
			     pathname match the argument.

			     Multiple  versions	 of  an	 application  can   be
			     supported	by  creating  a	 subdirectory  for the
			     application  containing  modulefiles   for	  each

	      use [-a|--append] directory...
			     Prepend one or more directories to the MODULEPATH
			     environment variable.   The  --append  flag  will
			     append the directory to MODULEPATH.

	      unuse directory...
			     Remove   one   or	 more	directories  from  the
			     MODULEPATH environment variable.

	      update	     Attempt to reload all  loaded  modulefiles.   The
			     environment  will	be  reconfigured  to match the
			     environment saved in ${HOME}/.modulesbeginenv (if
			     BEGINENV=1)   or	the   file   pointed   at   by
			     $MODULESBEGINEV   (if   BEGINENV=99)   and	   the
			     modulefiles will be reloaded.  This is only valid
			     if modules was configured with  --enable-beginenv
			     (which  defines  BEGINENV),  otherwise  this will
			     cause a warning.  update  will  only  change  the
			     environment variables that the modulefiles set.

	      clear	     Force  the	 Modules  package  to  believe that no
			     modules are currently loaded.

	      purge	     Unload all loaded modulefiles.

	      refresh	     Force a refresh of all non-persistent  components
			     of currently loaded modules.  This should be used
			     on	 derived  shells  where	 aliases  need	to  be
			     reinitialized  but the environment variables have
			     already been set by the currently loaded modules.

	      whatis [modulefile...]
			     Display the information set  up  by  the  module-
			     whatis	commands    inside    the    specified
			     modulefile(s). If no modulefile is specified, all
			     'whatis' lines will be shown.

	      apropos string
	      keyword string Seeks  through  the  'whatis' informations of all
			     modulefiles  for  the  specified	string.	   All
			     module-whatis  informations  matching  the string
			     will be displayed.

	      initadd modulefile...
			     Add modulefile(s) to the  shell's	initialization
			     file  in  the user's home directory.  The startup
			     files checked (in order) are:
			     csh - .modules, .cshrc(.ext), .csh_variables, and
			     tcsh    -	  .modules,   .tcshrc,	 .cshrc(.ext),
			     .csh_variables, and .login(.ext)
			     sh	 and  ksh  -  .modules,	 .profile(.ext),   and
			     bash   -  .modules,  .bash_profile,  .bash_login,
			     .profile(.ext), and .bashrc(.ext)
			     zsh - .modules, .zcshrc(.ext), .zshenv(.ext), and

			     If	 a 'module load' line is found in any of these
			     files, the modulefile(s) is(are) appended to  any
			     existing  list of modulefiles.  The 'module load'
			     line must be located in at least one of the files
			     listed  above  for any of the 'init' sub-commands
			     to work properly.	If the 'module load'  line  is
			     found in multiple shell initialization files, all
			     of the lines are changed.

	      initprepend modulefile [modulefile...]
			     Does the same as initadd but prepends  the	 given
			     modules to the beginning of the list.

	      initrm modulefile...
			     Remove    modulefile(s)	from	the    shell's
			     initialization files.

	      initswitch modulefile1 modulefile2
			     Switch  modulefile1  with	modulefile2   in   the
			     shell's initialization files.

	      initlist	     List  all	of  the	 modulefiles  loaded  from the
			     shell's initialization file.

	      initclear	     Clear all of the  modulefiles  from  the  shell's
			     initialization files.

       modulefiles  are	 written  in  the  Tool Command Language (Tcl) and are
       interpreted by modulecmd.  modulefiles can use conditional  statements.
       Thus  the  effect  a modulefile will have on the environment may change
       depending upon the current state of the environment.

       Environment variables are unset when unloading a modulefile.  Thus,  it
       is  possible to load a modulefile and then unload it without having the
       environment variables return to their prior state.

	      The location  of	the  master  Modules  package  file  directory
	      containing module command initialization scripts, the executable
	      program modulecmd, and a directory containing  a	collection  of
	      master modulefiles.

	      The  path	 that  the  module  command  searches when looking for
	      modulefiles.  Typically, it is set to a  default	value  by  the
	      bootstrap	 procedure.   MODULEPATH can be set using 'module use'
	      or by the	 module	 initialization	 script	 to  search  group  or
	      personal	modulefile  directories	 before	 or  after  the master
	      modulefile directory.

	      A colon separated list of all loaded modulefiles.

	      A colon separated list of	 the  full  pathname  for  all	loaded

	      If  modules  has	been configured (BEGINENV=99) to test for this
	      environment variable, then if it exists, it is the name  of  the
	      file   to	  store	 the  the  initial  shell  environment.	  This
	      environment variable will have  embedded	environment  variables
	      unrolled	to  one	 level.	 The contents of this variable is only
	      used the first time modules is invoked.

	      The  filename  of	 the  file   containing	  the	initialization
	      environment snapshot.

	      The MODULESHOME directory.

	      The  system-wide modules rc file.	 The location of this file can
	      be  changed  using  the  MODULERCFILE  environment  variable  as
	      described above.

	      The user specific modules rc file.

	      The  directory for system-wide modulefiles.  The location of the
	      directory	 can  be  changed  using  the  MODULEPATH  environment
	      variable as described above.

	      The   modulefile	 interpreter  that  gets  executed  upon  each
	      invocation of module.

	      The Modules package initialization file sourced into the	user's

	      File  containing	the  cached  list  of all modulefiles for each
	      directory in the	MODULEPATH  (only  when	 the  avail  cache  is
	      enabled  via  the	 configure  option  --enable-cache  which sets

	      File containing the names and modification times	for  all  sub-
	      directories with an avail cache (see above).

	      A	  snapshot   of	  the	user's	environment  taken  at	Module
	      initialization.  This information is used by the	module	update
	      sub-command (if BEGINENV=1), else

	      If  this defines a valid filename, it serves the same purpose as
	      above (if BEGINENV=99).



Modules version 3.2.10		   July 2009			     MODULE(1)

List of man pages available for Oracle

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net