
                             The Modules Package
                                 Version 2.0

                               John L. Furlani
                                SunSoft, Inc.
                          john.furlani@East.Sun.COM
                              22 February 1993


1. Introduction
_______________

This directory contains a copy of The Modules Package that uses Tcl (Tool
Command Language) developed by John Ousterhout at the University of California
at Berkeley.  You must obtain a copy of Tcl (at least version 6.3).  Tcl
should be available either at the same site you obtained The Modules Package
or sprite.berkeley.edu.

For an introduction to The Modules Package, see the paper, "Modules: Providing
a Flexible User Environment", in the Proceeding of the 1991 Large Installation
Systems Administrators USENIX Conference (USENIX LISA V).  A copy of the paper
is included in Postscript form in doc/Modules-Paper.ps.  The paper describes
the concepts behind Modules and a prototype/proof-of-concept implementation
based on shell scripts being sourced into the user environment.  The
implementation details have changed, but the package concepts haven't.


2. Documentation
________________

The ./doc directory contains both the paper and man pages describing the
user's and the module writer's usage.

Big changes include:

    o  Added a new environment variable, _LOADED_MODULEFILES_, which keeps
        track of which file and directory each modulefile was loaded from.
        This is necessary for locating modulefiles if the MODULEPATH variable
        has changed or if a full pathname was specified as the modulefile to
        load.

    o  Added an update sub-command which attempts to reload all of the
        currently loaded modulefiles.  When Modules is first initialized a
        snapshot of the environment is saved into a file in the user's home
        directory.  When the update sub-command is run, the environment
        variables are restored to their earlier state and the modulefiles are
        reloaded.  Only the variables that modulefiles touch are changed.
        
    o  Added an purge sub-command which unloads all currently loaded
        modulefiles.
    
    o  set-alias should be fixed and should work for all shell types.  In the
        case of the Bourne shell-variants, it creates functions.

    o  If multiple modulefiles are listed to be added or removed and one of
        them has an error, only that modulefile will fail.  All of the other
        modulefiles will load or unload successfully (assuming they don't in
        turn have errors).

    o  UNCOMPATABILITY ISSUE:  stdout is not tied to stderr any more.  So, if
        you to a 'puts stdout' in any of your modulefiles, that will go
        directly to the shell.  You should change all puts statements that
        goto stdout to goto stderr.
        
    o  avail prints out all of the modulefiles by recursively looking through
        all directories under every entry in MODULEPATH.  It will also cache
        the information since it can take much longer than the previous
        version.  Finally, only files containing the "#%Module" magic cookie
        header and that don't end in '~' will be listed.  Other files will be
        ignored.

    o  A .version file in a modulefile directory will be parsed to find out
        which modulefile is the default version for the directory name.

    o  Locating modulefiles is recursive and ignores files ending in '~' and
        which don't have the "#%Module" magic header.

    o  The switch command really works now.

    o  Added uname command for fast access to system information.  Not sure if
        uname is portable.

    o  Unload using a directoryname will look for a version that is already
        loaded instead of the default version specified by the .version file
        or by the highest lexicographical name in the directory.

    o  Added ability for modulefile-specific help and modulefile-specific
        display.



3. Building and Installing Modules
__________________________________

First, you'll need to decide on a location to keep Modules on your network.

The path name to the initialization files must be the same on all of the
systems using Modules.  This is because your users' .cshrc or other shell
startup files must hard code this directory in order to source their Modules
initialization file.

You will also need to choose a location for the 'modulecmd' program and all of
your modulefiles.  The location of these can be different on different
systems, but it is not recommended.  These paths are defined in the Modules
init files.

Example:
	Decided to keep Modules in /depot/Modules.

	initialization file   -->  /depot/Modules/init
	modulefiles           -->  /depot/Modules/modulefiles
	modulecmd             -->  /depot/Modules/bin

The Modules Package is written in conformant ANSI C and should build on any
UNIX machine with an ANSI C compiler like the GNU C compiler.  The Tcl package
can accommodate both ANSI C and traditional C.  Follow the directions provided
with Tcl for building Tcl.

To build Modules, first build Tcl and run the tests provided with Tcl to
verify it built correctly.

Then run the program ./Configure and answer all of the questions.  A Makefile
will automatically be generated.  Then type make after it's done.

A note.  I've found that at least the X11 libraries should be linked
statically.  In order to do this, you either must link everything statically
or use the linker to turn static linking on for the X11 libs and off for
everything else.  I've found something similar to the following to work well
under Solaris2:

LDLIBS= -Bstatic -ltcl -lXmu -lXt -lX11 -lsocket -lnsl -lintl -Bdynamic -ldl

I have provided a number of example modulefile in the example-modulefiles
directory.  This should help provide you with some idea on how to write
modulefiles.

Finally, type 'make install' and 'modulecmd' along with the initfiles will be
installed.


4. modules-interest@eng.auburn.eng
__________________________________

With release 2.0, I have worked with Richard Elling to being a Modules
interest alias for discussion about Modules and other Modules-related packages
such as user-setup.

If you would like to be added to the modules-interest alias, mail
listserv@eng.auburn.edu with "ADD address modules-interest" where "address" is
your Internet e-mail address.


5. Special Thanks
_________________

Ken Manheimer and Don Libes at the National Institute of Standards and
Technology deserve special thanks for their help and ideas toward the original
paper, design considerations, and the use of Tcl.  Maureen Chew and others at
Sun Microsystems have provided me with an test site and many ideas on how to
improve my Tcl implementation of Modules.  Leif Hedstrom added the x-resource
command and provided valuable input on the installation procedures.

I would also like to thank Richard Elling at Auburn University for his
comments, help with the Modules' man pages and his application 'user-setup'.
A paper on 'user-setup' was presented at this year's USENIX LISA VI
conference.  The paper and the application can be acquired via anonymous ftp
from ftp.eng.auburn.edu.

There are many others that deserve thanks but too many to list here -- thanks
to everyone who has helped.


6. Bugs and Comments
____________________

Report bugs to 'module-bugs@sunpix.East.Sun.COM'.  Please try to provide a
full environment listing and a copy of the modulefiles you're trying to
manipulate.  Be as explicit and detailed as possible.

Comments and suggestions for improvement are always welcome.

Thanks,
John L. Furlani



P.S.
    I have received questions about the /depot pathnames in the example
modulefiles like, "What is the depot stuff?"  The Depot was developed by a few
folks at NIST.  Their paper, "The Depot: A Framework for Sharing Software
Installation Across Organization and UNIX Platform Boundaries", was presented
at the USENIX LISA IV conference.  The depot is a scheme for distributing
and maintaining software efficiently.  If you want more information, contact
Ken Manheimer at klm@cme.nist.gov.

