3124 lines
168 KiB
HTML
3124 lines
168 KiB
HTML
|
<!DOCTYPE HTML>
|
|||
|
<html lang="en" class="sidebar-visible no-js light">
|
|||
|
<head>
|
|||
|
<!-- Book generated using mdBook -->
|
|||
|
<meta charset="UTF-8">
|
|||
|
<title>Shell Builtin Commands - Zsh Manual</title>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<!-- Custom HTML head -->
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
|
|||
|
<meta name="description" content="">
|
|||
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|||
|
<meta name="theme-color" content="#ffffff" />
|
|||
|
|
|||
|
|
|||
|
<link rel="icon" href="favicon.svg">
|
|||
|
|
|||
|
|
|||
|
<link rel="shortcut icon" href="favicon.png">
|
|||
|
|
|||
|
<link rel="stylesheet" href="css/variables.css">
|
|||
|
<link rel="stylesheet" href="css/general.css">
|
|||
|
<link rel="stylesheet" href="css/chrome.css">
|
|||
|
|
|||
|
<link rel="stylesheet" href="css/print.css" media="print">
|
|||
|
|
|||
|
|
|||
|
<!-- Fonts -->
|
|||
|
<link rel="stylesheet" href="FontAwesome/css/font-awesome.css">
|
|||
|
|
|||
|
<link rel="stylesheet" href="fonts/fonts.css">
|
|||
|
|
|||
|
|
|||
|
<!-- Highlight.js Stylesheets -->
|
|||
|
<link rel="stylesheet" href="highlight.css">
|
|||
|
<link rel="stylesheet" href="tomorrow-night.css">
|
|||
|
<link rel="stylesheet" href="ayu-highlight.css">
|
|||
|
|
|||
|
<!-- Custom theme stylesheets -->
|
|||
|
|
|||
|
|
|||
|
|
|||
|
</head>
|
|||
|
<body>
|
|||
|
<!-- Provide site root to javascript -->
|
|||
|
<script type="text/javascript">
|
|||
|
var path_to_root = "";
|
|||
|
var default_theme = window.matchMedia("(prefers-color-scheme: dark)").matches ? "navy" : "light";
|
|||
|
</script>
|
|||
|
|
|||
|
<!-- Work around some values being stored in localStorage wrapped in quotes -->
|
|||
|
<script type="text/javascript">
|
|||
|
try {
|
|||
|
var theme = localStorage.getItem('mdbook-theme');
|
|||
|
var sidebar = localStorage.getItem('mdbook-sidebar');
|
|||
|
|
|||
|
if (theme.startsWith('"') && theme.endsWith('"')) {
|
|||
|
localStorage.setItem('mdbook-theme', theme.slice(1, theme.length - 1));
|
|||
|
}
|
|||
|
|
|||
|
if (sidebar.startsWith('"') && sidebar.endsWith('"')) {
|
|||
|
localStorage.setItem('mdbook-sidebar', sidebar.slice(1, sidebar.length - 1));
|
|||
|
}
|
|||
|
} catch (e) { }
|
|||
|
</script>
|
|||
|
|
|||
|
<!-- Set the theme before any content is loaded, prevents flash -->
|
|||
|
<script type="text/javascript">
|
|||
|
var theme;
|
|||
|
try { theme = localStorage.getItem('mdbook-theme'); } catch(e) { }
|
|||
|
if (theme === null || theme === undefined) { theme = default_theme; }
|
|||
|
var html = document.querySelector('html');
|
|||
|
html.classList.remove('no-js')
|
|||
|
html.classList.remove('light')
|
|||
|
html.classList.add(theme);
|
|||
|
html.classList.add('js');
|
|||
|
</script>
|
|||
|
|
|||
|
<!-- Hide / unhide sidebar before it is displayed -->
|
|||
|
<script type="text/javascript">
|
|||
|
var html = document.querySelector('html');
|
|||
|
var sidebar = 'hidden';
|
|||
|
if (document.body.clientWidth >= 1080) {
|
|||
|
try { sidebar = localStorage.getItem('mdbook-sidebar'); } catch(e) { }
|
|||
|
sidebar = sidebar || 'visible';
|
|||
|
}
|
|||
|
html.classList.remove('sidebar-visible');
|
|||
|
html.classList.add("sidebar-" + sidebar);
|
|||
|
</script>
|
|||
|
|
|||
|
<nav id="sidebar" class="sidebar" aria-label="Table of contents">
|
|||
|
<div class="sidebar-scrollbox">
|
|||
|
<ol class="chapter"><li class="chapter-item expanded "><a href="The-Z-Shell-Manual.html"><strong aria-hidden="true">1.</strong> The Z Shell Manual</a></li><li class="chapter-item expanded "><a href="Introduction.html"><strong aria-hidden="true">2.</strong> Introduction</a></li><li class="chapter-item expanded "><a href="Roadmap.html"><strong aria-hidden="true">3.</strong> Roadmap</a></li><li class="chapter-item expanded "><a href="Invocation.html"><strong aria-hidden="true">4.</strong> Invocation</a></li><li class="chapter-item expanded "><a href="Files.html"><strong aria-hidden="true">5.</strong> Files</a></li><li class="chapter-item expanded "><a href="Shell-Grammar.html"><strong aria-hidden="true">6.</strong> Shell Grammar</a></li><li class="chapter-item expanded "><a href="Redirection.html"><strong aria-hidden="true">7.</strong> Redirection</a></li><li class="chapter-item expanded "><a href="Command-Execution.html"><strong aria-hidden="true">8.</strong> Command Execution</a></li><li class="chapter-item expanded "><a href="Functions.html"><strong aria-hidden="true">9.</strong> Functions</a></li><li class="chapter-item expanded "><a href="Jobs-_0026-Signals.html"><strong aria-hidden="true">10.</strong> Jobs & Signals</a></li><li class="chapter-item expanded "><a href="Arithmetic-Evaluation.html"><strong aria-hidden="true">11.</strong> Arithmetic Evaluation</a></li><li class="chapter-item expanded "><a href="Conditional-Expressions.html"><strong aria-hidden="true">12.</strong> Conditional Expressions</a></li><li class="chapter-item expanded "><a href="Prompt-Expansion.html"><strong aria-hidden="true">13.</strong> Prompt Expansion</a></li><li class="chapter-item expanded "><a href="Expansion.html"><strong aria-hidden="true">14.</strong> Expansion</a></li><li class="chapter-item expanded "><a href="Parameters.html"><strong aria-hidden="true">15.</strong> Parameters</a></li><li class="chapter-item expanded "><a href="Options.html"><strong aria-hidden="true">16.</strong> Options</a></li><li class="chapter-item expanded "><a href="Shell-Builtin-Commands.html" class="active"><strong aria-hidden="true">17.</strong> Shell Builtin Commands</a></li><li class="chapter-item expanded "><a href="Zsh-Line-Editor.html"><strong aria-hidden="true">18.</strong> Zsh Line Editor</a></li><li class="chapter-item expanded "><a href="Completion-Widgets.html"><strong aria-hidden="true">19.</strong> Completion Widgets</a></li><li class="chapter-item expanded "><a href="Completion-System.html"><strong aria-hidden="true">20.</strong> Completion System</a></li><li class="chapter-item expanded "><a href="Completion-Using-compctl.html"><strong aria-hidden="true">21.</strong> Completion Using compctl</a></li><li class="chapter-item expanded "><a href="Zsh-Modules.html"><strong aria-hidden="true">22.</strong> Zsh Modules</a></li><li class="chapter-item expanded "><a href="Calendar-Function-System.html"><strong aria-hidden="true">23.</strong> Calendar Function System</a></li><li class="chapter-item expanded "><a href="TCP-Function-System.html"><strong aria-hidden="true">24.</strong> TCP Function System</a></li><li class="chapter-item expanded "><a href="Zftp-Function-System.html"><strong aria-hidden="true">25.</strong> Zftp Function System</a></li><li class="chapter-item expanded "><a href="User-Contributions.html"><strong aria-hidden="true">26.</strong> User Contributions</a></li></ol>
|
|||
|
</div>
|
|||
|
<div id="sidebar-resize-handle" class="sidebar-resize-handle"></div>
|
|||
|
</nav>
|
|||
|
|
|||
|
<div id="page-wrapper" class="page-wrapper">
|
|||
|
|
|||
|
<div class="page">
|
|||
|
|
|||
|
<div id="menu-bar-hover-placeholder"></div>
|
|||
|
<div id="menu-bar" class="menu-bar sticky bordered">
|
|||
|
<div class="left-buttons">
|
|||
|
<button id="sidebar-toggle" class="icon-button" type="button" title="Toggle Table of Contents" aria-label="Toggle Table of Contents" aria-controls="sidebar">
|
|||
|
<i class="fa fa-bars"></i>
|
|||
|
</button>
|
|||
|
<button id="theme-toggle" class="icon-button" type="button" title="Change theme" aria-label="Change theme" aria-haspopup="true" aria-expanded="false" aria-controls="theme-list">
|
|||
|
<i class="fa fa-paint-brush"></i>
|
|||
|
</button>
|
|||
|
<ul id="theme-list" class="theme-popup" aria-label="Themes" role="menu">
|
|||
|
<li role="none"><button role="menuitem" class="theme" id="light">Light (default)</button></li>
|
|||
|
<li role="none"><button role="menuitem" class="theme" id="rust">Rust</button></li>
|
|||
|
<li role="none"><button role="menuitem" class="theme" id="coal">Coal</button></li>
|
|||
|
<li role="none"><button role="menuitem" class="theme" id="navy">Navy</button></li>
|
|||
|
<li role="none"><button role="menuitem" class="theme" id="ayu">Ayu</button></li>
|
|||
|
</ul>
|
|||
|
|
|||
|
<button id="search-toggle" class="icon-button" type="button" title="Search. (Shortkey: s)" aria-label="Toggle Searchbar" aria-expanded="false" aria-keyshortcuts="S" aria-controls="searchbar">
|
|||
|
<i class="fa fa-search"></i>
|
|||
|
</button>
|
|||
|
|
|||
|
</div>
|
|||
|
|
|||
|
<h1 class="menu-title">Zsh Manual</h1>
|
|||
|
|
|||
|
<div class="right-buttons">
|
|||
|
|
|||
|
<a href="print.html" title="Print this book" aria-label="Print this book">
|
|||
|
<i id="print-button" class="fa fa-print"></i>
|
|||
|
</a>
|
|||
|
|
|||
|
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
|
|||
|
|
|||
|
<div id="search-wrapper" class="hidden">
|
|||
|
<form id="searchbar-outer" class="searchbar-outer">
|
|||
|
<input type="search" name="search" id="searchbar" name="searchbar" placeholder="Search this book ..." aria-controls="searchresults-outer" aria-describedby="searchresults-header">
|
|||
|
</form>
|
|||
|
<div id="searchresults-outer" class="searchresults-outer hidden">
|
|||
|
<div id="searchresults-header" class="searchresults-header"></div>
|
|||
|
<ul id="searchresults">
|
|||
|
</ul>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
|
|||
|
|
|||
|
<!-- Apply ARIA attributes after the sidebar and the sidebar toggle button are added to the DOM -->
|
|||
|
<script type="text/javascript">
|
|||
|
document.getElementById('sidebar-toggle').setAttribute('aria-expanded', sidebar === 'visible');
|
|||
|
document.getElementById('sidebar').setAttribute('aria-hidden', sidebar !== 'visible');
|
|||
|
Array.from(document.querySelectorAll('#sidebar a')).forEach(function(link) {
|
|||
|
link.setAttribute('tabIndex', sidebar === 'visible' ? 0 : -1);
|
|||
|
});
|
|||
|
</script>
|
|||
|
|
|||
|
<div id="content" class="content">
|
|||
|
<main>
|
|||
|
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
|
|||
|
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
|
|||
|
<p><strong>Table of Contents</strong> <em>generated with <a href="https://github.com/thlorenz/doctoc">DocToc</a></em></p>
|
|||
|
<ul>
|
|||
|
<li><a href="#17-shell-builtin-commands">17 Shell Builtin Commands</a></li>
|
|||
|
</ul>
|
|||
|
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
|||
|
<p><span id="Shell-Builtin-Commands"></span>
|
|||
|
<span id="Shell-Builtin-Commands-1"></span></p>
|
|||
|
<h1 id="17-shell-builtin-commands"><a class="header" href="#17-shell-builtin-commands">17 Shell Builtin Commands</a></h1>
|
|||
|
<p><span id="index-builtin-commands"></span>
|
|||
|
<span id="index-commands_002c-builtin"></span></p>
|
|||
|
<p>Some shell builtin commands take options as described in individual
|
|||
|
entries; these are often referred to in the list below as ‘<code>flags</code>’ to
|
|||
|
avoid confusion with shell options, which may also have an effect on the
|
|||
|
behaviour of builtin commands. In this introductory section, ‘<code>option</code>’
|
|||
|
always has the meaning of an option to a command that should be familiar
|
|||
|
to most command line users.</p>
|
|||
|
<p>Typically, options are single letters preceded by a hyphen (<code>-</code>).
|
|||
|
Options that take an argument accept it either immediately following the
|
|||
|
option letter or after white space, for example ‘<code>print -C3 {1..9}</code>’ or
|
|||
|
‘<code>print -C 3 {1..9}</code>’ are equivalent. Arguments to options are not the
|
|||
|
same as arguments to the command; the documentation indicates which is
|
|||
|
which. Options that do not take an argument may be combined in a single
|
|||
|
word, for example ‘<code>print -rca – *</code>’ and ‘<code>print -r -c -a – *</code>’ are
|
|||
|
equivalent.</p>
|
|||
|
<p>Some shell builtin commands also take options that begin with ‘<code>+</code>’
|
|||
|
instead of ‘<code>-</code>’. The list below makes clear which commands these are.</p>
|
|||
|
<p>Options (together with their individual arguments, if any) must appear
|
|||
|
in a group before any non-option arguments; once the first non-option
|
|||
|
argument has been found, option processing is terminated.</p>
|
|||
|
<p>All builtin commands other than ‘<code>echo</code>’ and precommand modifiers, even
|
|||
|
those that have no options, can be given the argument ‘<code>-``-</code>’ to
|
|||
|
terminate option processing. This indicates that the following words are
|
|||
|
non-option arguments, but is otherwise ignored. This is useful in cases
|
|||
|
where arguments to the command may begin with ‘<code>-</code>’. For historical
|
|||
|
reasons, most builtin commands (including ‘<code>echo</code>’) also recognize a
|
|||
|
single ‘<code>-</code>’ in a separate word for this purpose; note that this is less
|
|||
|
standard and use of ‘<code>-``-</code>’ is recommended.</p>
|
|||
|
<ul>
|
|||
|
<li>
|
|||
|
<p><code>-</code> <code>simple command</code><br />
|
|||
|
See <a href="Shell-Grammar.html#Precommand-Modifiers">Precommand Modifiers</a>.</p>
|
|||
|
<p><span id="index-_002e"></span></p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>.</code> <code>file</code> [ <code>arg</code> ... ]<br />
|
|||
|
Read commands from <code>file</code> and execute them in the current shell
|
|||
|
environment.</p>
|
|||
|
<p>If <code>file</code> does not contain a slash, or if <code>PATH_DIRS</code> is set, the
|
|||
|
shell looks in the components of <code>$path</code> to find the directory
|
|||
|
containing <code>file</code>. Files in the current directory are not read
|
|||
|
unless ‘<code>.</code>’ appears somewhere in <code>$path</code>. If a file named
|
|||
|
‘<code>file``.zwc</code>’ is found, is newer than <code>file</code>, and is the compiled
|
|||
|
form (created with the <code>zcompile</code> builtin) of <code>file</code>, then commands
|
|||
|
are read from that file instead of <code>file</code>.</p>
|
|||
|
<p>If any arguments <code>arg</code> are given, they become the positional
|
|||
|
parameters; the old positional parameters are restored when the
|
|||
|
<code>file</code> is done executing. However, if no arguments are given, the
|
|||
|
positional parameters remain those of the calling context, and no
|
|||
|
restoring is done.</p>
|
|||
|
<p>If <code>file</code> was not found the return status is 127; if <code>file</code> was
|
|||
|
found but contained a syntax error the return status is 126; else
|
|||
|
the return status is the exit status of the last command executed.</p>
|
|||
|
<p><span id="index-_003a"></span>
|
|||
|
<span id="index-expanding-parameters"></span>
|
|||
|
<span id="index-parameters_002c-expanding"></span>
|
|||
|
<span id="index-doing-nothing"></span></p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>:</code> [ <code>arg</code> ... ]<br />
|
|||
|
This command does nothing, although normal argument expansions is
|
|||
|
performed which may have effects on shell parameters. A zero exit
|
|||
|
status is returned.</p>
|
|||
|
<p><span id="index-alias"></span>
|
|||
|
<span id="index-aliases_002c-defining"></span>
|
|||
|
<span id="index-aliases_002c-listing"></span></p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>alias</code> [ {<code>+</code>|<code>-</code>}<code>gmrsL</code> ] [ <code>name</code>[<code>=``value</code>] ... ]<br />
|
|||
|
For each <code>name</code> with a corresponding <code>value</code>, define an alias with
|
|||
|
that value. A trailing space in <code>value</code> causes the next word to be
|
|||
|
checked for alias expansion. If the <code>-g</code> flag is present, define a
|
|||
|
global alias; global aliases are expanded even if they do not occur
|
|||
|
in command position.</p>
|
|||
|
<p>If the <code>-s</code> flag is present, define a suffix alias: if the command
|
|||
|
word on a command line is in the form ‘<code>text``.``name</code>’, where
|
|||
|
<code>text</code> is any non-empty string, it is replaced by the text ‘<code>value</code>
|
|||
|
<code>text``.``name</code>’. Note that <code>name</code> is treated as a literal string,
|
|||
|
not a pattern. A trailing space in <code>value</code> is not special in this
|
|||
|
case. For example,</p>
|
|||
|
<div class="example">
|
|||
|
<pre><code class="language-example">alias -s ps='gv --'
|
|||
|
</code></pre>
|
|||
|
</div>
|
|||
|
<p>will cause the command ‘<code>*.ps</code>’ to be expanded to ‘<code>gv – *.ps</code>’. As
|
|||
|
alias expansion is carried out earlier than globbing, the ‘<code>*.ps</code>’
|
|||
|
will then be expanded. Suffix aliases constitute a different name
|
|||
|
space from other aliases (so in the above example it is still
|
|||
|
possible to create an alias for the command <code>ps</code>) and the two sets
|
|||
|
are never listed together.</p>
|
|||
|
<p>For each <code>name</code> with no <code>value</code>, print the value of <code>name</code>, if any.
|
|||
|
With no arguments, print all currently defined aliases other than
|
|||
|
suffix aliases. If the <code>-m</code> flag is given the arguments are taken as
|
|||
|
patterns (they should be quoted to preserve them from being
|
|||
|
interpreted as glob patterns), and the aliases matching these
|
|||
|
patterns are printed. When printing aliases and one of the <code>-g</code>,
|
|||
|
<code>-r</code> or <code>-s</code> flags is present, restrict the printing to global,
|
|||
|
regular or suffix aliases, respectively; a regular alias is one
|
|||
|
which is neither a global nor a suffix alias. Using ‘<code>+</code>’ instead of
|
|||
|
‘<code>-</code>’, or ending the option list with a single ‘<code>+</code>’, prevents the
|
|||
|
values of the aliases from being printed.</p>
|
|||
|
<p>If the <code>-L</code> flag is present, then print each status is nonzero if a
|
|||
|
<code>name</code> (with no <code>value</code>) is given for which no alias has been
|
|||
|
defined.</p>
|
|||
|
<p>For more on aliases, include common problems, see
|
|||
|
<a href="Shell-Grammar.html#Aliasing">Aliasing</a>.</p>
|
|||
|
<p><span id="index-autoload"></span>
|
|||
|
<span id="index-functions_002c-autoloading-1"></span>
|
|||
|
<span id="index-autoloading-functions-1"></span></p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>autoload</code> [ {<code>+</code>|<code>-</code>}<code>RTUXdkmrtWz</code> ] [ <code>-w</code> ] [ <code>name</code> ...
|
|||
|
]<br />
|
|||
|
<span id="index-fpath_002c-searching"></span></p>
|
|||
|
<p>See the section ‘Autoloading Functions’ in
|
|||
|
<a href="Functions.html#Functions">Functions</a> for full details. The <code>fpath</code>
|
|||
|
parameter will be searched to find the function definition when the
|
|||
|
function is first referenced.</p>
|
|||
|
<p>If <code>name</code> consists of an absolute path, the function is defined to
|
|||
|
load from the file given (searching as usual for dump files in the
|
|||
|
given location). The name of the function is the basename
|
|||
|
(non-directory part) of the file. It is normally an error if the
|
|||
|
function is not found in the given location; however, if the option
|
|||
|
<code>-d</code> is given, searching for the function defaults to <code>$fpath</code>. If a
|
|||
|
function is loaded by absolute path, any functions loaded from it
|
|||
|
that are marked for <code>autoload</code> without an absolute path have the
|
|||
|
load path of the parent function temporarily prepended to <code>$fpath</code>.</p>
|
|||
|
<p>If the option <code>-r</code> or <code>-R</code> is given, the function is searched for
|
|||
|
immediately and the location is recorded internally for use when the
|
|||
|
function is executed; a relative path is expanded using the value of
|
|||
|
<code>$PWD</code>. This protects against a change to <code>$fpath</code> after the call to
|
|||
|
<code>autoload</code>. With <code>-r</code>, if the function is not found, it is silently
|
|||
|
left unresolved until execution; with <code>-R</code>, an error message is
|
|||
|
printed and command processing aborted immediately the search fails,
|
|||
|
i.e. at the <code>autoload</code> command rather than at function execution..</p>
|
|||
|
<p>The flag <code>-X</code> may be used only inside a shell function. It causes
|
|||
|
the calling function to be marked for autoloading and then
|
|||
|
immediately loaded and executed, with the current array of
|
|||
|
positional parameters as arguments. This replaces the previous
|
|||
|
definition of the function. If no function definition is found, an
|
|||
|
error is printed and the function remains undefined and marked for
|
|||
|
autoloading. If an argument is given, it is used as a directory
|
|||
|
(i.e. it does not include the name of the function) in which the
|
|||
|
function is to be found; this may be combined with the <code>-d</code> option
|
|||
|
to allow the function search to default to <code>$fpath</code> if it is not in
|
|||
|
the given location.</p>
|
|||
|
<p>The flag <code>+X</code> attempts to load each <code>name</code> as an autoloaded
|
|||
|
function, but does <em>not</em> execute it. The exit status is zero
|
|||
|
(success) if the function was not previously defined <em>and</em> a
|
|||
|
definition for it was found. This does <em>not</em> replace any existing
|
|||
|
definition of the function. The exit status is nonzero (failure) if
|
|||
|
the function was already defined or when no definition was found. In
|
|||
|
the latter case the function remains undefined and marked for
|
|||
|
autoloading. If ksh-style autoloading is enabled, the function
|
|||
|
created will contain the contents of the file plus a call to the
|
|||
|
function itself appended to it, thus giving normal ksh autoloading
|
|||
|
behaviour on the first call to the function. If the <code>-m</code> flag is
|
|||
|
also given each <code>name</code> is treated as a pattern and all functions
|
|||
|
already marked for autoload that match the pattern are loaded.</p>
|
|||
|
<p>With the <code>-t</code> flag, turn on execution tracing; with <code>-T</code>, turn on
|
|||
|
execution tracing only for the current function, turning it off on
|
|||
|
entry to any called functions that do not also have tracing enabled.</p>
|
|||
|
<p>With the <code>-U</code> flag, alias expansion is suppressed when the function
|
|||
|
is loaded.</p>
|
|||
|
<p>With the <code>-w</code> flag, the <code>name</code>s are taken as names of files compiled
|
|||
|
with the <code>zcompile</code> builtin, and all functions defined in them are
|
|||
|
marked for autoloading.</p>
|
|||
|
<p>The flags <code>-z</code> and <code>-k</code> mark the function to be autoloaded using the
|
|||
|
zsh or ksh style, as if the option <code>KSH_AUTOLOAD</code> were unset or were
|
|||
|
set, respectively. The flags override the setting of the option at
|
|||
|
the time the function is loaded.</p>
|
|||
|
<p>Note that the <code>autoload</code> command makes no attempt to ensure the
|
|||
|
shell options set during the loading or execution of the file have
|
|||
|
any particular value. For this, the <code>emulate</code> command can be used:</p>
|
|||
|
<div class="example">
|
|||
|
<pre><code class="language-example">emulate zsh -c 'autoload -Uz func'
|
|||
|
</code></pre>
|
|||
|
</div>
|
|||
|
<p>arranges that when <code>func</code> is loaded the shell is in native <code>zsh</code>
|
|||
|
emulation, and this emulation is also applied when <code>func</code> is run.</p>
|
|||
|
<p>Some of the functions of <code>autoload</code> are also provided by <code>functions -u</code> or <code>functions -U</code>, but <code>autoload</code> is a more comprehensive
|
|||
|
interface.</p>
|
|||
|
<p><span id="index-bg"></span>
|
|||
|
<span id="index-jobs_002c-backgrounding"></span></p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>bg</code> [ <code>job</code> ... ]<br />
|
|||
|
<code>job</code> ... <code>&</code><br />
|
|||
|
Put each specified <code>job</code> in the background, or the current job if
|
|||
|
none is specified.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>bindkey</code><br />
|
|||
|
See <a href="Zsh-Line-Editor.html#Zle-Builtins">Zle Builtins</a>.</p>
|
|||
|
<p><span id="index-break"></span>
|
|||
|
<span id="index-exiting-loops"></span>
|
|||
|
<span id="index-loops_002c-exiting"></span></p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>break</code> [ <code>n</code> ]<br />
|
|||
|
Exit from an enclosing <code>for</code>, <code>while</code>, <code>until</code>, <code>select</code> or <code>repeat</code>
|
|||
|
loop. If an arithmetic expression <code>n</code> is specified, then break <code>n</code>
|
|||
|
levels instead of just one.</p>
|
|||
|
<p><span id="index-builtin-1"></span></p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>builtin</code> <code>name</code> [ <code>args</code> ... ]<br />
|
|||
|
Executes the builtin <code>name</code>, with the given <code>args</code>.</p>
|
|||
|
<p><span id="index-bye"></span></p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>bye</code><br />
|
|||
|
Same as <code>exit</code>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>cap</code><br />
|
|||
|
See <a href="Zsh-Modules.html#The-zsh_002fcap-Module">The zsh/cap Module</a>.</p>
|
|||
|
<p><span id="index-cd"></span>
|
|||
|
<span id="index-directories_002c-changing"></span></p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>cd</code> [ <code>-qsLP</code> ] [ <code>arg</code> ]<br />
|
|||
|
<code>cd</code> [ <code>-qsLP</code> ] <code>old</code> <code>new</code><br />
|
|||
|
<code>cd</code> [ <code>-qsLP</code> ] {<code>+</code>|<code>-</code>}<code>n</code><br />
|
|||
|
Change the current directory. In the first form, change the current
|
|||
|
directory to <code>arg</code>, or to the value of <code>$HOME</code> if <code>arg</code> is not
|
|||
|
specified. If <code>arg</code> is ‘<code>-</code>’, change to the previous directory.</p>
|
|||
|
<p>Otherwise, if <code>arg</code> begins with a slash, attempt to change to the
|
|||
|
directory given by <code>arg</code>.</p>
|
|||
|
<p>If <code>arg</code> does not begin with a slash, the behaviour depends on
|
|||
|
whether the current directory ‘<code>.</code>’ occurs in the list of
|
|||
|
directories contained in the shell parameter <code>cdpath</code>. If it does
|
|||
|
not, first attempt to change to the directory <code>arg</code> under the
|
|||
|
current directory, and if that fails but <code>cdpath</code> is set and
|
|||
|
contains at least one element attempt to change to the directory
|
|||
|
<code>arg</code> under each component of <code>cdpath</code> in turn until successful. If
|
|||
|
‘<code>.</code>’ occurs in <code>cdpath</code>, then <code>cdpath</code> is searched strictly in
|
|||
|
order so that ‘<code>.</code>’ is only tried at the appropriate point.</p>
|
|||
|
<p>The order of testing <code>cdpath</code> is modified if the option <code>POSIX_CD</code>
|
|||
|
is set, as described in the documentation for the option.</p>
|
|||
|
<p>If no directory is found, the option <code>CDABLE_VARS</code> is set, and a
|
|||
|
parameter named <code>arg</code> exists whose value begins with a slash, treat
|
|||
|
its value as the directory. In that case, the parameter is added to
|
|||
|
the named</p>
|
|||
|
<p>The second form of <code>cd</code> substitutes the string <code>new</code> for the string
|
|||
|
<code>old</code> in the name of the current directory, and tries to change to
|
|||
|
this new directory.</p>
|
|||
|
<p>The third form of <code>cd</code> extracts an entry from the directory stack,
|
|||
|
and changes to that directory. An argument of the form ‘<code>+``n</code>’
|
|||
|
identifies a stack entry by counting from the left of the list shown
|
|||
|
by the <code>dirs</code> command, starting with zero. An argument of the form
|
|||
|
‘<code>-``n</code>’ counts from the right. If the <code>PUSHD_MINUS</code> option is
|
|||
|
set, the meanings of ‘<code>+</code>’ and ‘<code>-</code>’ in this context are swapped. If
|
|||
|
the <code>POSIX_CD</code> option is set, this form of <code>cd</code> is not recognised
|
|||
|
and will be interpreted as the first form.</p>
|
|||
|
<p>If the <code>-q</code> (quiet) option is specified, the hook function <code>chpwd</code>
|
|||
|
and the functions in the array <code>chpwd_functions</code> are not called.
|
|||
|
This is useful for calls to <code>cd</code> that do not change the environment
|
|||
|
seen by an interactive user.</p>
|
|||
|
<p>If the <code>-s</code> option is specified, <code>cd</code> refuses to change the current
|
|||
|
directory if the given pathname contains symlinks. If the <code>-P</code>
|
|||
|
option is given or the <code>CHASE_LINKS</code> option is set, symbolic links
|
|||
|
are resolved to their true values. If the <code>-L</code> option is given
|
|||
|
symbolic links are retained in the directory (and not resolved)
|
|||
|
regardless of the state of the <code>CHASE_LINKS</code> option.</p>
|
|||
|
<p><span id="index-chdir"></span></p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>chdir</code><br />
|
|||
|
Same as <code>cd</code>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>clone</code><br />
|
|||
|
See <a href="Zsh-Modules.html#The-zsh_002fclone-Module">The zsh/clone
|
|||
|
Module</a>.</p>
|
|||
|
<p><span id="index-command-1"></span></p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>command</code> [ <code>-pvV</code> ] <code>simple command</code><br />
|
|||
|
The simple command argument is taken as an external command instead
|
|||
|
of a function or builtin and is executed. If the <code>POSIX_BUILTINS</code>
|
|||
|
option is set, builtins will also be executed but certain special
|
|||
|
properties of them are suppressed. The <code>-p</code> flag causes a default
|
|||
|
path to be searched instead of that in <code>$path</code>. With the <code>-v</code> flag,
|
|||
|
<code>command</code> is similar to <code>whence</code> and with <code>-V</code>, it is equivalent to
|
|||
|
<code>whence -v</code>.</p>
|
|||
|
<p>See also <a href="Shell-Grammar.html#Precommand-Modifiers">Precommand
|
|||
|
Modifiers</a>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>comparguments</code><br />
|
|||
|
See <a href="Zsh-Modules.html#The-zsh_002fcomputil-Module">The zsh/computil
|
|||
|
Module</a>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>compcall</code><br />
|
|||
|
See <a href="Zsh-Modules.html#The-zsh_002fcompctl-Module">The zsh/compctl
|
|||
|
Module</a>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>compctl</code><br />
|
|||
|
See <a href="Zsh-Modules.html#The-zsh_002fcompctl-Module">The zsh/compctl
|
|||
|
Module</a>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>compdescribe</code><br />
|
|||
|
See <a href="Zsh-Modules.html#The-zsh_002fcomputil-Module">The zsh/computil
|
|||
|
Module</a>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>compfiles</code><br />
|
|||
|
See <a href="Zsh-Modules.html#The-zsh_002fcomputil-Module">The zsh/computil
|
|||
|
Module</a>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>compgroups</code><br />
|
|||
|
See <a href="Zsh-Modules.html#The-zsh_002fcomputil-Module">The zsh/computil
|
|||
|
Module</a>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>compquote</code><br />
|
|||
|
See <a href="Zsh-Modules.html#The-zsh_002fcomputil-Module">The zsh/computil
|
|||
|
Module</a>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>comptags</code><br />
|
|||
|
See <a href="Zsh-Modules.html#The-zsh_002fcomputil-Module">The zsh/computil
|
|||
|
Module</a>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>comptry</code><br />
|
|||
|
See <a href="Zsh-Modules.html#The-zsh_002fcomputil-Module">The zsh/computil
|
|||
|
Module</a>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>compvalues</code><br />
|
|||
|
See <a href="Zsh-Modules.html#The-zsh_002fcomputil-Module">The zsh/computil
|
|||
|
Module</a>.</p>
|
|||
|
<p><span id="index-continue"></span>
|
|||
|
<span id="index-loops_002c-continuing"></span>
|
|||
|
<span id="index-continuing-loops"></span></p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>continue</code> [ <code>n</code> ]<br />
|
|||
|
Resume the next iteration of the enclosing <code>for</code>, <code>while</code>, <code>until</code>,
|
|||
|
<code>select</code> or <code>repeat</code> loop. If an arithmetic expression <code>n</code> is
|
|||
|
specified, break out of <code>n</code>-1 loops and resume at the <code>n</code>th
|
|||
|
enclosing loop.</p>
|
|||
|
<p><span id="index-declare"></span></p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>declare</code><br />
|
|||
|
Same as <code>typeset</code>.</p>
|
|||
|
<p><span id="index-dirs"></span>
|
|||
|
<span id="index-directory-stack_002c-printing"></span></p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>dirs</code> [ <code>-c</code> ] [ <code>arg</code> ... ]<br />
|
|||
|
<code>dirs</code> [ <code>-lpv</code> ]<br />
|
|||
|
With no arguments, print the contents of the directory stack.
|
|||
|
Directories are added to this stack with the <code>pushd</code> command, and
|
|||
|
removed with the <code>cd</code> or <code>popd</code> commands. If arguments are
|
|||
|
specified, load them onto the directory stack, replacing anything
|
|||
|
that was there, and push the current directory onto the stack.</p>
|
|||
|
<ul>
|
|||
|
<li>
|
|||
|
<p><code>-c</code><br />
|
|||
|
clear the directory stack.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-l</code><br />
|
|||
|
print directory names in full instead of using of using <code>~</code>
|
|||
|
expressions (<a href="Expansion.html#Filename-Expansion">Filename
|
|||
|
Expansion</a>).</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-p</code><br />
|
|||
|
print directory entries one per line.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-v</code><br />
|
|||
|
number the directories in the stack when printing.</p>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
<p><span id="index-disable"></span>
|
|||
|
<span id="index-disabling-commands"></span>
|
|||
|
<span id="index-commands_002c-disabling"></span></p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>disable</code> [ <code>-afmprs</code> ] <code>name</code> ...<br />
|
|||
|
<code>’?’</code><br />
|
|||
|
The pattern character <code>?</code> wherever it occurs, including when
|
|||
|
preceding a parenthesis with <code>KSH_GLOB</code>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>’*’</code><br />
|
|||
|
The pattern character <code>*</code> wherever it occurs, including recursive
|
|||
|
globbing and when preceding a parenthesis with <code>KSH_GLOB</code>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>’[’</code><br />
|
|||
|
Character classes.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>’<’</code> (<code>NO_SH_GLOB</code>)<br />
|
|||
|
Numeric ranges.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>’|’</code> (<code>NO_SH_GLOB</code>)<br />
|
|||
|
Alternation in grouped patterns, case statements, or KSH_GLOB
|
|||
|
parenthesised expressions.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>’(’</code> (<code>NO_SH_GLOB</code>)<br />
|
|||
|
Grouping using single parentheses. Disabling this does not disable
|
|||
|
the use of parentheses for <code>KSH_GLOB</code> where they are introduced by a
|
|||
|
special character, nor for glob qualifiers (use ‘<code>setopt NO_BARE_GLOB_QUAL</code>’ to disable glob qualifiers that use parentheses
|
|||
|
only).</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>’~’</code> (<code>EXTENDED_GLOB</code>)<br />
|
|||
|
Exclusion in the form <code>A``~``B</code>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>’^’</code> (<code>EXTENDED_GLOB</code>)<br />
|
|||
|
Exclusion in the form <code>A``^``B</code>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>’#’</code> (<code>EXTENDED_GLOB</code>)<br />
|
|||
|
The pattern character <code>#</code> wherever it occurs, both for repetition of
|
|||
|
a previous pattern and for indicating globbing flags.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>’?(’</code> (<code>KSH_GLOB</code>)<br />
|
|||
|
The grouping form <code>?(``...``)</code>. Note this is also disabled if <code>’?’</code>
|
|||
|
is disabled.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>’*(’</code> (<code>KSH_GLOB</code>)<br />
|
|||
|
The grouping form <code>*(``...``)</code>. Note this is also disabled if <code>’*’</code>
|
|||
|
is disabled.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>’+(’</code> (<code>KSH_GLOB</code>)<br />
|
|||
|
The grouping form <code>+(``...``)</code>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>’!(’</code> (<code>KSH_GLOB</code>)<br />
|
|||
|
The grouping form <code>!(``...``)</code>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>’@(’</code> (<code>KSH_GLOB</code>)<br />
|
|||
|
The grouping form <code>@(``...``)</code>.</p>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
<p><span id="index-disown"></span>
|
|||
|
<span id="index-jobs_002c-disowning-1"></span></p>
|
|||
|
<p><code>disown</code> [ <code>job</code> ... ]</p>
|
|||
|
<p><code>job</code> ... <code>&|</code></p>
|
|||
|
<p><code>job</code> ... <code>&!</code></p>
|
|||
|
<p>no longer report their status, and will not complain if you try to exit
|
|||
|
an interactive shell with them running or stopped. If no <code>job</code> is
|
|||
|
specified, disown the current job.</p>
|
|||
|
<p>If the <code>job</code>s are currently stopped and the <code>AUTO_CONTINUE</code> option is
|
|||
|
not set, a warning is printed containing information about how to make
|
|||
|
them running after they have been disowned. If one of the latter two
|
|||
|
forms is used, the <code>job</code>s will automatically be made running,
|
|||
|
independent of the setting of the <code>AUTO_CONTINUE</code> option.</p>
|
|||
|
<p><span id="index-echo"></span></p>
|
|||
|
<p><code>echo</code> [ <code>-neE</code> ] [ <code>arg</code> ... ]</p>
|
|||
|
<p>Write each <code>arg</code> on the standard output, with a space separating each
|
|||
|
one. If the <code>-n</code> flag is not present, print a newline at the end. <code>echo</code>
|
|||
|
recognizes the following escape sequences:</p>
|
|||
|
<ul>
|
|||
|
<li>
|
|||
|
<p><code>\a</code><br />
|
|||
|
bell character</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>\b</code><br />
|
|||
|
backspace</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>\c</code><br />
|
|||
|
suppress subsequent characters and final newline</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>\e</code><br />
|
|||
|
escape</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>\f</code><br />
|
|||
|
form feed</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>\n</code><br />
|
|||
|
linefeed (newline)</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>\r</code><br />
|
|||
|
carriage return</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>\t</code><br />
|
|||
|
horizontal tab</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>\v</code><br />
|
|||
|
vertical tab</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>\\</code><br />
|
|||
|
backslash</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>\0``NNN</code><br />
|
|||
|
character code in octal</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>\x``NN</code><br />
|
|||
|
character code in hexadecimal</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>\u``NNNN</code><br />
|
|||
|
unicode character code in hexadecimal</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>\U``NNNNNNNN</code><br />
|
|||
|
unicode character code in hexadecimal</p>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
<p><span id="index-BSD_005fECHO_002c-use-of"></span></p>
|
|||
|
<p>The <code>-E</code> flag, or the <code>BSD_ECHO</code> option, can be used to disable these
|
|||
|
escape sequences. In the latter case, <code>-e</code> flag can be used to enable
|
|||
|
them.</p>
|
|||
|
<p>Note that for standards compliance a double dash does not terminate
|
|||
|
option processing; instead, it is printed directly. However, a single
|
|||
|
dash does terminate option processing, so the first dash, possibly
|
|||
|
following options, is not printed, but everything following it is
|
|||
|
printed as an argument. The single dash behaviour is different <code>printf</code>,
|
|||
|
and for a more controllable way of printing text within zsh, see
|
|||
|
<code>print</code>.</p>
|
|||
|
<p><code>echotc</code></p>
|
|||
|
<p>See <a href="Zsh-Modules.html#The-zsh_002ftermcap-Module">The zsh/termcap
|
|||
|
Module</a>.</p>
|
|||
|
<p><code>echoti</code></p>
|
|||
|
<p>See <a href="Zsh-Modules.html#The-zsh_002fterminfo-Module">The zsh/terminfo
|
|||
|
Module</a>.</p>
|
|||
|
<p><span id="index-emulate"></span>
|
|||
|
<span id="index-compatibility_002c-sh"></span>
|
|||
|
<span id="index-compatibility_002c-ksh"></span>
|
|||
|
<span id="index-compatibility_002c-csh"></span>
|
|||
|
<span id="index-sh_002c-compatibility"></span>
|
|||
|
<span id="index-ksh_002c-compatibility"></span>
|
|||
|
<span id="index-csh_002c-compatibility"></span></p>
|
|||
|
<p><code>emulate</code> [ <code>-lLR</code> ] [ {<code>zsh</code>|<code>sh</code>|<code>ksh</code>|<code>csh</code>} [ <code>flags</code> ... ] ]</p>
|
|||
|
<p>Without any argument print current emulation mode.</p>
|
|||
|
<p>With single argument set up zsh options to emulate the specified shell
|
|||
|
as much as possible. csh will never be fully emulated. If the argument
|
|||
|
is not one of the shells listed above, <code>zsh</code> will be used as a default;
|
|||
|
more precisely, the tests performed on the argument are the same as
|
|||
|
those used to determine the emulation at startup based on the shell
|
|||
|
name, see <a href="Invocation.html#Compatibility">Compatibility</a> . In addition
|
|||
|
to setting shell options, the command also restores the pristine state
|
|||
|
of pattern enables, as if all patterns had been enabled using <code>enable -p</code>.</p>
|
|||
|
<p>If the <code>emulate</code> command occurs inside a function that has been marked
|
|||
|
for execution tracing with <code>functions -t</code> then the <code>xtrace</code> option will
|
|||
|
be turned on regardless of emulation mode or other options. Note that
|
|||
|
code executed inside the function by the <code>.</code>, <code>source</code>, or <code>eval</code>
|
|||
|
commands is not considered to be running directly from the function,
|
|||
|
hence does not provoke this behaviour.</p>
|
|||
|
<p>are reset to their default value corresponding to the specified
|
|||
|
emulation mode, except for certain options describing the interactive
|
|||
|
environment; otherwise, only those options likely to cause portability
|
|||
|
problems in scripts and functions are altered. If the <code>-L</code> switch is
|
|||
|
given, the options <code>LOCAL_OPTIONS</code>, <code>LOCAL_PATTERNS</code> and <code>LOCAL_TRAPS</code>
|
|||
|
will be set as well, causing the effects of the <code>emulate</code> command and
|
|||
|
any <code>setopt</code>, <code>disable -p</code> or <code>enable -p</code>, and <code>trap</code> commands to be
|
|||
|
local to the immediately surrounding shell function, if any; normally
|
|||
|
these options are turned off in all emulation modes except <code>ksh</code>. The
|
|||
|
<code>-L</code> switch is mutually exclusive with the use of <code>-c</code> in <code>flags</code>.</p>
|
|||
|
<p>If there is a single argument and the <code>-l</code> switch is given, the options
|
|||
|
that would be set or unset (the latter indicated with the prefix ‘<code>no</code>’)
|
|||
|
are listed. <code>-l</code> can be combined with <code>-L</code> or <code>-R</code> and the list will be
|
|||
|
modified in the appropriate way. Note the list does not depend on the
|
|||
|
current setting of options, i.e. it includes all options that may in
|
|||
|
principle change, not just those that would actually change.</p>
|
|||
|
<p>The <code>flags</code> may be any of the invocation-time flags described in
|
|||
|
<a href="Invocation.html#Invocation">Invocation</a>, except that ‘<code>-o EMACS</code>’ and
|
|||
|
‘<code>-o VI</code>’ may not be used. Flags such as ‘<code>+r</code>’/‘<code>+o RESTRICTED</code>’ may
|
|||
|
be prohibited in some circumstances.</p>
|
|||
|
<p>If <code>-c</code> <code>arg</code> appears in <code>flags</code>, <code>arg</code> is evaluated while the requested
|
|||
|
emulation is temporarily in effect. In this case the emulation mode and
|
|||
|
all options are restored to their previous values before <code>emulate</code>
|
|||
|
returns. The <code>-R</code> switch may precede the name of the shell to emulate;
|
|||
|
note this has a meaning distinct from including <code>-R</code> in <code>flags</code>.</p>
|
|||
|
<p>Use of <code>-c</code> enables ‘sticky’ emulation mode for functions defined within
|
|||
|
the evaluated expression: the emulation mode is associated thereafter
|
|||
|
with the function so that whenever the function is executed the
|
|||
|
emulation (respecting the <code>-R</code> switch, if present) and all options are
|
|||
|
set (and pattern disables cleared) before entry to the function, and the
|
|||
|
state is restored after exit. If the function is called when the sticky
|
|||
|
emulation is already in effect, either within an ‘<code>emulate</code> <code>shell</code>
|
|||
|
<code>-c</code>’ expression or within another function with the same sticky
|
|||
|
emulation, entry and exit from the function do not cause options to be
|
|||
|
altered (except due to standard processing such as the <code>LOCAL_OPTIONS</code>
|
|||
|
option). This also applies to functions marked for autoload within the
|
|||
|
sticky emulation; the appropriate set of options will be applied at the
|
|||
|
point the function is loaded as well as when it is run.</p>
|
|||
|
<p>For example:</p>
|
|||
|
<div class="example">
|
|||
|
<pre><code class="language-example">emulate sh -c 'fni() { setopt cshnullglob; }
|
|||
|
fno() { fni; }'
|
|||
|
fno
|
|||
|
</code></pre>
|
|||
|
</div>
|
|||
|
<p>The two functions <code>fni</code> and <code>fno</code> are defined with sticky <code>sh</code>
|
|||
|
emulation. <code>fno</code> is then executed, causing options associated with
|
|||
|
emulations to be set to their values in <code>sh</code>. <code>fno</code> then calls <code>fni</code>;
|
|||
|
because <code>fni</code> is also marked for sticky <code>sh</code> emulation, no option
|
|||
|
changes take place on entry to or exit from it. Hence the option
|
|||
|
<code>cshnullglob</code>, turned off by <code>sh</code> emulation, will be turned on within
|
|||
|
<code>fni</code> and remain on return to <code>fno</code>. On exit from <code>fno</code>, the emulation
|
|||
|
mode and all options will be restored to the state they were in before
|
|||
|
entry to the temporary emulation.</p>
|
|||
|
<p>The documentation above is typically sufficient for the intended
|
|||
|
environment. More detailed rules follow.</p>
|
|||
|
<ul>
|
|||
|
<li>
|
|||
|
<p>1.<br />
|
|||
|
The sticky emulation environment provided by ‘<code>emulate</code> <code>shell</code>
|
|||
|
<code>-c</code>’ is identical to that provided by entry to a function marked
|
|||
|
for sticky emulation as a consequence of being defined in such an
|
|||
|
environment. Hence, for example, the sticky emulation is inherited
|
|||
|
by subfunctions defined within functions with sticky emulation.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p>2.<br />
|
|||
|
No change of options takes place on entry to or exit from functions
|
|||
|
that are not marked for sticky emulation, other than those that
|
|||
|
would normally take place, even if those functions are called within
|
|||
|
sticky emulation.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p>3.<br />
|
|||
|
No special handling is provided for functions marked for <code>autoload</code>
|
|||
|
nor for functions present in wordcode created by the <code>zcompile</code>
|
|||
|
command.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p>4.<br />
|
|||
|
The presence or absence of the <code>-R</code> switch to <code>emulate</code> corresponds
|
|||
|
to different sticky emulation modes, so for example ‘<code>emulate sh -c</code>’, ‘<code>emulate -R sh -c</code>’ and ‘<code>emulate csh -c</code>’ are treated as
|
|||
|
three distinct sticky emulations.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p>5.<br />
|
|||
|
Difference in shell options supplied in addition to the basic
|
|||
|
emulation also mean the sticky emulations are different, so for
|
|||
|
example ‘<code>emulate zsh -c</code>’ and ‘<code>emulate zsh -o cbases -c</code>’ are
|
|||
|
treated as distinct sticky emulations.</p>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
<p><span id="index-enable"></span>
|
|||
|
<span id="index-enabling-commands"></span>
|
|||
|
<span id="index-commands_002c-enabling"></span></p>
|
|||
|
<p><code>enable</code> [ <code>-afmprs</code> ] <code>name</code> ...</p>
|
|||
|
<p>earlier with <code>disable</code>. The default is to enable builtin commands. The
|
|||
|
<code>-a</code> option causes <code>enable</code> to act on regular or global aliases. The
|
|||
|
<code>-s</code> option causes <code>enable</code> to act on suffix aliases. The <code>-f</code> option
|
|||
|
causes <code>enable</code> to act on shell functions. The <code>-r</code> option causes
|
|||
|
<code>enable</code> to act on reserved words. Without arguments printed. With the
|
|||
|
<code>-m</code> flag the arguments are taken as patterns disabled with the
|
|||
|
<code>disable</code> builtin command.</p>
|
|||
|
<p><code>enable -p</code> reenables patterns disabled with <code>disable -p</code>. Note that it
|
|||
|
does not override globbing options; for example, ‘<code>enable -p "~"</code>’ does
|
|||
|
not cause the pattern character <code>~</code> to be active unless the
|
|||
|
<code>EXTENDED_GLOB</code> option is also set. To enable all possible patterns (so
|
|||
|
that they may be individually disabled with <code>disable -p</code>), use ‘<code>setopt EXTENDED_GLOB KSH_GLOB NO_SH_GLOB</code>’.</p>
|
|||
|
<p><span id="index-eval"></span>
|
|||
|
<span id="index-evaluating-arguments-as-commands"></span></p>
|
|||
|
<p><code>eval</code> [ <code>arg</code> ... ]</p>
|
|||
|
<p>Read the arguments as input to the shell and execute the resulting
|
|||
|
command(s) in the current shell process. The return status is the same
|
|||
|
as if the commands had been executed directly by the shell; if there are
|
|||
|
no <code>args</code> or they contain no commands (i.e. are an empty string or
|
|||
|
whitespace) the return status is zero.</p>
|
|||
|
<p><code>exec</code> [ <code>-cl</code> ] [ <code>-a</code> <code>argv0</code> ] [ <code>command</code> [ <code>arg</code> ... ] ]</p>
|
|||
|
<p>Replace the current shell with <code>command</code> rather than forking. If
|
|||
|
<code>command</code> is a shell builtin command or a shell function, the shell
|
|||
|
executes it, and exits when the command is complete.</p>
|
|||
|
<p>With <code>-c</code> clear the environment; with <code>-l</code> prepend <code>-</code> to the <code>argv[0]</code>
|
|||
|
string of the command executed (to simulate a login shell); with <code>-a</code>
|
|||
|
<code>argv0</code> set the <code>argv[0]</code> string of the command executed. See
|
|||
|
<a href="Shell-Grammar.html#Precommand-Modifiers">Precommand Modifiers</a>.</p>
|
|||
|
<p>If the option <code>POSIX_BUILTINS</code> is set, <code>command</code> is never interpreted as
|
|||
|
a shell builtin command or shell function. This means further precommand
|
|||
|
modifiers such as <code>builtin</code> and <code>noglob</code> are also not interpreted within
|
|||
|
the shell. Hence <code>command</code> is always found by searching the command
|
|||
|
path.</p>
|
|||
|
<p><span id="index-redirection_002c-current-shell_0027s-I_002fO"></span></p>
|
|||
|
<p>If <code>command</code> is omitted but any redirections are specified, then the
|
|||
|
redirections will take effect in the current shell.</p>
|
|||
|
<p><span id="index-exit"></span></p>
|
|||
|
<p><code>exit</code> [ <code>n</code> ]</p>
|
|||
|
<p>Exit the shell with the exit status specified by an arithmetic
|
|||
|
expression <code>n</code>; if none is specified, use the exit status from the last
|
|||
|
command executed. <span id="index-IGNORE_005fEOF_002c-use-of"></span> An
|
|||
|
EOF condition will also cause the shell to exit, unless the <code>IGNORE_EOF</code>
|
|||
|
option is set.</p>
|
|||
|
<p>See notes at the end of <a href="Jobs-_0026-Signals.html#Jobs-_0026-Signals">Jobs &
|
|||
|
Signals</a> for some possibly
|
|||
|
unexpected interactions of the <code>exit</code> command with jobs.</p>
|
|||
|
<p><span id="index-export-1"></span></p>
|
|||
|
<p><code>export</code> [ <code>name</code>[<code>=``value</code>] ... ]</p>
|
|||
|
<p>The specified <code>name</code>s are marked for automatic export to the environment
|
|||
|
of subsequently executed commands. Equivalent to <code>typeset -gx</code>. If a
|
|||
|
parameter specified does not already exist, it is created in the global
|
|||
|
scope.</p>
|
|||
|
<p><span id="index-false"></span>
|
|||
|
<span id="index-doing-nothing_002c-unsuccessfully"></span></p>
|
|||
|
<p><code>false</code> [ <code>arg</code> ... ]</p>
|
|||
|
<p>Do nothing and return an exit status of 1.</p>
|
|||
|
<p><span id="index-fc"></span>
|
|||
|
<span id="index-history_002c-editing"></span>
|
|||
|
<span id="index-editing-history"></span></p>
|
|||
|
<p><code>fc</code> [ <code>-e</code> <code>ename</code> ] [ <code>-LI</code> ] [ <code>-m</code> <code>match</code> ] [ <code>old``=``new</code>
|
|||
|
... ] [ <code>first</code> [ <code>last</code> ] ]</p>
|
|||
|
<p><code>fc -l </code>[ <code>-LI</code> ] [ <code>-nrdfEiD</code> ] [ <code>-t</code> <code>timefmt</code> ] [ <code>-m</code>
|
|||
|
<code>match</code> ]</p>
|
|||
|
<p><code> </code>[ <code>old``=``new</code> ... ] [ <code>first</code> [ <code>last</code> ] ]</p>
|
|||
|
<p><code>fc -p </code>[ <code>-a</code> ] [ <code>filename</code> [ <code>histsize</code> [ <code>savehistsize</code> ] ]
|
|||
|
]</p>
|
|||
|
<p><code>fc</code> <code>-P</code></p>
|
|||
|
<p><code>fc</code> <code>-ARWI</code> [ <code>filename</code> ]</p>
|
|||
|
<p>The <code>fc</code> command controls the interactive history mechanism. Note that
|
|||
|
reading and writing of history options is only performed if the shell is
|
|||
|
interactive. Usually this is detected automatically, but it can be
|
|||
|
forced by setting the <code>interactive</code> option when starting the shell.</p>
|
|||
|
<p>The first two forms of this command select a range of events from
|
|||
|
<code>first</code> to <code>last</code> from the history list. The arguments <code>first</code> and
|
|||
|
<code>last</code> may be specified as a number or as a string. A negative number is
|
|||
|
used as an offset to the current history event number. A string
|
|||
|
specifies the most recent event beginning with the given string. All
|
|||
|
substitutions <code>old``=``new</code>, if any, are then performed on the text of
|
|||
|
the events.</p>
|
|||
|
<p>In addition to the number range,</p>
|
|||
|
<ul>
|
|||
|
<li>
|
|||
|
<p><code>-I</code><br />
|
|||
|
restricts to only internal events (not from <code>$HISTFILE</code>)</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-L</code><br />
|
|||
|
restricts to only local events (not from other shells, see
|
|||
|
<code>SHARE_HISTORY</code> in <a href="Options.html#Description-of-Options">Description of
|
|||
|
Options</a> – note that
|
|||
|
<code>$HISTFILE</code> is considered local when read at startup)</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-m</code><br />
|
|||
|
takes the first argument as a pattern (should be quoted) and only
|
|||
|
the history events matching this pattern are considered</p>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
<p>If <code>first</code> is not specified, it will be set to -1 (the most recent
|
|||
|
event), or to -16 if the <code>-l</code> flag is given. If <code>last</code> is not specified,
|
|||
|
it will be set to <code>first</code>, or to -1 if the <code>-l</code> flag is given. However,
|
|||
|
if the current event has added entries to the history with ‘<code>print -s</code>’
|
|||
|
or ‘<code>fc -R</code>’, then the default <code>last</code> for <code>-l</code> includes all new history
|
|||
|
entries since the current event began.</p>
|
|||
|
<p>When the <code>-l</code> flag is given, the resulting events are listed on standard
|
|||
|
output. Otherwise the editor program specified by <code>-e</code> <code>ename</code> is
|
|||
|
invoked on a file containing these history events. If <code>-e</code> is not given,
|
|||
|
the value of the parameter <code>FCEDIT</code> is used; if that is not set the
|
|||
|
value of the parameter <code>EDITOR</code> is used; if that is not set a builtin
|
|||
|
default, usually ‘<code>vi</code>’ is used. If <code>ename</code> is ‘<code>-</code>’, no editor is
|
|||
|
invoked. When editing is complete, the edited command is executed.</p>
|
|||
|
<p>The flag <code>-r</code> reverses the order of the events and the flag <code>-n</code>
|
|||
|
suppresses event numbers when listing.</p>
|
|||
|
<p>Also when listing,</p>
|
|||
|
<ul>
|
|||
|
<li>
|
|||
|
<p><code>-d</code><br />
|
|||
|
prints timestamps for each event</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-f</code><br />
|
|||
|
prints full time-date stamps in the US ‘<code>MM``/``DD``/``YY</code>
|
|||
|
<code>hh``:``mm</code>’ format</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-E</code><br />
|
|||
|
prints full time-date stamps in the European ‘<code>dd``.``mm``.``yyyy</code>
|
|||
|
<code>hh``:``mm</code>’ format</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-i</code><br />
|
|||
|
prints full time-date stamps in ISO8601 ‘<code>yyyy``-``mm``-``dd</code>
|
|||
|
<code>hh``:``mm</code>’ format</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-t</code> <code>fmt</code><br />
|
|||
|
prints time and date stamps in the given format; <code>fmt</code> is formatted
|
|||
|
with the strftime function with the zsh extensions described for the
|
|||
|
<code>%D{``string``}</code> prompt format in <a href="Prompt-Expansion.html#Prompt-Expansion">Prompt
|
|||
|
Expansion</a>. The resulting
|
|||
|
formatted string must be no more than 256 characters or will not be
|
|||
|
printed</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-D</code><br />
|
|||
|
prints elapsed times; may be combined with one of the options above</p>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
<p><span id="index-history_002c-stack"></span>
|
|||
|
<span id="index-stack_002c-history"></span></p>
|
|||
|
<p>‘<code>fc -p</code>’ pushes the current history list onto a stack and switches to a
|
|||
|
new history list. If the <code>-a</code> option is also specified, this history
|
|||
|
list will be automatically popped when the current function scope is
|
|||
|
exited, which is a much better solution than creating a trap function to
|
|||
|
call ‘<code>fc -P</code>’ manually. If no arguments are specified, the history list
|
|||
|
is left empty, <code>$HISTFILE</code> is unset, and <code>$HISTSIZE</code> & <code>$SAVEHIST</code> are
|
|||
|
set to their default values. If one argument is given, <code>$HISTFILE</code> is
|
|||
|
set to that filename, <code>$HISTSIZE</code> & <code>$SAVEHIST</code> are left unchanged, and
|
|||
|
the history file is read in (if it exists) to initialize the new list.
|
|||
|
If a second argument is specified, <code>$HISTSIZE</code> & <code>$SAVEHIST</code> are instead
|
|||
|
set to the single specified numeric value. Finally, if a third argument
|
|||
|
is specified, <code>$SAVEHIST</code> is set to a separate value from <code>$HISTSIZE</code>.
|
|||
|
You are free to change these environment values for the new history list
|
|||
|
however you desire in order to manipulate the new history list.</p>
|
|||
|
<p>‘<code>fc -P</code>’ pops the history list back to an older list saved by ‘<code>fc -p</code>’. The current list is saved to its <code>$HISTFILE</code> before it is
|
|||
|
destroyed (assuming that <code>$HISTFILE</code> and <code>$SAVEHIST</code> are set
|
|||
|
appropriately, of course). The values of <code>$HISTFILE</code>, <code>$HISTSIZE</code>, and
|
|||
|
<code>$SAVEHIST</code> are restored to the values they had when ‘<code>fc -p</code>’ was
|
|||
|
called. Note that this restoration can conflict with making these
|
|||
|
variables "local", so your best bet is to avoid local declarations for
|
|||
|
these variables in functions that use ‘<code>fc -p</code>’. The one other
|
|||
|
guaranteed-safe combination is declaring these variables to be local at
|
|||
|
the top of your function and using the automatic option (<code>-a</code>) with ‘<code>fc -p</code>’. Finally, note that it is legal to manually pop a push marked for
|
|||
|
automatic popping if you need to do so before the function exits.</p>
|
|||
|
<p><span id="index-history_002c-file"></span>
|
|||
|
<span id="index-file_002c-history"></span></p>
|
|||
|
<p>‘<code>fc -R</code>’ reads the history from the given file, ‘<code>fc -W</code>’ writes the
|
|||
|
history out to the given file, and ‘<code>fc -A</code>’ appends the history out to
|
|||
|
the given file. If no filename is specified, the <code>$HISTFILE</code> is assumed.
|
|||
|
If the <code>-I</code> option is added to <code>-R</code>, only those events that are not
|
|||
|
already contained within the internal history list are added. If the
|
|||
|
<code>-I</code> option is added to <code>-A</code> or <code>-W</code>, only those events that are new
|
|||
|
since last incremental append/write to the history file are
|
|||
|
appended/written. In any case, the created file will have no more than
|
|||
|
<code>$SAVEHIST</code> entries.</p>
|
|||
|
<p><span id="index-fg"></span>
|
|||
|
<span id="index-jobs_002c-foregrounding"></span>
|
|||
|
<span id="index-jobs_002c-resuming"></span></p>
|
|||
|
<p><code>fg</code> [ <code>job</code> ... ]</p>
|
|||
|
<p><code>job</code> ...</p>
|
|||
|
<p>Bring each specified <code>job</code> in turn to the foreground. If no <code>job</code> is
|
|||
|
specified, resume the current job.</p>
|
|||
|
<p><span id="index-float"></span></p>
|
|||
|
<p><code>float</code> [ {<code>+</code>|<code>-</code>}<code>Hghlprtux</code> ] [ {<code>+</code>|<code>-</code>}<code>EFLRZ</code> [ <code>n</code> ] ] [
|
|||
|
<code>name</code>[<code>=``value</code>] ... ]</p>
|
|||
|
<p>Equivalent to <code>typeset -E</code>, except that options irrelevant to floating
|
|||
|
point numbers are not permitted.</p>
|
|||
|
<p><span id="index-functions-1"></span></p>
|
|||
|
<p><code>functions</code> [ {<code>+</code>|<code>-</code>}<code>UkmtTuWz</code> ] [ <code>-x</code> <code>num</code> ] [ <code>name</code> ... ]</p>
|
|||
|
<p><code>functions -c</code> <code>oldfn</code> <code>newfn</code></p>
|
|||
|
<p><code>functions -M</code> [<code>-s</code>] <code>mathfn</code> [ <code>min</code> [ <code>max</code> [ <code>shellfn</code> ] ] ]</p>
|
|||
|
<p><code>functions -M</code> [ <code>-m</code> <code>pattern</code> ... ]</p>
|
|||
|
<p><code>functions +M</code> [ <code>-m</code> ] <code>mathfn</code> ...</p>
|
|||
|
<p>Equivalent to <code>typeset -f</code>, with the exception of the <code>-c</code>, <code>-x</code>, <code>-M</code>
|
|||
|
and <code>-W</code> options. For <code>functions -u</code> and <code>functions -U</code>, see <code>autoload</code>,
|
|||
|
which provides additional options.</p>
|
|||
|
<p>The <code>-x</code> option indicates that any functions output will have each
|
|||
|
leading tab for indentation, added by the shell to show syntactic
|
|||
|
structure, expanded to the given number <code>num</code> of spaces. <code>num</code> can also
|
|||
|
be 0 to suppress all indentation.</p>
|
|||
|
<p>The <code>-W</code> option turns on the option <code>WARN_NESTED_VAR</code> for the named
|
|||
|
function or functions only. The option is turned off at the start of
|
|||
|
nested functions (apart from anonoymous functions) unless the called
|
|||
|
function also has the <code>-W</code> attribute.</p>
|
|||
|
<p>The <code>-c</code> option causes <code>oldfn</code> to be copied to <code>newfn</code>. The copy is
|
|||
|
efficiently handled internally by reference counting. If <code>oldfn</code> was
|
|||
|
marked for autoload it is first loaded and if this fails the copy fails.
|
|||
|
Either function may subsequently be redefined without affecting the
|
|||
|
other. A typical idiom is that <code>oldfn</code> is the name of a library shell
|
|||
|
function which is then redefined to call <code>newfn</code>, thereby installing a
|
|||
|
modified version of the function.</p>
|
|||
|
<p>Use of the <code>-M</code> option may not be combined with any of the options
|
|||
|
handled by <code>typeset -f</code>.</p>
|
|||
|
<p><code>functions -M</code> <code>mathfn</code> defines <code>mathfn</code> as the name of a mathematical
|
|||
|
function recognised in all forms of arithmetical expressions; see
|
|||
|
<a href="Arithmetic-Evaluation.html#Arithmetic-Evaluation">Arithmetic
|
|||
|
Evaluation</a>. By
|
|||
|
default <code>mathfn</code> may take any number of comma-separated arguments. If
|
|||
|
<code>min</code> is given, it must have exactly <code>min</code> args; if <code>min</code> and <code>max</code> are
|
|||
|
both given, it must have at least <code>min</code> and at most <code>max</code> args. <code>max</code>
|
|||
|
may be -1 to indicate that there is no upper limit.</p>
|
|||
|
<p>By default the function is implemented by a shell function of the same
|
|||
|
name; if <code>shellfn</code> is specified it gives the name of the corresponding
|
|||
|
shell function while <code>mathfn</code> remains the name used in arithmetical
|
|||
|
expressions. The name of the function in <code>$0</code> is <code>mathfn</code> (not <code>shellfn</code>
|
|||
|
as would usually be the case), provided the option <code>FUNCTION_ARGZERO</code> is
|
|||
|
in effect. The positional parameters in the shell function correspond to
|
|||
|
the arguments of the mathematical function call. The result of the last
|
|||
|
arithmetical expression evaluated inside the shell function (even if it
|
|||
|
is a form that normally only returns a status) gives the result of the
|
|||
|
mathematical function.</p>
|
|||
|
<p>If the additional option <code>-s</code> is given to <code>functions -M</code>, the argument
|
|||
|
to the function is a single string: anything between the opening and
|
|||
|
matching closing parenthesis is passed to the function as a single
|
|||
|
argument, even if it includes commas or white space. The minimum and
|
|||
|
maximum argument specifiers must therefore be 1 if given. An empty
|
|||
|
argument list is passed as a zero-length string.</p>
|
|||
|
<p><code>functions -M</code> with no arguments lists all such user-defined functions
|
|||
|
in the same form as a definition. With the additional option <code>-m</code> and a
|
|||
|
list of arguments, all functions whose <code>mathfn</code> matches one of the
|
|||
|
pattern arguments are listed.</p>
|
|||
|
<p><code>function +M</code> removes the list of mathematical functions; with the
|
|||
|
additional option <code>-m</code> the arguments are treated as patterns and all
|
|||
|
functions whose <code>mathfn</code> matches the pattern are removed. Note that the
|
|||
|
shell function implementing the behaviour is not removed (regardless of
|
|||
|
whether its name coincides with <code>mathfn</code>).</p>
|
|||
|
<p>For example, the following prints the cube of 3:</p>
|
|||
|
<div class="example">
|
|||
|
<pre><code class="language-example">zmath_cube() { (( $1 * $1 * $1 )) }
|
|||
|
functions -M cube 1 1 zmath_cube
|
|||
|
print $(( cube(3) ))
|
|||
|
</code></pre>
|
|||
|
</div>
|
|||
|
<p>The following string function takes a single argument, including the
|
|||
|
commas, so prints 11:</p>
|
|||
|
<div class="example">
|
|||
|
<pre><code class="language-example">stringfn() { (( $#1 )) }
|
|||
|
functions -Ms stringfn
|
|||
|
print $(( stringfn(foo,bar,rod) ))
|
|||
|
</code></pre>
|
|||
|
</div>
|
|||
|
<p><code>getcap</code></p>
|
|||
|
<p>See <a href="Zsh-Modules.html#The-zsh_002fcap-Module">The zsh/cap Module</a>.</p>
|
|||
|
<p><span id="index-getln"></span>
|
|||
|
<span id="index-line_002c-reading"></span>
|
|||
|
<span id="index-reading-a-line"></span></p>
|
|||
|
<p><code>getln</code> [ <code>-AclneE</code> ] <code>name</code> ...</p>
|
|||
|
<p>Read the top value from the buffer stack and put it in the shell
|
|||
|
parameter <code>name</code>. Equivalent to <code>read -zr</code>.</p>
|
|||
|
<p><span id="index-getopts"></span>
|
|||
|
<span id="index-options_002c-processing"></span></p>
|
|||
|
<p><code>getopts</code> <code>optstring</code> <code>name</code> [ <code>arg</code> ... ]</p>
|
|||
|
<p>Checks the <code>arg</code>s for legal options. If the <code>arg</code>s are omitted, use the
|
|||
|
positional parameters. A valid option argument begins with a ‘<code>+</code>’ or a
|
|||
|
‘<code>-</code>’. An argument not beginning with a ‘<code>+</code>’ or a ‘<code>-</code>’, or the
|
|||
|
argument ‘<code>-``-</code>’, ends the options. Note that a single ‘<code>-</code>’ is not
|
|||
|
considered a valid option argument. <code>optstring</code> contains the letters
|
|||
|
that <code>getopts</code> recognizes. If a letter is followed by a ‘<code>:</code>’, that
|
|||
|
option requires an argument. The options can be separated from the
|
|||
|
argument by blanks.</p>
|
|||
|
<p>Each time it is invoked, <code>getopts</code> places the option letter it finds in
|
|||
|
the shell parameter <code>name</code>, prepended with a ‘<code>+</code>’ when <code>arg</code> begins
|
|||
|
with a ‘<code>+</code>’. The index of the next <code>arg</code> is stored in <code>OPTIND</code>. The
|
|||
|
option argument, if any, is stored in <code>OPTARG</code>.
|
|||
|
<span id="index-OPTIND_002c-use-of"></span>
|
|||
|
<span id="index-OPTARG_002c-use-of"></span></p>
|
|||
|
<p>The first option to be examined may be changed by explicitly assigning
|
|||
|
to <code>OPTIND</code>. <code>OPTIND</code> has an initial value of <code>1</code>, and is normally set
|
|||
|
to <code>1</code> upon entry to a shell function and restored upon exit (this is
|
|||
|
disabled by the <code>POSIX_BUILTINS</code> option). <code>OPTARG</code> is not reset and
|
|||
|
retains its value from the most recent call to <code>getopts</code>. If either of
|
|||
|
<code>OPTIND</code> or <code>OPTARG</code> is explicitly unset, it remains unset, and the
|
|||
|
index or option argument is not stored. The option itself is still
|
|||
|
stored in <code>name</code> in this case.</p>
|
|||
|
<p>A leading ‘<code>:</code>’ in <code>optstring</code> causes <code>getopts</code> to store the letter of
|
|||
|
any invalid option in <code>OPTARG</code>, and to set <code>name</code> to ‘<code>?</code>’ for an
|
|||
|
unknown option and to ‘<code>:</code>’ when a required argument is missing.
|
|||
|
Otherwise, <code>getopts</code> sets <code>name</code> to ‘<code>?</code>’ and prints an error message
|
|||
|
when an option is invalid. The exit status is nonzero when there are no
|
|||
|
more options.</p>
|
|||
|
<p><span id="index-hash-1"></span></p>
|
|||
|
<p><code>hash</code> [ <code>-Ldfmrv</code> ] [ <code>name</code>[<code>=``value</code>] ] ...</p>
|
|||
|
<p><code>hash</code> can be used to directly modify the contents of the command</p>
|
|||
|
<p>A command <code>name</code> starting with a <code>/</code> is never hashed, whether by
|
|||
|
explicit use of the <code>hash</code> command or otherwise. Such a command is
|
|||
|
always found by direct look up in the file system.</p>
|
|||
|
<p>Given no arguments, and neither the <code>-r</code> or <code>-f</code> options,</p>
|
|||
|
<p>It will be subsequently rebuilt in the normal fashion. all the absolute
|
|||
|
directories in the <code>PATH</code>, These two options cannot be used with any
|
|||
|
arguments.</p>
|
|||
|
<p>The <code>-m</code> option causes the arguments to be taken as patterns matching
|
|||
|
those patterns are printed. This is the only way to display</p>
|
|||
|
<p>For each <code>name</code> with a corresponding <code>value</code>, put ‘<code>name</code>’ in whenever
|
|||
|
‘<code>name</code>’ is used as a command argument, the shell will try to execute
|
|||
|
the file given by ‘<code>value</code>’. that ‘<code>value</code>’ may be referred to as
|
|||
|
‘<code>~``name</code>’.</p>
|
|||
|
<p>For each <code>name</code> with no checking what the appropriate <code>value</code> is in the
|
|||
|
normal manner for</p>
|
|||
|
<p>added by explicit specification. If has no effect if used with <code>-f</code>.</p>
|
|||
|
<p>the form of a call to hash.</p>
|
|||
|
<p><span id="index-history-1"></span></p>
|
|||
|
<p><code>history</code></p>
|
|||
|
<p>Same as <code>fc -l</code>.</p>
|
|||
|
<p><span id="index-integer"></span></p>
|
|||
|
<p><code>integer</code> [ {<code>+</code>|<code>-</code>}<code>Hghlprtux</code> ] [ {<code>+</code>|<code>-</code>}<code>LRZi</code> [ <code>n</code> ] ] [
|
|||
|
<code>name</code>[<code>=``value</code>] ... ]</p>
|
|||
|
<p>Equivalent to <code>typeset -i</code>, except that options irrelevant to integers
|
|||
|
are not permitted.</p>
|
|||
|
<p><span id="index-jobs-1"></span></p>
|
|||
|
<p><code>jobs</code> [ <code>-dlprs</code> ] [ <code>job</code> ... ]</p>
|
|||
|
<p><code>jobs -Z</code> <code>string</code></p>
|
|||
|
<p>Lists information about each given job, or all jobs if <code>job</code> is omitted.
|
|||
|
The <code>-l</code> flag lists process IDs, and the <code>-p</code> flag lists process groups.
|
|||
|
If the <code>-r</code> flag is specified only running jobs will be listed and if
|
|||
|
the <code>-s</code> flag is given only stopped jobs are shown. If the <code>-d</code> flag is
|
|||
|
given, the directory from which the job was started (which may not be
|
|||
|
the current directory of the job) will also be shown.</p>
|
|||
|
<p>The <code>-Z</code> option replaces the shell’s argument and environment space with
|
|||
|
the given string, truncated if necessary to fit. This will normally be
|
|||
|
visible in <code>ps</code> (man page ps(1)) listings. This feature is typically
|
|||
|
used by daemons, to indicate their state.</p>
|
|||
|
<p><span id="index-kill"></span> <span id="index-killing-jobs"></span>
|
|||
|
<span id="index-jobs_002c-killing"></span></p>
|
|||
|
<p><code>kill</code> [ <code>-s</code> <code>signal_name</code> | <code>-n</code> <code>signal_number</code> | <code>-``sig</code> ] <code>job</code>
|
|||
|
...</p>
|
|||
|
<p><code>kill</code> <code>-l</code> [ <code>sig</code> ... ]</p>
|
|||
|
<p>Sends either <code>SIGTERM</code> or the specified signal to the given jobs or
|
|||
|
processes. Signals are given by number or by names, with or without the
|
|||
|
‘<code>SIG</code>’ prefix. If the signal being sent is not ‘<code>KILL</code>’ or ‘<code>CONT</code>’,
|
|||
|
then the job will be sent a ‘<code>CONT</code>’ signal if it is stopped. The
|
|||
|
argument <code>job</code> can be the process ID of a job not in the job list. In
|
|||
|
the second form, <code>kill -l</code>, if <code>sig</code> is not specified the signal names
|
|||
|
are listed. Otherwise, for each <code>sig</code> that is a name, the corresponding
|
|||
|
signal number is listed. For each <code>sig</code> that is a signal number or a
|
|||
|
number representing the exit status of a process which was terminated or
|
|||
|
stopped by a signal the name of the signal is printed.</p>
|
|||
|
<p>On some systems, alternative signal names are allowed for a few signals.
|
|||
|
Typical examples are <code>SIGCHLD</code> and <code>SIGCLD</code> or <code>SIGPOLL</code> and <code>SIGIO</code>,
|
|||
|
assuming they correspond to the same signal number. <code>kill -l</code> will only
|
|||
|
list the preferred form, however <code>kill -l</code> <code>alt</code> will show if the
|
|||
|
alternative form corresponds to a signal number. For example, under
|
|||
|
Linux <code>kill -l IO</code> and <code>kill -l POLL</code> both output 29, hence <code>kill -IO</code>
|
|||
|
and <code>kill -POLL</code> have the same effect.</p>
|
|||
|
<p>Many systems will allow process IDs to be negative to kill a process
|
|||
|
group or zero to kill the current process group.</p>
|
|||
|
<p><span id="index-let"></span></p>
|
|||
|
<p><code>let</code> <code>arg</code> ...</p>
|
|||
|
<p>Evaluate each <code>arg</code> as an arithmetic expression. See <a href="Arithmetic-Evaluation.html#Arithmetic-Evaluation">Arithmetic
|
|||
|
Evaluation</a> for a
|
|||
|
description of arithmetic expressions. The exit status is 0 if the value
|
|||
|
of the last expression is nonzero, 1 if it is zero, and 2 if an error
|
|||
|
occurred.</p>
|
|||
|
<p><span id="index-limit"></span> <span id="index-resource-limits"></span>
|
|||
|
<span id="index-limits_002c-resource"></span></p>
|
|||
|
<p><code>limit</code> [ <code>-hs</code> ] [ <code>resource</code> [ <code>limit</code> ] ] ...</p>
|
|||
|
<p>Set or display resource limits. Unless the <code>-s</code> flag is given, the limit
|
|||
|
applies only the children of the shell. If <code>-s</code> is given without other
|
|||
|
arguments, the resource limits of the current shell is set to the
|
|||
|
previously set resource limits of the children.</p>
|
|||
|
<p>If <code>limit</code> is not specified, print the current limit placed on
|
|||
|
<code>resource</code>, otherwise set the limit to the specified value. If the <code>-h</code>
|
|||
|
flag is given, use hard limits instead of soft limits. If no <code>resource</code>
|
|||
|
is given, print all limits.</p>
|
|||
|
<p>When looping over multiple resources, the shell will abort immediately
|
|||
|
if it detects a badly formed argument. However, if it fails to set a
|
|||
|
limit for some other reason it will continue trying to set the remaining
|
|||
|
limits.</p>
|
|||
|
<p><code>resource</code> can be one of:</p>
|
|||
|
<ul>
|
|||
|
<li>
|
|||
|
<p><code>addressspace</code><br />
|
|||
|
Maximum amount of address space used.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>aiomemorylocked</code><br />
|
|||
|
Maximum amount of memory locked in RAM for AIO operations.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>aiooperations</code><br />
|
|||
|
Maximum number of AIO operations.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>cachedthreads</code><br />
|
|||
|
Maximum number of cached threads.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>coredumpsize</code><br />
|
|||
|
Maximum size of a core dump.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>cputime</code><br />
|
|||
|
Maximum CPU seconds per process.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>datasize</code><br />
|
|||
|
Maximum data size (including stack) for each process.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>descriptors</code><br />
|
|||
|
Maximum value for a file descriptor.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>filesize</code><br />
|
|||
|
Largest single file allowed.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>kqueues</code><br />
|
|||
|
Maximum number of kqueues allocated.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>maxproc</code><br />
|
|||
|
Maximum number of processes.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>maxpthreads</code><br />
|
|||
|
Maximum number of threads per process.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>memorylocked</code><br />
|
|||
|
Maximum amount of memory locked in RAM.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>memoryuse</code><br />
|
|||
|
Maximum resident set size.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>msgqueue</code><br />
|
|||
|
Maximum number of bytes in POSIX message queues.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>posixlocks</code><br />
|
|||
|
Maximum number of POSIX locks per user.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>pseudoterminals</code><br />
|
|||
|
Maximum number of pseudo-terminals.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>resident</code><br />
|
|||
|
Maximum resident set size.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>sigpending</code><br />
|
|||
|
Maximum number of pending signals.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>sockbufsize</code><br />
|
|||
|
Maximum size of all socket buffers.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>stacksize</code><br />
|
|||
|
Maximum stack size for each process.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>swapsize</code><br />
|
|||
|
Maximum amount of swap used.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>vmemorysize</code><br />
|
|||
|
Maximum amount of virtual memory.</p>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
<p>Which of these resource limits are available depends on the system.
|
|||
|
<code>resource</code> can be abbreviated to any unambiguous prefix. It can also be
|
|||
|
an integer, which corresponds to the integer defined for the resource by
|
|||
|
the operating system.</p>
|
|||
|
<p>If argument corresponds to a number which is out of the range of the
|
|||
|
resources configured into the shell, the shell will try to read or write
|
|||
|
the limit anyway, and will report an error if this fails. As the shell
|
|||
|
does not store such resources internally, an attempt to set the limit
|
|||
|
will fail unless the <code>-s</code> option is present.</p>
|
|||
|
<p><code>limit</code> is a number, with an optional scaling factor, as follows:</p>
|
|||
|
<ul>
|
|||
|
<li>
|
|||
|
<p><code>n``h</code><br />
|
|||
|
hours</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>n``k</code><br />
|
|||
|
kilobytes (default)</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>n``m</code><br />
|
|||
|
megabytes or minutes</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>n``g</code><br />
|
|||
|
gigabytes</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p>[<code>mm``:</code>]<code>ss</code><br />
|
|||
|
minutes and seconds</p>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
<p>The <code>limit</code> command is not made available by default when the shell
|
|||
|
starts in a mode emulating another shell. It can be made available with
|
|||
|
the command ‘<code>zmodload -F zsh/rlimits b:limit</code>’.</p>
|
|||
|
<p><span id="index-local"></span></p>
|
|||
|
<p><code>local</code> [ {<code>+</code>|<code>-</code>}<code>AHUahlprtux</code> ] [ {<code>+</code>|<code>-</code>}<code>EFLRZi</code> [ <code>n</code> ] ]
|
|||
|
[ <code>name</code>[<code>=``value</code>] ... ]</p>
|
|||
|
<p>Same as <code>typeset</code>, except that the options <code>-g</code>, and <code>-f</code> are not
|
|||
|
permitted. In this case the <code>-x</code> option does not force the use of <code>-g</code>,
|
|||
|
i.e. exported variables will be local to functions.</p>
|
|||
|
<p><span id="index-log"></span> <span id="index-watch_002c-use-of"></span>
|
|||
|
<span id="index-watching-users"></span>
|
|||
|
<span id="index-users_002c-watching"></span></p>
|
|||
|
<p><code>log</code></p>
|
|||
|
<p>List all users currently logged in who are affected by the current
|
|||
|
setting of the <code>watch</code> parameter.</p>
|
|||
|
<p><span id="index-logout"></span></p>
|
|||
|
<p><code>logout</code> [ <code>n</code> ]</p>
|
|||
|
<p>Same as <code>exit</code>, except that it only works in a login shell.</p>
|
|||
|
<p><code>noglob</code> <code>simple command</code></p>
|
|||
|
<p>See <a href="Shell-Grammar.html#Precommand-Modifiers">Precommand Modifiers</a>.</p>
|
|||
|
<p><span id="index-popd"></span></p>
|
|||
|
<p><code>popd</code> [ <code>-q</code> ] [ {<code>+</code>|<code>-</code>}<code>n</code> ]</p>
|
|||
|
<p>Remove an entry from the directory stack, and perform a <code>cd</code> to the new
|
|||
|
top directory. With no argument, the current top entry is removed. An
|
|||
|
argument of the form ‘<code>+``n</code>’ identifies a stack entry by counting from
|
|||
|
the left of the list shown by the <code>dirs</code> command, starting with zero. An
|
|||
|
argument of the form <code>-``n</code> counts from the right.
|
|||
|
<span id="index-PUSHD_005fMINUS_002c-use-of-1"></span> If the
|
|||
|
<code>PUSHD_MINUS</code> option is set, the meanings of ‘<code>+</code>’ and ‘<code>-</code>’ in this
|
|||
|
context are swapped.</p>
|
|||
|
<p>If the <code>-q</code> (quiet) option is specified, the hook function <code>chpwd</code> and
|
|||
|
the functions in the array <code>$chpwd_functions</code> are not called, and the
|
|||
|
new directory stack is not printed. This is useful for calls to <code>popd</code>
|
|||
|
that do not change the environment seen by an interactive user.</p>
|
|||
|
<p><span id="index-print"></span></p>
|
|||
|
<p><code>print </code>[ <code>-abcDilmnNoOpPrsSz</code> ] [ <code>-u</code> <code>n</code> ] [ <code>-f</code> <code>format</code> ]
|
|||
|
[ <code>-C</code> <code>cols</code> ]</p>
|
|||
|
<p><code> </code>[ <code>-v</code> <code>name</code> ] [ <code>-xX</code> <code>tabstop</code> ] [ <code>-R</code> [ <code>-en</code> ]] [
|
|||
|
<code>arg</code> ... ]</p>
|
|||
|
<p>With the ‘<code>-f</code>’ option the arguments are printed as described by
|
|||
|
<code>printf</code>. With no flags or with the flag ‘<code>-</code>’, the arguments are
|
|||
|
printed on the standard output as described by <code>echo</code>, with the
|
|||
|
following differences: the escape sequence ‘<code>\M-``x</code>’ (or ‘<code>\M``x</code>’)
|
|||
|
metafies the character <code>x</code> (sets the highest bit), ‘<code>\C-``x</code>’ (or
|
|||
|
‘<code>\C``x</code>’) produces a control character (‘<code>\C-@</code>’ and ‘<code>\C-?</code>’ give
|
|||
|
the characters NULL and delete), a character code in octal is
|
|||
|
represented by ‘<code>\``NNN</code>’ (instead of ‘<code>\0``NNN</code>’), and ‘<code>\E</code>’ is a
|
|||
|
synonym for ‘<code>\e</code>’. Finally, if not in an escape sequence, ‘<code>\</code>’ escapes
|
|||
|
the following character and is not printed.</p>
|
|||
|
<ul>
|
|||
|
<li>
|
|||
|
<p><code>-a</code><br />
|
|||
|
Print arguments with the column incrementing first. Only useful with
|
|||
|
the <code>-c</code> and <code>-C</code> options.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-b</code><br />
|
|||
|
Recognize all the escape sequences defined for the <code>bindkey</code>
|
|||
|
command, see <a href="Zsh-Line-Editor.html#Zle-Builtins">Zle Builtins</a>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-c</code><br />
|
|||
|
Print the arguments in columns. Unless <code>-a</code> is also given, arguments
|
|||
|
are printed with the row incrementing first.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-C</code> <code>cols</code><br />
|
|||
|
Print the arguments in <code>cols</code> columns. Unless <code>-a</code> is also given,
|
|||
|
arguments are printed with the row incrementing first.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-D</code><br />
|
|||
|
Treat the arguments as paths, replacing directory prefixes with <code>~</code>
|
|||
|
expressions corresponding to directory names, as appropriate.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-i</code><br />
|
|||
|
If given together with <code>-o</code> or <code>-O</code>, sorting is performed
|
|||
|
case-independently.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-l</code><br />
|
|||
|
Print the arguments separated by newlines instead of spaces. Note:
|
|||
|
if the list of arguments is empty, <code>print -l</code> will still output one
|
|||
|
empty line. To print a possibly-empty list of arguments one per
|
|||
|
line, use <code>print -C1</code>, as in ‘<code>print -rC1 – "$list[@]"</code>’.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-m</code><br />
|
|||
|
Take the first argument as a pattern (should be quoted), and remove
|
|||
|
it from the argument list together with subsequent arguments that do
|
|||
|
not match this pattern.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-n</code><br />
|
|||
|
Do not add a newline to the output.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-N</code><br />
|
|||
|
Print the arguments separated and terminated by nulls. Again, <code>print -rNC1 – "$list[@]"</code> is a canonical way to print an arbitrary list as
|
|||
|
null-delimited records.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-o</code><br />
|
|||
|
Print the arguments sorted in ascending order.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-O</code><br />
|
|||
|
Print the arguments sorted in descending order.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-p</code><br />
|
|||
|
Print the arguments to the input of the coprocess.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-P</code><br />
|
|||
|
Perform prompt expansion (see <a href="Prompt-Expansion.html#Prompt-Expansion">Prompt
|
|||
|
Expansion</a>). In combination
|
|||
|
with ‘<code>-f</code>’, prompt escape sequences are parsed only within
|
|||
|
interpolated arguments, not within the format string.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-r</code><br />
|
|||
|
Ignore the escape conventions of <code>echo</code>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-R</code><br />
|
|||
|
Emulate the BSD <code>echo</code> command, which does not process escape
|
|||
|
sequences unless the <code>-e</code> flag is given. The <code>-n</code> flag suppresses
|
|||
|
the trailing newline. Only the <code>-e</code> and <code>-n</code> flags are recognized
|
|||
|
after <code>-R</code>; all other arguments and options are printed.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-s</code><br />
|
|||
|
Place the results in the history list instead of on the standard
|
|||
|
output. Each argument to the <code>print</code> command is treated as a single
|
|||
|
word in the history, regardless of its content.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-S</code><br />
|
|||
|
Place the results in the history list instead of on the standard
|
|||
|
output. In this case only a single argument is allowed; it will be
|
|||
|
split into words as if it were a full shell command line. The effect
|
|||
|
is similar to reading the line from a history file with the
|
|||
|
<code>HIST_LEX_WORDS</code> option active.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-u</code> <code>n</code><br />
|
|||
|
Print the arguments to file descriptor <code>n</code>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-v</code> <code>name</code><br />
|
|||
|
Store the printed arguments as the value of the parameter <code>name</code>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-x</code> <code>tab-stop</code><br />
|
|||
|
Expand leading tabs on each line of output in the printed string
|
|||
|
assuming a tab stop every <code>tab-stop</code> characters. This is appropriate
|
|||
|
for formatting code that may be indented with tabs. Note that
|
|||
|
leading tabs of any argument to print, not just the first, are
|
|||
|
expanded, even if <code>print</code> is using spaces to separate arguments (the
|
|||
|
column count is maintained across arguments but may be incorrect on
|
|||
|
output owing to previous unexpanded tabs).</p>
|
|||
|
<p>The start of the output of each print command is assumed to be
|
|||
|
aligned with a tab stop. Widths of multibyte characters are handled
|
|||
|
if the option <code>MULTIBYTE</code> is in effect. This option is ignored if
|
|||
|
other formatting options are in effect, namely column alignment or
|
|||
|
<code>printf</code> style, or if output is to a special location such as shell
|
|||
|
history or the command line editor.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-X</code> <code>tab-stop</code><br />
|
|||
|
This is similar to <code>-x</code>, except that all tabs in the printed string
|
|||
|
are expanded. This is appropriate if tabs in the arguments are</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-z</code><br />
|
|||
|
Push the arguments onto the editing buffer stack, separated by
|
|||
|
spaces.</p>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
<p>If any of ‘<code>-m</code>’, ‘<code>-o</code>’ or ‘<code>-O</code>’ are used in combination with ‘<code>-f</code>’
|
|||
|
and there are no arguments (after the removal process in the case of
|
|||
|
‘<code>-m</code>’) then nothing is printed.</p>
|
|||
|
<p><span id="index-printf"></span></p>
|
|||
|
<p><code>printf</code> [ <code>-v</code> <code>name</code> ] <code>format</code> [ <code>arg</code> ... ]</p>
|
|||
|
<p>Print the arguments according to the format specification. Formatting
|
|||
|
rules are the same as used in C. The same escape sequences as for <code>echo</code>
|
|||
|
are recognised in the format. All C conversion specifications ending in
|
|||
|
one of <code>csdiouxXeEfgGn</code> are handled. In addition to this, ‘<code>%b</code>’ can be
|
|||
|
used instead of ‘<code>%s</code>’ to cause escape sequences in the argument to be
|
|||
|
recognised and ‘<code>%q</code>’ can be used to quote the argument in such a way
|
|||
|
that allows it to be reused as shell input. With the numeric format
|
|||
|
specifiers, if the corresponding argument starts with a quote character,
|
|||
|
the numeric value of the following character is used as the number to
|
|||
|
print; otherwise the argument is evaluated as an arithmetic expression.
|
|||
|
See <a href="Arithmetic-Evaluation.html#Arithmetic-Evaluation">Arithmetic
|
|||
|
Evaluation</a> for a
|
|||
|
description of arithmetic expressions. With ‘<code>%n</code>’, the corresponding
|
|||
|
argument is taken as an identifier which is created as an integer
|
|||
|
parameter.</p>
|
|||
|
<p>Normally, conversion specifications are applied to each argument in
|
|||
|
order but they can explicitly specify the <code>n</code>th argument is to be used
|
|||
|
by replacing ‘<code>%</code>’ by ‘<code>%``n``$</code>’ and ‘<code>*</code>’ by ‘<code>*``n``$</code>’. It is
|
|||
|
recommended that you do not mix references of this explicit style with
|
|||
|
the normal style and the handling of such mixed styles may be subject to
|
|||
|
future change.</p>
|
|||
|
<p>If arguments remain unused after formatting, the format string is reused
|
|||
|
until all arguments have been consumed. With the <code>print</code> builtin, this
|
|||
|
can be suppressed by using the <code>-r</code> option. If more arguments are
|
|||
|
required by the format than have been specified, the behaviour is as if
|
|||
|
zero or an empty string had been specified as the argument.</p>
|
|||
|
<p>The <code>-v</code> option causes the output to be stored as the value of the
|
|||
|
parameter <code>name</code>, instead of printed. If <code>name</code> is an array and the
|
|||
|
format string is reused when consuming arguments then one array element
|
|||
|
will be used for each use of the format string.</p>
|
|||
|
<p><span id="index-pushd"></span>
|
|||
|
<span id="index-PUSHD_005fTO_005fHOME_002c-use-of"></span>
|
|||
|
<span id="index-PUSHD_005fMINUS_002c-use-of-2"></span>
|
|||
|
<span id="index-CDABLE_005fVARS_002c-use-of"></span>
|
|||
|
<span id="index-PUSHD_005fSILENT_002c-use-of"></span></p>
|
|||
|
<p><code>pushd</code> [ <code>-qsLP</code> ] [ <code>arg</code> ]</p>
|
|||
|
<p><code>pushd</code> [ <code>-qsLP</code> ] <code>old</code> <code>new</code></p>
|
|||
|
<p><code>pushd</code> [ <code>-qsLP</code> ] {<code>+</code>|<code>-</code>}<code>n</code></p>
|
|||
|
<p>Change the current directory, and push the old current directory onto
|
|||
|
the directory stack. In the first form, change the current directory to
|
|||
|
<code>arg</code>. If <code>arg</code> is not specified, change to the second directory on the
|
|||
|
stack (that is, exchange the top two entries), or change to <code>$HOME</code> if
|
|||
|
the <code>PUSHD_TO_HOME</code> option is set or if there is only one entry on the
|
|||
|
stack. Otherwise, <code>arg</code> is interpreted as it would be by <code>cd</code>. The
|
|||
|
meaning of <code>old</code> and <code>new</code> in the second form is also the same as for
|
|||
|
<code>cd</code>.</p>
|
|||
|
<p>The third form of <code>pushd</code> changes directory by rotating the directory
|
|||
|
list. An argument of the form ‘<code>+``n</code>’ identifies a stack entry by
|
|||
|
counting from the left of the list shown by the <code>dirs</code> command, starting
|
|||
|
with zero. An argument of the form ‘<code>-``n</code>’ counts from the right. If
|
|||
|
the <code>PUSHD_MINUS</code> option is set, the meanings of ‘<code>+</code>’ and ‘<code>-</code>’ in this
|
|||
|
context are swapped.</p>
|
|||
|
<p>If the <code>-q</code> (quiet) option is specified, the hook function <code>chpwd</code> and
|
|||
|
the functions in the array <code>$chpwd_functions</code> are not called, and the
|
|||
|
new directory stack is not printed. This is useful for calls to <code>pushd</code>
|
|||
|
that do not change the environment seen by an interactive user.</p>
|
|||
|
<p>If the option <code>-q</code> is not specified and the shell option <code>PUSHD_SILENT</code>
|
|||
|
is not set, the directory stack will be printed after a <code>pushd</code> is
|
|||
|
performed.</p>
|
|||
|
<p>The options <code>-s</code>, <code>-L</code> and <code>-P</code> have the same meanings as for the <code>cd</code>
|
|||
|
builtin.</p>
|
|||
|
<p><span id="index-pushln"></span></p>
|
|||
|
<p><code>pushln</code> [ <code>arg</code> ... ]</p>
|
|||
|
<p>Equivalent to <code>print -nz</code>.</p>
|
|||
|
<p><span id="index-pwd"></span>
|
|||
|
<span id="index-CHASE_005fLINKS_002c-use-of"></span></p>
|
|||
|
<p><code>pwd</code> [ <code>-rLP</code> ]</p>
|
|||
|
<p>Print the absolute pathname of the current working directory. If the
|
|||
|
<code>-r</code> or the <code>-P</code> flag is specified, or the <code>CHASE_LINKS</code> option is set
|
|||
|
and the <code>-L</code> flag is not given, the printed path will not contain
|
|||
|
symbolic links.</p>
|
|||
|
<p><span id="index-r"></span></p>
|
|||
|
<p><code>r</code></p>
|
|||
|
<p>Same as <code>fc -e -</code>.</p>
|
|||
|
<p><span id="index-read"></span> <span id="index-IFS_002c-use-of-2"></span></p>
|
|||
|
<p><code>read </code>[ <code>-rszpqAclneE</code> ] [ <code>-t</code> [ <code>num</code> ] ] [ <code>-k</code> [ <code>num</code> ]
|
|||
|
] [ <code>-d</code> <code>delim</code> ]</p>
|
|||
|
<p><code> </code>[ <code>-u</code> <code>n</code> ] [ <code>name</code>[<code>?``prompt</code>] ] [ <code>name</code> ... ]</p>
|
|||
|
<p><span id="index-REPLY_002c-use-of-2"></span>
|
|||
|
<span id="index-reply_002c-use-of-1"></span></p>
|
|||
|
<p>Read one line and break it into fields using the characters in <code>$IFS</code> as
|
|||
|
separators, except as noted below. The first field is assigned to the
|
|||
|
first <code>name</code>, the second field to the second <code>name</code>, etc., with leftover
|
|||
|
fields assigned to the last <code>name</code>. If <code>name</code> is omitted then <code>REPLY</code> is
|
|||
|
used for scalars and <code>reply</code> for arrays.</p>
|
|||
|
<ul>
|
|||
|
<li>
|
|||
|
<p><code>-r</code><br />
|
|||
|
Raw mode: a ‘<code>\</code>’ at the end of a line does not signify line
|
|||
|
continuation and backslashes in the line don’t quote the following
|
|||
|
character and are not removed.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-s</code><br />
|
|||
|
Don’t echo back characters if reading from the terminal.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-q</code><br />
|
|||
|
Read only one character from the terminal and set <code>name</code> to ‘<code>y</code>’ if
|
|||
|
this character was ‘<code>y</code>’ or ‘<code>Y</code>’ and to ‘<code>n</code>’ otherwise. With this
|
|||
|
flag set the return status is zero only if the character was ‘<code>y</code>’
|
|||
|
or ‘<code>Y</code>’. This option may be used with a timeout (see <code>-t</code>); if the
|
|||
|
read times out, or encounters end of file, status 2 is returned.
|
|||
|
Input is read from the terminal unless one of <code>-u</code> or <code>-p</code> is
|
|||
|
present. This option may also be used within zle widgets.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-k</code> [ <code>num</code> ]<br />
|
|||
|
Read only one (or <code>num</code>) characters. All are assigned to the first
|
|||
|
<code>name</code>, without word splitting. This flag is ignored when <code>-q</code> is
|
|||
|
present. Input is read from the terminal unless one of <code>-u</code> or <code>-p</code>
|
|||
|
is present. This option may also be used within zle widgets.</p>
|
|||
|
<p>Note that despite the mnemonic ‘key’ this option does read full
|
|||
|
characters, which may consist of multiple bytes if the option
|
|||
|
<code>MULTIBYTE</code> is set.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-z</code><br />
|
|||
|
Read one entry from the editor buffer stack and assign it to the
|
|||
|
first <code>name</code>, without word splitting. Text is pushed onto the stack
|
|||
|
with ‘<code>print -z</code>’ or with <code>push-line</code> from the line editor (see <a href="Zsh-Line-Editor.html#Zsh-Line-Editor">Zsh
|
|||
|
Line Editor</a>). This flag is
|
|||
|
ignored when the <code>-k</code> or <code>-q</code> flags are present.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-e</code><br />
|
|||
|
<code>-E</code><br />
|
|||
|
The input read is printed (echoed) to the standard output. If the
|
|||
|
<code>-e</code> flag is used, no input is assigned to the parameters.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-A</code><br />
|
|||
|
The first <code>name</code> is taken as the name of an array and all words are
|
|||
|
assigned to it.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-c</code><br />
|
|||
|
<code>-l</code><br />
|
|||
|
These flags are allowed only if called inside a function used for
|
|||
|
completion (specified with the <code>-K</code> flag to <code>compctl</code>). If the <code>-c</code>
|
|||
|
flag is given, the words of the current command are read. If the
|
|||
|
<code>-l</code> flag is given, the whole line is assigned as a scalar. If both
|
|||
|
flags are present, <code>-l</code> is used and <code>-c</code> is ignored.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-n</code><br />
|
|||
|
Together with <code>-c</code>, the number of the word the cursor is on is read.
|
|||
|
With <code>-l</code>, the index of the character the cursor is on is read. Note
|
|||
|
that the command name is word number 1, not word 0, and that when
|
|||
|
the cursor is at the end of the line, its character index is the
|
|||
|
length of the line plus one.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-u</code> <code>n</code><br />
|
|||
|
Input is read from file descriptor <code>n</code>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-p</code><br />
|
|||
|
Input is read from the coprocess.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-d</code> <code>delim</code><br />
|
|||
|
Input is terminated by the first character of <code>delim</code> instead of by
|
|||
|
newline.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-t</code> [ <code>num</code> ]<br />
|
|||
|
Test if input is available before attempting to read. If <code>num</code> is
|
|||
|
present, it must begin with a digit and will be evaluated to give a
|
|||
|
number of seconds, which may be a floating point number; in this
|
|||
|
case the read times out if input is not available within this time.
|
|||
|
If <code>num</code> is not present, it is taken to be zero, so that <code>read</code>
|
|||
|
returns immediately if no input is available. If no input is
|
|||
|
available, return status 1 and do not set any variables.</p>
|
|||
|
<p>This option is not available when reading from the editor buffer
|
|||
|
with <code>-z</code>, when called from within completion with <code>-c</code> or <code>-l</code>,
|
|||
|
with <code>-q</code> which clears the input queue before reading, or within zle
|
|||
|
where other mechanisms should be used to test for input.</p>
|
|||
|
<p>Note that read does not attempt to alter the input processing mode.
|
|||
|
The default mode is canonical input, in which an entire line is read
|
|||
|
at a time, so usually ‘<code>read -t</code>’ will not read anything until an
|
|||
|
entire line has been typed. However, when reading from the terminal
|
|||
|
with <code>-k</code> input is processed one key at a time; in this case, only
|
|||
|
availability of the first character is tested, so that e.g. ‘<code>read -t -k 2</code>’ can still block on the second character. Use two instances
|
|||
|
of ‘<code>read -t -k</code>’ if this is not what is wanted.</p>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
<p>If the first argument contains a ‘<code>?</code>’, the remainder of this word is
|
|||
|
used as a <code>prompt</code> on standard error when the shell is interactive.</p>
|
|||
|
<p>The value (exit status) of <code>read</code> is 1 when an end-of-file is
|
|||
|
encountered, or when <code>-c</code> or <code>-l</code> is present and the command is not
|
|||
|
called from a <code>compctl</code> function, or as described for <code>-q</code>. Otherwise
|
|||
|
the value is 0.</p>
|
|||
|
<p>The behavior of some combinations of the <code>-k</code>, <code>-p</code>, <code>-q</code>, <code>-u</code> and <code>-z</code>
|
|||
|
flags is undefined. Presently <code>-q</code> cancels all the others, <code>-p</code> cancels
|
|||
|
<code>-u</code>, <code>-k</code> cancels <code>-z</code>, and otherwise <code>-z</code> cancels both <code>-p</code> and <code>-u</code>.</p>
|
|||
|
<p>The <code>-c</code> or <code>-l</code> flags cancel any and all of <code>-kpquz</code>.</p>
|
|||
|
<p><span id="index-parameters_002c-marking-readonly"></span></p>
|
|||
|
<p><code>readonly</code></p>
|
|||
|
<p>Same as <code>typeset -r</code>. With the <code>POSIX_BUILTINS</code> option set, same as
|
|||
|
<code>typeset -gr</code>.</p>
|
|||
|
<p><span id="index-rehash"></span></p>
|
|||
|
<p><code>rehash</code></p>
|
|||
|
<p>Same as <code>hash -r</code>.</p>
|
|||
|
<p><span id="index-return"></span>
|
|||
|
<span id="index-functions_002c-returning-from"></span></p>
|
|||
|
<p><code>return</code> [ <code>n</code> ]</p>
|
|||
|
<p>Causes a shell function or ‘<code>.</code>’ script to return to the invoking script
|
|||
|
with the return status specified by an arithmetic expression <code>n</code>. If <code>n</code>
|
|||
|
is omitted, the return status is that of the last command executed.</p>
|
|||
|
<p>If <code>return</code> was executed from a trap in a <code>TRAP``NAL</code> function, the
|
|||
|
effect is different for zero and non-zero return status. With zero
|
|||
|
status (or after an implicit return at the end of the trap), the shell
|
|||
|
will return to whatever it was previously processing; with a non-zero
|
|||
|
status, the shell will behave as interrupted except that the return
|
|||
|
status of the trap is retained. Note that the numeric value of the
|
|||
|
signal which caused the trap is passed as the first argument, so the
|
|||
|
statement ‘<code>return $((128+$1))</code>’ will return the same status as if the
|
|||
|
signal had not been trapped.</p>
|
|||
|
<p><code>sched</code></p>
|
|||
|
<p>See <a href="Zsh-Modules.html#The-zsh_002fsched-Module">The zsh/sched Module</a>.</p>
|
|||
|
<p><span id="index-set"></span>
|
|||
|
<span id="index-parameters_002c-listing"></span>
|
|||
|
<span id="index-parameters_002c-positional"></span>
|
|||
|
<span id="index-parameters_002c-setting-array"></span>
|
|||
|
<span id="index-array-parameters_002c-setting"></span>
|
|||
|
<span id="index-KSH_005fARRAYS_002c-use-of-1"></span></p>
|
|||
|
<p><code>set </code>[ {<code>+</code>|<code>-</code>}<code>options</code> | {<code>+</code>|<code>-</code>}<code>o</code> [ <code>option_name</code> ] ] ...
|
|||
|
[ {<code>+</code>|<code>-</code>}<code>A</code> [ <code>name</code> ] ]</p>
|
|||
|
<p><code> </code>[ <code>arg</code> ... ]</p>
|
|||
|
<p>Set the options for the shell and/or set the positional parameters, or
|
|||
|
declare and set an array. If the <code>-s</code> option is given, it causes the
|
|||
|
specified arguments to be sorted before assigning them to the positional
|
|||
|
parameters (or to the array <code>name</code> if <code>-A</code> is used). With <code>+s</code> sort
|
|||
|
arguments in descending order. For the meaning of the other flags, see
|
|||
|
<a href="Options.html#Options">Options</a>. Flags may be specified by name using
|
|||
|
the <code>-o</code> option. If no option name is supplied with <code>-o</code>, the current
|
|||
|
option states are printed: see the description of <code>setopt</code> below for
|
|||
|
more information on the format. With <code>+o</code> they are printed in a form
|
|||
|
that can be used as input to the shell.</p>
|
|||
|
<p>If the <code>-A</code> flag is specified, <code>name</code> is set to an array containing the
|
|||
|
given <code>arg</code>s; if no <code>name</code> is specified, all arrays are printed together
|
|||
|
with their values.</p>
|
|||
|
<p>If <code>+A</code> is used and <code>name</code> is an array, the given arguments will replace
|
|||
|
the initial elements of that array; if no <code>name</code> is specified, all
|
|||
|
arrays are printed without their values.</p>
|
|||
|
<p>The behaviour of arguments after <code>-A</code> <code>name</code> or <code>+A</code> <code>name</code> depends on
|
|||
|
whether the option <code>KSH_ARRAYS</code> is set. If it is not set, all arguments
|
|||
|
following <code>name</code> are treated as values for the array, regardless of
|
|||
|
their form. If the option is set, normal option processing continues at
|
|||
|
that point; only regular arguments are treated as values for the array.
|
|||
|
This means that</p>
|
|||
|
<div class="example">
|
|||
|
<pre><code class="language-example">set -A array -x -- foo
|
|||
|
</code></pre>
|
|||
|
</div>
|
|||
|
<p>sets <code>array</code> to ‘<code>-x -``- foo</code>’ if <code>KSH_ARRAYS</code> is not set, but sets the
|
|||
|
array to <code>foo</code> and turns on the option ‘<code>-x</code>’ if it is set.</p>
|
|||
|
<p>If the <code>-A</code> flag is not present, but there are arguments beyond the
|
|||
|
options, the positional parameters are set. If the option list (if any)
|
|||
|
is terminated by ‘<code>-``-</code>’, and there are no further arguments, the
|
|||
|
positional parameters will be unset.</p>
|
|||
|
<p>If no arguments and no ‘<code>-``-</code>’ are given, then the names and values of
|
|||
|
all parameters are printed on the standard output. If the only argument
|
|||
|
is ‘<code>+</code>’, the names of all parameters are printed.</p>
|
|||
|
<p>For historical reasons, ‘<code>set -</code>’ is treated as ‘<code>set +xv</code>’ and ‘<code>set -</code>
|
|||
|
<code>args</code>’ as ‘<code>set +xv –</code> <code>args</code>’ when in any other emulation mode than
|
|||
|
zsh’s native mode.</p>
|
|||
|
<p><code>setcap</code></p>
|
|||
|
<p>See <a href="Zsh-Modules.html#The-zsh_002fcap-Module">The zsh/cap Module</a>.</p>
|
|||
|
<p><span id="index-setopt"></span>
|
|||
|
<span id="index-options_002c-setting"></span></p>
|
|||
|
<p><code>setopt</code> [ {<code>+</code>|<code>-</code>}<code>options</code> | {<code>+</code>|<code>-</code>}<code>o</code> <code>option_name</code> ] [ <code>-m</code>
|
|||
|
] [ <code>name</code> ... ]</p>
|
|||
|
<p>Set the options for the shell. All options specified either with flags
|
|||
|
or by name are set.</p>
|
|||
|
<p>If no arguments are supplied, the names of all options currently set are
|
|||
|
printed. The form is chosen so as to minimize the differences from the
|
|||
|
default options for the current emulation (the default emulation being
|
|||
|
native <code>zsh</code>, shown as <code><Z></code> in <a href="Options.html#Description-of-Options">Description of
|
|||
|
Options</a>). Options that are on by
|
|||
|
default for the emulation are shown with the prefix <code>no</code> only if they
|
|||
|
are off, while other options are shown without the prefix <code>no</code> and only
|
|||
|
if they are on. In addition to options changed from the default state by
|
|||
|
the user, any options activated automatically by the shell (for example,
|
|||
|
<code>SHIN_STDIN</code> or <code>INTERACTIVE</code>) will be shown in the list. The format is
|
|||
|
further modified by the option <code>KSH_OPTION_PRINT</code>, however the rationale
|
|||
|
for choosing options with or without the <code>no</code> prefix remains the same in
|
|||
|
this case.</p>
|
|||
|
<p>If the <code>-m</code> flag is given the arguments are taken as patterns (which
|
|||
|
should be quoted to protect them from filename expansion), and all
|
|||
|
options with names matching these patterns are set.</p>
|
|||
|
<p>Note that a bad option name does not cause execution of subsequent shell
|
|||
|
code to be aborted; this is behaviour is different from that of ‘<code>set -o</code>’. This is because <code>set</code> is regarded as a special builtin by the
|
|||
|
POSIX standard, but <code>setopt</code> is not.</p>
|
|||
|
<p><span id="index-shift"></span>
|
|||
|
<span id="index-parameters_002c-positional-1"></span></p>
|
|||
|
<p><code>shift</code> [ <code>-p</code> ] [ <code>n</code> ] [ <code>name</code> ... ]</p>
|
|||
|
<p>The positional parameters <code>${``n</code>+1<code>}</code> ... are renamed to <code>$1</code> ...,
|
|||
|
where <code>n</code> is an arithmetic expression that defaults to 1. If any <code>name</code>s
|
|||
|
are given then the arrays with these names are shifted instead of the
|
|||
|
positional parameters.</p>
|
|||
|
<p>If the option <code>-p</code> is given arguments are instead removed (popped) from
|
|||
|
the end rather than the start of the array.</p>
|
|||
|
<p><span id="index-source"></span></p>
|
|||
|
<p><code>source</code> <code>file</code> [ <code>arg</code> ... ]</p>
|
|||
|
<p>Same as ‘<code>.</code>’, except that the current directory is always searched and
|
|||
|
is always searched first, before directories in <code>$path</code>.</p>
|
|||
|
<p><code>stat</code></p>
|
|||
|
<p>See <a href="Zsh-Modules.html#The-zsh_002fstat-Module">The zsh/stat Module</a>.</p>
|
|||
|
<p><span id="index-suspend"></span>
|
|||
|
<span id="index-shell_002c-suspending"></span>
|
|||
|
<span id="index-suspending-the-shell"></span></p>
|
|||
|
<p><code>suspend</code> [ <code>-f</code> ]</p>
|
|||
|
<p>Suspend the execution of the shell (send it a <code>SIGTSTP</code>) until it
|
|||
|
receives a <code>SIGCONT</code>. Unless the <code>-f</code> option is given, this will refuse
|
|||
|
to suspend a login shell.</p>
|
|||
|
<p><span id="index-test"></span></p>
|
|||
|
<p><code>test</code> [ <code>arg</code> ... ]</p>
|
|||
|
<p><code>[</code> [ <code>arg</code> ... ] <code>]</code></p>
|
|||
|
<p>Like the system version of <code>test</code>. Added for compatibility; use
|
|||
|
conditional expressions instead (see <a href="Conditional-Expressions.html#Conditional-Expressions">Conditional
|
|||
|
Expressions</a>). The
|
|||
|
main differences between the conditional expression syntax and the
|
|||
|
<code>test</code> and <code>[</code> builtins are: these commands are not handled
|
|||
|
syntactically, so for example an empty variable expansion may cause an
|
|||
|
argument to be omitted; syntax errors cause status 2 to be returned
|
|||
|
instead of a shell error; and arithmetic operators expect integer
|
|||
|
arguments rather than arithmetic expressions.</p>
|
|||
|
<p>The command attempts to implement POSIX and its extensions where these
|
|||
|
are specified. Unfortunately there are intrinsic ambiguities in the
|
|||
|
syntax; in particular there is no distinction between test operators and
|
|||
|
strings that resemble them. The standard attempts to resolve these for
|
|||
|
small numbers of arguments (up to four); for five or more arguments
|
|||
|
compatibility cannot be relied on. Users are urged wherever possible to
|
|||
|
use the ‘<code>[[</code>’ test syntax which does not have these ambiguities.</p>
|
|||
|
<p><span id="index-times"></span>
|
|||
|
<span id="index-shell_002c-timing"></span>
|
|||
|
<span id="index-timing-the-shell"></span></p>
|
|||
|
<p><code>times</code></p>
|
|||
|
<p>Print the accumulated user and system times for the shell and for
|
|||
|
processes run from the shell.</p>
|
|||
|
<p><span id="index-trap"></span>
|
|||
|
<span id="index-signals_002c-trapping-1"></span>
|
|||
|
<span id="index-trapping-signals-1"></span></p>
|
|||
|
<p><code>trap</code> [ <code>arg</code> ] [ <code>sig</code> ... ]</p>
|
|||
|
<p><code>arg</code> is a series of commands (usually quoted to protect it from
|
|||
|
immediate evaluation by the shell) to be read and executed when the
|
|||
|
shell receives any of the signals specified by one or more <code>sig</code> args.
|
|||
|
Each <code>sig</code> can be given as a number, or as the name of a signal either
|
|||
|
with or without the string <code>SIG</code> in front (e.g. 1, HUP, and SIGHUP are
|
|||
|
all the same signal).</p>
|
|||
|
<p>If <code>arg</code> is ‘<code>-</code>’, then the specified signals are reset to their
|
|||
|
defaults, or, if no <code>sig</code> args are present, all traps are reset.</p>
|
|||
|
<p>If <code>arg</code> is an empty string, then the specified signals are ignored by
|
|||
|
the shell (and by the commands it invokes).</p>
|
|||
|
<p>If <code>arg</code> is omitted but one or more <code>sig</code> args are provided (i.e. the
|
|||
|
first argument is a valid signal number or name), the effect is the same
|
|||
|
as if <code>arg</code> had been specified as ‘<code>-</code>’.</p>
|
|||
|
<p>The <code>trap</code> command with no arguments prints a list of commands
|
|||
|
associated with each signal.</p>
|
|||
|
<p>If <code>sig</code> is <code>ZERR</code> then <code>arg</code> will be executed after each command with a
|
|||
|
nonzero exit status. <code>ERR</code> is an alias for <code>ZERR</code> on systems that have
|
|||
|
no <code>SIGERR</code> signal (this is the usual case).</p>
|
|||
|
<p>If <code>sig</code> is <code>DEBUG</code> then <code>arg</code> will be executed before each command if
|
|||
|
the option <code>DEBUG_BEFORE_CMD</code> is set (as it is by default), else after
|
|||
|
each command. Here, a ‘command’ is what is described as a ‘sublist’ in
|
|||
|
the shell grammar, see <a href="Shell-Grammar.html#Simple-Commands-_0026-Pipelines">Simple Commands &
|
|||
|
Pipelines</a>. If
|
|||
|
<code>DEBUG_BEFORE_CMD</code> is set various additional features are available.
|
|||
|
First, it is possible to skip the next command by setting the option
|
|||
|
<code>ERR_EXIT</code>; see the description of the <code>ERR_EXIT</code> option in <a href="Options.html#Description-of-Options">Description
|
|||
|
of Options</a>. Also, the shell
|
|||
|
parameter <code>ZSH_DEBUG_CMD</code> is set to the string corresponding to the
|
|||
|
command to be executed following the trap. Note that this string is
|
|||
|
reconstructed from the internal format and may not be formatted the same
|
|||
|
way as the original text. The parameter is unset after the trap is
|
|||
|
executed.</p>
|
|||
|
<p>If <code>sig</code> is <code>0</code> or <code>EXIT</code> and the <code>trap</code> statement is executed inside
|
|||
|
the body of a function, then the command <code>arg</code> is executed after the
|
|||
|
function completes. The value of <code>$?</code> at the start of execution is the
|
|||
|
exit status of the shell or the return status of the function exiting.
|
|||
|
If <code>sig</code> is <code>0</code> or <code>EXIT</code> and the <code>trap</code> statement is not executed
|
|||
|
inside the body of a function, then the command <code>arg</code> is executed when
|
|||
|
the shell terminates; the trap runs before any <code>zshexit</code> hook functions.</p>
|
|||
|
<p><code>ZERR</code>, <code>DEBUG</code>, and <code>EXIT</code> traps are not executed inside other traps.
|
|||
|
<code>ZERR</code> and <code>DEBUG</code> traps are kept within subshells, while other traps
|
|||
|
are reset.</p>
|
|||
|
<p>Note that traps defined with the <code>trap</code> builtin are slightly different
|
|||
|
from those defined as ‘<code>TRAP``NAL</code> () { ... }’, as the latter have their
|
|||
|
own function environment (line numbers, local variables, etc.) while the
|
|||
|
former use the environment of the command in which they were called. For
|
|||
|
example,</p>
|
|||
|
<div class="example">
|
|||
|
<pre><code class="language-example">trap 'print $LINENO' DEBUG
|
|||
|
</code></pre>
|
|||
|
</div>
|
|||
|
<p>will print the line number of a command executed after it has run, while</p>
|
|||
|
<div class="example">
|
|||
|
<pre><code class="language-example">TRAPDEBUG() { print $LINENO; }
|
|||
|
</code></pre>
|
|||
|
</div>
|
|||
|
<p>will always print the number zero.</p>
|
|||
|
<p>Alternative signal names are allowed as described under <code>kill</code> above.
|
|||
|
Defining a trap under either name causes any trap under an alternative
|
|||
|
name to be removed. However, it is recommended that for consistency
|
|||
|
users stick exclusively to one name or another.</p>
|
|||
|
<p><span id="index-true"></span>
|
|||
|
<span id="index-doing-nothing_002c-successfully"></span></p>
|
|||
|
<p><code>true</code> [ <code>arg</code> ... ]</p>
|
|||
|
<p>Do nothing and return an exit status of 0.</p>
|
|||
|
<p><span id="index-ttyctl"></span>
|
|||
|
<span id="index-tty_002c-freezing"></span></p>
|
|||
|
<p><code>ttyctl</code> [ <code>-fu</code> ]</p>
|
|||
|
<p>The <code>-f</code> option freezes the tty (i.e. terminal or terminal emulator),
|
|||
|
and <code>-u</code> unfreezes it. When the tty is frozen, no changes made to the
|
|||
|
tty settings by external programs will be honored by the shell, except
|
|||
|
for changes in the size of the screen; the shell will simply reset the
|
|||
|
settings to their previous values as soon as each command exits or is
|
|||
|
suspended. Thus, <code>stty</code> and similar programs have no effect when the tty
|
|||
|
is frozen. Freezing the tty does not cause the current state to be
|
|||
|
remembered: instead, it causes future changes to the state to be
|
|||
|
blocked.</p>
|
|||
|
<p>Without options it reports whether the terminal is frozen or not.</p>
|
|||
|
<p>Note that, regardless of whether the tty is frozen or not, the shell
|
|||
|
needs to change the settings when the line editor starts, so unfreezing
|
|||
|
the tty does not guarantee settings made on the command line are
|
|||
|
preserved. Strings of commands run between editing the command line will
|
|||
|
see a consistent tty state. See also the shell variable <code>STTY</code> for a
|
|||
|
means of initialising the tty before running external commands.</p>
|
|||
|
<p><span id="index-type"></span></p>
|
|||
|
<p><code>type</code> [ <code>-wfpamsS</code> ] <code>name</code> ...</p>
|
|||
|
<p>Equivalent to <code>whence -v</code>.</p>
|
|||
|
<p><span id="index-typeset"></span>
|
|||
|
<span id="index-parameters_002c-setting"></span>
|
|||
|
<span id="index-parameters_002c-declaring"></span></p>
|
|||
|
<p><code>typeset </code>[ {<code>+</code>|<code>-</code>}<code>AHUaghlmrtux</code> ] [ {<code>+</code>|<code>-</code>}<code>EFLRZip</code> [ <code>n</code>
|
|||
|
] ]</p>
|
|||
|
<p><code> </code>[ <code>+</code> ] [ <code>name</code>[<code>=``value</code>] ... ]</p>
|
|||
|
<p><code> typeset ``-T</code> [ {<code>+</code>|<code>-</code>}<code>Uglrux</code> ] [ {<code>+</code>|<code>-</code>}<code>LRZp</code> [ <code>n</code> ] ]</p>
|
|||
|
<p><code> </code>[ <code>+</code> | <code>SCALAR</code>[<code>=``value</code>] <code>array</code>[<code>=(``value</code> ...<code>)</code>]
|
|||
|
[ <code>sep</code> ] ]</p>
|
|||
|
<p><code>typeset</code> <code>-f</code> [ {<code>+</code>|<code>-</code>}<code>TUkmtuz</code> ] [ <code>+</code> ] [ <code>name</code> ... ]</p>
|
|||
|
<p>Set or display attributes and values for shell parameters.</p>
|
|||
|
<p>Except as noted below for control flags that change the behavior, a
|
|||
|
parameter is created for each <code>name</code> that does not already refer to one.
|
|||
|
When inside a function, a new parameter is created for every <code>name</code>
|
|||
|
(even those that already exist), and is unset again when the function
|
|||
|
completes. See <a href="Parameters.html#Local-Parameters">Local Parameters</a>. The
|
|||
|
same rules apply to special shell parameters, which retain their special
|
|||
|
attributes when made local.</p>
|
|||
|
<p>For each <code>name``=``value</code> assignment, the parameter <code>name</code> is set to
|
|||
|
<code>value</code>.</p>
|
|||
|
<p>If the shell option <code>TYPESET_SILENT</code> is not set, for each remaining
|
|||
|
<code>name</code> that refers to a parameter that is already set, the name and
|
|||
|
value of the parameter are printed in the form of an assignment. Nothing
|
|||
|
is printed for newly-created parameters, or when any attribute flags
|
|||
|
listed below are given along with the <code>name</code>. Using ‘<code>+</code>’ instead of
|
|||
|
minus to introduce an attribute turns it off.</p>
|
|||
|
<p>If no <code>name</code> is present, the names and values of all parameters are
|
|||
|
printed. In this case the attribute flags restrict the display to only
|
|||
|
those parameters that have the specified attributes, and using ‘<code>+</code>’
|
|||
|
rather than ‘<code>-</code>’ to introduce the flag suppresses printing of the
|
|||
|
values of parameters when there is no parameter name.</p>
|
|||
|
<p>All forms of the command handle scalar assignment. Array assignment is
|
|||
|
possible if any of the reserved words <code>declare</code>, <code>export</code>, <code>float</code>,
|
|||
|
<code>integer</code>, <code>local</code>, <code>readonly</code> or <code>typeset</code> is matched when the line is
|
|||
|
parsed (N.B. not when it is executed). In this case the arguments are
|
|||
|
parsed as assignments, except that the ‘<code>+=</code>’ syntax and the
|
|||
|
<code>GLOB_ASSIGN</code> option are not supported, and scalar values after <code>=</code> are
|
|||
|
<em>not</em> split further into words, even if expanded (regardless of the
|
|||
|
setting of the <code>KSH_TYPESET</code> option; this option is obsolete).</p>
|
|||
|
<p>Examples of the differences between command and reserved word parsing:</p>
|
|||
|
<div class="example">
|
|||
|
<pre><code class="language-example"># Reserved word parsing
|
|||
|
typeset svar=$(echo one word) avar=(several words)
|
|||
|
</code></pre>
|
|||
|
</div>
|
|||
|
<p>The above creates a scalar parameter <code>svar</code> and an array parameter
|
|||
|
<code>avar</code> as if the assignments had been</p>
|
|||
|
<div class="example">
|
|||
|
<pre><code class="language-example">svar="one word"
|
|||
|
avar=(several words)
|
|||
|
</code></pre>
|
|||
|
</div>
|
|||
|
<p>On the other hand:</p>
|
|||
|
<div class="example">
|
|||
|
<pre><code class="language-example"># Normal builtin interface
|
|||
|
builtin typeset svar=$(echo two words)
|
|||
|
</code></pre>
|
|||
|
</div>
|
|||
|
<p>The <code>builtin</code> keyword causes the above to use the standard builtin
|
|||
|
interface to <code>typeset</code> in which argument parsing is performed in the
|
|||
|
same way as for other commands. This example creates a scalar <code>svar</code>
|
|||
|
containing the value <code>two</code> and another scalar parameter <code>words</code> with no
|
|||
|
value. An array value in this case would either cause an error or be
|
|||
|
treated as an obscure set of glob qualifiers.</p>
|
|||
|
<p>Arbitrary arguments are allowed if they take the form of assignments
|
|||
|
after command line expansion; however, these only perform scalar
|
|||
|
assignment:</p>
|
|||
|
<div class="example">
|
|||
|
<pre><code class="language-example">var='svar=val'
|
|||
|
typeset $var
|
|||
|
</code></pre>
|
|||
|
</div>
|
|||
|
<p>The above sets the scalar parameter <code>svar</code> to the value <code>val</code>.
|
|||
|
Parentheses around the value within <code>var</code> would not cause array
|
|||
|
assignment as they will be treated as ordinary characters when <code>$var</code> is
|
|||
|
substituted. Any non-trivial expansion in the name part of the
|
|||
|
assignment causes the argument to be treated in this fashion:</p>
|
|||
|
<div class="example">
|
|||
|
<pre><code class="language-example">typeset {var1,var2,var3}=name
|
|||
|
</code></pre>
|
|||
|
</div>
|
|||
|
<p>The above syntax is valid, and has the expected effect of setting the
|
|||
|
three parameters to the same value, but the command line is parsed as a
|
|||
|
set of three normal command line arguments to <code>typeset</code> after expansion.
|
|||
|
Hence it is not possible to assign to multiple arrays by this means.</p>
|
|||
|
<p>Note that each interface to any of the commands my be disabled
|
|||
|
separately. For example, ‘<code>disable -r typeset</code>’ disables the reserved
|
|||
|
word interface to <code>typeset</code>, exposing the builtin interface, while
|
|||
|
‘<code>disable typeset</code>’ disables the builtin. Note that disabling the
|
|||
|
reserved word interface for <code>typeset</code> may cause problems with the output
|
|||
|
of ‘<code>typeset -p</code>’, which assumes the reserved word interface is
|
|||
|
available in order to restore array and associative array values.</p>
|
|||
|
<p>Unlike parameter assignment statements, <code>typeset</code>’s exit status on an
|
|||
|
assignment that involves a command substitution does not reflect the
|
|||
|
exit status of the command substitution. Therefore, to test for an error
|
|||
|
in a command substitution, separate the declaration of the parameter
|
|||
|
from its initialization:</p>
|
|||
|
<div class="example">
|
|||
|
<pre><code class="language-example"># WRONG
|
|||
|
typeset var1=$(exit 1) || echo "Trouble with var1"
|
|||
|
|
|||
|
# RIGHT
|
|||
|
typeset var1 && var1=$(exit 1) || echo "Trouble with var1"
|
|||
|
</code></pre>
|
|||
|
</div>
|
|||
|
<p>To initialize a parameter <code>param</code> to a command output and mark it
|
|||
|
readonly, use <code> typeset -r ``param</code> or <code> readonly ``param</code> after the
|
|||
|
parameter assignment statement.</p>
|
|||
|
<p>If no attribute flags are given, and either no <code>name</code> arguments are
|
|||
|
present or the flag <code>+m</code> is used, then each parameter name printed is
|
|||
|
preceded by a list of the attributes of that parameter (<code>array</code>,
|
|||
|
<code>association</code>, <code>exported</code>, <code>float</code>, <code>integer</code>, <code>readonly</code>, or
|
|||
|
<code>undefined</code> for autoloaded parameters not yet loaded). If <code>+m</code> is used
|
|||
|
with attribute flags, and all those flags are introduced with <code>+</code>, the
|
|||
|
matching parameter names are printed but their values are not.</p>
|
|||
|
<p>The following control flags change the behavior of <code>typeset</code>:</p>
|
|||
|
<ul>
|
|||
|
<li>
|
|||
|
<p><code>+</code><br />
|
|||
|
If ‘<code>+</code>’ appears by itself in a separate word as the last option,
|
|||
|
then the names of all parameters (functions with <code>-f</code>) are printed,
|
|||
|
but the values (function bodies) are not. No <code>name</code> arguments may
|
|||
|
appear, and it is an error for any other options to follow ‘<code>+</code>’.
|
|||
|
The effect of ‘<code>+</code>’ is as if all attribute flags which precede it
|
|||
|
were given with a ‘<code>+</code>’ prefix. For example, ‘<code>typeset -U +</code>’ is
|
|||
|
equivalent to ‘<code>typeset +U</code>’ and displays the names of all arrays
|
|||
|
having the uniqueness attribute, whereas ‘<code>typeset -f -U +</code>’
|
|||
|
displays the names of all autoloadable functions. If <code>+</code> is the only
|
|||
|
option, then type information (array, readonly, etc.) is also
|
|||
|
printed for each parameter, in the same manner as ‘<code>typeset +m "*"</code>’.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-g</code><br />
|
|||
|
The <code>-g</code> (global) means that any resulting parameter will not be
|
|||
|
restricted to local scope. Note that this does not necessarily mean
|
|||
|
that the parameter will be global, as the flag will apply to any
|
|||
|
existing parameter (even if unset) from an enclosing function. This
|
|||
|
flag does not affect the parameter after creation, hence it has no
|
|||
|
effect when listing existing parameters, nor does the flag <code>+g</code> have
|
|||
|
any effect except in combination with <code>-m</code> (see below).</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-m</code><br />
|
|||
|
If the <code>-m</code> flag is given the <code>name</code> arguments are taken as patterns
|
|||
|
(use quoting to prevent these from being interpreted as file
|
|||
|
patterns). With no attribute flags, all parameters (or functions
|
|||
|
with the <code>-f</code> flag) with matching names are printed (the shell
|
|||
|
option <code>TYPESET_SILENT</code> is not used in this case).</p>
|
|||
|
<p>If the <code>+g</code> flag is combined with <code>-m</code>, a new local parameter is
|
|||
|
created for every matching parameter that is not already local.
|
|||
|
Otherwise <code>-m</code> applies all other flags or assignments to the
|
|||
|
existing parameters.</p>
|
|||
|
<p>Except when assignments are made with <code>name``=``value</code>, using <code>+m</code>
|
|||
|
forces the matching parameters and their attributes to be printed,
|
|||
|
even inside a function. Note that <code>-m</code> is ignored if no patterns are
|
|||
|
given, so ‘<code>typeset -m</code>’ displays attributes but ‘<code>typeset -a +m</code>’
|
|||
|
does not.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-p</code> [ <code>n</code> ]<br />
|
|||
|
If the <code>-p</code> option is given, parameters and values are printed in
|
|||
|
the form of a typeset command with an assignment, regardless of
|
|||
|
other flags and options. Note that the <code>-H</code> flag on parameters is
|
|||
|
respected; no value will be shown for these parameters.</p>
|
|||
|
<p><code>-p</code> may be followed by an optional integer argument. Currently only
|
|||
|
the value <code>1</code> is supported. In this case arrays and associative
|
|||
|
arrays are printed with newlines between indented elements for
|
|||
|
readability.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-T</code> [ <code>scalar</code>[<code>=``value</code>] <code>array</code>[<code>=(``value</code> ...<code>)</code>] [
|
|||
|
<code>sep</code> ] ]<br />
|
|||
|
This flag has a different meaning when used with <code>-f</code>; see below.
|
|||
|
Otherwise the <code>-T</code> option requires zero, two, or three arguments to
|
|||
|
be present. With no arguments, the list of parameters created in
|
|||
|
this fashion is shown. With two or three arguments, the first two
|
|||
|
are the name of a scalar and of an array parameter (in that order)
|
|||
|
that will be tied together in the manner of <code>$PATH</code> and <code>$path</code>. The
|
|||
|
optional third argument is a single-character separator which will
|
|||
|
be used to join the elements of the array to form the scalar; if
|
|||
|
absent, a colon is used, as with <code>$PATH</code>. Only the first character
|
|||
|
of the separator is significant; any remaining characters are
|
|||
|
ignored. Multibyte characters are not yet supported.</p>
|
|||
|
<p>Only one of the scalar and array parameters may be assigned an
|
|||
|
initial value (the restrictions on assignment forms described above
|
|||
|
also apply).</p>
|
|||
|
<p>Both the scalar and the array may be manipulated as normal. If one
|
|||
|
is unset, the other will automatically be unset too. There is no way
|
|||
|
of untying the variables without unsetting them, nor of converting
|
|||
|
the type of one of them with another <code>typeset</code> command; <code>+T</code> does
|
|||
|
not work, assigning an array to <code>scalar</code> is an error, and assigning
|
|||
|
a scalar to <code>array</code> sets it to be a single-element array.</p>
|
|||
|
<p>Note that both ‘<code>typeset -xT ...</code>’ and ‘<code>export -T ...</code>’ work, but
|
|||
|
only the scalar will be marked for export. Setting the value using
|
|||
|
the scalar version causes a split on all separators (which cannot be
|
|||
|
quoted). It is possible to apply <code>-T</code> to two previously tied
|
|||
|
variables but with a different separator character, in which case
|
|||
|
the variables remain joined as before but the separator is changed.</p>
|
|||
|
<p>When an existing scalar is tied to a new array, the value of the
|
|||
|
scalar is preserved but no attribute other than export will be
|
|||
|
preserved.</p>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
<p>Attribute flags that transform the final value (<code>-L</code>, <code>-R</code>, <code>-Z</code>, <code>-l</code>,
|
|||
|
<code>-u</code>) are only applied to the expanded value at the point of a parameter
|
|||
|
expansion expression using ‘<code>$</code>’. They are not applied when a parameter
|
|||
|
is retrieved internally by the shell for any purpose.</p>
|
|||
|
<p>The following attribute flags may be specified:</p>
|
|||
|
<ul>
|
|||
|
<li>
|
|||
|
<p><code>-A</code><br />
|
|||
|
The names refer to associative array parameters; see <a href="Parameters.html#Array-Parameters">Array
|
|||
|
Parameters</a>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-L</code> [ <code>n</code> ]<br />
|
|||
|
Left justify and remove leading blanks from the value when the
|
|||
|
parameter is expanded. If <code>n</code> is nonzero, it defines the width of
|
|||
|
the field. If <code>n</code> is zero, the width is determined by the width of
|
|||
|
the value of the first assignment. In the case of numeric
|
|||
|
parameters, the length of the complete value assigned to the
|
|||
|
parameter is used to determine the width, not the value that would
|
|||
|
be output.</p>
|
|||
|
<p>The width is the count of characters, which may be multibyte
|
|||
|
characters if the <code>MULTIBYTE</code> option is in effect. Note that the
|
|||
|
screen width of the character is not taken into account; if this is
|
|||
|
required, use padding with parameter expansion flags
|
|||
|
<code>${(ml``...``)``...``}</code> as described in ‘Parameter Expansion Flags’
|
|||
|
in <a href="Expansion.html#Parameter-Expansion">Parameter Expansion</a>.</p>
|
|||
|
<p>When the parameter is expanded, it is filled on the right with
|
|||
|
blanks or truncated if necessary to fit the field. Note truncation
|
|||
|
can lead to unexpected results with numeric parameters. Leading
|
|||
|
zeros are removed if the <code>-Z</code> flag is also set.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-R</code> [ <code>n</code> ]<br />
|
|||
|
Similar to <code>-L</code>, except that right justification is used; when the
|
|||
|
parameter is expanded, the field is left filled with blanks or
|
|||
|
truncated from the end. May not be combined with the <code>-Z</code> flag.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-U</code><br />
|
|||
|
For arrays (but not for associative arrays), keep only the first
|
|||
|
occurrence of each duplicated value. This may also be set for tied
|
|||
|
parameters (see <code>-T</code>) or colon-separated special parameters like
|
|||
|
<code>PATH</code> or <code>FIGNORE</code>, etc. Note the flag takes effect on assignment,
|
|||
|
and the type of the variable being assigned to is determinative; for
|
|||
|
variables with shared values it is therefore recommended to set the
|
|||
|
flag for all interfaces, e.g. ‘<code>typeset -U PATH path</code>’.</p>
|
|||
|
<p>This flag has a different meaning when used with <code>-f</code>; see below.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-Z</code> [ <code>n</code> ]<br />
|
|||
|
Specially handled if set along with the <code>-L</code> flag. Otherwise,
|
|||
|
similar to <code>-R</code>, except that leading zeros are used for padding
|
|||
|
instead of blanks if the first non-blank character is a digit.
|
|||
|
Numeric parameters are specially handled: they are always eligible
|
|||
|
for padding with zeroes, and the zeroes are inserted at an
|
|||
|
appropriate place in the output.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-a</code><br />
|
|||
|
The names refer to array parameters. An array parameter may be
|
|||
|
created this way, but it may be assigned to in the <code>typeset</code>
|
|||
|
statement only if the reserved word form of <code>typeset</code> is enabled (as
|
|||
|
it is by default). When displaying, both normal and associative
|
|||
|
arrays are shown.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-f</code><br />
|
|||
|
The names refer to functions rather than parameters. No assignments
|
|||
|
can be made, and the only other valid flags are <code>-t</code>, <code>-T</code>, <code>-k</code>,
|
|||
|
<code>-u</code>, <code>-U</code> and <code>-z</code>. The flag <code>-t</code> turns on execution tracing for
|
|||
|
this function; the flag <code>-T</code> does the same, but turns off tracing
|
|||
|
for any named (not anonymous) function called from the present one,
|
|||
|
unless that function also has the <code>-t</code> or <code>-T</code> flag. The <code>-u</code> and
|
|||
|
<code>-U</code> flags cause the function to be marked for autoloading; <code>-U</code>
|
|||
|
also causes alias expansion to be suppressed when the function is
|
|||
|
loaded. See the description of the ‘<code>autoload</code>’ builtin for details.</p>
|
|||
|
<p>Note that the builtin <code>functions</code> provides the same basic
|
|||
|
capabilities as <code>typeset -f</code> but gives access to a few extra
|
|||
|
options; <code>autoload</code> gives further additional options for the case
|
|||
|
<code>typeset -fu</code> and <code>typeset -fU</code>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-h</code><br />
|
|||
|
<code>-H</code><br />
|
|||
|
Hide value: specifies that <code>typeset</code> will not display the value of
|
|||
|
the parameter when listing parameters; the display for such
|
|||
|
parameters is always as if the ‘<code>+</code>’ flag had been given. Use of the
|
|||
|
parameter is in other respects normal, and the option does not apply
|
|||
|
if the parameter is specified by name, or by pattern with the <code>-m</code>
|
|||
|
option. This is on by default for the parameters in the
|
|||
|
<code>zsh/parameter</code> and <code>zsh/mapfile</code> modules. Note, however, that
|
|||
|
unlike the <code>-h</code> flag this is also useful for non-special parameters.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-i</code> [ <code>n</code> ]<br />
|
|||
|
Use an internal integer representation. If <code>n</code> is nonzero it defines
|
|||
|
the output arithmetic base, otherwise it is determined by the first
|
|||
|
assignment. Bases from 2 to 36 inclusive are allowed.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-E</code> [ <code>n</code> ]<br />
|
|||
|
Use an internal double-precision floating point representation. On
|
|||
|
output the variable will be converted to scientific notation. If <code>n</code>
|
|||
|
is nonzero it defines the number of significant figures to display;
|
|||
|
the default is ten.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-F</code> [ <code>n</code> ]<br />
|
|||
|
Use an internal double-precision floating point representation. On
|
|||
|
output the variable will be converted to fixed-point decimal
|
|||
|
notation. If <code>n</code> is nonzero it defines the number of digits to
|
|||
|
display after the decimal point; the default is ten.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-l</code><br />
|
|||
|
Convert the result to lower case whenever the parameter is expanded.
|
|||
|
The value is <em>not</em> converted when assigned.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-r</code><br />
|
|||
|
The given <code>name</code>s are marked readonly. Note that if <code>name</code> is a
|
|||
|
special parameter, the readonly attribute can be turned on, but
|
|||
|
cannot then be turned off.</p>
|
|||
|
<p>If the <code>POSIX_BUILTINS</code> option is set, the readonly attribute is
|
|||
|
more restrictive: unset variables can be marked readonly and cannot
|
|||
|
then be set; furthermore, the readonly attribute cannot be removed
|
|||
|
from any variable.</p>
|
|||
|
<p>It is still possible to change other attributes of the variable
|
|||
|
though, some of which like <code>-U</code> or <code>-Z</code> would affect the value. More
|
|||
|
generally, the readonly attribute should not be relied on as a
|
|||
|
security mechanism.</p>
|
|||
|
<p>Note that in zsh (like in pdksh but unlike most other shells) it is
|
|||
|
still possible to create a local variable of the same name as this
|
|||
|
is considered a different variable (though this variable, too, can
|
|||
|
be marked readonly). Special variables that have been made readonly
|
|||
|
retain their value and readonly attribute when made local.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-t</code><br />
|
|||
|
Tags the named parameters. Tags have no special meaning to the
|
|||
|
shell. This flag has a different meaning when used with <code>-f</code>; see
|
|||
|
above.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-u</code><br />
|
|||
|
Convert the result to upper case whenever the parameter is expanded.
|
|||
|
The value is <em>not</em> converted when assigned. This flag has a
|
|||
|
different meaning when used with <code>-f</code>; see above.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-x</code><br />
|
|||
|
Mark for automatic export to the environment of subsequently
|
|||
|
executed commands. If the option <code>GLOBAL_EXPORT</code> is set, this
|
|||
|
implies the option <code>-g</code>, unless <code>+g</code> is also explicitly given; in
|
|||
|
other words the parameter is not made local to the enclosing
|
|||
|
function. This is for compatibility with previous versions of zsh.</p>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
<p><span id="index-ulimit"></span>
|
|||
|
<span id="index-resource-limits-1"></span>
|
|||
|
<span id="index-limits_002c-resource-1"></span></p>
|
|||
|
<p><code>ulimit</code> [ <code>-HSa</code> ] [ { <code>-bcdfiklmnpqrsTtvwx</code> | <code>-N</code> <code>resource</code> } [
|
|||
|
<code>limit</code> ] ... ]</p>
|
|||
|
<p>Set or display resource limits of the shell and the processes started by
|
|||
|
the shell. The value of <code>limit</code> can be a number in the unit specified
|
|||
|
below or one of the values ‘<code>unlimited</code>’, which removes the limit on the
|
|||
|
resource, or ‘<code>hard</code>’, which uses the current value of the hard limit on
|
|||
|
the resource.</p>
|
|||
|
<p>By default, only soft limits are manipulated. If the <code>-H</code> flag is given
|
|||
|
use hard limits instead of soft limits. If the <code>-S</code> flag is given
|
|||
|
together with the <code>-H</code> flag set both hard and soft limits.</p>
|
|||
|
<p>If no options are used, the file size limit (<code>-f</code>) is assumed.</p>
|
|||
|
<p>If <code>limit</code> is omitted the current value of the specified resources are
|
|||
|
printed. When more than one resource value is printed, the limit name
|
|||
|
and unit is printed before each value.</p>
|
|||
|
<p>When looping over multiple resources, the shell will abort immediately
|
|||
|
if it detects a badly formed argument. However, if it fails to set a
|
|||
|
limit for some other reason it will continue trying to set the remaining
|
|||
|
limits.</p>
|
|||
|
<p>Not all the following resources are supported on all systems. Running
|
|||
|
<code>ulimit -a</code> will show which are supported.</p>
|
|||
|
<ul>
|
|||
|
<li>
|
|||
|
<p><code>-a</code><br />
|
|||
|
Lists all of the current resource limits.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-b</code><br />
|
|||
|
Socket buffer size in bytes (N.B. not kilobytes)</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-c</code><br />
|
|||
|
512-byte blocks on the size of core dumps.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-d</code><br />
|
|||
|
Kilobytes on the size of the data segment.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-f</code><br />
|
|||
|
512-byte blocks on the size of files written.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-i</code><br />
|
|||
|
The number of pending signals.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-k</code><br />
|
|||
|
The number of kqueues allocated.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-l</code><br />
|
|||
|
Kilobytes on the size of locked-in memory.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-m</code><br />
|
|||
|
Kilobytes on the size of physical memory.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-n</code><br />
|
|||
|
open file descriptors.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-p</code><br />
|
|||
|
The number of pseudo-terminals.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-q</code><br />
|
|||
|
Bytes in POSIX message queues.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-r</code><br />
|
|||
|
Maximum real time priority. On some systems where this is not
|
|||
|
available, such as NetBSD, this has the same effect as <code>-T</code> for
|
|||
|
compatibility with <code>sh</code>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-s</code><br />
|
|||
|
Kilobytes on the size of the stack.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-T</code><br />
|
|||
|
The number of simultaneous threads available to the user.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-t</code><br />
|
|||
|
CPU seconds to be used.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-u</code><br />
|
|||
|
The number of processes available to the user.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-v</code><br />
|
|||
|
Kilobytes on the size of virtual memory. On some systems this refers
|
|||
|
to the limit called ‘address space’.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-w</code><br />
|
|||
|
Kilobytes on the size of swapped out memory.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-x</code><br />
|
|||
|
The number of locks on files.</p>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
<p>A resource may also be specified by integer in the form ‘<code>-N</code>
|
|||
|
<code>resource</code>’, where <code>resource</code> corresponds to the integer defined for
|
|||
|
the resource by the operating system. This may be used to set the limits
|
|||
|
for resources known to the shell which do not correspond to option
|
|||
|
letters. Such limits will be shown by number in the output of ‘<code>ulimit -a</code>’.</p>
|
|||
|
<p>The number may alternatively be out of the range of limits compiled into
|
|||
|
the shell. The shell will try to read or write the limit anyway, and
|
|||
|
will report an error if this fails.</p>
|
|||
|
<p><span id="index-umask"></span> <span id="index-umask-1"></span></p>
|
|||
|
<p><code>umask</code> [ <code>-S</code> ] [ <code>mask</code> ]</p>
|
|||
|
<p>The umask is set to <code>mask</code>. <code>mask</code> can be either an octal number or a
|
|||
|
symbolic value as described in man page chmod(1). If <code>mask</code> is omitted,
|
|||
|
the current value is printed. The <code>-S</code> option causes the mask to be
|
|||
|
printed as a symbolic value. Otherwise, the mask is printed as an octal
|
|||
|
number. Note that in the symbolic form the permissions you specify are
|
|||
|
those which are to be allowed (not denied) to the users specified.</p>
|
|||
|
<p><span id="index-aliases_002c-removing"></span></p>
|
|||
|
<p><code>unalias</code> [ <code>-ams</code> ] <code>name</code> ...</p>
|
|||
|
<p>Removes aliases. This command works the same as <code>unhash -a</code>, except that
|
|||
|
the <code>-a</code> option removes all regular or global aliases, or with <code>-s</code> all
|
|||
|
suffix aliases: in this case no <code>name</code> arguments may appear. The options
|
|||
|
<code>-m</code> (remove by pattern) and <code>-s</code> without <code>-a</code> (remove listed suffix
|
|||
|
aliases) behave as for <code>unhash -a</code>. Note that the meaning of <code>-a</code> is
|
|||
|
different between <code>unalias</code> and <code>unhash</code>.</p>
|
|||
|
<p><span id="index-functions_002c-removing"></span>
|
|||
|
<span id="index-unfunction"></span></p>
|
|||
|
<p><code>unfunction</code></p>
|
|||
|
<p>Same as <code>unhash -f</code>.</p>
|
|||
|
<p><span id="index-unhash"></span></p>
|
|||
|
<p><code>unhash</code> [ <code>-adfms</code> ] <code>name</code> ...</p>
|
|||
|
<p>option causes <code>unhash</code> to remove regular or global aliases; note when
|
|||
|
removing a global aliases that the argument must be quoted to prevent it
|
|||
|
from being expanded before being passed to the command. The <code>-s</code> option
|
|||
|
causes <code>unhash</code> to remove suffix aliases. The <code>-f</code> option causes
|
|||
|
<code>unhash</code> to remove shell functions. The <code>-d</code> options causes <code>unhash</code> to
|
|||
|
remove named directories. If the <code>-m</code> flag is given the arguments are
|
|||
|
taken as patterns (should be quoted) and all elements</p>
|
|||
|
<p><span id="index-unlimit"></span>
|
|||
|
<span id="index-resource-limits-2"></span>
|
|||
|
<span id="index-limits_002c-resource-2"></span></p>
|
|||
|
<p><code>unlimit</code> [ <code>-hs</code> ] <code>resource</code> ...</p>
|
|||
|
<p>The resource limit for each <code>resource</code> is set to the hard limit. If the
|
|||
|
<code>-h</code> flag is given and the shell has appropriate privileges, the hard
|
|||
|
resource limit for each <code>resource</code> is removed. The resources of the
|
|||
|
shell process are only changed if the <code>-s</code> flag is given.</p>
|
|||
|
<p>The <code>unlimit</code> command is not made available by default when the shell
|
|||
|
starts in a mode emulating another shell. It can be made available with
|
|||
|
the command ‘<code>zmodload -F zsh/rlimits b:unlimit</code>’.</p>
|
|||
|
<p><span id="index-unset"></span>
|
|||
|
<span id="index-parameters_002c-unsetting"></span></p>
|
|||
|
<p><code>unset</code> [ <code>-fmv</code> ] <code>name</code> ...</p>
|
|||
|
<p>Each named parameter is unset. Local parameters remain local even if
|
|||
|
unset; they appear unset within scope, but the previous value will still
|
|||
|
reappear when the scope ends.</p>
|
|||
|
<p>Individual elements of associative array parameters may be unset by
|
|||
|
using subscript syntax on <code>name</code>, which should be quoted (or the entire
|
|||
|
command prefixed with <code>noglob</code>) to protect the subscript from filename
|
|||
|
generation.</p>
|
|||
|
<p>If the <code>-m</code> flag is specified the arguments are taken as patterns
|
|||
|
(should be quoted) and all parameters with matching names are unset.
|
|||
|
Note that this cannot be used when unsetting associative array elements,
|
|||
|
as the subscript will be treated as part of the pattern.</p>
|
|||
|
<p>The <code>-v</code> flag specifies that <code>name</code> refers to parameters. This is the
|
|||
|
default behaviour.</p>
|
|||
|
<p><code>unset -f</code> is equivalent to <code>unfunction</code>.</p>
|
|||
|
<p><span id="index-unsetopt"></span>
|
|||
|
<span id="index-options_002c-unsetting"></span></p>
|
|||
|
<p><code>unsetopt</code> [ {<code>+</code>|<code>-</code>}<code>options</code> | {<code>+</code>|<code>-</code>}<code>o</code> <code>option_name</code> ] [
|
|||
|
<code>name</code> ... ]</p>
|
|||
|
<p>Unset the options for the shell. All options specified either with flags
|
|||
|
or by name are unset. If no arguments are supplied, the names of all
|
|||
|
options currently unset are printed. If the <code>-m</code> flag is given the
|
|||
|
arguments are taken as patterns (which should be quoted to preserve them
|
|||
|
from being interpreted as glob patterns), and all options with names
|
|||
|
matching these patterns are unset.</p>
|
|||
|
<p><code>vared</code></p>
|
|||
|
<p>See <a href="Zsh-Line-Editor.html#Zle-Builtins">Zle Builtins</a>.</p>
|
|||
|
<p><span id="index-wait"></span> <span id="index-waiting-for-jobs"></span>
|
|||
|
<span id="index-jobs_002c-waiting-for"></span></p>
|
|||
|
<p><code>wait</code> [ <code>job</code> ... ]</p>
|
|||
|
<p>Wait for the specified jobs or processes. If <code>job</code> is not given then all
|
|||
|
currently active child processes are waited for. Each <code>job</code> can be
|
|||
|
either a job specification or the process ID The exit status from this
|
|||
|
command is that of the job waited for. If <code>job</code> represents an unknown
|
|||
|
job or process ID, a warning is printed (unless the <code>POSIX_BUILTINS</code>
|
|||
|
option is set) and the exit status is 127.</p>
|
|||
|
<p>It is possible to wait for recent processes (specified by process ID,
|
|||
|
not by job) that were running in the background even if the process has
|
|||
|
exited. Typically the process ID will be recorded by capturing the value
|
|||
|
of the variable <code>$!</code> immediately after the process has been started.
|
|||
|
There is a limit on the number of process IDs remembered by the shell;
|
|||
|
this is given by the value of the system configuration parameter
|
|||
|
<code>CHILD_MAX</code>. When this limit is reached, older process IDs are
|
|||
|
discarded, least recently started processes first.</p>
|
|||
|
<p>Note there is no protection against the process ID wrapping, i.e. if the
|
|||
|
wait is not executed soon enough there is a chance the process waited
|
|||
|
for is the wrong one. A conflict implies both process IDs have been
|
|||
|
generated by the shell, as other processes are not recorded, and that
|
|||
|
the user is potentially interested in both, so this problem is intrinsic
|
|||
|
to process IDs.</p>
|
|||
|
<p><span id="index-whence"></span></p>
|
|||
|
<p><code>whence</code> [ <code>-vcwfpamsS</code> ] [ <code>-x</code> <code>num</code> ] <code>name</code> ...</p>
|
|||
|
<p>For each <code>name</code>, indicate how it would be interpreted if used as a
|
|||
|
command name.</p>
|
|||
|
<p>If <code>name</code> is not an alias, built-in command, external command, shell
|
|||
|
function, hashed command, or a reserved word, the exit status shall be
|
|||
|
non-zero, and — if <code>-v</code>, <code>-c</code>, or <code>-w</code> was passed — a message will be
|
|||
|
written to standard output. (This is different from other shells that
|
|||
|
write that message to standard error.)</p>
|
|||
|
<p><code>whence</code> is most useful when <code>name</code> is only the last path component of a
|
|||
|
command, i.e. does not include a ‘<code>/</code>’; in particular, pattern matching
|
|||
|
only succeeds if just the non-directory component of the command is
|
|||
|
passed.</p>
|
|||
|
<ul>
|
|||
|
<li>
|
|||
|
<p><code>-v</code><br />
|
|||
|
Produce a more verbose report.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-c</code><br />
|
|||
|
Print the results in a csh-like format. This takes precedence over
|
|||
|
<code>-v</code>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-w</code><br />
|
|||
|
For each <code>name</code>, print ‘<code>name``:</code> <code>word</code>’ where <code>word</code> is one of
|
|||
|
<code>alias</code>, <code>builtin</code>, <code>command</code>, <code>function</code>, <code>hashed</code>, <code>reserved</code> or
|
|||
|
<code>none</code>, according as <code>name</code> corresponds to an alias, a built-in
|
|||
|
command, an external command, a shell function, a command defined
|
|||
|
with the <code>hash</code> builtin, a reserved word, or is not recognised. This
|
|||
|
takes precedence over <code>-v</code> and <code>-c</code>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-f</code><br />
|
|||
|
Causes the contents of a shell function to be displayed, which would
|
|||
|
otherwise not happen unless the <code>-c</code> flag were used.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-p</code><br />
|
|||
|
Do a path search for <code>name</code> even if it is an alias, reserved word,
|
|||
|
shell function or builtin.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-a</code><br />
|
|||
|
Do a search for all occurrences of <code>name</code> throughout the command
|
|||
|
path. Normally only the first occurrence is printed.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-m</code><br />
|
|||
|
The arguments are taken as patterns (pattern characters should be
|
|||
|
quoted), and the information is displayed for each command matching
|
|||
|
one of these patterns.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-s</code><br />
|
|||
|
If a pathname contains symlinks, print the symlink-free pathname as
|
|||
|
well.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-S</code><br />
|
|||
|
As <code>-s</code>, but if the pathname had to be resolved by following
|
|||
|
multiple symlinks, the intermediate steps are printed, too. The
|
|||
|
symlink resolved at each step might be anywhere in the path.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-x</code> <code>num</code><br />
|
|||
|
Expand tabs when outputting shell functions using the <code>-c</code> option.
|
|||
|
This has the same effect as the <code>-x</code> option to the <code>functions</code>
|
|||
|
builtin.</p>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
<p><span id="index-where"></span></p>
|
|||
|
<p><code>where</code> [ <code>-wpmsS</code> ] [ <code>-x</code> <code>num</code> ] <code>name</code> ...</p>
|
|||
|
<p>Equivalent to <code>whence -ca</code>.</p>
|
|||
|
<p><span id="index-which"></span></p>
|
|||
|
<p><code>which</code> [ <code>-wpamsS</code> ] [ <code>-x</code> <code>num</code> ] <code>name</code> ...</p>
|
|||
|
<p>Equivalent to <code>whence -c</code>.</p>
|
|||
|
<p><span id="index-zcompile"></span>
|
|||
|
<span id="index-_002ezwc-files_002c-creation"></span>
|
|||
|
<span id="index-compilation"></span></p>
|
|||
|
<p><code>zcompile</code> [ <code>-U</code> ] [ <code>-z</code> | <code>-k</code> ] [ <code>-R</code> | <code>-M</code> ] <code>file</code> [
|
|||
|
<code>name</code> ... ]</p>
|
|||
|
<p><code>zcompile</code> <code>-ca</code> [ <code>-m</code> ] [ <code>-R</code> | <code>-M</code> ] <code>file</code> [ <code>name</code> ... ]</p>
|
|||
|
<p><code>zcompile -t</code> <code>file</code> [ <code>name</code> ... ]</p>
|
|||
|
<p>This builtin command can be used to compile functions or scripts,
|
|||
|
storing the compiled form in a file, and to examine files containing the
|
|||
|
compiled form. This allows faster autoloading of functions and sourcing
|
|||
|
of scripts by avoiding parsing of the text when the files are read.</p>
|
|||
|
<p>The first form (without the <code>-c</code>, <code>-a</code> or <code>-t</code> options) creates a
|
|||
|
compiled file. If only the <code>file</code> argument is given, the output file has
|
|||
|
the name ‘<code>file``.zwc</code>’ and will be placed in the same directory as the
|
|||
|
<code>file</code>. The shell will load the compiled file instead of the normal
|
|||
|
function file when the function is autoloaded; see
|
|||
|
<a href="Functions.html#Functions">Functions</a> for a description of how
|
|||
|
autoloaded functions are searched. The extension <code>.zwc</code> stands for ‘zsh
|
|||
|
word code’.</p>
|
|||
|
<p><span id="index-fpath_002c-with-zcompile"></span></p>
|
|||
|
<p>If there is at least one <code>name</code> argument, all the named files are
|
|||
|
compiled into the output <code>file</code> given as the first argument. If <code>file</code>
|
|||
|
does not end in <code>.zwc</code>, this extension is automatically appended. Files
|
|||
|
containing multiple compiled functions are called ‘digest’ files, and
|
|||
|
are intended to be used as elements of the <code>FPATH</code>/<code>fpath</code> special
|
|||
|
array.</p>
|
|||
|
<p>The second form, with the <code>-c</code> or <code>-a</code> options, writes the compiled
|
|||
|
definitions for all the named functions into <code>file</code>. For <code>-c</code>, the names
|
|||
|
must be functions currently defined in the shell, not those marked for
|
|||
|
autoloading. Undefined functions that are marked for autoloading may be
|
|||
|
written by using the <code>-a</code> option, in which case the <code>fpath</code> is searched
|
|||
|
and the contents of the definition files for those functions, if found,
|
|||
|
are compiled into <code>file</code>. If both <code>-c</code> and <code>-a</code> are given, names of both
|
|||
|
defined functions and functions marked for autoloading may be given. In
|
|||
|
either case, the functions in files written with the <code>-c</code> or <code>-a</code> option
|
|||
|
will be autoloaded as if the <code>KSH_AUTOLOAD</code> option were unset.</p>
|
|||
|
<p>The reason for handling loaded and not-yet-loaded functions with
|
|||
|
different options is that some definition files for autoloading define
|
|||
|
multiple functions, including the function with the same name as the
|
|||
|
file, and, at the end, call that function. In such cases the output of
|
|||
|
‘<code>zcompile -c</code>’ does not include the additional functions defined in
|
|||
|
the file, and any other initialization code in the file is lost. Using
|
|||
|
‘<code>zcompile -a</code>’ captures all this extra information.</p>
|
|||
|
<p>If the <code>-m</code> option is combined with <code>-c</code> or <code>-a</code>, the <code>name</code>s are used
|
|||
|
as patterns and all functions whose names match one of these patterns
|
|||
|
will be written. If no <code>name</code> is given, the definitions of all functions
|
|||
|
currently defined or marked as autoloaded will be written.</p>
|
|||
|
<p>Note the second form cannot be used for compiling functions that include
|
|||
|
redirections as part of the definition rather than within the body of
|
|||
|
the function; for example</p>
|
|||
|
<div class="example">
|
|||
|
<pre><code class="language-example">fn1() { { ... } >~/logfile }
|
|||
|
</code></pre>
|
|||
|
</div>
|
|||
|
<p>can be compiled but</p>
|
|||
|
<div class="example">
|
|||
|
<pre><code class="language-example">fn1() { ... } >~/logfile
|
|||
|
</code></pre>
|
|||
|
</div>
|
|||
|
<p>cannot. It is possible to use the first form of <code>zcompile</code> to compile
|
|||
|
autoloadable functions that include the full function definition instead
|
|||
|
of just the body of the function.</p>
|
|||
|
<p>The third form, with the <code>-t</code> option, examines an existing compiled
|
|||
|
file. Without further arguments, the names of the original files
|
|||
|
compiled into it are listed. The first line of output shows the version
|
|||
|
of the shell which compiled the file and how the file will be used (i.e.
|
|||
|
by reading it directly or by mapping it into memory). With arguments,
|
|||
|
nothing is output and the return status is set to zero if definitions
|
|||
|
for <em>all</em> <code>name</code>s were found in the compiled file, and non-zero if the
|
|||
|
definition for at least one <code>name</code> was not found.</p>
|
|||
|
<p>Other options:</p>
|
|||
|
<ul>
|
|||
|
<li>
|
|||
|
<p><code>-U</code><br />
|
|||
|
Aliases are not expanded when compiling the <code>name</code>d files.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-R</code><br />
|
|||
|
When the compiled file is read, its contents are copied into the
|
|||
|
shell’s memory, rather than memory-mapped (see <code>-M</code>). This happens
|
|||
|
automatically on systems that do not support memory mapping.</p>
|
|||
|
<p>When compiling scripts instead of autoloadable functions, it is
|
|||
|
often desirable to use this option; otherwise the whole file,
|
|||
|
including the code to define functions which have already been
|
|||
|
defined, will remain mapped, consequently wasting memory.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-M</code><br />
|
|||
|
The compiled file is mapped into the shell’s memory when read. This
|
|||
|
is done in such a way that multiple instances of the shell running
|
|||
|
on the same host will share this mapped file. If neither <code>-R</code> nor
|
|||
|
<code>-M</code> is given, the <code>zcompile</code> builtin decides what to do based on
|
|||
|
the size of the compiled file.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>-k</code><br />
|
|||
|
<code>-z</code><br />
|
|||
|
These options are used when the compiled file contains functions
|
|||
|
which are to be autoloaded. If <code>-z</code> is given, the function will be
|
|||
|
autoloaded as if the <code>KSH_AUTOLOAD</code> option is <em>not</em> set, even if it
|
|||
|
is set at the time the compiled file is read, while if the <code>-k</code> is
|
|||
|
given, the function will be loaded as if <code>KSH_AUTOLOAD</code> <em>is</em> set.
|
|||
|
These options also take precedence over any <code>-k</code> or <code>-z</code> options
|
|||
|
specified to the <code>autoload</code> builtin. If neither of these options is
|
|||
|
given, the function will be loaded as determined by the setting of
|
|||
|
the <code>KSH_AUTOLOAD</code> option at the time the compiled file is read.</p>
|
|||
|
<p>These options may also appear as many times as necessary between the
|
|||
|
listed <code>name</code>s to specify the loading style of all following
|
|||
|
functions, up to the next <code>-k</code> or <code>-z</code>.</p>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
<p>The created file always contains two versions of the compiled format,
|
|||
|
one for big-endian machines and one for small-endian machines. The
|
|||
|
upshot of this is that the compiled file is machine independent and if
|
|||
|
it is read or mapped, only one half of the file is actually used (and
|
|||
|
mapped).</p>
|
|||
|
<p><code>zformat</code></p>
|
|||
|
<p>See <a href="Zsh-Modules.html#The-zsh_002fzutil-Module">The zsh/zutil Module</a>.</p>
|
|||
|
<p><code>zftp</code></p>
|
|||
|
<p>See <a href="Zsh-Modules.html#The-zsh_002fzftp-Module">The zsh/zftp Module</a>.</p>
|
|||
|
<p><code>zle</code></p>
|
|||
|
<p>See <a href="Zsh-Line-Editor.html#Zle-Builtins">Zle Builtins</a>.</p>
|
|||
|
<p><span id="index-zmodload"></span>
|
|||
|
<span id="index-modules_002c-loading"></span>
|
|||
|
<span id="index-loading-modules"></span></p>
|
|||
|
<p><code>zmodload</code> [ <code>-dL</code> ] [ <code>-s</code> ] [ ... ]</p>
|
|||
|
<p><code>zmodload -F</code> [ <code>-alLme</code> <code>-P</code> <code>param</code> ] <code>module</code> [ [<code>+-</code>]<code>feature</code>
|
|||
|
... ]</p>
|
|||
|
<p><code>zmodload -e</code> [ <code>-A</code> ] [ ... ]</p>
|
|||
|
<p><code>zmodload</code> [ <code>-a</code> [ <code>-bcpf</code> [ <code>-I</code> ] ] ] [ <code>-iL</code> ] ...</p>
|
|||
|
<p><code>zmodload</code> <code>-u</code> [ <code>-abcdpf</code> [ <code>-I</code> ] ] [ <code>-iL</code> ] ...</p>
|
|||
|
<p><code>zmodload</code> <code>-A</code> [ <code>-L</code> ] [ <code>modalias</code>[<code>=``module</code>] ... ]</p>
|
|||
|
<p><code>zmodload</code> <code>-R</code> <code>modalias</code> ...</p>
|
|||
|
<p>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 <code>zmodload</code> command itself is
|
|||
|
always available and can be used to manipulate modules built into
|
|||
|
versions of the</p>
|
|||
|
<p>Without arguments the names of all currently loaded binary modules are
|
|||
|
printed. The <code>-L</code> option causes this list to be in the form of a series
|
|||
|
of <code>zmodload</code> commands. Forms with arguments are:</p>
|
|||
|
<ul>
|
|||
|
<li>
|
|||
|
<p><code>zmodload</code> [ <code>-is</code> ] <code>name</code> ...<br />
|
|||
|
<code>zmodload</code> <code>-u</code> [ <code>-i</code> ] <code>name</code> ...<br />
|
|||
|
In the simplest case, <code>zmodload</code> loads a binary module. The module
|
|||
|
must be in a file with a name consisting of the specified <code>name</code>
|
|||
|
followed by a standard suffix, usually ‘<code>.so</code>’ (‘<code>.sl</code>’ on HPUX). If
|
|||
|
the module to be loaded is already loaded the duplicate module is
|
|||
|
ignored. If <code>zmodload</code> 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 <code>-i</code> is accepted for compatibility but has no effect.</p>
|
|||
|
<p>The <code>name</code>d module is searched for in the same way a command is,
|
|||
|
using <code>$module_path</code> instead of <code>$path</code>. However, the path search is
|
|||
|
performed even when the module name contains a ‘<code>/</code>’, which it
|
|||
|
usually does. There is no way to prevent the path search.</p>
|
|||
|
<p>If the module supports features (see below), <code>zmodload</code> tries to
|
|||
|
enable all features when loading a module. If the module was
|
|||
|
successfully loaded but not all features could be enabled,
|
|||
|
<code>zmodload</code> returns status 2.</p>
|
|||
|
<p>If the option <code>-s</code> 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.</p>
|
|||
|
<p>With <code>-u</code>, <code>zmodload</code> unloads modules. The same <code>name</code> 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 <code>-i</code> option
|
|||
|
suppresses the error if the module is already unloaded (or was never
|
|||
|
loaded).</p>
|
|||
|
<p>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.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>zmodload -F</code> [ <code>-almLe</code> <code>-P</code> <code>param</code> ] <code>module</code> [
|
|||
|
[<code>+-</code>]<code>feature</code> ... ]<br />
|
|||
|
<code>zmodload -F</code> allows more selective control over the features
|
|||
|
provided by modules. With no options apart from <code>-F</code>, the module
|
|||
|
named <code>module</code> is loaded, if it was not already loaded, and the list
|
|||
|
of <code>feature</code>s is set to the required state. If no <code>feature</code>s 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 <code>+</code> to turn the feature on, or <code>-</code> to turn it off; the <code>+</code> 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.</p>
|
|||
|
<p>The standard features are builtins, conditions, parameters and math
|
|||
|
functions; these are indicated by the prefix ‘<code>b:</code>’, ‘<code>c:</code>’ (‘<code>C:</code>’
|
|||
|
for an infix condition), ‘<code>p:</code>’ and ‘<code>f:</code>’, respectively, followed
|
|||
|
by the name that the corresponding feature would have in the shell.
|
|||
|
For example, ‘<code>b:strftime</code>’ indicates a builtin named <code>strftime</code> and
|
|||
|
<code>p:EPOCHSECONDS</code> indicates a parameter named <code>EPOCHSECONDS</code>. The
|
|||
|
module may provide other (‘abstract’) features of its own as
|
|||
|
indicated by its documentation; these have no prefix.</p>
|
|||
|
<p>With <code>-l</code> or <code>-L</code>, features provided by the module are listed. With
|
|||
|
<code>-l</code> alone, a list of features together with their states is shown,
|
|||
|
one feature per line. With <code>-L</code> alone, a <code>zmodload -F</code> command that
|
|||
|
would cause enabled features of the module to be turned on is shown.
|
|||
|
With <code>-lL</code>, a <code>zmodload -F</code> 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 <code>-P</code> <code>param</code> then the
|
|||
|
parameter <code>param</code> is set to an array of features, either features
|
|||
|
together with their state or (if <code>-L</code> alone is given) enabled
|
|||
|
features.</p>
|
|||
|
<p>With the option <code>-L</code> the module name may be omitted; then a list of
|
|||
|
all enabled features for all modules providing features is printed
|
|||
|
in the form of <code>zmodload -F</code> commands. If <code>-l</code> is also given, the
|
|||
|
state of both enabled and disabled features is output in that form.</p>
|
|||
|
<p>A set of features may be provided together with <code>-l</code> or <code>-L</code> and a
|
|||
|
module name; in that case only the state of those features is
|
|||
|
considered. Each feature may be preceded by <code>+</code> or <code>-</code> but the
|
|||
|
character has no effect. If no set of features is provided, all
|
|||
|
features are considered.</p>
|
|||
|
<p>With <code>-e</code>, 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 <code>+</code> or <code>-</code> 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.</p>
|
|||
|
<p>With <code>-m</code>, 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 <code>+</code> or <code>-</code> must be given explicitly. This may not
|
|||
|
be combined with the <code>-a</code> option as autoloads must be specified
|
|||
|
explicitly.</p>
|
|||
|
<p>With <code>-a</code>, the given list of features is marked for autoload from
|
|||
|
the specified module, which may not yet be loaded. An optional <code>+</code>
|
|||
|
may appear before the feature name. If the feature is prefixed with
|
|||
|
<code>-</code>, any existing autoload is removed. The options <code>-l</code> and <code>-L</code> 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 ‘<code>zmodload -Fa</code> <code>module</code>
|
|||
|
<code>-``feature</code>’ is issued. It is not an error to request an autoload
|
|||
|
for a feature of a module that is already loaded.</p>
|
|||
|
<p>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 <code>zmodload -Fa</code> is run, an error message is printed and
|
|||
|
status 1 returned.</p>
|
|||
|
<p><code>zmodload -Fa</code> can be used with the <code>-l</code>, <code>-L</code>, <code>-e</code> and <code>-P</code>
|
|||
|
options for listing and testing the existence of autoloadable
|
|||
|
features. In this case <code>-l</code> is ignored if <code>-L</code> is specified.
|
|||
|
<code>zmodload -FaL</code> with no module name lists autoloads for all modules.</p>
|
|||
|
<p>Note that only standard features as described above can be
|
|||
|
autoloaded; other features require the module to be loaded before
|
|||
|
enabling.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>zmodload</code> <code>-d</code> [ <code>-L</code> ] [ <code>name</code> ]<br />
|
|||
|
<code>zmodload</code> <code>-d</code> <code>name</code> <code>dep</code> ...<br />
|
|||
|
<code>zmodload</code> <code>-ud</code> <code>name</code> [ <code>dep</code> ... ]<br />
|
|||
|
The <code>-d</code> 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.</p>
|
|||
|
<p>With <code>-d</code> and one argument, all dependencies for that module are
|
|||
|
listed. With <code>-d</code> and no arguments, all module dependencies are
|
|||
|
listed. This listing is by default in a Makefile-like format. The
|
|||
|
<code>-L</code> option changes this format to a list of <code>zmodload -d</code> commands.</p>
|
|||
|
<p>If <code>-d</code> and <code>-u</code> are both used, dependencies are removed. If only
|
|||
|
one argument is given, all dependencies for that module are removed.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>zmodload</code> <code>-ab</code> [ <code>-L</code> ]<br />
|
|||
|
<code>zmodload</code> <code>-ab</code> [ <code>-i</code> ] <code>name</code> [ <code>builtin</code> ... ]<br />
|
|||
|
<code>zmodload</code> <code>-ub</code> [ <code>-i</code> ] <code>builtin</code> ...<br />
|
|||
|
The <code>-ab</code> option defines autoloaded builtins. It defines the
|
|||
|
specified <code>builtin</code>s. 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
|
|||
|
‘<code>zmodload -F -a</code>’ as described above). If only the <code>name</code> is
|
|||
|
given, one builtin is defined, with the same name as the module.
|
|||
|
<code>-i</code> suppresses the error if the builtin is already defined or
|
|||
|
autoloaded, but not if another builtin of the same name is already
|
|||
|
defined.</p>
|
|||
|
<p>With <code>-ab</code> and no arguments, all autoloaded builtins are listed,
|
|||
|
with the module name (if different) shown in parentheses after the
|
|||
|
builtin name. The <code>-L</code> option changes this format to a list of
|
|||
|
<code>zmodload -a</code> commands.</p>
|
|||
|
<p>If <code>-b</code> is used together with the <code>-u</code> option, it removes builtins
|
|||
|
previously defined with <code>-ab</code>. This is only possible if the builtin
|
|||
|
is not yet loaded. <code>-i</code> suppresses the error if the builtin is
|
|||
|
already removed (or never existed).</p>
|
|||
|
<p>Autoload requests are retained if the module is subsequently
|
|||
|
unloaded until an explicit ‘<code>zmodload -ub</code> <code>builtin</code>’ is issued.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>zmodload</code> <code>-ac</code> [ <code>-IL</code> ]<br />
|
|||
|
<code>zmodload</code> <code>-ac</code> [ <code>-iI</code> ] <code>name</code> [ <code>cond</code> ... ]<br />
|
|||
|
<code>zmodload</code> <code>-uc</code> [ <code>-iI</code> ] <code>cond</code> ...<br />
|
|||
|
The <code>-ac</code> option is used to define autoloaded condition codes. The
|
|||
|
<code>cond</code> strings give the names of the conditions defined by the
|
|||
|
module. The optional <code>-I</code> option is used to define infix condition
|
|||
|
names. Without this option prefix condition names are defined.</p>
|
|||
|
<p>If given no condition names, all defined names are listed (as a
|
|||
|
series of <code>zmodload</code> commands if the <code>-L</code> option is given).</p>
|
|||
|
<p>The <code>-uc</code> option removes definitions for autoloaded conditions.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>zmodload</code> <code>-ap</code> [ <code>-L</code> ]<br />
|
|||
|
<code>zmodload</code> <code>-ap</code> [ <code>-i</code> ] <code>name</code> [ <code>parameter</code> ... ]<br />
|
|||
|
<code>zmodload</code> <code>-up</code> [ <code>-i</code> ] <code>parameter</code> ...<br />
|
|||
|
The <code>-p</code> option is like the <code>-b</code> and <code>-c</code> options, but makes
|
|||
|
<code>zmodload</code> work on autoloaded parameters instead.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>zmodload</code> <code>-af</code> [ <code>-L</code> ]<br />
|
|||
|
<code>zmodload</code> <code>-af</code> [ <code>-i</code> ] <code>name</code> [ <code>function</code> ... ]<br />
|
|||
|
<code>zmodload</code> <code>-uf</code> [ <code>-i</code> ] <code>function</code> ...<br />
|
|||
|
The <code>-f</code> option is like the <code>-b</code>, <code>-p</code>, and <code>-c</code> options, but makes
|
|||
|
<code>zmodload</code> work on autoloaded math functions instead.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>zmodload</code> <code>-a</code> [ <code>-L</code> ]<br />
|
|||
|
<code>zmodload</code> <code>-a</code> [ <code>-i</code> ] <code>name</code> [ <code>builtin</code> ... ]<br />
|
|||
|
<code>zmodload</code> <code>-ua</code> [ <code>-i</code> ] <code>builtin</code> ...<br />
|
|||
|
Equivalent to <code>-ab</code> and <code>-ub</code>.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>zmodload -e</code> [ <code>-A</code> ] [ <code>string</code> ... ]<br />
|
|||
|
The <code>-e</code> option without arguments lists all loaded modules; if the
|
|||
|
<code>-A</code> 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 <code>string</code>s given as
|
|||
|
arguments are names of loaded modules and to one if at least on
|
|||
|
<code>string</code> 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 <code>-A</code> flag is
|
|||
|
not used.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>zmodload</code> <code>-A</code> [ <code>-L</code> ] [ <code>modalias</code>[<code>=``module</code>] ... ]<br />
|
|||
|
For each argument, if both <code>modalias</code> and <code>module</code> are given, define
|
|||
|
<code>modalias</code> to be an alias for the module <code>module</code>. If the module
|
|||
|
<code>modalias</code> is ever subsequently requested, either via a call to
|
|||
|
<code>zmodload</code> or implicitly, the shell will attempt to load <code>module</code>
|
|||
|
instead. If <code>module</code> is not given, show the definition of
|
|||
|
<code>modalias</code>. If no arguments are given, list all defined module
|
|||
|
aliases. When listing, if the <code>-L</code> flag was also given, list the
|
|||
|
definition as a <code>zmodload</code> command to recreate the alias.</p>
|
|||
|
<p>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 <code>zmodload -R</code> 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, ‘<code>any/old/alias</code>’ is always a valid alias.</p>
|
|||
|
<p>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.</p>
|
|||
|
<p>Apart from the above, aliases can be used in the <code>zmodload</code> command
|
|||
|
anywhere module names are required. However, aliases will not be
|
|||
|
shown in lists of loaded modules with a bare ‘<code>zmodload</code>’.</p>
|
|||
|
</li>
|
|||
|
<li>
|
|||
|
<p><code>zmodload</code> <code>-R</code> <code>modalias</code> ...<br />
|
|||
|
For each <code>modalias</code> argument that was previously defined as a module
|
|||
|
alias via <code>zmodload -A</code>, delete the alias. If any was not defined,
|
|||
|
an error is caused and the remainder of the line is ignored.</p>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
<p>Note that <code>zsh</code> 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.</p>
|
|||
|
<p><code>zparseopts</code></p>
|
|||
|
<p>See <a href="Zsh-Modules.html#The-zsh_002fzutil-Module">The zsh/zutil Module</a>.</p>
|
|||
|
<p><code>zprof</code></p>
|
|||
|
<p>See <a href="Zsh-Modules.html#The-zsh_002fzprof-Module">The zsh/zprof Module</a>.</p>
|
|||
|
<p><code>zpty</code></p>
|
|||
|
<p>See <a href="Zsh-Modules.html#The-zsh_002fzpty-Module">The zsh/zpty Module</a>.</p>
|
|||
|
<p><code>zregexparse</code></p>
|
|||
|
<p>See <a href="Zsh-Modules.html#The-zsh_002fzutil-Module">The zsh/zutil Module</a>.</p>
|
|||
|
<p><code>zsocket</code></p>
|
|||
|
<p>See <a href="Zsh-Modules.html#The-zsh_002fnet_002fsocket-Module">The zsh/net/socket
|
|||
|
Module</a>.</p>
|
|||
|
<p><code>zstyle</code></p>
|
|||
|
<p>See <a href="Zsh-Modules.html#The-zsh_002fzutil-Module">The zsh/zutil Module</a>.</p>
|
|||
|
<p><code>ztcp</code></p>
|
|||
|
<p>See <a href="Zsh-Modules.html#The-zsh_002fnet_002ftcp-Module">The zsh/net/tcp
|
|||
|
Module</a>.</p>
|
|||
|
<hr />
|
|||
|
<p>This document was generated on <em>February 15, 2020</em> using
|
|||
|
<a href="http://www.nongnu.org/texi2html/"><em>texi2html 5.0</em></a>.<br />
|
|||
|
Zsh version 5.8, released on February 14, 2020.</p>
|
|||
|
|
|||
|
</main>
|
|||
|
|
|||
|
<nav class="nav-wrapper" aria-label="Page navigation">
|
|||
|
<!-- Mobile navigation buttons -->
|
|||
|
|
|||
|
<a rel="prev" href="Options.html" class="mobile-nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
|||
|
<i class="fa fa-angle-left"></i>
|
|||
|
</a>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<a rel="next" href="Zsh-Line-Editor.html" class="mobile-nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
|||
|
<i class="fa fa-angle-right"></i>
|
|||
|
</a>
|
|||
|
|
|||
|
|
|||
|
<div style="clear: both"></div>
|
|||
|
</nav>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
|
|||
|
<nav class="nav-wide-wrapper" aria-label="Page navigation">
|
|||
|
|
|||
|
<a rel="prev" href="Options.html" class="nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
|||
|
<i class="fa fa-angle-left"></i>
|
|||
|
</a>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<a rel="next" href="Zsh-Line-Editor.html" class="nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
|||
|
<i class="fa fa-angle-right"></i>
|
|||
|
</a>
|
|||
|
|
|||
|
</nav>
|
|||
|
|
|||
|
</div>
|
|||
|
|
|||
|
|
|||
|
<!-- Livereload script (if served using the cli tool) -->
|
|||
|
<script type="text/javascript">
|
|||
|
var socket = new WebSocket("ws://localhost:3000/__livereload");
|
|||
|
socket.onmessage = function (event) {
|
|||
|
if (event.data === "reload") {
|
|||
|
socket.close();
|
|||
|
location.reload();
|
|||
|
}
|
|||
|
};
|
|||
|
|
|||
|
window.onbeforeunload = function() {
|
|||
|
socket.close();
|
|||
|
}
|
|||
|
</script>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<script type="text/javascript">
|
|||
|
window.playground_copyable = true;
|
|||
|
</script>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<script src="elasticlunr.min.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
<script src="mark.min.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
<script src="searcher.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
|
|||
|
|
|||
|
<script src="clipboard.min.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
<script src="highlight.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
<script src="book.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
|
|||
|
<!-- Custom JS scripts -->
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
</body>
|
|||
|
</html>
|