zmodload [ -dL ] [ -s ] [ ... ]
zmodload -F [ -alLme -P param ] module [ [+-]feature ... ]
zmodload -e [ -A ] [ ... ]
zmodload [ -a [ -bcpf [ -I ] ] ] [ -iL ] ...
zmodload -u [ -abcdpf [ -I ] ] [ -iL ] ...
zmodload -A [ -L ] [ modalias[=module] ... ]
zmodload -R modalias ...
       Performs operations relating to zsh's loadable modules.  Loading of
       modules while the shell is running (`dynamical loading') is not
       available on all operating systems, or on all installations on a
       particular operating system, although the zmodload command itself is
       always available and can be used to manipulate modules built into
       versions of the shell executable without dynamical loading.

       Without arguments the names of all currently loaded binary modules
       are printed.  The -L option causes this list to be in the form of a
       series of zmodload commands.  Forms with arguments are:

       zmodload [ -is ] name ...
       zmodload -u [ -i ] name ...
              In the simplest case, zmodload loads a binary module.  The
              module must be in a file with a name consisting of the
              specified name followed by a standard suffix, usually `.so'
              (`.sl' on HPUX).  If the module to be loaded is already
              loaded the duplicate module is ignored.  If zmodload detects
              an inconsistency, such as an invalid module name or circular
              dependency list, the current code block is aborted.  If it is
              available, the module is loaded if necessary, while if it is
              not available, non-zero status is silently returned.  The
              option -i is accepted for compatibility but has no effect.

              The named module is searched for in the same way a command
              is, using $module_path instead of $path.  However, the path
              search is performed even when the module name contains a `/',
              which it usually does.  There is no way to prevent the path
              search.

              If the module supports features (see below), zmodload tries
              to enable all features when loading a module.  If the module
              was successfully loaded but not all features could be
              enabled, zmodload returns status 2.

              If the option -s is given, no error is printed if the module
              was not available (though other errors indicating a problem
              with the module are printed).  The return status indicates if
              the module was loaded.  This is appropriate if the caller
              considers the module optional.

              With -u, zmodload unloads modules.  The same name must be
              given that was given when the module was loaded, but it is
              not necessary for the module to exist in the file system.
              The -i option suppresses the error if the module is already
              unloaded (or was never loaded).

              Each module has a boot and a cleanup function.  The module
              will not be loaded if its boot function fails.  Similarly a
              module can only be unloaded if its cleanup function runs
              successfully.

       zmodload -F [ -almLe -P param ] module [ [+-]feature ... ]
              zmodload -F allows more selective control over the features
              provided by modules.  With no options apart from -F, the
              module named module is loaded, if it was not already loaded,
              and the list of features is set to the required state.  If no
              features are specified, the module is loaded, if it was not
              already loaded, but the state of features is unchanged.  Each
              feature may be preceded by a + to turn the feature on, or -
              to turn it off; the + is assumed if neither character is
              present.  Any feature not explicitly mentioned is left in its
              current state; if the module was not previously loaded this
              means any such features will remain disabled.  The return
              status is zero if all features were set, 1 if the module
              failed to load, and 2 if some features could not be set (for
              example, a parameter couldn't be added because there was a
              different parameter of the same name) but the module was
              loaded.

              The standard features are builtins, conditions, parameters
              and math functions; these are indicated by the prefix `b:',
              `c:' (`C:' for an infix condition), `p:' and `f:',
              respectively, followed by the name that the corresponding
              feature would have in the shell.  For example, `b:strftime'
              indicates a builtin named strftime and p:EPOCHSECONDS
              indicates a parameter named EPOCHSECONDS.  The module may
              provide other (`abstract') features of its own as indicated
              by its documentation; these have no prefix.

              With -l or -L, features provided by the module are listed.
              With -l alone, a list of features together with their states
              is shown, one feature per line.  With -L alone, a zmodload -F
              command that would cause enabled features of the module to be
              turned on is shown.  With -lL, a zmodload -F command that
              would cause all the features to be set to their current state
              is shown.  If one of these combinations is given with the
              option -P param then the parameter param is set to an array
              of features, either features together with their state or (if
              -L alone is given) enabled features.

              With the option -L the module name may be omitted; then a
              list of all enabled features for all modules providing
              features is printed in the form of zmodload -F commands.  If
              -l is also given, the state of both enabled and disabled
              features is output in that form.

              A set of features may be provided together with -l or -L and
              a module name; in that case only the state of those features
              is considered.  Each feature may be preceded by + or - but
              the character has no effect.  If no set of features is
              provided, all features are considered.

              With -e, the command first tests that the module is loaded;
              if it is not, status 1 is returned.  If the module is loaded,
              the list of features given as an argument is examined.  Any
              feature given with no prefix is simply tested to see if the
              module provides it; any feature given with a prefix + or - is
              tested to see if is provided and in the given state.  If the
              tests on all features in the list succeed, status 0 is
              returned, else status 1.

              With -m, each entry in the given list of features is taken as
              a pattern to be matched against the list of features provided
              by the module.  An initial + or - must be given explicitly.
              This may not be combined with the -a option as autoloads must
              be specified explicitly.

              With -a, the given list of features is marked for autoload
              from the specified module, which may not yet be loaded.  An
              optional + may appear before the feature name.  If the
              feature is prefixed with -, any existing autoload is removed.
              The options -l and -L may be used to list autoloads.
              Autoloading is specific to individual features; when the
              module is loaded only the requested feature is enabled.
              Autoload requests are preserved if the module is subsequently
              unloaded until an explicit `zmodload -Fa module -feature' is
              issued.  It is not an error to request an autoload for a
              feature of a module that is already loaded.

              When the module is loaded each autoload is checked against
              the features actually provided by the module; if the feature
              is not provided the autoload request is deleted.  A warning
              message is output; if the module is being loaded to provide a
              different feature, and that autoload is successful, there is
              no effect on the status of the current command.  If the
              module is already loaded at the time when zmodload -Fa is
              run, an error message is printed and status 1 returned.

              zmodload -Fa can be used with the -l, -L, -e and -P options
              for listing and testing the existence of autoloadable
              features.  In this case -l is ignored if -L is specified.
              zmodload -FaL with no module name lists autoloads for all
              modules.

              Note that only standard features as described above can be
              autoloaded; other features require the module to be loaded
              before enabling.

       zmodload -d [ -L ] [ name ]
       zmodload -d name dep ...
       zmodload -ud name [ dep ... ]
              The -d option can be used to specify module dependencies.
              The modules named in the second and subsequent arguments will
              be loaded before the module named in the first argument.

              With -d and one argument, all dependencies for that module
              are listed.  With -d and no arguments, all module
              dependencies are listed.  This listing is by default in a
              Makefile-like format.  The -L option changes this format to a
              list of zmodload -d commands.

              If -d and -u are both used, dependencies are removed.  If
              only one argument is given, all dependencies for that module
              are removed.

       zmodload -ab [ -L ]
       zmodload -ab [ -i ] name [ builtin ... ]
       zmodload -ub [ -i ] builtin ...
              The -ab option defines autoloaded builtins.  It defines the
              specified builtins.  When any of those builtins is called,
              the module specified in the first argument is loaded and all
              its features are enabled (for selective control of features
              use `zmodload -F -a' as described above).  If only the name
              is given, one builtin is defined, with the same name as the
              module.  -i suppresses the error if the builtin is already
              defined or autoloaded, but not if another builtin of the same
              name is already defined.

              With -ab and no arguments, all autoloaded builtins are
              listed, with the module name (if different) shown in
              parentheses after the builtin name.  The -L option changes
              this format to a list of zmodload -a commands.

              If -b is used together with the -u option, it removes
              builtins previously defined with -ab.  This is only possible
              if the builtin is not yet loaded.  -i suppresses the error if
              the builtin is already removed (or never existed).

              Autoload requests are retained if the module is subsequently
              unloaded until an explicit `zmodload -ub builtin' is issued.

       zmodload -ac [ -IL ]
       zmodload -ac [ -iI ] name [ cond ... ]
       zmodload -uc [ -iI ] cond ...
              The -ac option is used to define autoloaded condition codes.
              The cond strings give the names of the conditions defined by
              the module. The optional -I option is used to define infix
              condition names. Without this option prefix condition names
              are defined.

              If given no condition names, all defined names are listed (as
              a series of zmodload commands if the -L option is given).

              The -uc option removes definitions for autoloaded conditions.

       zmodload -ap [ -L ]
       zmodload -ap [ -i ] name [ parameter ... ]
       zmodload -up [ -i ] parameter ...
              The -p option is like the -b and -c options, but makes
              zmodload work on autoloaded parameters instead.

       zmodload -af [ -L ]
       zmodload -af [ -i ] name [ function ... ]
       zmodload -uf [ -i ] function ...
              The -f option is like the -b, -p, and -c options, but makes
              zmodload work on autoloaded math functions instead.

       zmodload -a [ -L ]
       zmodload -a [ -i ] name [ builtin ... ]
       zmodload -ua [ -i ] builtin ...
              Equivalent to -ab and -ub.

       zmodload -e [ -A ] [ string ... ]
              The -e option without arguments lists all loaded modules; if
              the -A option is also given, module aliases corresponding to
              loaded modules are also shown.  If arguments are provided,
              nothing is printed; the return status is set to zero if all
              strings given as arguments are names of loaded modules and to
              one if at least on string is not the name of a loaded module.
              This can be used to test for the availability of things
              implemented by modules.  In this case, any aliases are
              automatically resolved and the -A flag is not used.

       zmodload -A [ -L ] [ modalias[=module] ... ]
              For each argument, if both modalias and module are given,
              define modalias to be an alias for the module module.  If the
              module modalias is ever subsequently requested, either via a
              call to zmodload or implicitly, the shell will attempt to
              load module instead.  If module is not given, show the
              definition of modalias.  If no arguments are given, list all
              defined module aliases.  When listing, if the -L flag was
              also given, list the definition as a zmodload command to
              recreate the alias.

              The existence of aliases for modules is completely
              independent of whether the name resolved is actually loaded
              as a module: while the alias exists, loading and unloading
              the module under any alias has exactly the same effect as
              using the resolved name, and does not affect the connection
              between the alias and the resolved name which can be removed
              either by zmodload -R or by redefining the alias.  Chains of
              aliases (i.e. where the first resolved name is itself an
              alias) are valid so long as these are not circular.  As the
              aliases take the same format as module names, they may
              include path separators:  in this case, there is no
              requirement for any part of the path named to exist as the
              alias will be resolved first.  For example, `any/old/alias'
              is always a valid alias.

              Dependencies added to aliased modules are actually added to
              the resolved module; these remain if the alias is removed.
              It is valid to create an alias whose name is one of the
              standard shell modules and which resolves to a different
              module.  However, if a module has dependencies, it will not
              be possible to use the module name as an alias as the module
              will already be marked as a loadable module in its own right.

              Apart from the above, aliases can be used in the zmodload
              command anywhere module names are required.  However, aliases
              will not be shown in lists of loaded modules with a bare
              `zmodload'.

       zmodload -R modalias ...
              For each modalias argument that was previously defined as a
              module alias via zmodload -A, delete the alias.  If any was
              not defined, an error is caused and the remainder of the line
              is ignored.

       Note that zsh makes no distinction between modules that were linked
       into the shell and modules that are loaded dynamically. In both
       cases this builtin command has to be used to make available the
       builtins and other things defined by modules (unless the module is
       autoloaded on these definitions). This is true even for systems that
       don't support dynamic loading of modules.
