| Server IP : 217.160.0.244 / Your IP : 216.73.216.151 Web Server : Apache System : Linux infong-eu155 4.4.400-icpu-108 #2 SMP Wed Feb 11 11:51:01 UTC 2026 x86_64 User : u100174116 ( 6746176) PHP Version : 8.5.10 Disable Function : NONE MySQL : OFF | cURL : ON | WGET : ON | Perl : ON | Python : OFF | Sudo : OFF | Pkexec : OFF Directory : /usr/share/zsh/help/ |
Upload File : |
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 mod-
ules 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 al-
ready 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 nec-
essary, while if it is not available, non-zero status is
silently returned. The option -i is accepted for compati-
bility 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 con-
tains 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 mod-
ule 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 al-
ready 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 fea-
tures 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 fea-
tures 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 para-
meter couldn't be added because there was a different pa-
rameter 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:strf-
time' indicates a builtin named strftime and p:EPOCHSEC-
ONDS indicates a parameter named EPOCHSECONDS. The module
may provide other (`abstract') features of its own as in-
dicated 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 combina-
tions is given with the option -P param then the parameter
param is set to an array of features, either features to-
gether 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 dis-
abled 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 fea-
tures 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 re-
moved. The options -l and -L may be used to list au-
toloads. 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 mod-
ule -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 fea-
ture 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 suc-
cessful, 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 sta-
tus 1 returned.
zmodload -Fa can be used with the -l, -L, -e and -P op-
tions for listing and testing the existence of autoload-
able features. In this case -l is ignored if -L is speci-
fied. 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 argu-
ment.
With -d and one argument, all dependencies for that module
are listed. With -d and no arguments, all module depen-
dencies are listed. This listing is by default in a Make-
file-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 mod-
ule 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 de-
fined, 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 de-
fined.
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 possi-
ble if the builtin is not yet loaded. -i suppresses the
error if the builtin is already removed (or never ex-
isted).
Autoload requests are retained if the module is subse-
quently 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 condi-
tions.
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 correspond-
ing 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 at-
tempt 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 zmod-
load command to recreate the alias.
The existence of aliases for modules is completely inde-
pendent 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 connec-
tion 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 circu-
lar. 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 re-
moved. It is valid to create an alias whose name is one
of the standard shell modules and which resolves to a dif-
ferent 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 mod-
ule is autoloaded on these definitions). This is true even for
systems that don't support dynamic loading of modules.