Current File : //usr/local/share/zsh/5.8/help/zmodload
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.
Mini Shell