33937 lines
1.8 MiB
33937 lines
1.8 MiB
<!DOCTYPE HTML>
|
||
<html lang="en" class="sidebar-visible no-js light">
|
||
<head>
|
||
<!-- Book generated using mdBook -->
|
||
<meta charset="UTF-8">
|
||
<title>Zsh Manual</title>
|
||
|
||
<meta name="robots" content="noindex" />
|
||
|
||
|
||
|
||
|
||
<!-- 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"><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="The-Z-Shell-Manual.html#1-the-z-shell-manual">1 The Z Shell Manual</a>
|
||
<ul>
|
||
<li><a href="The-Z-Shell-Manual.html#11-producing-documentation-from-zshtexi">1.1 Producing documentation from zsh.texi</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="The-Z-Shell-Manual"></span>
|
||
<span id="The-Z-Shell-Manual-1"></span></p>
|
||
<h1 id="1-the-z-shell-manual"><a class="header" href="#1-the-z-shell-manual">1 The Z Shell Manual</a></h1>
|
||
<p>This document has been produced from the texinfo file <code>zsh.texi</code>,
|
||
included in the <code>Doc</code> sub-directory of the Zsh distribution.</p>
|
||
<hr />
|
||
<p><span id="Producing-documentation-from-zsh_002etexi"></span></p>
|
||
<h2 id="11-producing-documentation-from-zshtexi"><a class="header" href="#11-producing-documentation-from-zshtexi">1.1 Producing documentation from zsh.texi</a></h2>
|
||
<p>The texinfo source may be converted into several formats:</p>
|
||
<ul>
|
||
<li>
|
||
<p>The Info manual<br />
|
||
The Info format allows searching for topics, commands, functions,
|
||
etc. from the many Indices. The command ‘<code>makeinfo zsh.texi</code>’ is
|
||
used to produce the Info documentation.</p>
|
||
</li>
|
||
<li>
|
||
<p>The printed manual<br />
|
||
The command ‘<code>texi2dvi zsh.texi</code>’ will output <code>zsh.dvi</code> which can
|
||
then be processed with dvips and optionally gs (Ghostscript) to
|
||
produce a nicely formatted printed manual.</p>
|
||
</li>
|
||
<li>
|
||
<p>The HTML manual<br />
|
||
An HTML version of this manual is available at the Zsh web site via:</p>
|
||
<p><code>http://zsh.sourceforge.net/Doc/</code>.</p>
|
||
<p>(The HTML version is produced with texi2html, which may be obtained
|
||
from <code>http://www.nongnu.org/texi2html/</code>. The command is ‘<code>texi2html –output . –ifinfo –split=chapter –node-files zsh.texi</code>’. If
|
||
necessary, upgrade to version 1.78 of texi2html.)</p>
|
||
</li>
|
||
</ul>
|
||
<p>For those who do not have the necessary tools to process texinfo,
|
||
precompiled documentation (PostScript, dvi, PDF, info and HTML formats)
|
||
is available from the zsh archive site or its mirrors, in the file
|
||
<code>zsh-doc.tar.gz</code>. (See <a href="Introduction.html#Availability">Availability</a>
|
||
for a list of sites.)</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>
|
||
<!-- 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="Introduction.html#2-introduction">2 Introduction</a>
|
||
<ul>
|
||
<li><a href="Introduction.html#21-author">2.1 Author</a></li>
|
||
<li><a href="Introduction.html#22-availability">2.2 Availability</a></li>
|
||
<li><a href="Introduction.html#23-mailing-lists">2.3 Mailing Lists</a></li>
|
||
<li><a href="Introduction.html#24-the-zsh-faq">2.4 The Zsh FAQ</a></li>
|
||
<li><a href="Introduction.html#25-the-zsh-web-page">2.5 The Zsh Web Page</a></li>
|
||
<li><a href="Introduction.html#26-the-zsh-userguide">2.6 The Zsh Userguide</a></li>
|
||
<li><a href="Introduction.html#27-see-also">2.7 See Also</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Introduction"></span> <span id="Introduction-1"></span></p>
|
||
<h1 id="2-introduction"><a class="header" href="#2-introduction">2 Introduction</a></h1>
|
||
<p><span id="index-introduction"></span></p>
|
||
<p>Zsh is a UNIX command interpreter (shell) usable as an interactive login
|
||
shell and as a shell script command processor. Of the standard shells,
|
||
zsh most closely resembles ksh but includes many enhancements. It does
|
||
not provide compatibility with POSIX or other shells in its default
|
||
operating mode: see the section
|
||
<a href="Invocation.html#Compatibility">Compatibility</a>.</p>
|
||
<p>Zsh has command line editing, builtin spelling correction, programmable
|
||
command completion, shell functions (with autoloading), a history
|
||
mechanism, and a host of other features.</p>
|
||
<hr />
|
||
<p><span id="Author"></span> <span id="Author-1"></span></p>
|
||
<h2 id="21-author"><a class="header" href="#21-author">2.1 Author</a></h2>
|
||
<p><span id="index-author"></span></p>
|
||
<p>Zsh was originally written by Paul Falstad <code><pf@zsh.org></code>. Zsh is now
|
||
maintained by the members of the zsh-workers mailing list
|
||
<code><zsh-workers@zsh.org></code>. The development is currently coordinated by
|
||
Peter Stephenson <code><pws@zsh.org></code>. The coordinator can be contacted at
|
||
<code><coordinator@zsh.org></code>, but matters relating to the code should
|
||
generally go to the mailing list.</p>
|
||
<hr />
|
||
<p><span id="Availability"></span> <span id="Availability-1"></span></p>
|
||
<h2 id="22-availability"><a class="header" href="#22-availability">2.2 Availability</a></h2>
|
||
<p>Zsh is available from the following HTTP and anonymous FTP site.</p>
|
||
<p><span id="index-FTP-sites-for-zsh"></span>
|
||
<span id="index-acquiring-zsh-by-FTP"></span>
|
||
<span id="index-availability-of-zsh"></span></p>
|
||
<p><code>ftp://ftp.zsh.org/pub/</code><br />
|
||
<code>https://www.zsh.org/pub/</code> )</p>
|
||
<p>The up-to-date source code is available via Git from Sourceforge. See
|
||
<code>https://sourceforge.net/projects/zsh/</code> for details. A summary of
|
||
instructions for the archive can be found at
|
||
<code>http://zsh.sourceforge.net/</code>.</p>
|
||
<hr />
|
||
<p><span id="Mailing-Lists"></span> <span id="Mailing-Lists-1"></span></p>
|
||
<h2 id="23-mailing-lists"><a class="header" href="#23-mailing-lists">2.3 Mailing Lists</a></h2>
|
||
<p><span id="index-mailing-lists"></span></p>
|
||
<p>Zsh has 3 mailing lists:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code><zsh-announce@zsh.org></code><br />
|
||
Announcements about releases, major changes in the shell and the
|
||
monthly posting of the Zsh FAQ. (moderated)</p>
|
||
</li>
|
||
<li>
|
||
<p><code><zsh-users@zsh.org></code><br />
|
||
User discussions.</p>
|
||
</li>
|
||
<li>
|
||
<p><code><zsh-workers@zsh.org></code><br />
|
||
Hacking, development, bug reports and patches.</p>
|
||
</li>
|
||
</ul>
|
||
<p>To subscribe or unsubscribe, send mail to the associated administrative
|
||
address for the mailing list.</p>
|
||
<p><code><zsh-announce-subscribe@zsh.org></code></p>
|
||
<p><code><zsh-users-subscribe@zsh.org></code></p>
|
||
<p><code><zsh-workers-subscribe@zsh.org></code></p>
|
||
<p><code><zsh-announce-unsubscribe@zsh.org></code></p>
|
||
<p><code><zsh-users-unsubscribe@zsh.org></code></p>
|
||
<p><code><zsh-workers-unsubscribe@zsh.org></code></p>
|
||
<p>YOU ONLY NEED TO JOIN ONE OF THE MAILING LISTS AS THEY ARE NESTED. All
|
||
submissions to zsh-announce are automatically forwarded to zsh-users.
|
||
All submissions to zsh-users are automatically forwarded to zsh-workers.</p>
|
||
<p>If you have problems subscribing/unsubscribing to any of the mailing
|
||
lists, send mail to <code><listmaster@zsh.org></code>. The mailing lists are
|
||
maintained by Karsten Thygesen <code><karthy@kom.auc.dk></code>.</p>
|
||
<p>The mailing lists are archived; the archives can be accessed via the
|
||
administrative addresses listed above. There is also a hypertext
|
||
archive, maintained by Geoff Wing <code><gcw@zsh.org></code>, available at
|
||
<code>https://www.zsh.org/mla/</code>.</p>
|
||
<hr />
|
||
<p><span id="The-Zsh-FAQ"></span> <span id="The-Zsh-FAQ-1"></span></p>
|
||
<h2 id="24-the-zsh-faq"><a class="header" href="#24-the-zsh-faq">2.4 The Zsh FAQ</a></h2>
|
||
<p>Zsh has a list of Frequently Asked Questions (FAQ), maintained by Peter
|
||
Stephenson <code><pws@zsh.org></code>. It is regularly posted to the newsgroup
|
||
comp.unix.shell and the zsh-announce mailing list. The latest version
|
||
can be found at any of the Zsh FTP sites, or at
|
||
<code>http://www.zsh.org/FAQ/</code>. The contact address for FAQ-related matters
|
||
is <code><faqmaster@zsh.org></code>.</p>
|
||
<hr />
|
||
<p><span id="The-Zsh-Web-Page"></span>
|
||
<span id="The-Zsh-Web-Page-1"></span></p>
|
||
<h2 id="25-the-zsh-web-page"><a class="header" href="#25-the-zsh-web-page">2.5 The Zsh Web Page</a></h2>
|
||
<p>Zsh has a web page which is located at <code>https://www.zsh.org/</code>. This is
|
||
maintained by Karsten Thygesen <code><karthy@zsh.org></code>, of SunSITE Denmark.
|
||
The contact address for web-related matters is <code><webmaster@zsh.org></code>.</p>
|
||
<hr />
|
||
<p><span id="The-Zsh-Userguide"></span>
|
||
<span id="The-Zsh-Userguide-1"></span></p>
|
||
<h2 id="26-the-zsh-userguide"><a class="header" href="#26-the-zsh-userguide">2.6 The Zsh Userguide</a></h2>
|
||
<p>A userguide is currently in preparation. It is intended to complement
|
||
the manual, with explanations and hints on issues where the manual can
|
||
be cabbalistic, hierographic, or downright mystifying (for example, the
|
||
word ‘hierographic’ does not exist). It can be viewed in its current
|
||
state at <code>http://zsh.sourceforge.net/Guide/</code>. At the time of writing,
|
||
chapters dealing with startup files and their contents and the new
|
||
completion system were essentially complete.</p>
|
||
<hr />
|
||
<p><span id="See-Also"></span> <span id="See-Also-1"></span></p>
|
||
<h2 id="27-see-also"><a class="header" href="#27-see-also">2.7 See Also</a></h2>
|
||
<p>man page sh(1), man page csh(1), man page tcsh(1), man page rc(1), man
|
||
page bash(1), man page ksh(1)</p>
|
||
<p>IEEE Standard for information Technology - Part 2: Shell and Utilities,
|
||
IEEE Inc, 1993, ISBN 1-55937-255-9.</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>
|
||
<!-- 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="Roadmap.html#3-roadmap">3 Roadmap</a>
|
||
<ul>
|
||
<li><a href="Roadmap.html#31-when-the-shell-starts">3.1 When the shell starts</a></li>
|
||
<li><a href="Roadmap.html#32-interactive-use">3.2 Interactive Use</a>
|
||
<ul>
|
||
<li><a href="Roadmap.html#321-completion">3.2.1 Completion</a></li>
|
||
<li><a href="Roadmap.html#322-extending-the-line-editor">3.2.2 Extending the line editor</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Roadmap.html#33-options">3.3 Options</a></li>
|
||
<li><a href="Roadmap.html#34-pattern-matching">3.4 Pattern Matching</a></li>
|
||
<li><a href="Roadmap.html#35-general-comments-on-syntax">3.5 General Comments on Syntax</a></li>
|
||
<li><a href="Roadmap.html#36-programming">3.6 Programming</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Roadmap"></span> <span id="Roadmap-1"></span></p>
|
||
<h1 id="3-roadmap"><a class="header" href="#3-roadmap">3 Roadmap</a></h1>
|
||
<p><span id="index-roadmap"></span></p>
|
||
<p>The Zsh Manual, like the shell itself, is large and often complicated.
|
||
This section of the manual provides some pointers to areas of the shell
|
||
that are likely to be of particular interest to new users, and indicates
|
||
where in the rest of the manual the documentation is to be found.</p>
|
||
<hr />
|
||
<p><span id="When-the-shell-starts"></span></p>
|
||
<h2 id="31-when-the-shell-starts"><a class="header" href="#31-when-the-shell-starts">3.1 When the shell starts</a></h2>
|
||
<p>When it starts, the shell reads commands from various files. These can
|
||
be created or edited to customize the shell. See
|
||
<a href="Files.html#Files">Files</a>.</p>
|
||
<p>If no personal initialization files exist for the current user, a
|
||
function is run to help you change some of the most common settings. It
|
||
won’t appear if your administrator has disabled the <code>zsh/newuser</code>
|
||
module. The function is designed to be self-explanatory. You can run it
|
||
by hand with ‘<code>autoload -Uz zsh-newuser-install; zsh-newuser-install -f</code>’. See also <a href="User-Contributions.html#User-Configuration-Functions">User Configuration
|
||
Functions</a>.</p>
|
||
<hr />
|
||
<p><span id="Interactive-Use"></span></p>
|
||
<h2 id="32-interactive-use"><a class="header" href="#32-interactive-use">3.2 Interactive Use</a></h2>
|
||
<p>Interaction with the shell uses the builtin Zsh Line Editor, ZLE. This
|
||
is described in detail in <a href="Zsh-Line-Editor.html#Zsh-Line-Editor">Zsh Line
|
||
Editor</a>.</p>
|
||
<p>The first decision a user must make is whether to use the Emacs or Vi
|
||
editing mode as the keys for editing are substantially different. Emacs
|
||
editing mode is probably more natural for beginners and can be selected
|
||
explicitly with the command <code>bindkey -e</code>.</p>
|
||
<p>A history mechanism for retrieving previously typed lines (most simply
|
||
with the Up or Down arrow keys) is available; note that, unlike other
|
||
shells, zsh will not save these lines when the shell exits unless you
|
||
set appropriate variables, and the number of history lines retained by
|
||
default is quite small (30 lines). See the description of the shell
|
||
variables (referred to in the documentation as parameters) <code>HISTFILE</code>,
|
||
<code>HISTSIZE</code> and <code>SAVEHIST</code> in <a href="Parameters.html#Parameters-Used-By-The-Shell">Parameters Used By The
|
||
Shell</a>. Note that it’s
|
||
currently only possible to read and write files saving history when the
|
||
shell is interactive, i.e. it does not work from scripts.</p>
|
||
<p>The shell now supports the UTF-8 character set (and also others if
|
||
supported by the operating system). This is (mostly) handled
|
||
transparently by the shell, but the degree of support in terminal
|
||
emulators is variable. There is some discussion of this in the shell
|
||
FAQ, <code>http://www.zsh.org/FAQ/</code>. Note in particular that for combining
|
||
characters to be handled the option <code>COMBINING_CHARS</code> needs to be set.
|
||
Because the shell is now more sensitive to the definition of the
|
||
character set, note that if you are upgrading from an older version of
|
||
the shell you should ensure that the appropriate variable, either <code>LANG</code>
|
||
(to affect all aspects of the shell’s operation) or <code>LC_CTYPE</code> (to
|
||
affect only the handling of character sets) is set to an appropriate
|
||
value. This is true even if you are using a single-byte character set
|
||
including extensions of ASCII such as <code>ISO-8859-1</code> or <code>ISO-8859-15</code>. See
|
||
the description of <code>LC_CTYPE</code> in
|
||
<a href="Parameters.html#Parameters">Parameters</a>.</p>
|
||
<hr />
|
||
<p><span id="Completion-1"></span></p>
|
||
<h3 id="321-completion"><a class="header" href="#321-completion">3.2.1 Completion</a></h3>
|
||
<p>Completion is a feature present in many shells. It allows the user to
|
||
type only a part (usually the prefix) of a word and have the shell fill
|
||
in the rest. The completion system in zsh is programmable. For example,
|
||
the shell can be set to complete email addresses in arguments to the
|
||
mail command from your <code>~/.abook/addressbook</code>; usernames, hostnames, and
|
||
even remote paths in arguments to scp, and so on. Anything that can be
|
||
written in or glued together with zsh can be the source of what the line
|
||
editor offers as possible completions.</p>
|
||
<p>Zsh has two completion systems, an old, so called <code>compctl</code> completion
|
||
(named after the builtin command that serves as its complete and only
|
||
user interface), and a new one, referred to as <code>compsys</code>, organized as
|
||
library of builtin and user-defined functions. The two systems differ in
|
||
their interface for specifying the completion behavior. The new system
|
||
is more customizable and is supplied with completions for many commonly
|
||
used commands; it is therefore to be preferred.</p>
|
||
<p>The completion system must be enabled explicitly when the shell starts.
|
||
For more information see <a href="Completion-System.html#Completion-System">Completion
|
||
System</a>.</p>
|
||
<hr />
|
||
<p><span id="Extending-the-line-editor"></span></p>
|
||
<h3 id="322-extending-the-line-editor"><a class="header" href="#322-extending-the-line-editor">3.2.2 Extending the line editor</a></h3>
|
||
<p>Apart from completion, the line editor is highly extensible by means of
|
||
shell functions. Some useful functions are provided with the shell; they
|
||
provide facilities such as:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>insert-composed-char</code><br />
|
||
composing characters not found on the keyboard</p>
|
||
</li>
|
||
<li>
|
||
<p><code>match-words-by-style</code><br />
|
||
configuring what the line editor considers a word when moving or
|
||
deleting by word</p>
|
||
</li>
|
||
<li>
|
||
<p><code>history-beginning-search-backward-end</code>, etc.<br />
|
||
alternative ways of searching the shell history</p>
|
||
</li>
|
||
<li>
|
||
<p><code>replace-string</code>, <code>replace-pattern</code><br />
|
||
functions for replacing strings or patterns globally in the command
|
||
line</p>
|
||
</li>
|
||
<li>
|
||
<p><code>edit-command-line</code><br />
|
||
edit the command line with an external editor.</p>
|
||
</li>
|
||
</ul>
|
||
<p>See <a href="User-Contributions.html#ZLE-Functions">ZLE Functions</a> for
|
||
descriptions of these.</p>
|
||
<hr />
|
||
<p><span id="Options-3"></span></p>
|
||
<h2 id="33-options"><a class="header" href="#33-options">3.3 Options</a></h2>
|
||
<p>The shell has a large number of options for changing its behaviour.
|
||
These cover all aspects of the shell; browsing the full documentation is
|
||
the only good way to become acquainted with the many possibilities. See
|
||
<a href="Options.html#Options">Options</a>.</p>
|
||
<hr />
|
||
<p><span id="Pattern-Matching"></span></p>
|
||
<h2 id="34-pattern-matching"><a class="header" href="#34-pattern-matching">3.4 Pattern Matching</a></h2>
|
||
<p>The shell has a rich set of patterns which are available for file
|
||
matching (described in the documentation as ‘filename generation’ and
|
||
also known for historical reasons as ‘globbing’) and for use when
|
||
programming. These are described in <a href="Expansion.html#Filename-Generation">Filename
|
||
Generation</a>.</p>
|
||
<p>Of particular interest are the following patterns that are not commonly
|
||
supported by other systems of pattern matching:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>**</code><br />
|
||
for matching over multiple directories</p>
|
||
</li>
|
||
<li>
|
||
<p><code>|</code><br />
|
||
for matching either of two alternatives</p>
|
||
</li>
|
||
<li>
|
||
<p><code>~</code>, <code>^</code><br />
|
||
the ability to exclude patterns from matching when the
|
||
<code>EXTENDED_GLOB</code> option is set</p>
|
||
</li>
|
||
<li>
|
||
<p><code>(``...``)</code><br />
|
||
glob qualifiers, included in parentheses at the end of the pattern,
|
||
which select files by type (such as directories) or attribute (such
|
||
as size).</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="General-Comments-on-Syntax"></span></p>
|
||
<h2 id="35-general-comments-on-syntax"><a class="header" href="#35-general-comments-on-syntax">3.5 General Comments on Syntax</a></h2>
|
||
<p>Although the syntax of zsh is in ways similar to the Korn shell, and
|
||
therefore more remotely to the original UNIX shell, the Bourne shell,
|
||
its default behaviour does not entirely correspond to those shells.
|
||
General shell syntax is introduced in <a href="Shell-Grammar.html#Shell-Grammar">Shell
|
||
Grammar</a>.</p>
|
||
<p>One commonly encountered difference is that variables substituted onto
|
||
the command line are not split into words. See the description of the
|
||
shell option <code>SH_WORD_SPLIT</code> in <a href="Expansion.html#Parameter-Expansion">Parameter
|
||
Expansion</a>. In zsh, you can either
|
||
explicitly request the splitting (e.g. <code>${=foo}</code>) or use an array when
|
||
you want a variable to expand to more than one word. See <a href="Parameters.html#Array-Parameters">Array
|
||
Parameters</a>.</p>
|
||
<hr />
|
||
<p><span id="Programming"></span></p>
|
||
<h2 id="36-programming"><a class="header" href="#36-programming">3.6 Programming</a></h2>
|
||
<p>The most convenient way of adding enhancements to the shell is typically
|
||
by writing a shell function and arranging for it to be autoloaded.
|
||
Functions are described in <a href="Functions.html#Functions">Functions</a>. Users
|
||
changing from the C shell and its relatives should notice that aliases
|
||
are less used in zsh as they don’t perform argument substitution, only
|
||
simple text replacement.</p>
|
||
<p>A few general functions, other than those for the line editor described
|
||
above, are provided with the shell and are described in <a href="User-Contributions.html#User-Contributions">User
|
||
Contributions</a>. Features
|
||
include:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>promptinit</code><br />
|
||
a prompt theme system for changing prompts easily, see <a href="User-Contributions.html#Prompt-Themes">Prompt
|
||
Themes</a></p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh-mime-setup</code><br />
|
||
a MIME-handling system which dispatches commands according to the
|
||
suffix of a file as done by graphical file managers</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zcalc</code><br />
|
||
a calculator</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zargs</code><br />
|
||
a version of <code>xargs</code> that makes the <code>find</code> command redundant</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zmv</code><br />
|
||
a command for renaming files by means of shell patterns.</p>
|
||
</li>
|
||
</ul>
|
||
<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>
|
||
<!-- 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="Invocation.html#4-invocation">4 Invocation</a>
|
||
<ul>
|
||
<li><a href="Invocation.html#41-invocation">4.1 Invocation</a></li>
|
||
<li><a href="Invocation.html#42-compatibility">4.2 Compatibility</a></li>
|
||
<li><a href="Invocation.html#43-restricted-shell">4.3 Restricted Shell</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Invocation"></span> <span id="Invocation-1"></span></p>
|
||
<h1 id="4-invocation"><a class="header" href="#4-invocation">4 Invocation</a></h1>
|
||
<p><span id="index-invocation"></span></p>
|
||
<hr />
|
||
<p><span id="Invocation-2"></span></p>
|
||
<h2 id="41-invocation"><a class="header" href="#41-invocation">4.1 Invocation</a></h2>
|
||
<p><span id="index-shell-options"></span>
|
||
<span id="index-options_002c-shell"></span>
|
||
<span id="index-shell-flags"></span>
|
||
<span id="index-flags_002c-shell"></span></p>
|
||
<p>The following flags are interpreted by the shell when invoked to
|
||
determine where the shell will read commands from:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-c</code><br />
|
||
Take the first argument as a command to execute, rather than reading
|
||
commands from a script or standard input. If any further arguments
|
||
are given, the first one is assigned to <code>$0</code>, rather than being used
|
||
as a positional parameter.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-i</code><br />
|
||
Force shell to be interactive. It is still possible to specify a
|
||
script to execute.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-s</code><br />
|
||
Force shell to read commands from the standard input. If the <code>-s</code>
|
||
flag is not present and an argument is given, the first argument is
|
||
taken to be the pathname of a script to execute.</p>
|
||
</li>
|
||
</ul>
|
||
<p>If there are any remaining arguments after option processing, and
|
||
neither of the options <code>-c</code> or <code>-s</code> was supplied, the first argument is
|
||
taken as the file name of a script containing shell commands to be
|
||
executed. If the option <code>PATH_SCRIPT</code> is set, and the file name does not
|
||
contain a directory path (i.e. there is no ‘<code>/</code>’ in the name), first the
|
||
current directory and then the command path given by the variable <code>PATH</code>
|
||
are searched for the script. If the option is not set or the file name
|
||
contains a ‘<code>/</code>’ it is used directly.</p>
|
||
<p>After the first one or two arguments have been appropriated as described
|
||
above, the remaining arguments are assigned to the positional
|
||
parameters.</p>
|
||
<p>For further options, which are common to invocation and the <code>set</code>
|
||
builtin, see <a href="Options.html#Options">Options</a>.</p>
|
||
<p>The long option ‘<code>-``-emulate</code>’ followed (in a separate word) by an
|
||
emulation mode may be passed to the shell. The emulation modes are those
|
||
described for the <code>emulate</code> builtin, see <a href="Shell-Builtin-Commands.html#Shell-Builtin-Commands">Shell Builtin
|
||
Commands</a>. The
|
||
‘<code>-``-emulate</code>’ option must precede any other options (which might
|
||
otherwise be overridden), but following options are honoured, so may be
|
||
used to modify the requested emulation mode. Note that certain extra
|
||
steps are taken to ensure a smooth emulation when this option is used
|
||
compared with the <code>emulate</code> command within the shell: for example,
|
||
variables that conflict with POSIX usage such as <code>path</code> are not defined
|
||
within the shell.</p>
|
||
<p>Options may be specified by name using the <code>-o</code> option. <code>-o</code> acts like a
|
||
single-letter option, but takes a following string as the option name.
|
||
For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zsh -x -o shwordsplit scr
|
||
</code></pre>
|
||
</div>
|
||
<p>runs the script <code>scr</code>, setting the <code>XTRACE</code> option by the corresponding
|
||
letter ‘<code>-x</code>’ and the <code>SH_WORD_SPLIT</code> option by name. Options may be
|
||
turned <em>off</em> by name by using <code>+o</code> instead of <code>-o</code>. <code>-o</code> can be stacked
|
||
up with preceding single-letter options, so for example ‘<code>-xo shwordsplit</code>’ or ‘<code>-xoshwordsplit</code>’ is equivalent to ‘<code>-x -o shwordsplit</code>’.</p>
|
||
<p><span id="index-long-option"></span></p>
|
||
<p>Options may also be specified by name in GNU long option style,
|
||
‘<code>-``-``option-name</code>’. When this is done, ‘<code>-</code>’ characters in the
|
||
option name are permitted: they are translated into ‘<code>_</code>’, and thus
|
||
ignored. So, for example, ‘<code>zsh -``-sh-word-split</code>’ invokes zsh with the
|
||
<code>SH_WORD_SPLIT</code> option turned on. Like other option syntaxes, options
|
||
can be turned off by replacing the initial ‘<code>-</code>’ with a ‘<code>+</code>’; thus
|
||
‘<code>+-sh-word-split</code>’ is equivalent to ‘<code>-``-no-sh-word-split</code>’. Unlike
|
||
other option syntaxes, GNU-style long options cannot be stacked with any
|
||
other options, so for example ‘<code>-x-shwordsplit</code>’ is an error, rather
|
||
than being treated like ‘<code>-x -``-shwordsplit</code>’.</p>
|
||
<p><span id="index-_002d_002dversion"></span>
|
||
<span id="index-_002d_002dhelp"></span></p>
|
||
<p>The special GNU-style option ‘<code>-``-version</code>’ is handled; it sends to
|
||
standard output the shell’s version information, then exits
|
||
successfully. ‘<code>-``-help</code>’ is also handled; it sends to standard output
|
||
a list of options that can be used when invoking the shell, then exits
|
||
successfully.</p>
|
||
<p>Option processing may be finished, allowing following arguments that
|
||
start with ‘<code>-</code>’ or ‘<code>+</code>’ to be treated as normal arguments, in two
|
||
ways. Firstly, a lone ‘<code>-</code>’ (or ‘<code>+</code>’) as an argument by itself ends
|
||
option processing. Secondly, a special option ‘<code>-``-</code>’ (or ‘<code>+-</code>’),
|
||
which may be specified on its own (which is the standard POSIX usage) or
|
||
may be stacked with preceding options (so ‘<code>-x-</code>’ is equivalent to ‘<code>-x -``-</code>’). Options are not permitted to be stacked after ‘<code>-``-</code>’ (so
|
||
‘<code>-x-f</code>’ is an error), but note the GNU-style option form discussed
|
||
above, where ‘<code>-``-shwordsplit</code>’ is permitted and does not end option
|
||
processing.</p>
|
||
<p>Except when the sh/ksh emulation single-letter options are in effect,
|
||
the option ‘<code>-b</code>’ (or ‘<code>+b</code>’) ends option processing. ‘<code>-b</code>’ is like
|
||
‘<code>-``-</code>’, except that further single-letter options can be stacked
|
||
after the ‘<code>-b</code>’ and will take effect as normal.</p>
|
||
<hr />
|
||
<p><span id="Compatibility"></span> <span id="Compatibility-1"></span></p>
|
||
<h2 id="42-compatibility"><a class="header" href="#42-compatibility">4.2 Compatibility</a></h2>
|
||
<p><span id="index-compatibility"></span>
|
||
<span id="index-sh-compatibility"></span>
|
||
<span id="index-ksh-compatibility"></span></p>
|
||
<p>Zsh tries to emulate sh or ksh when it is invoked as <code>sh</code> or <code>ksh</code>
|
||
respectively; more precisely, it looks at the first letter of the name
|
||
by which it was invoked, excluding any initial ‘<code>r</code>’ (assumed to stand
|
||
for ‘restricted’), and if that is ‘<code>b</code>’, ‘<code>s</code>’ or ‘<code>k</code>’ it will emulate
|
||
sh or ksh. Furthermore, if invoked as <code>su</code> (which happens on certain
|
||
systems when the shell is executed by the <code>su</code> command), the shell will
|
||
try to find an alternative name from the <code>SHELL</code> environment variable
|
||
and perform emulation based on that.</p>
|
||
<p>In sh and ksh compatibility modes the following parameters are not
|
||
special and not initialized by the shell: <code>ARGC</code>, <code>argv</code>, <code>cdpath</code>,
|
||
<code>fignore</code>, <code>fpath</code>, <code>HISTCHARS</code>, <code>mailpath</code>, <code>MANPATH</code>, <code>manpath</code>,
|
||
<code>path</code>, <code>prompt</code>, <code>PROMPT</code>, <code>PROMPT2</code>, <code>PROMPT3</code>, <code>PROMPT4</code>, <code>psvar</code>,
|
||
<code>status</code>, <code>watch</code>.</p>
|
||
<p><span id="index-ENV_002c-use-of"></span></p>
|
||
<p>The usual zsh startup/shutdown scripts are not executed. Login shells
|
||
source <code>/etc/profile</code> followed by <code>$HOME/.profile</code>. If the <code>ENV</code>
|
||
environment variable is set on invocation, <code>$ENV</code> is sourced after the
|
||
profile scripts. The value of <code>ENV</code> is subjected to parameter expansion,
|
||
command substitution, and arithmetic expansion before being interpreted
|
||
as a pathname. Note that the <code>PRIVILEGED</code> option also affects the
|
||
execution of startup files.</p>
|
||
<p>The following options are set if the shell is invoked as <code>sh</code> or <code>ksh</code>:
|
||
<code>NO_BAD_PATTERN</code>, <code>NO_BANG_HIST</code>, <code>NO_BG_NICE</code>, <code>NO_EQUALS</code>,
|
||
<code>NO_FUNCTION_ARGZERO</code>, <code>GLOB_SUBST</code>, <code>NO_GLOBAL_EXPORT</code>, <code>NO_HUP</code>,
|
||
<code>INTERACTIVE_COMMENTS</code>, <code>KSH_ARRAYS</code>, <code>NO_MULTIOS</code>, <code>NO_NOMATCH</code>,
|
||
<code>NO_NOTIFY</code>, <code>POSIX_BUILTINS</code>, <code>NO_PROMPT_PERCENT</code>, <code>RM_STAR_SILENT</code>,
|
||
<code>SH_FILE_EXPANSION</code>, <code>SH_GLOB</code>, <code>SH_OPTION_LETTERS</code>, <code>SH_WORD_SPLIT</code>.
|
||
Additionally the <code>BSD_ECHO</code> and <code>IGNORE_BRACES</code> options are set if zsh
|
||
is invoked as <code>sh</code>. Also, the <code>KSH_OPTION_PRINT</code>, <code>LOCAL_OPTIONS</code>,
|
||
<code>PROMPT_BANG</code>, <code>PROMPT_SUBST</code> and <code>SINGLE_LINE_ZLE</code> options are set if
|
||
zsh is invoked as <code>ksh</code>.</p>
|
||
<hr />
|
||
<p><span id="Restricted-Shell"></span>
|
||
<span id="Restricted-Shell-1"></span></p>
|
||
<h2 id="43-restricted-shell"><a class="header" href="#43-restricted-shell">4.3 Restricted Shell</a></h2>
|
||
<p><span id="index-restricted-shell"></span>
|
||
<span id="index-RESTRICTED"></span></p>
|
||
<p>When the basename of the command used to invoke zsh starts with the
|
||
letter ‘<code>r</code>’ or the ‘<code>-r</code>’ command line option is supplied at
|
||
invocation, the shell becomes restricted. Emulation mode is determined
|
||
after stripping the letter ‘<code>r</code>’ from the invocation name. The following
|
||
are disabled in restricted mode:</p>
|
||
<ul>
|
||
<li>changing directories with the <code>cd</code> builtin</li>
|
||
<li>changing or unsetting the <code>EGID</code>, <code>EUID</code>, <code>GID</code>, <code>HISTFILE</code>,
|
||
<code>HISTSIZE</code>, <code>IFS</code>, <code>LD_AOUT_LIBRARY_PATH</code>, <code>LD_AOUT_PRELOAD</code>,
|
||
<code>LD_LIBRARY_PATH</code>, <code>LD_PRELOAD</code>, <code>MODULE_PATH</code>, <code>module_path</code>,
|
||
<code>PATH</code>, <code>path</code>, <code>SHELL</code>, <code>UID</code> and <code>USERNAME</code> parameters</li>
|
||
<li>specifying command names containing <code>/</code></li>
|
||
<li>specifying command pathnames using <code>hash</code></li>
|
||
<li>redirecting output to files</li>
|
||
<li>using the <code>exec</code> builtin command to replace the shell with another
|
||
command</li>
|
||
<li>using <code>jobs -Z</code> to overwrite the shell process’ argument and
|
||
environment space</li>
|
||
<li>using the <code>ARGV0</code> parameter to override <code>argv[0]</code> for external
|
||
commands</li>
|
||
<li>turning off restricted mode with <code>set +r</code> or <code>unsetopt RESTRICTED</code></li>
|
||
</ul>
|
||
<p>These restrictions are enforced after processing the startup files. The
|
||
startup files should set up <code>PATH</code> to point to a directory of commands
|
||
which can be safely invoked in the restricted environment. They may also
|
||
add further restrictions by disabling selected builtins.</p>
|
||
<p>Restricted mode can also be activated any time by setting the
|
||
<code>RESTRICTED</code> option. This immediately enables all the restrictions
|
||
described above even if the shell still has not processed all startup
|
||
files.</p>
|
||
<p>A shell <em>Restricted Mode</em> is an outdated way to restrict what users may
|
||
do: modern systems have better, safer and more reliable ways to confine
|
||
user actions, such as <em>chroot jails</em>, <em>containers</em> and <em>zones</em>.</p>
|
||
<p>A restricted shell is very difficult to implement safely. The feature
|
||
may be removed in a future version of zsh.</p>
|
||
<p>It is important to realise that the restrictions only apply to the
|
||
shell, not to the commands it runs (except for some shell builtins).
|
||
While a restricted shell can only run the restricted list of commands
|
||
accessible via the predefined ‘<code>PATH</code>’ variable, it does not prevent
|
||
those commands from running any other command.</p>
|
||
<p>As an example, if ‘<code>env</code>’ is among the list of <em>allowed</em> commands, then
|
||
it allows the user to run any command as ‘<code>env</code>’ is not a shell</p>
|
||
<p>So when implementing a restricted shell framework it is important to be
|
||
fully aware of what actions each of the <em>allowed</em> commands or features
|
||
(which may be regarded as <em>modules</em>) can perform.</p>
|
||
<p>Many commands can have their behaviour affected by environment
|
||
variables. Except for the few listed above, zsh does not restrict the
|
||
setting of environment variables.</p>
|
||
<p>If a ‘<code>perl</code>’, ‘<code>python</code>’, ‘<code>bash</code>’, or other general purpose
|
||
interpreted script it treated as a restricted command, the user can work
|
||
around the restriction by setting specially crafted ‘<code>PERL5LIB</code>’,
|
||
‘<code>PYTHONPATH</code>’, ‘<code>BASHENV</code>’ (etc.) environment variables. On GNU
|
||
systems, any command can be made to run arbitrary code when performing
|
||
character set conversion (including zsh itself) by setting a
|
||
‘<code>GCONV_PATH</code>’ environment variable. Those are only a few examples.</p>
|
||
<p>Bear in mind that, contrary to some other shells, ‘<code>readonly</code>’ is not a
|
||
security feature in zsh as it can be undone and so cannot be used to
|
||
mitigate the above.</p>
|
||
<p>A restricted shell only works if the allowed commands are few and
|
||
carefully written so as not to grant more access to users than intended.
|
||
It is also important to restrict what zsh module the user may load as
|
||
some of them, such as ‘<code>zsh/system</code>’, ‘<code>zsh/mapfile</code>’ and ‘<code>zsh/files</code>’,
|
||
allow bypassing most of the restrictions.</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>
|
||
<!-- 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="Files.html#5-files">5 Files</a>
|
||
<ul>
|
||
<li><a href="Files.html#51-startupshutdown-files">5.1 Startup/Shutdown Files</a></li>
|
||
<li><a href="Files.html#52-files">5.2 Files</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Files"></span> <span id="Files-1"></span></p>
|
||
<h1 id="5-files"><a class="header" href="#5-files">5 Files</a></h1>
|
||
<hr />
|
||
<p><span id="Startup_002fShutdown-Files"></span></p>
|
||
<h2 id="51-startupshutdown-files"><a class="header" href="#51-startupshutdown-files">5.1 Startup/Shutdown Files</a></h2>
|
||
<p><span id="index-files_002c-startup"></span>
|
||
<span id="index-startup-files"></span>
|
||
<span id="index-files_002c-shutdown"></span>
|
||
<span id="index-shutdown-files"></span>
|
||
<span id="index-RCS_002c-use-of"></span>
|
||
<span id="index-GLOBAL_005fRCS_002c-use-of"></span>
|
||
<span id="index-NO_005fRCS_002c-use-of"></span>
|
||
<span id="index-NO_005fGLOBAL_005fRCS_002c-use-of"></span>
|
||
<span id="index-ZDOTDIR_002c-use-of"></span>
|
||
<span id="index-zshenv"></span></p>
|
||
<p>Commands are first read from <code>/etc/zshenv</code>; this cannot be overridden.
|
||
Subsequent behaviour is modified by the <code>RCS</code> and <code>GLOBAL_RCS</code> options;
|
||
the former affects all startup files, while the second only affects
|
||
global startup files (those shown here with an path starting with a
|
||
<code>/</code>). If one of the options is unset at any point, any subsequent
|
||
startup file(s) of the corresponding type will not be read. It is also
|
||
possible for a file in <code>$ZDOTDIR</code> to re-enable <code>GLOBAL_RCS</code>. Both <code>RCS</code>
|
||
and <code>GLOBAL_RCS</code> are set by default.</p>
|
||
<p>Commands are then read from <code>$ZDOTDIR/.zshenv</code>.
|
||
<span id="index-LOGIN_002c-use-of"></span>
|
||
<span id="index-zprofile"></span> If the shell is a login shell,
|
||
commands are read from <code>/etc/zprofile</code> and then <code>$ZDOTDIR/.zprofile</code>.
|
||
<span id="index-zshrc"></span> Then, if the shell is interactive,
|
||
commands are read from <code>/etc/zshrc</code> and then <code>$ZDOTDIR/.zshrc</code>.
|
||
<span id="index-zlogin"></span> Finally, if the shell is a login shell,
|
||
<code>/etc/zlogin</code> and <code>$ZDOTDIR/.zlogin</code> are read.</p>
|
||
<p><span id="index-zlogout"></span></p>
|
||
<p>When a login shell exits, the files <code>$ZDOTDIR/.zlogout</code> and then
|
||
<code>/etc/zlogout</code> are read. This happens with either an explicit exit via
|
||
the <code>exit</code> or <code>logout</code> commands, or an implicit exit by reading
|
||
end-of-file from the terminal. However, if the shell terminates due to
|
||
<code>exec</code>’ing another process, the logout files are not read. These are
|
||
also affected by the <code>RCS</code> and <code>GLOBAL_RCS</code> options. Note also that the
|
||
<code>RCS</code> option affects the saving of history files, i.e. if <code>RCS</code> is unset
|
||
when the shell exits, no history file will be saved.</p>
|
||
<p><span id="index-HOME_002c-use-of"></span></p>
|
||
<p>If <code>ZDOTDIR</code> is unset, <code>HOME</code> is used instead. Files listed above as
|
||
being in <code>/etc</code> may be in another directory, depending on the
|
||
installation.</p>
|
||
<p>As <code>/etc/zshenv</code> is run for all instances of zsh, it is important that
|
||
it be kept as small as possible. In particular, it is a good idea to put
|
||
code that does not need to be run for every single shell behind a test
|
||
of the form ‘<code>if [[ -o rcs ]]; then ...</code>’ so that it will not be
|
||
executed when zsh is invoked with the ‘<code>-f</code>’ option.</p>
|
||
<hr />
|
||
<p><span id="Files-2"></span></p>
|
||
<h2 id="52-files"><a class="header" href="#52-files">5.2 Files</a></h2>
|
||
<p><span id="index-files-used"></span></p>
|
||
<p><code>$ZDOTDIR/.zshenv</code></p>
|
||
<p><code>$ZDOTDIR/.zprofile</code></p>
|
||
<p><code>$ZDOTDIR/.zshrc</code></p>
|
||
<p><code>$ZDOTDIR/.zlogin</code></p>
|
||
<p><code>$ZDOTDIR/.zlogout</code></p>
|
||
<p><code>${TMPPREFIX}*</code> (default is /tmp/zsh*)</p>
|
||
<p><code>/etc/zshenv</code></p>
|
||
<p><code>/etc/zprofile</code></p>
|
||
<p><code>/etc/zshrc</code></p>
|
||
<p><code>/etc/zlogin</code></p>
|
||
<p><code>/etc/zlogout</code> (installation-specific - <code>/etc</code> is the default)</p>
|
||
<p>Any of these files may be pre-compiled with the <code>zcompile</code> builtin
|
||
command (<a href="Shell-Builtin-Commands.html#Shell-Builtin-Commands">Shell Builtin
|
||
Commands</a>). If a
|
||
compiled file exists (named for the original file plus the <code>.zwc</code>
|
||
extension) and it is newer than the original file, the compiled file
|
||
will be used instead.</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>
|
||
<!-- 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="Shell-Grammar.html#6-shell-grammar">6 Shell Grammar</a>
|
||
<ul>
|
||
<li><a href="Shell-Grammar.html#61-simple-commands--pipelines">6.1 Simple Commands & Pipelines</a></li>
|
||
<li><a href="Shell-Grammar.html#62-precommand-modifiers">6.2 Precommand Modifiers</a></li>
|
||
<li><a href="Shell-Grammar.html#63-complex-commands">6.3 Complex Commands</a></li>
|
||
<li><a href="Shell-Grammar.html#64-alternate-forms-for-complex-commands">6.4 Alternate Forms For Complex Commands</a></li>
|
||
<li><a href="Shell-Grammar.html#65-reserved-words">6.5 Reserved Words</a></li>
|
||
<li><a href="Shell-Grammar.html#66-errors">6.6 Errors</a></li>
|
||
<li><a href="Shell-Grammar.html#67-comments">6.7 Comments</a></li>
|
||
<li><a href="Shell-Grammar.html#68-aliasing">6.8 Aliasing</a>
|
||
<ul>
|
||
<li><a href="Shell-Grammar.html#681-alias-difficulties">6.8.1 Alias difficulties</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Shell-Grammar.html#69-quoting">6.9 Quoting</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Shell-Grammar"></span> <span id="Shell-Grammar-1"></span></p>
|
||
<h1 id="6-shell-grammar"><a class="header" href="#6-shell-grammar">6 Shell Grammar</a></h1>
|
||
<p><span id="index-shell-grammar"></span>
|
||
<span id="index-grammar_002c-shell"></span></p>
|
||
<hr />
|
||
<p><span id="Simple-Commands-_0026-Pipelines"></span>
|
||
<span id="Simple-Commands-_0026-Pipelines-1"></span></p>
|
||
<h2 id="61-simple-commands--pipelines"><a class="header" href="#61-simple-commands--pipelines">6.1 Simple Commands & Pipelines</a></h2>
|
||
<p><span id="index-simple-commands"></span>
|
||
<span id="index-commands_002c-simple"></span></p>
|
||
<p>A <em>simple command</em> is a sequence of optional parameter assignments
|
||
followed by blank-separated words, with optional redirections
|
||
interspersed. For a description of assignment, see the beginning of
|
||
<a href="Parameters.html#Parameters">Parameters</a>.</p>
|
||
<p>The first word is the command to be executed, and the remaining words,
|
||
if any, are arguments to the command. If a command name is given, the
|
||
parameter assignments modify the environment of the command when it is
|
||
executed. The value of a simple command is its exit status, or 128 plus
|
||
the signal number if terminated by a signal. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">echo foo
|
||
</code></pre>
|
||
</div>
|
||
<p>is a simple command with arguments.</p>
|
||
<p><span id="index-pipeline"></span></p>
|
||
<p>A <em>pipeline</em> is either a simple command, or a sequence of two or more
|
||
simple commands where each command is separated from the next by ‘<code>|</code>’
|
||
or ‘<code>|&</code>’. Where commands are separated by ‘<code>|</code>’, the standard output of
|
||
the first command is connected to the standard input of the next. ‘<code>|&</code>’
|
||
is shorthand for ‘<code>2>&1 |</code>’, which connects both the standard output and
|
||
the standard error of the command to the standard input of the next. The
|
||
value of a pipeline is the value of the last command, unless the
|
||
pipeline is preceded by ‘<code>!</code>’ in which case the value is the logical
|
||
inverse of the value of the last command. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">echo foo | sed 's/foo/bar/'
|
||
</code></pre>
|
||
</div>
|
||
<p>is a pipeline, where the output (‘<code>foo</code>’ plus a newline) of the first
|
||
command will be passed to the input of the second.</p>
|
||
<p><span id="index-coproc"></span> <span id="index-coprocess"></span></p>
|
||
<p>If a pipeline is preceded by ‘<code>coproc</code>’, it is executed as a coprocess;
|
||
a two-way pipe is established between it and the parent shell. The shell
|
||
can read from or write to the coprocess by means of the ‘<code>>&p</code>’ and
|
||
‘<code><&p</code>’ redirection operators or with ‘<code>print -p</code>’ and ‘<code>read -p</code>’. A
|
||
pipeline cannot be preceded by both ‘<code>coproc</code>’ and ‘<code>!</code>’. If job control
|
||
is active, the coprocess can be treated in other than input and output
|
||
as an ordinary background job.</p>
|
||
<p><span id="index-sublist"></span></p>
|
||
<p>A <em>sublist</em> is either a single pipeline, or a sequence of two or more
|
||
pipelines separated by ‘<code>&&</code>’ or ‘<code>||</code>’. If two pipelines are separated
|
||
by ‘<code>&&</code>’, the second pipeline is executed only if the first succeeds
|
||
(returns a zero status). If two pipelines are separated by ‘<code>||</code>’, the
|
||
second is executed only if the first fails (returns a nonzero status).
|
||
Both operators have equal precedence and are left associative. The value
|
||
of the sublist is the value of the last pipeline executed. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">dmesg | grep panic && print yes
|
||
</code></pre>
|
||
</div>
|
||
<p>is a sublist consisting of two pipelines, the second just a simple
|
||
command which will be executed if and only if the <code>grep</code> command returns
|
||
a zero status. If it does not, the value of the sublist is that return
|
||
status, else it is the status returned by the <code>print</code> (almost certainly
|
||
zero).</p>
|
||
<p><span id="index-list"></span></p>
|
||
<p>A <em>list</em> is a sequence of zero or more sublists, in which each sublist
|
||
is terminated by ‘<code>;</code>’, ‘<code>&</code>’, ‘<code>&|</code>’, ‘<code>&!</code>’, or a newline. This
|
||
terminator may optionally be omitted from the last sublist in the list
|
||
when the list appears as a complex command inside ‘<code>(</code>...<code>)</code>’ or
|
||
‘<code>{</code>...<code>}</code>’. When a sublist is terminated by ‘<code>;</code>’ or newline, the
|
||
shell waits for it to finish before executing the next sublist. If a
|
||
sublist is terminated by a ‘<code>&</code>’, ‘<code>&|</code>’, or ‘<code>&!</code>’, the shell executes
|
||
the last pipeline in it in the background, and does not wait for it to
|
||
finish (note the difference from other shells which execute the whole
|
||
sublist in the background). A backgrounded pipeline returns a status of
|
||
zero.</p>
|
||
<p>More generally, a list can be seen as a set of any shell commands
|
||
whatsoever, including the complex commands below; this is implied
|
||
wherever the word ‘list’ appears in later descriptions. For example, the
|
||
commands in a shell function form a special sort of list.</p>
|
||
<hr />
|
||
<p><span id="Precommand-Modifiers"></span>
|
||
<span id="Precommand-Modifiers-1"></span></p>
|
||
<h2 id="62-precommand-modifiers"><a class="header" href="#62-precommand-modifiers">6.2 Precommand Modifiers</a></h2>
|
||
<p><span id="index-precommand-modifiers"></span>
|
||
<span id="index-modifiers_002c-precommand"></span></p>
|
||
<p>A simple command may be preceded by a <em>precommand modifier</em>, which will
|
||
alter how the command is interpreted. These modifiers are shell builtin
|
||
commands with the exception of <code>nocorrect</code> which is a reserved word.</p>
|
||
<p><span id="index-_002d"></span></p>
|
||
<p><code>-</code></p>
|
||
<p>The command is executed with a ‘<code>-</code>’ prepended to its <code>argv[0]</code> string.</p>
|
||
<p><span id="index-builtin"></span></p>
|
||
<p><code>builtin</code></p>
|
||
<p>The command word is taken to be the name of a builtin command, rather
|
||
than a shell function or external command.</p>
|
||
<p><span id="index-command"></span></p>
|
||
<p><code>command</code> [ <code>-pvV</code> ]</p>
|
||
<p>The command word is taken to be the name of an external command, rather
|
||
than a shell function or builtin. 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><span id="index-exec"></span></p>
|
||
<p><code>exec</code> [ <code>-cl</code> ] [ <code>-a</code> <code>argv0</code> ]</p>
|
||
<p>The following command together with any arguments is run in place of the
|
||
current process, rather than as a sub-process. The shell does not fork
|
||
and is replaced. The shell does not invoke <code>TRAPEXIT</code>, nor does it
|
||
source <code>zlogout</code> files. The options are provided for compatibility with
|
||
other shells.</p>
|
||
<p>The <code>-c</code> option clears the environment.</p>
|
||
<p>The <code>-l</code> option is equivalent to the <code>-</code> precommand modifier, to treat
|
||
the replacement command as a login shell; the command is executed with a
|
||
<code>-</code> prepended to its <code>argv[0]</code> string. This flag has no effect if used
|
||
together with the <code>-a</code> option.</p>
|
||
<p>The <code>-a</code> option is used to specify explicitly the <code>argv[0]</code> string (the
|
||
name of the command as seen by the process itself) to be used by the
|
||
replacement command and is directly equivalent to setting a value for
|
||
the <code>ARGV0</code> environment variable.</p>
|
||
<p><span id="index-nocorrect"></span></p>
|
||
<p><code>nocorrect</code></p>
|
||
<p>Spelling correction is not done on any of the words. This must appear
|
||
before any other precommand modifier, as it is interpreted immediately,
|
||
before any parsing is done. It has no effect in non-interactive shells.</p>
|
||
<p><span id="index-noglob"></span></p>
|
||
<p><code>noglob</code></p>
|
||
<p>Filename generation (globbing) is not performed on any of the words.</p>
|
||
<hr />
|
||
<p><span id="Complex-Commands"></span>
|
||
<span id="Complex-Commands-1"></span></p>
|
||
<h2 id="63-complex-commands"><a class="header" href="#63-complex-commands">6.3 Complex Commands</a></h2>
|
||
<p><span id="index-complex-commands"></span>
|
||
<span id="index-commands_002c-complex"></span></p>
|
||
<p>A <em>complex command</em> in zsh is one of the following:</p>
|
||
<p><span id="index-if"></span> <span id="index-if-construct"></span></p>
|
||
<p><code>if</code> <code>list</code> <code>then</code> <code>list</code> [ <code>elif</code> <code>list</code> <code>then</code> <code>list</code> ] ... [
|
||
<code>else</code> <code>list</code> ] <code>fi</code></p>
|
||
<p>The <code>if</code> <code>list</code> is executed, and if it returns a zero exit status, the
|
||
<code>then</code> <code>list</code> is executed. Otherwise, the <code>elif</code> <code>list</code> is executed and
|
||
if its status is zero, the <code>then</code> <code>list</code> is executed. If each <code>elif</code>
|
||
<code>list</code> returns nonzero status, the <code>else</code> <code>list</code> is executed.</p>
|
||
<p><span id="index-for"></span> <span id="index-for-loops"></span>
|
||
<span id="index-loops_002c-for"></span></p>
|
||
<p><code>for</code> <code>name</code> ... [ <code>in</code> <code>word</code> ... ] <code>term</code> <code>do</code> <code>list</code> <code>done</code></p>
|
||
<p>Expand the list of <code>word</code>s, and set the parameter <code>name</code> to each of them
|
||
in turn, executing <code>list</code> each time. If the ‘<code>in</code> <code>word</code>’ is omitted,
|
||
use the positional parameters instead of the <code>word</code>s.</p>
|
||
<p>The <code>term</code> consists of one or more newline or <code>;</code> which terminate the
|
||
<code>word</code>s, and are optional when the ‘<code>in</code> <code>word</code>’ is omitted.</p>
|
||
<p>More than one parameter <code>name</code> can appear before the list of <code>word</code>s. If
|
||
<code>N</code> <code>name</code>s are given, then on each execution of the loop the next <code>N</code>
|
||
<code>word</code>s are assigned to the corresponding parameters. If there are more
|
||
<code>name</code>s than remaining <code>word</code>s, the remaining parameters are each set to
|
||
the empty string. Execution of the loop ends when there is no remaining
|
||
<code>word</code> to assign to the first <code>name</code>. It is only possible for <code>in</code> to
|
||
appear as the first <code>name</code> in the list, else it will be treated as
|
||
marking the end of the list.</p>
|
||
<p><code>for ((</code> [<code>expr1</code>] <code>;</code> [<code>expr2</code>] <code>;</code> [<code>expr3</code>] <code>)) do</code> <code>list</code>
|
||
<code>done</code></p>
|
||
<p>The arithmetic expression <code>expr1</code> is evaluated first (see <a href="Arithmetic-Evaluation.html#Arithmetic-Evaluation">Arithmetic
|
||
Evaluation</a>). The
|
||
arithmetic expression <code>expr2</code> is repeatedly evaluated until it evaluates
|
||
to zero and when non-zero, <code>list</code> is executed and the arithmetic
|
||
expression <code>expr3</code> evaluated. If any expression is omitted, then it
|
||
behaves as if it evaluated to 1.</p>
|
||
<p><span id="index-while"></span> <span id="index-while-loops"></span>
|
||
<span id="index-loops_002c-while"></span></p>
|
||
<p><code>while</code> <code>list</code> <code>do</code> <code>list</code> <code>done</code></p>
|
||
<p>Execute the <code>do</code> <code>list</code> as long as the <code>while</code> <code>list</code> returns a zero
|
||
exit status.</p>
|
||
<p><span id="index-until"></span> <span id="index-until-loops"></span>
|
||
<span id="index-loops_002c-until"></span></p>
|
||
<p><code>until</code> <code>list</code> <code>do</code> <code>list</code> <code>done</code></p>
|
||
<p>Execute the <code>do</code> <code>list</code> as long as <code>until</code> <code>list</code> returns a nonzero exit
|
||
status.</p>
|
||
<p><span id="index-repeat"></span> <span id="index-repeat-loops"></span>
|
||
<span id="index-loops_002c-repeat"></span></p>
|
||
<p><code>repeat</code> <code>word</code> <code>do</code> <code>list</code> <code>done</code></p>
|
||
<p><code>word</code> is expanded and treated as an arithmetic expression, which must
|
||
evaluate to a number <code>n</code>. <code>list</code> is then executed <code>n</code> times.</p>
|
||
<p>The <code>repeat</code> syntax is disabled by default when the shell starts in a
|
||
mode emulating another shell. It can be enabled with the command
|
||
‘<code>enable -r repeat</code>’</p>
|
||
<p><span id="index-case"></span> <span id="index-case-selection"></span>
|
||
<span id="index-selection_002c-case"></span></p>
|
||
<p><code>case</code> <code>word</code> <code>in</code> [ [<code>(</code>] <code>pattern</code> [ <code>|</code> <code>pattern</code> ] ... <code>)</code>
|
||
<code>list</code> (<code>;;</code>|<code>;&</code>|<code>;|</code>) ] ... <code>esac</code></p>
|
||
<p>Execute the <code>list</code> associated with the first <code>pattern</code> that matches
|
||
<code>word</code>, if any. The form of the patterns is the same as that used for
|
||
filename generation. See <a href="Expansion.html#Filename-Generation">Filename
|
||
Generation</a>.</p>
|
||
<p>Note further that, unless the <code>SH_GLOB</code> option is set, the whole pattern
|
||
with alternatives is treated by the shell as equivalent to a group of
|
||
patterns within parentheses, although white space may appear about the
|
||
parentheses and the vertical bar and will be stripped from the pattern
|
||
at those points. White space may appear elsewhere in the pattern; this
|
||
is not stripped. If the <code>SH_GLOB</code> option is set, so that an opening
|
||
parenthesis can be unambiguously treated as part of the case syntax, the
|
||
expression is parsed into separate words and these are treated as strict
|
||
alternatives (as in other shells).</p>
|
||
<p>If the <code>list</code> that is executed is terminated with <code>;&</code> rather than <code>;;</code>,
|
||
the following list is also executed. The rule for the terminator of the
|
||
following list <code>;;</code>, <code>;&</code> or <code>;|</code> is applied unless the <code>esac</code> is
|
||
reached.</p>
|
||
<p>If the <code>list</code> that is executed is terminated with <code>;|</code> the shell
|
||
continues to scan the <code>pattern</code>s looking for the next match, executing
|
||
the corresponding <code>list</code>, and applying the rule for the corresponding
|
||
terminator <code>;;</code>, <code>;&</code> or <code>;|</code>. Note that <code>word</code> is not re-expanded; all
|
||
applicable <code>pattern</code>s are tested with the same <code>word</code>.</p>
|
||
<p><span id="index-select"></span> <span id="index-user-selection"></span>
|
||
<span id="index-selection_002c-user"></span></p>
|
||
<p><code>select</code> <code>name</code> [ <code>in</code> <code>word</code> ... <code>term</code> ] <code>do</code> <code>list</code> <code>done</code></p>
|
||
<p>where <code>term</code> is one or more newline or <code>;</code> to terminate the <code>word</code>s.
|
||
<span id="index-REPLY_002c-use-of"></span> Print the set of <code>word</code>s,
|
||
each preceded by a number. If the <code>in</code> <code>word</code> is omitted, use the
|
||
positional parameters. The <code>PROMPT3</code> prompt is printed and a line is
|
||
read from the line editor if the shell is interactive and that is
|
||
active, or else standard input. If this line consists of the number of
|
||
one of the listed <code>word</code>s, then the parameter <code>name</code> is set to the
|
||
<code>word</code> corresponding to this number. If this line is empty, the
|
||
selection list is printed again. Otherwise, the value of the parameter
|
||
<code>name</code> is set to null. The contents of the line read from standard input
|
||
is saved in the parameter <code>REPLY</code>. <code>list</code> is executed for each selection
|
||
until a break or end-of-file is encountered.</p>
|
||
<p><span id="index-subshell"></span></p>
|
||
<p><code>(</code> <code>list</code> <code>)</code></p>
|
||
<p>Execute <code>list</code> in a subshell. Traps set by the <code>trap</code> builtin are reset
|
||
to their default values while executing <code>list</code>.</p>
|
||
<p><code>{</code> <code>list</code> <code>}</code></p>
|
||
<p>Execute <code>list</code>.</p>
|
||
<p><span id="index-always"></span> <span id="index-always-blocks"></span>
|
||
<span id="index-try-blocks"></span></p>
|
||
<p><code>{</code> <code>try-list</code> <code>} always {</code> <code>always-list</code> <code>}</code></p>
|
||
<p>First execute <code>try-list</code>. Regardless of errors, or <code>break</code> or <code>continue</code>
|
||
commands encountered within <code>try-list</code>, execute <code>always-list</code>. Execution
|
||
then continues from the result of the execution of <code>try-list</code>; in other
|
||
words, any error, or <code>break</code> or <code>continue</code> command is treated in the
|
||
normal way, as if <code>always-list</code> were not present. The two chunks of code
|
||
are referred to as the ‘try block’ and the ‘always block’.</p>
|
||
<p>Optional newlines or semicolons may appear after the <code>always</code>; note,
|
||
however, that they may <em>not</em> appear between the preceding closing brace
|
||
and the <code>always</code>.</p>
|
||
<p>An ‘error’ in this context is a condition such as a syntax error which
|
||
causes the shell to abort execution of the current function, script, or
|
||
list. Syntax errors encountered while the shell is parsing the code do
|
||
not cause the <code>always-list</code> to be executed. For example, an erroneously
|
||
constructed <code>if</code> block in <code>try-list</code> would cause the shell to abort
|
||
during parsing, so that <code>always-list</code> would not be executed, while an
|
||
erroneous substitution such as <code>${*foo*}</code> would cause a run-time error,
|
||
after which <code>always-list</code> would be executed.</p>
|
||
<p>An error condition can be tested and reset with the special integer
|
||
variable <code>TRY_BLOCK_ERROR</code>. Outside an <code>always-list</code> the value is
|
||
irrelevant, but it is initialised to <code>-1</code>. Inside <code>always-list</code>, the
|
||
value is 1 if an error occurred in the <code>try-list</code>, else 0. If
|
||
<code>TRY_BLOCK_ERROR</code> is set to 0 during the <code>always-list</code>, the error
|
||
condition caused by the <code>try-list</code> is reset, and shell execution
|
||
continues normally after the end of <code>always-list</code>. Altering the value
|
||
during the <code>try-list</code> is not useful (unless this forms part of an
|
||
enclosing <code>always</code> block).</p>
|
||
<p>Regardless of <code>TRY_BLOCK_ERROR</code>, after the end of <code>always-list</code> the
|
||
normal shell status <code>$?</code> is the value returned from <code>try-list</code>. This
|
||
will be non-zero if there was an error, even if <code>TRY_BLOCK_ERROR</code> was
|
||
set to zero.</p>
|
||
<p>The following executes the given code, ignoring any errors it causes.
|
||
This is an alternative to the usual convention of protecting code by
|
||
executing it in a subshell.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">{
|
||
# code which may cause an error
|
||
} always {
|
||
# This code is executed regardless of the error.
|
||
(( TRY_BLOCK_ERROR = 0 ))
|
||
}
|
||
# The error condition has been reset.
|
||
</code></pre>
|
||
</div>
|
||
<p>When a <code>try</code> block occurs outside of any function, a <code>return</code> or a
|
||
<code>exit</code> encountered in <code>try-list</code> does <em>not</em> cause the execution of
|
||
<code>always-list</code>. Instead, the shell exits immediately after any <code>EXIT</code>
|
||
trap has been executed. Otherwise, a <code>return</code> command encountered in
|
||
<code>try-list</code> will cause the execution of <code>always-list</code>, just like <code>break</code>
|
||
and <code>continue</code>.</p>
|
||
<p><span id="index-function"></span></p>
|
||
<p><code>function</code> <code>word</code> ... [ <code>()</code> ] [ <code>term</code> ] <code>{</code> <code>list</code> <code>}</code></p>
|
||
<p><code>word</code> ... <code>()</code> [ <code>term</code> ] <code>{</code> <code>list</code> <code>}</code></p>
|
||
<p><code>word</code> ... <code>()</code> [ <code>term</code> ] <code>command</code></p>
|
||
<p>where <code>term</code> is one or more newline or <code>;</code>. Define a function which is
|
||
referenced by any one of <code>word</code>. Normally, only one <code>word</code> is provided;
|
||
multiple <code>word</code>s are usually only useful for setting traps. The body of
|
||
the function is the <code>list</code> between the <code>{</code> and <code>}</code>. See
|
||
<a href="Functions.html#Functions">Functions</a>.</p>
|
||
<p>If the option <code>SH_GLOB</code> is set for compatibility with other shells, then
|
||
whitespace may appear between the left and right parentheses when there
|
||
is a single <code>word</code>; otherwise, the parentheses will be treated as
|
||
forming a globbing pattern in that case.</p>
|
||
<p>In any of the forms above, a redirection may appear outside the function
|
||
body, for example</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">func() { ... } 2>&1
|
||
</code></pre>
|
||
</div>
|
||
<p>The redirection is stored with the function and applied whenever the
|
||
function is executed. Any variables in the redirection are expanded at
|
||
the point the function is executed, but outside the function scope.</p>
|
||
<p><span id="index-timing"></span> <span id="index-time"></span></p>
|
||
<p><code>time</code> [ <code>pipeline</code> ]</p>
|
||
<p>The <code>pipeline</code> is executed, and timing statistics are reported on the
|
||
standard error in the form specified by the <code>TIMEFMT</code> parameter. If
|
||
<code>pipeline</code> is omitted, print statistics about the shell process and its
|
||
children.</p>
|
||
<p><span id="index-conditional-expression"></span>
|
||
<span id="index-_005b_005b"></span></p>
|
||
<p><code>[[</code> <code>exp</code> <code>]]</code></p>
|
||
<p>Evaluates the conditional expression <code>exp</code> and return a zero exit status
|
||
if it is true. See <a href="Conditional-Expressions.html#Conditional-Expressions">Conditional
|
||
Expressions</a> for a
|
||
description of <code>exp</code>.</p>
|
||
<hr />
|
||
<p><span id="Alternate-Forms-For-Complex-Commands"></span>
|
||
<span id="Alternate-Forms-For-Complex-Commands-1"></span></p>
|
||
<h2 id="64-alternate-forms-for-complex-commands"><a class="header" href="#64-alternate-forms-for-complex-commands">6.4 Alternate Forms For Complex Commands</a></h2>
|
||
<p><span id="index-alternate-forms-for-complex-commands"></span>
|
||
<span id="index-commands_002c-alternate-forms-for-complex"></span></p>
|
||
<p>Many of zsh’s complex commands have alternate forms. These are
|
||
non-standard and are likely not to be obvious even to seasoned shell
|
||
programmers; they should not be used anywhere that portability of shell
|
||
code is a concern.</p>
|
||
<p>The short versions below only work if <code>sublist</code> is of the form ‘<code>{</code>
|
||
<code>list</code> <code>}</code>’ or if the <code>SHORT_LOOPS</code> option is set. For the <code>if</code>, <code>while</code>
|
||
and <code>until</code> commands, in both these cases the test part of the loop must
|
||
also be suitably delimited, such as by ‘<code>[[</code> <code>...</code> <code>]]</code>’ or ‘<code>((</code> <code>...</code>
|
||
<code>))</code>’, else the end of the test will not be recognized. For the <code>for</code>,
|
||
<code>repeat</code>, <code>case</code> and <code>select</code> commands no such special form for the
|
||
arguments is necessary, but the other condition (the special form of
|
||
<code>sublist</code> or use of the <code>SHORT_LOOPS</code> option) still applies.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>if</code> <code>list</code> <code>{</code> <code>list</code> <code>}</code> [ <code>elif</code> <code>list</code> <code>{</code> <code>list</code> <code>}</code> ] ... [
|
||
<code>else {</code> <code>list</code> <code>}</code> ]<br />
|
||
An alternate form of <code>if</code>. The rules mean that</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">if [[ -o ignorebraces ]] {
|
||
print yes
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p>works, but</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">if true { # Does not work!
|
||
print yes
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p>does <em>not</em>, since the test is not suitably delimited.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>if</code> <code>list</code> <code>sublist</code><br />
|
||
A short form of the alternate <code>if</code>. The same limitations on the form
|
||
of <code>list</code> apply as for the previous form.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>for</code> <code>name</code> ... <code>(</code> <code>word</code> ... <code>)</code> <code>sublist</code><br />
|
||
A short form of <code>for</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>for</code> <code>name</code> ... [ <code>in</code> <code>word</code> ... ] <code>term</code> <code>sublist</code><br />
|
||
where <code>term</code> is at least one newline or <code>;</code>. Another short form of
|
||
<code>for</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>for ((</code> [<code>expr1</code>] <code>;</code> [<code>expr2</code>] <code>;</code> [<code>expr3</code>] <code>))</code>
|
||
<code>sublist</code><br />
|
||
A short form of the arithmetic <code>for</code> command.</p>
|
||
<p><span id="index-foreach"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>foreach</code> <code>name</code> ... <code>(</code> <code>word</code> ... <code>)</code> <code>list</code> <code>end</code><br />
|
||
Another form of <code>for</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>while</code> <code>list</code> <code>{</code> <code>list</code> <code>}</code><br />
|
||
An alternative form of <code>while</code>. Note the limitations on the form of
|
||
<code>list</code> mentioned above.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>until</code> <code>list</code> <code>{</code> <code>list</code> <code>}</code><br />
|
||
An alternative form of <code>until</code>. Note the limitations on the form of
|
||
<code>list</code> mentioned above.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>repeat</code> <code>word</code> <code>sublist</code><br />
|
||
This is a short form of <code>repeat</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>case</code> <code>word</code> <code>{</code> [ [<code>(</code>] <code>pattern</code> [ <code>|</code> <code>pattern</code> ] ... <code>)</code>
|
||
<code>list</code> (<code>;;</code>|<code>;&</code>|<code>;|</code>) ] ... <code>}</code><br />
|
||
An alternative form of <code>case</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>select</code> <code>name</code> [ <code>in</code> <code>word</code> ... <code>term</code> ] <code>sublist</code><br />
|
||
where <code>term</code> is at least one newline or <code>;</code>. A short form of
|
||
<code>select</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>function</code> <code>word</code> ... [ <code>()</code> ] [ <code>term</code> ] <code>sublist</code><br />
|
||
This is a short form of <code>function</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Reserved-Words"></span> <span id="Reserved-Words-1"></span></p>
|
||
<h2 id="65-reserved-words"><a class="header" href="#65-reserved-words">6.5 Reserved Words</a></h2>
|
||
<p><span id="index-reserved-words"></span>
|
||
<span id="index-disable_002c-use-of"></span></p>
|
||
<p>The following words are recognized as reserved words when used as the
|
||
first word of a command unless quoted or disabled using <code>disable -r</code>:</p>
|
||
<p><code>do done esac then elif else fi for case if while function repeat time until select coproc nocorrect foreach end ! [[ { } declare export float integer local readonly typeset</code></p>
|
||
<p>Additionally, ‘<code>}</code>’ is recognized in any position if neither the
|
||
<code>IGNORE_BRACES</code> option nor the <code>IGNORE_CLOSE_BRACES</code> option is set.</p>
|
||
<hr />
|
||
<p><span id="Errors"></span> <span id="Errors-1"></span></p>
|
||
<h2 id="66-errors"><a class="header" href="#66-errors">6.6 Errors</a></h2>
|
||
<p><span id="index-errors_002c-handling-of"></span></p>
|
||
<p>Certain errors are treated as fatal by the shell: in an interactive
|
||
shell, they cause control to return to the command line, and in a
|
||
non-interactive shell they cause the shell to be aborted. In older
|
||
versions of zsh, a non-interactive shell running a script would not
|
||
abort completely, but would resume execution at the next command to be
|
||
read from the script, skipping the remainder of any functions or shell
|
||
constructs such as loops or conditions; this somewhat illogical
|
||
behaviour can be recovered by setting the option <code>CONTINUE_ON_ERROR</code>.</p>
|
||
<p>Fatal errors found in non-interactive shells include:</p>
|
||
<ul>
|
||
<li>Failure to parse shell options passed when invoking the shell</li>
|
||
<li>Failure to change options with the <code>set</code> builtin</li>
|
||
<li>Parse errors of all sorts, including failures to parse mathematical
|
||
expressions</li>
|
||
<li>Failures to set or modify variable behaviour with <code>typeset</code>,
|
||
<code>local</code>, <code>declare</code>, <code>export</code>, <code>integer</code>, <code>float</code></li>
|
||
<li>Execution of incorrectly positioned loop control structures
|
||
(<code>continue</code>, <code>break</code>)</li>
|
||
<li>Attempts to use regular expression with no regular expression module
|
||
available</li>
|
||
<li>Disallowed operations when the <code>RESTRICTED</code> options is set</li>
|
||
<li>Failure to create a pipe needed for a pipeline</li>
|
||
<li>Failure to create a multio</li>
|
||
<li>Failure to autoload a module needed for a declared shell feature</li>
|
||
<li>Errors creating command or process substitutions</li>
|
||
<li>Syntax errors in glob qualifiers</li>
|
||
<li>File generation errors where not caught by the option <code>BAD_PATTERN</code></li>
|
||
<li>All bad patterns used for matching within case statements</li>
|
||
<li>File generation failures where not caused by <code>NO_MATCH</code> or similar
|
||
options</li>
|
||
<li>All file generation errors where the pattern was used to create a
|
||
multio</li>
|
||
<li>Memory errors where detected by the shell</li>
|
||
<li>Invalid subscripts to shell variables</li>
|
||
<li>Attempts to assign read-only variables</li>
|
||
<li>Logical errors with variables such as assignment to the wrong type</li>
|
||
<li>Use of invalid variable names</li>
|
||
<li>Errors in variable substitution syntax</li>
|
||
<li>Failure to convert characters in <code>$’</code>...<code>’</code> expressions</li>
|
||
</ul>
|
||
<p>If the <code>POSIX_BUILTINS</code> option is set, more errors associated with shell
|
||
builtin commands are treated as fatal, as specified by the POSIX
|
||
standard.</p>
|
||
<hr />
|
||
<p><span id="Comments"></span> <span id="Comments-1"></span></p>
|
||
<h2 id="67-comments"><a class="header" href="#67-comments">6.7 Comments</a></h2>
|
||
<p><span id="index-comments"></span>
|
||
<span id="index-INTERACTIVE_005fCOMMENTS_002c-use-of"></span>
|
||
<span id="index-histchars_002c-use-of"></span></p>
|
||
<p>In non-interactive shells, or in interactive shells with the
|
||
<code>INTERACTIVE_COMMENTS</code> option set, a word beginning with the third
|
||
character of the <code>histchars</code> parameter (‘<code>#</code>’ by default) causes that
|
||
word and all the following characters up to a newline to be ignored.</p>
|
||
<hr />
|
||
<p><span id="Aliasing"></span> <span id="Aliasing-1"></span></p>
|
||
<h2 id="68-aliasing"><a class="header" href="#68-aliasing">6.8 Aliasing</a></h2>
|
||
<p><span id="index-aliasing"></span></p>
|
||
<p>Every eligible <em>word</em> in the shell input is checked to see if there is
|
||
an alias defined for it. If so, it is replaced by the text of the alias
|
||
if it is in command position (if it could be the first word of a simple
|
||
command), or if the alias is global. If the replacement text ends with a
|
||
space, the next word in the shell input is always eligible for purposes
|
||
of alias expansion. <span id="index-alias_002c-use-of"></span>
|
||
<span id="index-aliases_002c-global"></span> An alias is defined using
|
||
the <code>alias</code> builtin; global aliases may be defined using the <code>-g</code> option
|
||
to that builtin.</p>
|
||
<p>A <em>word</em> is defined as:</p>
|
||
<ul>
|
||
<li>Any plain string or glob pattern</li>
|
||
<li>Any quoted string, using any quoting method (note that the quotes
|
||
must be part of the alias definition for this to be eligible)</li>
|
||
<li>Any parameter reference or command substitution</li>
|
||
<li>Any series of the foregoing, concatenated without whitespace or
|
||
other tokens between them</li>
|
||
<li>Any reserved word (<code>case</code>, <code>do</code>, <code>else</code>, etc.)</li>
|
||
<li>With global aliasing, any command separator, any redirection
|
||
operator, and ‘<code>(</code>’ or ‘<code>)</code>’ when not part of a glob pattern</li>
|
||
</ul>
|
||
<p>Alias expansion is done on the shell input before any other expansion
|
||
except history expansion. Therefore, if an alias is defined for the word
|
||
<code>foo</code>, alias expansion may be avoided by quoting part of the word, e.g.
|
||
<code>\foo</code>. Any form of quoting works, although there is nothing to prevent
|
||
an alias being defined for the quoted form such as <code>\foo</code> as well.</p>
|
||
<p>When <code>POSIX_ALIASES</code> is set, only plain unquoted strings are eligible
|
||
for aliasing. The <code>alias</code> builtin does not reject ineligible aliases,
|
||
but they are not expanded.</p>
|
||
<p>For use with completion, which would remove an initial backslash
|
||
followed by a character that isn’t special, it may be more convenient to
|
||
quote the word by starting with a single quote, i.e. <code>’foo</code>; completion
|
||
will automatically add the trailing single quote.</p>
|
||
<hr />
|
||
<p><span id="Alias-difficulties"></span></p>
|
||
<h3 id="681-alias-difficulties"><a class="header" href="#681-alias-difficulties">6.8.1 Alias difficulties</a></h3>
|
||
<p>Although aliases can be used in ways that bend normal shell syntax, not
|
||
every string of non-white-space characters can be used as an alias.</p>
|
||
<p>Any set of characters not listed as a word above is not a word, hence no
|
||
attempt is made to expand it as an alias, no matter how it is defined
|
||
(i.e. via the builtin or the special parameter <code>aliases</code> described in
|
||
<a href="Zsh-Modules.html#The-zsh_002fparameter-Module">The zsh/parameter
|
||
Module</a>). However, as
|
||
noted in the case of <code>POSIX_ALIASES</code> above, the shell does not attempt
|
||
to deduce whether the string corresponds to a word at the time the alias
|
||
is created.</p>
|
||
<p>For example, an expression containing an <code>=</code> at the start of a command
|
||
line is an assignment and cannot be expanded as an alias; a lone <code>=</code> is
|
||
not an assignment but can only be set as an alias using the parameter,
|
||
as otherwise the <code>=</code> is taken part of the syntax of the builtin command.</p>
|
||
<p>It is not presently possible to alias the ‘<code>((</code>’ token that introduces
|
||
arithmetic expressions, because until a full statement has been parsed,
|
||
it cannot be distinguished from two consecutive ‘<code>(</code>’ tokens introducing
|
||
nested subshells. Also, if a separator such as <code>&&</code> is aliased, <code>\&&</code>
|
||
turns into the two tokens <code>\&</code> and <code>&</code>, each of which may have been
|
||
aliased separately. Similarly for <code>\<<</code>, <code>\>|</code>, etc.</p>
|
||
<p>There is a commonly encountered problem with aliases illustrated by the
|
||
following code:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">alias echobar='echo bar'; echobar
|
||
</code></pre>
|
||
</div>
|
||
<p>This prints a message that the command <code>echobar</code> could not be found.
|
||
This happens because aliases are expanded when the code is read in; the
|
||
entire line is read in one go, so that when <code>echobar</code> is executed it is
|
||
too late to expand the newly defined alias. This is often a problem in
|
||
shell scripts, functions, and code executed with ‘<code>source</code>’ or ‘<code>.</code>’.
|
||
Consequently, use of functions rather than aliases is recommended in
|
||
non-interactive code.</p>
|
||
<p>Note also the unhelpful interaction of aliases and function definitions:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">alias func='noglob func'
|
||
func() {
|
||
echo Do something with $*
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p>Because aliases are expanded in function definitions, this causes the
|
||
following command to be executed:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">noglob func() {
|
||
echo Do something with $*
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p>which defines <code>noglob</code> as well as <code>func</code> as functions with the body
|
||
given. To avoid this, either quote the name <code>func</code> or use the
|
||
alternative function definition form ‘<code>function func</code>’. Ensuring the
|
||
alias is defined after the function works but is problematic if the code
|
||
fragment might be re-executed.</p>
|
||
<hr />
|
||
<p><span id="Quoting"></span> <span id="Quoting-1"></span></p>
|
||
<h2 id="69-quoting"><a class="header" href="#69-quoting">6.9 Quoting</a></h2>
|
||
<p><span id="index-quoting"></span></p>
|
||
<p>A character may be <em>quoted</em> (that is, made to stand for itself) by
|
||
preceding it with a ‘<code>\</code>’. ‘<code>\</code>’ followed by a newline is ignored.</p>
|
||
<p>A string enclosed between ‘<code>$’</code>’ and ‘<code>’</code>’ is processed the same way as
|
||
the string arguments of the <code>print</code> builtin, and the resulting string is
|
||
considered to be entirely quoted. A literal ‘<code>’</code>’ character can be
|
||
included in the string by using the ‘<code>\’</code>’ escape.</p>
|
||
<p><span id="index-RC_005fQUOTES_002c-use-of"></span></p>
|
||
<p>All characters enclosed between a pair of single quotes (<code>’’</code>) that is
|
||
not preceded by a ‘<code>$</code>’ are quoted. A single quote cannot appear within
|
||
single quotes unless the option <code>RC_QUOTES</code> is set, in which case a pair
|
||
of single quotes are turned into a single quote. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">print ''''
|
||
</code></pre>
|
||
</div>
|
||
<p>outputs nothing apart from a newline if <code>RC_QUOTES</code> is not set, but one
|
||
single quote if it is set.</p>
|
||
<p>Inside double quotes (<code>""</code>), parameter and command substitution occur,
|
||
and ‘<code>\</code>’ quotes the characters ‘<code>\</code>’, ‘<code>‘</code>’, ‘<code>"</code>’, ‘<code>$</code>’, and the
|
||
first character of <code>$histchars</code> (default ‘<code>!</code>’).</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>
|
||
<!-- 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="Redirection.html#7-redirection">7 Redirection</a>
|
||
<ul>
|
||
<li><a href="Redirection.html#71-opening-file-descriptors-using-parameters">7.1 Opening file descriptors using parameters</a></li>
|
||
<li><a href="Redirection.html#72-multios">7.2 Multios</a></li>
|
||
<li><a href="Redirection.html#73-redirections-with-no-command">7.3 Redirections with no command</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Redirection"></span> <span id="Redirection-1"></span></p>
|
||
<h1 id="7-redirection"><a class="header" href="#7-redirection">7 Redirection</a></h1>
|
||
<p><span id="index-redirection"></span>
|
||
<span id="index-file-descriptors"></span>
|
||
<span id="index-descriptors_002c-file"></span></p>
|
||
<p>If a command is followed by <code>&</code> and job control is not active, then the
|
||
default standard input for the command is the empty file <code>/dev/null</code>.
|
||
Otherwise, the environment for the execution of a command contains the
|
||
file descriptors of the invoking shell as modified by input/output
|
||
specifications.</p>
|
||
<p>The following may appear anywhere in a simple command or may precede or
|
||
follow a complex command. Expansion occurs before <code>word</code> or <code>digit</code> is
|
||
used except as noted below. If the result of substitution on <code>word</code>
|
||
produces more than one filename, redirection occurs for each separate
|
||
filename in turn.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code><</code> <code>word</code><br />
|
||
Open file <code>word</code> for reading as standard input. It is an error to
|
||
open a file in this fashion if it does not exist.</p>
|
||
</li>
|
||
<li>
|
||
<p><code><></code> <code>word</code><br />
|
||
Open file <code>word</code> for reading and writing as standard input. If the
|
||
file does not exist then it is created.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>></code> <code>word</code><br />
|
||
Open file <code>word</code> for writing as standard output. If the file does
|
||
not exist then it is created. If the file exists, and the <code>CLOBBER</code>
|
||
option is unset, this causes an error; otherwise, it is truncated to
|
||
zero length.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>>|</code> <code>word</code><br />
|
||
<code>>!</code> <code>word</code><br />
|
||
Same as <code>></code>, except that the file is truncated to zero length if it
|
||
exists, regardless of <code>CLOBBER</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>>></code> <code>word</code><br />
|
||
Open file <code>word</code> for writing in append mode as standard output. If
|
||
the file does not exist, and the <code>CLOBBER</code> and <code>APPEND_CREATE</code>
|
||
options are both unset, this causes an error; otherwise, the file is
|
||
created.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>>>|</code> <code>word</code><br />
|
||
<code>>>!</code> <code>word</code><br />
|
||
Same as <code>>></code>, except that the file is created if it does not exist,
|
||
regardless of <code>CLOBBER</code> and <code>APPEND_CREATE</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code><<</code>[<code>-</code>] <code>word</code><br />
|
||
The shell input is read up to a line that is the same as <code>word</code>, or
|
||
to an end-of-file. No parameter expansion, command substitution or
|
||
filename generation is performed on <code>word</code>. The resulting document,
|
||
called a <em>here-document</em>, becomes the standard input.</p>
|
||
<p>If any character of <code>word</code> is quoted with single or double quotes or
|
||
a ‘<code>\</code>’, no interpretation is placed upon the characters of the
|
||
document. Otherwise, parameter and command substitution occurs,
|
||
‘<code>\</code>’ followed by a newline is removed, and ‘<code>\</code>’ must be used
|
||
to quote the characters ‘<code>\</code>’, ‘<code>$</code>’, ‘<code>‘</code>’ and the first character
|
||
of <code>word</code>.</p>
|
||
<p>Note that <code>word</code> itself does not undergo shell expansion. Backquotes
|
||
in <code>word</code> do not have their usual effect; instead they behave
|
||
similarly to double quotes, except that the backquotes themselves
|
||
are passed through unchanged. (This information is given for
|
||
completeness and it is not recommended that backquotes be used.)
|
||
Quotes in the form <code>$’``...``’</code> have their standard effect of
|
||
expanding backslashed references to special characters.</p>
|
||
<p>If <code><<-</code> is used, then all leading tabs are stripped from <code>word</code> and
|
||
from the document.</p>
|
||
</li>
|
||
<li>
|
||
<p><code><<<</code> <code>word</code><br />
|
||
Perform shell expansion on <code>word</code> and pass the result to standard
|
||
input. This is known as a <em>here-string</em>. Compare the use of <code>word</code>
|
||
in here-documents above, where <code>word</code> does not undergo shell
|
||
expansion.</p>
|
||
</li>
|
||
<li>
|
||
<p><code><&</code> <code>number</code><br />
|
||
<code>>&</code> <code>number</code><br />
|
||
The standard input/output is duplicated from file descriptor
|
||
<code>number</code> (see man page dup2(2)).</p>
|
||
</li>
|
||
<li>
|
||
<p><code><& -</code><br />
|
||
<code>>& -</code><br />
|
||
Close the standard input/output.</p>
|
||
</li>
|
||
<li>
|
||
<p><code><& p</code><br />
|
||
<code>>& p</code><br />
|
||
The input/output from/to the coprocess is moved to the standard
|
||
input/output.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>>&</code> <code>word</code><br />
|
||
<code>&></code> <code>word</code><br />
|
||
(Except where ‘<code>>&</code> <code>word</code>’ matches one of the above syntaxes;
|
||
‘<code>&></code>’ can always be used to avoid this ambiguity.) Redirects
|
||
both standard output and standard error (file descriptor 2) in the
|
||
manner of ‘<code>></code> <code>word</code>’. Note that this does <em>not</em> have the same
|
||
effect as ‘<code>></code> <code>word</code> <code>2>&1</code>’ in the presence of multios (see the
|
||
section below).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>>&|</code> <code>word</code><br />
|
||
<code>>&!</code> <code>word</code><br />
|
||
<code>&>|</code> <code>word</code><br />
|
||
<code>&>!</code> <code>word</code><br />
|
||
Redirects both standard output and standard error (file descriptor</p>
|
||
<ol start="2">
|
||
<li>in the manner of ‘<code>>|</code> <code>word</code>’.</li>
|
||
</ol>
|
||
</li>
|
||
<li>
|
||
<p><code>>>&</code> <code>word</code><br />
|
||
<code>&>></code> <code>word</code><br />
|
||
Redirects both standard output and standard error (file descriptor</p>
|
||
<ol start="2">
|
||
<li>in the manner of ‘<code>>></code> <code>word</code>’.</li>
|
||
</ol>
|
||
</li>
|
||
<li>
|
||
<p><code>>>&|</code> <code>word</code><br />
|
||
<code>>>&!</code> <code>word</code><br />
|
||
<code>&>>|</code> <code>word</code><br />
|
||
<code>&>>!</code> <code>word</code><br />
|
||
Redirects both standard output and standard error (file descriptor</p>
|
||
<ol start="2">
|
||
<li>in the manner of ‘<code>>>|</code> <code>word</code>’.</li>
|
||
</ol>
|
||
</li>
|
||
</ul>
|
||
<p>If one of the above is preceded by a digit, then the file descriptor
|
||
referred to is that specified by the digit instead of the default 0 or</p>
|
||
<ol>
|
||
<li>The order in which redirections are specified is significant. The
|
||
shell evaluates each redirection in terms of the (<em>file descriptor</em>,
|
||
<em>file</em>) association at the time of evaluation. For example:</li>
|
||
</ol>
|
||
<blockquote>
|
||
<p>... <code>1>``fname</code> <code>2>&1</code></p>
|
||
</blockquote>
|
||
<p>first associates file descriptor 1 with file <code>fname</code>. It then associates
|
||
file descriptor 2 with the file associated with file descriptor 1 (that
|
||
is, <code>fname</code>). If the order of redirections were reversed, file
|
||
descriptor 2 would be associated with the terminal (assuming file
|
||
descriptor 1 had been) and then file descriptor 1 would be associated
|
||
with file <code>fname</code>.</p>
|
||
<p>The ‘<code>|&</code>’ command separator described in <a href="Shell-Grammar.html#Simple-Commands-_0026-Pipelines">Simple Commands &
|
||
Pipelines</a> is a
|
||
shorthand for ‘<code>2>&1 |</code>’.</p>
|
||
<p>The various forms of process substitution, ‘<code><(``list``)</code>’, and
|
||
‘<code>=(``list``)</code>’ for input and ‘<code>>(``list``)</code>’ for output, are often
|
||
used together with redirection. For example, if <code>word</code> in an output
|
||
redirection is of the form ‘<code>>(``list``)</code>’ then the output is piped to
|
||
the command represented by <code>list</code>. See <a href="Expansion.html#Process-Substitution">Process
|
||
Substitution</a>.</p>
|
||
<hr />
|
||
<p><span id="Opening-file-descriptors-using-parameters"></span></p>
|
||
<h2 id="71-opening-file-descriptors-using-parameters"><a class="header" href="#71-opening-file-descriptors-using-parameters">7.1 Opening file descriptors using parameters</a></h2>
|
||
<p><span id="index-file-descriptors_002c-use-with-parameters"></span>
|
||
<span id="index-parameters_002c-for-using-file-descriptors"></span></p>
|
||
<p>When the shell is parsing arguments to a command, and the shell option
|
||
<code>IGNORE_BRACES</code> is not set, a different form of redirection is allowed:
|
||
instead of a digit before the operator there is a valid shell identifier
|
||
enclosed in braces. The shell will open a new file descriptor that is
|
||
guaranteed to be at least 10 and set the parameter named by the
|
||
identifier to the file descriptor opened. No whitespace is allowed
|
||
between the closing brace and the redirection character. For example:</p>
|
||
<blockquote>
|
||
<p>... <code>{myfd}>&1</code></p>
|
||
</blockquote>
|
||
<p>This opens a new file descriptor that is a duplicate of file descriptor
|
||
1 and sets the parameter <code>myfd</code> to the number of the file descriptor,
|
||
which will be at least 10. The new file descriptor can be written to
|
||
using the syntax <code>>&$myfd</code>. The file descriptor remains open in
|
||
subshells</p>
|
||
<p>The syntax <code>{``varid``}>&-</code>, for example <code>{myfd}>&-</code>, may be used to
|
||
close a file descriptor opened in this fashion. Note that the parameter
|
||
given by <code>varid</code> must previously be set to a file descriptor in this
|
||
case.</p>
|
||
<p>It is an error to open or close a file descriptor in this fashion when
|
||
the parameter is readonly. However, it is not an error to read or write
|
||
a file descriptor using <code><&$``param</code> or <code>>&$``param</code> if <code>param</code> is
|
||
readonly.</p>
|
||
<p>If the option <code>CLOBBER</code> is unset, it is an error to open a file
|
||
descriptor using a parameter that is already set to an open file
|
||
descriptor previously allocated by this mechanism. Unsetting the
|
||
parameter before using it for allocating a file descriptor avoids the
|
||
error.</p>
|
||
<p>Note that this mechanism merely allocates or closes a file descriptor;
|
||
it does not perform any redirections from or to it. It is usually
|
||
convenient to allocate a file descriptor prior to use as an argument to
|
||
<code>exec</code>. The syntax does not in any case work when used around complex
|
||
commands such as parenthesised subshells or loops, where the opening
|
||
brace is interpreted as part of a command list to be executed in the
|
||
current shell.</p>
|
||
<p>The following shows a typical sequence of allocation, use, and closing
|
||
of a file descriptor:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">integer myfd
|
||
exec {myfd}>~/logs/mylogfile.txt
|
||
print This is a log message. >&$myfd
|
||
exec {myfd}>&-
|
||
</code></pre>
|
||
</div>
|
||
<p>Note that the expansion of the variable in the expression <code>>&$myfd</code>
|
||
occurs at the point the redirection is opened. This is after the
|
||
expansion of command arguments and after any redirections to the left on
|
||
the command line have been processed.</p>
|
||
<hr />
|
||
<p><span id="Multios"></span></p>
|
||
<h2 id="72-multios"><a class="header" href="#72-multios">7.2 Multios</a></h2>
|
||
<p><span id="index-multios"></span>
|
||
<span id="index-MULTIOS_002c-use-of"></span></p>
|
||
<p>If the user tries to open a file descriptor for writing more than once,
|
||
the shell opens the file descriptor as a pipe to a process that copies
|
||
its input to all the specified outputs, similar to tee, provided the
|
||
<code>MULTIOS</code> option is set, as it is by default. Thus:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">date >foo >bar
|
||
</code></pre>
|
||
</div>
|
||
<p>writes the date to two files, named ‘<code>foo</code>’ and ‘<code>bar</code>’. Note that a
|
||
pipe is an implicit redirection; thus</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">date >foo | cat
|
||
</code></pre>
|
||
</div>
|
||
<p>writes the date to the file ‘<code>foo</code>’, and also pipes it to cat.</p>
|
||
<p>Note that the shell opens all the files to be used in the multio process
|
||
immediately, not at the point they are about to be written.</p>
|
||
<p>Note also that redirections are always expanded in order. This happens
|
||
regardless of the setting of the <code>MULTIOS</code> option, but with the option
|
||
in effect there are additional consequences. For example, the meaning of
|
||
the expression <code>>&1</code> will change after a previous redirection:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">date >&1 >output
|
||
</code></pre>
|
||
</div>
|
||
<p>In the case above, the <code>>&1</code> refers to the standard output at the start
|
||
of the line; the result is similar to the <code>tee</code> command. However,
|
||
consider:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">date >output >&1
|
||
</code></pre>
|
||
</div>
|
||
<p>As redirections are evaluated in order, when the <code>>&1</code> is encountered
|
||
the standard output is set to the file <code>output</code> and another copy of the
|
||
output is therefore sent to that file. This is unlikely to be what is
|
||
intended.</p>
|
||
<p>If the <code>MULTIOS</code> option is set, the word after a redirection operator is
|
||
also subjected to filename generation (globbing). Thus</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">: > *
|
||
</code></pre>
|
||
</div>
|
||
<p>will truncate all files in the current directory, assuming there’s at
|
||
least one. (Without the <code>MULTIOS</code> option, it would create an empty file
|
||
called ‘<code>*</code>’.) Similarly, you can do</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">echo exit 0 >> *.sh
|
||
</code></pre>
|
||
</div>
|
||
<p>If the user tries to open a file descriptor for reading more than once,
|
||
the shell opens the file descriptor as a pipe to a process that copies
|
||
all the specified inputs to its output in the order specified, provided
|
||
the <code>MULTIOS</code> option is set. It should be noted that each file is opened
|
||
immediately, not at the point where it is about to be read: this
|
||
behaviour differs from <code>cat</code>, so if strictly standard behaviour is
|
||
needed, <code>cat</code> should be used instead.</p>
|
||
<p>Thus</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">sort <foo <fubar
|
||
</code></pre>
|
||
</div>
|
||
<p>or even</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">sort <f{oo,ubar}
|
||
</code></pre>
|
||
</div>
|
||
<p>is equivalent to ‘<code>cat foo fubar | sort</code>’.</p>
|
||
<p>Expansion of the redirection argument occurs at the point the
|
||
redirection is opened, at the point described above for the expansion of
|
||
the variable in <code>>&$myfd</code>.</p>
|
||
<p>Note that a pipe is an implicit redirection; thus</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">cat bar | sort <foo
|
||
</code></pre>
|
||
</div>
|
||
<p>is equivalent to ‘<code>cat bar foo | sort</code>’ (note the order of the inputs).</p>
|
||
<p>If the <code>MULTIOS</code> option is <em>un</em>set, each redirection replaces the
|
||
previous redirection for that file descriptor. However, all files
|
||
redirected to are actually opened, so</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">echo Hello > bar > baz
|
||
</code></pre>
|
||
</div>
|
||
<p>when <code>MULTIOS</code> is unset will truncate ‘<code>bar</code>’, and write ‘<code>Hello</code>’ into
|
||
‘<code>baz</code>’.</p>
|
||
<p>There is a problem when an output multio is attached to an external
|
||
program. A simple example shows this:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">cat file >file1 >file2
|
||
cat file1 file2
|
||
</code></pre>
|
||
</div>
|
||
<p>Here, it is possible that the second ‘<code>cat</code>’ will not display the full
|
||
contents of <code>file1</code> and <code>file2</code> (i.e. the original contents of <code>file</code>
|
||
repeated twice).</p>
|
||
<p>The reason for this is that the multios are spawned after the <code>cat</code>
|
||
process is forked from the parent shell, so the parent shell does not
|
||
wait for the multios to finish writing data. This means the command as
|
||
shown can exit before <code>file1</code> and <code>file2</code> are completely written. As a
|
||
workaround, it is possible to run the <code>cat</code> process as part of a job in
|
||
the current shell:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">{ cat file } >file >file2
|
||
</code></pre>
|
||
</div>
|
||
<p>Here, the <code>{``...``}</code> job will pause to wait for both files to be
|
||
written.</p>
|
||
<hr />
|
||
<p><span id="Redirections-with-no-command"></span></p>
|
||
<h2 id="73-redirections-with-no-command"><a class="header" href="#73-redirections-with-no-command">7.3 Redirections with no command</a></h2>
|
||
<p>When a simple command consists of one or more redirection operators and
|
||
zero or more parameter assignments, but no command name, zsh can behave
|
||
in several ways.</p>
|
||
<p><span id="index-NULLCMD_002c-use-of"></span>
|
||
<span id="index-CSH_005fNULLCMD_002c-use-of"></span></p>
|
||
<p>If the parameter <code>NULLCMD</code> is not set or the option <code>CSH_NULLCMD</code> is
|
||
set, an error is caused. This is the csh behavior and <code>CSH_NULLCMD</code> is
|
||
set by default when emulating csh.</p>
|
||
<p><span id="index-SH_005fNULLCMD_002c-use-of"></span></p>
|
||
<p>If the option <code>SH_NULLCMD</code> is set, the builtin ‘<code>:</code>’ is inserted as a
|
||
command with the given redirections. This is the default when emulating
|
||
sh or ksh.</p>
|
||
<p><span id="index-READNULLCMD_002c-use-of"></span></p>
|
||
<p>Otherwise, if the parameter <code>NULLCMD</code> is set, its value will be used as
|
||
a command with the given redirections. If both <code>NULLCMD</code> and
|
||
<code>READNULLCMD</code> are set, then the value of the latter will be used instead
|
||
of that of the former when the redirection is an input. The default for
|
||
<code>NULLCMD</code> is ‘<code>cat</code>’ and for <code>READNULLCMD</code> is ‘<code>more</code>’. Thus</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">< file
|
||
</code></pre>
|
||
</div>
|
||
<p>shows the contents of <code>file</code> on standard output, with paging if that is
|
||
a terminal. <code>NULLCMD</code> and <code>READNULLCMD</code> may refer to shell functions.</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>
|
||
<!-- 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="Command-Execution.html#8-command-execution">8 Command Execution</a></li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Command-Execution"></span>
|
||
<span id="Command-Execution-1"></span></p>
|
||
<h1 id="8-command-execution"><a class="header" href="#8-command-execution">8 Command Execution</a></h1>
|
||
<p><span id="index-command-execution"></span>
|
||
<span id="index-execution_002c-of-commands"></span>
|
||
<span id="index-command-not-found_002c-handling-of"></span>
|
||
<span id="index-command_005fnot_005ffound_005fhandler"></span></p>
|
||
<p>If a command name contains no slashes, the shell attempts to locate it.
|
||
If there exists a shell function by that name, the function is invoked
|
||
as described in <a href="Functions.html#Functions">Functions</a>. If there exists a
|
||
shell builtin by that name, the builtin is invoked.</p>
|
||
<p><span id="index-path_002c-use-of"></span></p>
|
||
<p>Otherwise, the shell searches each element of <code>$path</code> for a search is
|
||
unsuccessful, the shell prints an error message and returns a nonzero
|
||
exit status.</p>
|
||
<p>and the file is not a directory, it is assumed to be a shell script.
|
||
<code>/bin/sh</code> is spawned to execute it. If the program is a file beginning
|
||
with ‘<code>#!</code>’, the remainder of the first line specifies an interpreter
|
||
for the program. The shell will execute the specified interpreter on
|
||
operating systems that do</p>
|
||
<p>If no external command is found but a function
|
||
<code>command_not_found_handler</code> exists the shell executes this function with
|
||
all command line arguments. The return status of the function becomes
|
||
the status of the command. If the function wishes to mimic the behaviour
|
||
of the shell when the command is not found, it should print the message
|
||
‘<code>command not found:</code> <code>cmd</code>’ to standard error and return status 127.
|
||
Note that the handler is executed in a subshell forked to execute an
|
||
external command, hence changes to directories, shell parameters, etc.
|
||
have no effect on the main shell.</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>
|
||
<!-- 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="Functions.html#9-functions">9 Functions</a>
|
||
<ul>
|
||
<li><a href="Functions.html#91-autoloading-functions">9.1 Autoloading Functions</a></li>
|
||
<li><a href="Functions.html#92-anonymous-functions">9.2 Anonymous Functions</a></li>
|
||
<li><a href="Functions.html#93-special-functions">9.3 Special Functions</a>
|
||
<ul>
|
||
<li><a href="Functions.html#931-hook-functions">9.3.1 Hook Functions</a></li>
|
||
<li><a href="Functions.html#932-trap-functions">9.3.2 Trap Functions</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Functions"></span> <span id="Functions-3"></span></p>
|
||
<h1 id="9-functions"><a class="header" href="#9-functions">9 Functions</a></h1>
|
||
<p><span id="index-functions"></span>
|
||
<span id="index-function_002c-use-of"></span></p>
|
||
<p>Shell functions are defined with the <code>function</code> reserved word or the
|
||
special syntax ‘<code>funcname</code> <code>()</code>’. Shell functions are read in and stored
|
||
internally. Alias names are resolved when the function is read.
|
||
Functions are executed like commands with the arguments passed as
|
||
positional parameters. (See <a href="Command-Execution.html#Command-Execution">Command
|
||
Execution</a>.)</p>
|
||
<p>Functions execute in the same process as the caller and share all files
|
||
and present working directory with the caller. A trap on <code>EXIT</code> set
|
||
inside a function is executed after the function completes in the
|
||
environment of the caller.</p>
|
||
<p><span id="index-return_002c-use-of"></span></p>
|
||
<p>The <code>return</code> builtin is used to return from function calls.</p>
|
||
<p><span id="index-functions_002c-use-of"></span></p>
|
||
<p>Function identifiers can be listed with the <code>functions</code> builtin.
|
||
<span id="index-unfunction_002c-use-of"></span> Functions can be
|
||
undefined with the <code>unfunction</code> builtin.</p>
|
||
<hr />
|
||
<p><span id="Autoloading-Functions"></span></p>
|
||
<h2 id="91-autoloading-functions"><a class="header" href="#91-autoloading-functions">9.1 Autoloading Functions</a></h2>
|
||
<p><span id="index-autoloading-functions"></span>
|
||
<span id="index-functions_002c-autoloading"></span>
|
||
<span id="index-autoload_002c-use-of"></span>
|
||
<span id="index-fpath_002c-use-of"></span></p>
|
||
<p>A function can be marked as <em>undefined</em> using the <code>autoload</code> builtin (or
|
||
‘<code>functions -u</code>’ or ‘<code>typeset -fu</code>’). Such a function has no body. When
|
||
the function is first executed, the shell searches for its definition
|
||
using the elements of the <code>fpath</code> variable. Thus to define functions for
|
||
autoloading, a typical sequence is:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">fpath=(~/myfuncs $fpath)
|
||
autoload myfunc1 myfunc2 ...
|
||
</code></pre>
|
||
</div>
|
||
<p>The usual alias expansion during reading will be suppressed if the
|
||
<code>autoload</code> builtin or its equivalent is given the option <code>-U</code>. This is
|
||
recommended for the use of functions supplied with the zsh distribution.
|
||
<span id="index-zcompile_002c-use-of"></span> Note that for functions
|
||
precompiled with the <code>zcompile</code> builtin command the flag <code>-U</code> must be
|
||
provided when the <code>.zwc</code> file is created, as the corresponding
|
||
information is compiled into the latter.</p>
|
||
<p>For each <code>element</code> in <code>fpath</code>, the shell looks for three possible files,
|
||
the newest of which is used to load the definition for the function:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>element``.zwc</code><br />
|
||
A file created with the <code>zcompile</code> builtin command, which is
|
||
expected to contain the definitions for all functions in the
|
||
directory named <code>element</code>. The file is treated in the same manner as
|
||
a directory containing files for functions and is searched for the
|
||
definition of the function. If the definition is not found, the
|
||
search for a definition proceeds with the other two possibilities
|
||
described below.</p>
|
||
<p>If <code>element</code> already includes a <code>.zwc</code> extension (i.e. the extension
|
||
was explicitly given by the user), <code>element</code> is searched for the
|
||
definition of the function without comparing its age to that of
|
||
other files; in fact, there does not need to be any directory named
|
||
<code>element</code> without the suffix. Thus including an element such as
|
||
‘<code>/usr/local/funcs.zwc</code>’ in <code>fpath</code> will speed up the search for
|
||
functions, with the disadvantage that functions included must be
|
||
explicitly recompiled by hand before the shell notices any changes.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>element``/``function``.zwc</code><br />
|
||
A file created with <code>zcompile</code>, which is expected to contain the
|
||
definition for <code>function</code>. It may include other function definitions
|
||
as well, but those are neither loaded nor executed; a file found in
|
||
this way is searched <em>only</em> for the definition of <code>function</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>element``/``function</code><br />
|
||
A file of zsh command text, taken to be the definition for
|
||
<code>function</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<p>In summary, the order of searching is, first, in the <em>parents of</em>
|
||
directories in <code>fpath</code> for the newer of either a compiled directory or a
|
||
directory in <code>fpath</code>; second, if more than one of these contains a
|
||
definition for the function that is sought, the leftmost in the <code>fpath</code>
|
||
is chosen; and third, within a directory, the newer of either a compiled
|
||
function or an ordinary function definition is used.</p>
|
||
<p><span id="index-KSH_005fAUTOLOAD_002c-use-of"></span></p>
|
||
<p>If the <code>KSH_AUTOLOAD</code> option is set, or the file contains only a simple
|
||
definition of the function, the file’s contents will be executed. This
|
||
will normally define the function in question, but may also perform
|
||
initialization, which is executed in the context of the function
|
||
execution, and may therefore define local parameters. It is an error if
|
||
the function is not defined by loading the file.</p>
|
||
<p>Otherwise, the function body (with no surrounding ‘<code>funcname``() {``...``}</code>’) is taken to be the complete contents of the file. This
|
||
processing of the file results in the function being re-defined, the
|
||
function itself is not re-executed. To force the shell to perform
|
||
initialization and then call the function defined, the file should
|
||
contain initialization code (which will be executed then discarded) in
|
||
addition to a complete function definition (which will be retained for
|
||
subsequent calls to the function), and a call to the shell function,
|
||
including any arguments, at the end.</p>
|
||
<p>For example, suppose the autoload file <code>func</code> contains</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">func() { print This is func; }
|
||
print func is initialized
|
||
</code></pre>
|
||
</div>
|
||
<p>then ‘<code>func; func</code>’ with <code>KSH_AUTOLOAD</code> set will produce both messages
|
||
on the first call, but only the message ‘<code>This is func</code>’ on the second
|
||
and subsequent calls. Without <code>KSH_AUTOLOAD</code> set, it will produce the
|
||
initialization message on the first call, and the other message on the
|
||
second and subsequent calls.</p>
|
||
<p>It is also possible to create a function that is not marked as
|
||
autoloaded, but which loads its own definition by searching <code>fpath</code>, by
|
||
using ‘<code>autoload -X</code>’ within a shell function. For example, the
|
||
following are equivalent:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">myfunc() {
|
||
autoload -X
|
||
}
|
||
myfunc args...
|
||
</code></pre>
|
||
</div>
|
||
<p>and</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">unfunction myfunc # if myfunc was defined
|
||
autoload myfunc
|
||
myfunc args...
|
||
</code></pre>
|
||
</div>
|
||
<p>In fact, the <code>functions</code> command outputs ‘<code>builtin autoload -X</code>’ as the
|
||
body of an autoloaded function. This is done so that</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">eval "$(functions)"
|
||
</code></pre>
|
||
</div>
|
||
<p>produces a reasonable result. A true autoloaded function can be
|
||
identified by the presence of the comment ‘<code># undefined</code>’ in the body,
|
||
because all comments are discarded from defined functions.</p>
|
||
<p>To load the definition of an autoloaded function <code>myfunc</code> without
|
||
executing <code>myfunc</code>, use:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">autoload +X myfunc
|
||
</code></pre>
|
||
</div>
|
||
<hr />
|
||
<p><span id="Anonymous-Functions"></span></p>
|
||
<h2 id="92-anonymous-functions"><a class="header" href="#92-anonymous-functions">9.2 Anonymous Functions</a></h2>
|
||
<p><span id="index-anonymous-functions"></span>
|
||
<span id="index-functions_002c-anonymous"></span></p>
|
||
<p>If no name is given for a function, it is ‘anonymous’ and is handled
|
||
specially. Either form of function definition may be used: a ‘<code>()</code>’ with
|
||
no preceding name, or a ‘<code>function</code>’ with an immediately following open
|
||
brace. The function is executed immediately at the point of definition
|
||
and is not stored for future use. The function name is set to
|
||
‘<code>(anon)</code>’.</p>
|
||
<p>Arguments to the function may be specified as words following the
|
||
closing brace defining the function, hence if there are none no
|
||
arguments (other than <code>$0</code>) are set. This is a difference from the way
|
||
other functions are parsed: normal function definitions may be followed
|
||
by certain keywords such as ‘<code>else</code>’ or ‘<code>fi</code>’, which will be treated as
|
||
arguments to anonymous functions, so that a newline or semicolon is
|
||
needed to force keyword interpretation.</p>
|
||
<p>Note also that the argument list of any enclosing script or function is
|
||
hidden (as would be the case for any other function called at this
|
||
point).</p>
|
||
<p>Redirections may be applied to the anonymous function in the same manner
|
||
as to a current-shell structure enclosed in braces. The main use of
|
||
anonymous functions is to provide a scope for local variables. This is
|
||
particularly convenient in start-up files as these do not provide their
|
||
own local variable scope.</p>
|
||
<p>For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">variable=outside
|
||
function {
|
||
local variable=inside
|
||
print "I am $variable with arguments $*"
|
||
} this and that
|
||
print "I am $variable"
|
||
</code></pre>
|
||
</div>
|
||
<p>outputs the following:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">I am inside with arguments this and that
|
||
I am outside
|
||
</code></pre>
|
||
</div>
|
||
<p>Note that function definitions with arguments that expand to nothing,
|
||
for example ‘<code>name=; function $name { ``...`` }</code>’, are not treated
|
||
as anonymous functions. Instead, they are treated as normal function
|
||
definitions where the definition is silently discarded.</p>
|
||
<hr />
|
||
<p><span id="Special-Functions"></span></p>
|
||
<h2 id="93-special-functions"><a class="header" href="#93-special-functions">9.3 Special Functions</a></h2>
|
||
<p>Certain functions, if defined, have special meaning to the shell.</p>
|
||
<hr />
|
||
<p><span id="Hook-Functions"></span></p>
|
||
<h3 id="931-hook-functions"><a class="header" href="#931-hook-functions">9.3.1 Hook Functions</a></h3>
|
||
<p><span id="index-functions_002c-hook"></span>
|
||
<span id="index-hook-functions"></span></p>
|
||
<p>For the functions below, it is possible to define an array that has the
|
||
same name as the function with ‘<code>_functions</code>’ appended. Any element in
|
||
such an array is taken as the name of a function to execute; it is
|
||
executed in the same context and with the same arguments as the basic
|
||
function. For example, if <code>$chpwd_functions</code> is an array containing the
|
||
values ‘<code>mychpwd</code>’, ‘<code>chpwd_save_dirstack</code>’, then the shell attempts to
|
||
execute the functions ‘<code>chpwd</code>’, ‘<code>mychpwd</code>’ and
|
||
‘<code>chpwd_save_dirstack</code>’, in that order. Any function that does not
|
||
exist is silently ignored. A function found by this mechanism is
|
||
referred to elsewhere as a ‘hook function’. An error in any function
|
||
causes subsequent functions not to be run. Note further that an error in
|
||
a <code>precmd</code> hook causes an immediately following <code>periodic</code> function not
|
||
to run (though it may run at the next opportunity).</p>
|
||
<p><span id="index-chpwd"></span>
|
||
<span id="index-chpwd_005ffunctions"></span></p>
|
||
<p><code>chpwd</code></p>
|
||
<p>Executed whenever the current working directory is changed.</p>
|
||
<p><span id="index-periodic"></span>
|
||
<span id="index-periodic_005ffunctions"></span></p>
|
||
<p><code>periodic</code></p>
|
||
<p><span id="index-PERIOD"></span></p>
|
||
<p>If the parameter <code>PERIOD</code> is set, this function is executed every
|
||
<code>$PERIOD</code> seconds, just before a prompt. Note that if multiple functions
|
||
are defined using the array <code>periodic_functions</code> only one period is
|
||
applied to the complete set of functions, and the scheduled time is not
|
||
reset if the list of functions is altered. Hence the set of functions is
|
||
always called together.</p>
|
||
<p><span id="index-precmd"></span>
|
||
<span id="index-precmd_005ffunctions"></span></p>
|
||
<p><code>precmd</code></p>
|
||
<p>Executed before each prompt. Note that precommand functions are not
|
||
re-executed simply because the command line is redrawn, as happens, for
|
||
example, when a notification about an exiting job is displayed.</p>
|
||
<p><span id="index-preexec"></span>
|
||
<span id="index-preexec_005ffunctions"></span></p>
|
||
<p><code>preexec</code></p>
|
||
<p>Executed just after a command has been read and is about to be executed.
|
||
If the history mechanism is active (regardless of whether the line was
|
||
discarded from the history buffer), the string that the user typed is
|
||
passed as the first argument, otherwise it is an empty string. The
|
||
actual command that will be executed (including expanded aliases) is
|
||
passed in two different forms: the second argument is a single-line,
|
||
size-limited version of the command (with things like function bodies
|
||
elided); the third argument contains the full text that is being
|
||
executed.</p>
|
||
<p><span id="index-zshaddhistory"></span>
|
||
<span id="index-zshaddhistory_005ffunctions"></span></p>
|
||
<p><code>zshaddhistory</code></p>
|
||
<p><span id="index-history_002c-hook-when-line-is-saved"></span></p>
|
||
<p>Executed when a history line has been read interactively, but before it
|
||
is executed. The sole argument is the complete history line (so that any
|
||
terminating newline will still be present).</p>
|
||
<p>If any of the hook functions returns status 1 (or any non-zero value
|
||
other than 2, though this is not guaranteed for future versions of the
|
||
shell) the history line will not be saved, although it lingers in the
|
||
history until the next line is executed, allowing you to reuse or edit
|
||
it immediately.</p>
|
||
<p>If any of the hook functions returns status 2 the history line will be
|
||
saved on the internal history list, but not written to the history file.
|
||
In case of a conflict, the first non-zero status value is taken.</p>
|
||
<p>A hook function may call ‘<code>fc -p</code> <code>...</code>’ to switch the history context
|
||
so that the history is saved in a different file from the that in the
|
||
global <code>HISTFILE</code> parameter. This is handled specially: the history
|
||
context is automatically restored after the processing of the history
|
||
line is finished.</p>
|
||
<p>The following example function works with one of the options
|
||
<code>INC_APPEND_HISTORY</code> or <code>SHARE_HISTORY</code> set, in order that the line is
|
||
written out immediately after the history entry is added. It first adds
|
||
the history line to the normal history with the newline stripped, which
|
||
is usually the correct behaviour. Then it switches the history context
|
||
so that the line will be written to a history file in the current
|
||
directory.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zshaddhistory() {
|
||
print -sr -- ${1%%$'\n'}
|
||
fc -p .zsh_local_history
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-zshexit"></span>
|
||
<span id="index-zshexit_005ffunctions"></span></p>
|
||
<p><code>zshexit</code></p>
|
||
<p>Executed at the point where the main shell is about to exit normally.
|
||
This is not called by exiting subshells, nor when the <code>exec</code> precommand
|
||
modifier is used before an external command. Also, unlike <code>TRAPEXIT</code>, it
|
||
is not called when functions exit.</p>
|
||
<hr />
|
||
<p><span id="Trap-Functions"></span></p>
|
||
<h3 id="932-trap-functions"><a class="header" href="#932-trap-functions">9.3.2 Trap Functions</a></h3>
|
||
<p>The functions below are treated specially but do not have corresponding
|
||
hook arrays.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>TRAP``NAL</code><br />
|
||
<span id="index-signals_002c-trapping"></span>
|
||
<span id="index-trapping-signals"></span></p>
|
||
<p>If defined and non-null, this function will be executed whenever the
|
||
shell catches a signal <code>SIG``NAL</code>, where <code>NAL</code> is a signal name as
|
||
specified for the <code>kill</code> builtin. The signal number will be passed
|
||
as the first parameter to the function.</p>
|
||
<p>If a function of this form is defined and null, the shell and
|
||
processes spawned by it will ignore <code>SIG``NAL</code>.</p>
|
||
<p>The return status from the function is handled specially. If it is
|
||
zero, the signal is assumed to have been handled, and execution
|
||
continues normally. Otherwise, the shell will behave as interrupted
|
||
except that the return status of the trap is retained.</p>
|
||
<p>Programs terminated by uncaught signals typically return the status
|
||
128 plus the signal number. Hence the following causes the handler
|
||
for <code>SIGINT</code> to print a message, then mimic the usual effect of the
|
||
signal.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">TRAPINT() {
|
||
print "Caught SIGINT, aborting."
|
||
return $(( 128 + $1 ))
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p>The functions <code>TRAPZERR</code>, <code>TRAPDEBUG</code> and <code>TRAPEXIT</code> are never
|
||
executed inside other traps.</p>
|
||
<p><span id="index-TRAPDEBUG"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>TRAPDEBUG</code><br />
|
||
If the option <code>DEBUG_BEFORE_CMD</code> is set (as it is by default),
|
||
executed before each command; otherwise executed after each command.
|
||
See the description of the <code>trap</code> builtin in <a href="Shell-Builtin-Commands.html#Shell-Builtin-Commands">Shell Builtin
|
||
Commands</a> for
|
||
details of additional features provided in debug traps.</p>
|
||
<p><span id="index-TRAPEXIT"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>TRAPEXIT</code><br />
|
||
Executed when the shell exits, or when the current function exits if
|
||
defined inside a function. 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.</p>
|
||
<p><span id="index-TRAPZERR"></span> <span id="index-TRAPERR"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>TRAPZERR</code><br />
|
||
Executed whenever a command has a non-zero exit status. However, the
|
||
function is not executed if the command occurred in a sublist
|
||
followed by ‘<code>&&</code>’ or ‘<code>||</code>’; only the final command in a sublist of
|
||
this type causes the trap to be executed. The function <code>TRAPERR</code>
|
||
acts the same as <code>TRAPZERR</code> on systems where there is no <code>SIGERR</code>
|
||
(this is the usual case).</p>
|
||
</li>
|
||
</ul>
|
||
<p><span id="index-trap_002c-use-of"></span></p>
|
||
<p>The functions beginning ‘<code>TRAP</code>’ may alternatively be defined with the
|
||
<code>trap</code> builtin: this may be preferable for some uses. Setting a trap
|
||
with one form removes any trap of the other form for the same signal;
|
||
removing a trap in either form removes all traps for the same signal.
|
||
The forms</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">TRAPNAL() {
|
||
# code
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p>(’function traps’) and</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">trap '
|
||
# code
|
||
' NAL
|
||
</code></pre>
|
||
</div>
|
||
<p>(’list traps’) are equivalent in most ways, the exceptions being the
|
||
following:</p>
|
||
<ul>
|
||
<li>Function traps have all the properties of normal functions,
|
||
appearing in the list of functions and being called with their own
|
||
function context rather than the context where the trap was
|
||
triggered.</li>
|
||
<li>The return status from function traps is special, whereas a return
|
||
from a list trap causes the surrounding context to return with the
|
||
given status.</li>
|
||
<li>Function traps are not reset within subshells, in accordance with
|
||
zsh behaviour; list traps are reset, in accordance with POSIX
|
||
behaviour.</li>
|
||
</ul>
|
||
<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>
|
||
<!-- 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="Jobs-_0026-Signals.html#10-jobs--signals">10 Jobs & Signals</a>
|
||
<ul>
|
||
<li><a href="Jobs-_0026-Signals.html#101-jobs">10.1 Jobs</a></li>
|
||
<li><a href="Jobs-_0026-Signals.html#102-signals">10.2 Signals</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Jobs-_0026-Signals"></span>
|
||
<span id="Jobs-_0026-Signals-1"></span></p>
|
||
<h1 id="10-jobs--signals"><a class="header" href="#10-jobs--signals">10 Jobs & Signals</a></h1>
|
||
<hr />
|
||
<p><span id="Jobs"></span></p>
|
||
<h2 id="101-jobs"><a class="header" href="#101-jobs">10.1 Jobs</a></h2>
|
||
<p><span id="index-jobs"></span>
|
||
<span id="index-MONITOR_002c-use-of"></span></p>
|
||
<p>If the <code>MONITOR</code> option is set, an interactive shell associates a <em>job</em>
|
||
with each pipeline. command, and assigns them small integer numbers.
|
||
When a job is started asynchronously with ‘<code>&</code>’, the shell prints a line
|
||
to standard error which looks like:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">[1] 1234
|
||
</code></pre>
|
||
</div>
|
||
<p>indicating that the job which was started asynchronously was job number
|
||
1 and had one (top-level) process, whose process ID was 1234.</p>
|
||
<p>If a job is started with ‘<code>&|</code>’ or ‘<code>&!</code>’, then that job is immediately
|
||
disowned. After startup, it to the job control features described here.</p>
|
||
<p>If you are running a job and wish to do something else you may hit the
|
||
key ^Z (control-Z) which sends a <code>TSTP</code> signal to the current job: this
|
||
key may be redefined by the <code>susp</code> option of the external <code>stty</code>
|
||
command. <span id="index-jobs_002c-suspending"></span>
|
||
<span id="index-suspending-jobs"></span> The shell will then normally
|
||
indicate that the job has been ‘suspended’, and print another prompt.
|
||
You can then manipulate the state of this job,
|
||
<span id="index-bg_002c-use-of"></span> putting it in the background
|
||
with the <code>bg</code> command, or run some other commands and then eventually
|
||
bring the job back into the foreground with
|
||
<span id="index-fg_002c-use-of"></span> the foreground command <code>fg</code>. A
|
||
^Z takes effect immediately and is like an interrupt in that pending
|
||
output and unread input are discarded when it is typed.</p>
|
||
<p>A job being run in the background will suspend if it tries to read from
|
||
the terminal.</p>
|
||
<p>Note that if the job running in the foreground is a shell function, then
|
||
suspending it will have the effect of causing the shell to fork. This is
|
||
necessary to separate the function’s state from that of the parent shell
|
||
performing the job control, so that the latter can return to the command
|
||
line prompt. As a result, even if <code>fg</code> is used to continue the job the
|
||
function will no longer be part of the parent shell, and any variables
|
||
set by the function will not be visible in the parent shell. Thus the
|
||
behaviour is different from the case where the function was never
|
||
suspended. Zsh is different from many other shells in this regard.</p>
|
||
<p>One additional side effect is that use of <code>disown</code> with a job created by
|
||
suspending shell code in this fashion is delayed: the job can only be
|
||
disowned once any process started from the parent shell has terminated.
|
||
At that point, the disowned job disappears silently from the job list.</p>
|
||
<p>The same behaviour is found when the shell is executing code as the
|
||
right hand side of a pipeline or any complex shell construct such as
|
||
<code>if</code>, <code>for</code>, etc., in order that the entire block of code can be managed
|
||
as a single job. <span id="index-background-jobs_002c-I_002fO"></span>
|
||
<span id="index-jobs_002c-background_002c-I_002fO"></span> Background
|
||
jobs are normally allowed to produce output, but this can be disabled by
|
||
giving the command ‘<code>stty tostop</code>’. If you set this tty option, then
|
||
background jobs will suspend when they try to produce output like they
|
||
do when they try to read input.</p>
|
||
<p>When a command is suspended and continued later with the <code>fg</code> or <code>wait</code>
|
||
builtins, zsh restores tty modes that were in effect when it was
|
||
suspended. This (intentionally) does not apply if the command is
|
||
continued via ‘<code>kill -CONT</code>’, nor when it is continued with <code>bg</code>.</p>
|
||
<p><span id="index-jobs_002c-referring-to"></span>
|
||
<span id="index-referring-to-jobs"></span></p>
|
||
<p>There are several ways to refer to jobs in the shell. A job can be
|
||
referred to by the process ID of any process of the job or by one of the
|
||
following:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>%``number</code><br />
|
||
The job with the given number.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%``string</code><br />
|
||
The last job whose command line begins with <code>string</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%?``string</code><br />
|
||
The last job whose command line contains <code>string</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%%</code><br />
|
||
Current job.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%+</code><br />
|
||
Equivalent to ‘<code>%%</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%-</code><br />
|
||
Previous job.</p>
|
||
</li>
|
||
</ul>
|
||
<p>The shell learns immediately whenever a process changes state.
|
||
<span id="index-NOTIFY_002c-use-of"></span> It normally informs you
|
||
whenever a job becomes blocked so that no further progress is possible.
|
||
If the <code>NOTIFY</code> option is not set, it waits until just before it prints
|
||
a prompt before it informs you. All such notifications are sent directly
|
||
to the terminal, not to the standard output or standard error.</p>
|
||
<p>When the monitor mode is on, each background job that completes triggers
|
||
any trap set for <code>CHLD</code>.</p>
|
||
<p>When you try to leave the shell while jobs are running or suspended, you
|
||
will be warned that ‘You have suspended (running) jobs’. You may use the
|
||
<code>jobs</code> command to see what they are. If you do this or immediately try
|
||
to exit again, the shell will not warn you a second time; the suspended
|
||
jobs will be terminated, and the running jobs will be sent a <code>SIGHUP</code>
|
||
signal, if the <code>HUP</code> option is set.
|
||
<span id="index-HUP_002c-use-of"></span></p>
|
||
<p><span id="index-jobs_002c-disowning"></span>
|
||
<span id="index-disowning-jobs"></span>
|
||
<span id="index-disown_002c-use-of"></span></p>
|
||
<p>To avoid having the shell terminate the running jobs, either use the
|
||
nohup command (see man page nohup(1)) or the <code>disown</code> builtin.</p>
|
||
<hr />
|
||
<p><span id="Signals"></span></p>
|
||
<h2 id="102-signals"><a class="header" href="#102-signals">10.2 Signals</a></h2>
|
||
<p>The <code>INT</code> and <code>QUIT</code> signals for an invoked command are ignored if the
|
||
command is followed by ‘<code>&</code>’ and the <code>MONITOR</code> option is not active. The
|
||
shell itself always ignores the <code>QUIT</code> signal. Otherwise, signals have
|
||
the values inherited by the shell from its parent (but see the
|
||
<code>TRAP``NAL</code> special functions in <a href="Functions.html#Functions">Functions</a>).</p>
|
||
<p><span id="index-exiting-shell_002c-and-asynchronous-jobs"></span>
|
||
<span id="index-asynchronous-jobs_002c-and-exiting-shell"></span>
|
||
<span id="index-jobs_002c-asynchronous_002c-and-exiting-shell"></span></p>
|
||
<p>Certain jobs are run asynchronously by the shell other than those
|
||
explicitly put into the background; even in cases where the shell would
|
||
usually wait for such jobs, an explicit <code>exit</code> command or exit due to
|
||
the option <code>ERR_EXIT</code> will cause the shell to exit without waiting.
|
||
Examples of such asynchronous jobs are process substitution, see
|
||
<a href="Expansion.html#Process-Substitution">Process Substitution</a>, and the
|
||
handler processes for multios, see the section Multios in
|
||
<a href="Redirection.html#Redirection">Redirection</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>
|
||
<!-- 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="Arithmetic-Evaluation.html#11-arithmetic-evaluation">11 Arithmetic Evaluation</a></li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Arithmetic-Evaluation"></span>
|
||
<span id="Arithmetic-Evaluation-1"></span></p>
|
||
<h1 id="11-arithmetic-evaluation"><a class="header" href="#11-arithmetic-evaluation">11 Arithmetic Evaluation</a></h1>
|
||
<p><span id="index-arithmetic-evaluation"></span>
|
||
<span id="index-evaluation_002c-arithmetic"></span>
|
||
<span id="index-let_002c-use-of"></span></p>
|
||
<p>The shell can perform integer and floating point arithmetic, either
|
||
using the builtin <code>let</code>, or via a substitution of the form
|
||
<code>$((``...``))</code>. For integers, the shell is usually compiled to use
|
||
8-byte precision where this is available, otherwise precision is 4
|
||
bytes. This can be tested, for example, by giving the command ‘<code>print - $(( 12345678901 ))</code>’; if the number appears unchanged, the precision is
|
||
at least 8 bytes. Floating point arithmetic always uses the ‘double’
|
||
type with whatever corresponding precision is provided by the compiler
|
||
and the library.</p>
|
||
<p>The <code>let</code> builtin command takes arithmetic expressions as arguments;
|
||
each is evaluated separately. Since many of the arithmetic operators, as
|
||
well as spaces, require quoting, an alternative form is provided: for
|
||
any command which begins with a ‘<code>((</code>’, all the characters until a
|
||
matching ‘<code>))</code>’ are treated as a quoted expression and arithmetic
|
||
expansion performed as for an argument of <code>let</code>. More precisely,
|
||
‘<code>((``...``))</code>’ is equivalent to ‘<code>let "``...``"</code>’. The return status
|
||
is 0 if the arithmetic value of the expression is non-zero, 1 if it is
|
||
zero, and 2 if an error occurred.</p>
|
||
<p>For example, the following statement</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">(( val = 2 + 1 ))
|
||
</code></pre>
|
||
</div>
|
||
<p>is equivalent to</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">let "val = 2 + 1"
|
||
</code></pre>
|
||
</div>
|
||
<p>both assigning the value 3 to the shell variable <code>val</code> and returning a
|
||
zero status.</p>
|
||
<p><span id="index-arithmetic-base"></span>
|
||
<span id="index-bases_002c-in-arithmetic"></span></p>
|
||
<p>Integers can be in bases other than 10. A leading ‘<code>0x</code>’ or ‘<code>0X</code>’
|
||
denotes hexadecimal and a leading ‘<code>0b</code>’ or ‘<code>0B</code>’ binary. Integers may
|
||
also be of the form ‘<code>base``#``n</code>’, where <code>base</code> is a decimal number
|
||
between two and thirty-six representing the arithmetic base and <code>n</code> is a
|
||
number in that base (for example, ‘<code>16#ff</code>’ is 255 in hexadecimal). The
|
||
<code>base``#</code> may also be omitted, in which case base 10 is used. For
|
||
backwards compatibility the form ‘<code>[``base``]``n</code>’ is also accepted.</p>
|
||
<p>An integer expression or a base given in the form ‘<code>base``#``n</code>’ may
|
||
contain underscores (‘<code>_</code>’) after the leading digit for visual guidance;
|
||
these are ignored in computation. Examples are <code>1_000_000</code> or
|
||
<code>0xffff_ffff</code> which are equivalent to <code>1000000</code> and <code>0xffffffff</code>
|
||
respectively.</p>
|
||
<p>It is also possible to specify a base to be used for output in the form
|
||
‘<code>[#``base``]</code>’, for example ‘<code>[#16]</code>’. This is used when outputting
|
||
arithmetical substitutions or when assigning to scalar parameters, but
|
||
an explicitly defined integer or floating point parameter will not be
|
||
affected. If an integer variable is implicitly defined by an arithmetic
|
||
expression, any base specified in this way will be set as the variable’s
|
||
output arithmetic base as if the option ‘<code>-i</code> <code>base</code>’ to the <code>typeset</code>
|
||
builtin had been used. The expression has no precedence and if it occurs
|
||
more than once in a mathematical expression, the last encountered is
|
||
used. For clarity it is recommended that it appear at the beginning of
|
||
an expression. As an example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">typeset -i 16 y
|
||
print $(( [#8] x = 32, y = 32 ))
|
||
print $x $y
|
||
</code></pre>
|
||
</div>
|
||
<p>outputs first ‘<code>8#40</code>’, the rightmost value in the given output base,
|
||
and then ‘<code>8#40 16#20</code>’, because <code>y</code> has been explicitly declared to
|
||
have output base 16, while <code>x</code> (assuming it does not already exist) is
|
||
implicitly typed by the arithmetic evaluation, where it acquires the
|
||
output base 8.</p>
|
||
<p>The <code>base</code> may be replaced or followed by an underscore, which may
|
||
itself be followed by a positive integer (if it is missing the value 3
|
||
is used). This indicates that underscores should be inserted into the
|
||
output string, grouping the number for visual clarity. The following
|
||
integer specifies the number of digits to group together. For example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">setopt cbases
|
||
print $(( [#16_4] 65536 ** 2 ))
|
||
</code></pre>
|
||
</div>
|
||
<p>outputs ‘<code>0x1_0000_0000</code>’.</p>
|
||
<p>The feature can be used with floating point numbers, in which case the
|
||
base must be omitted; grouping is away from the decimal point. For
|
||
example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zmodload zsh/mathfunc
|
||
print $(( [#_] sqrt(1e7) ))
|
||
</code></pre>
|
||
</div>
|
||
<p>outputs ‘<code>3_162.277_660_168_379_5</code>’ (the number of decimal places shown
|
||
may vary).</p>
|
||
<p><span id="index-C_005fBASES_002c-use-of"></span>
|
||
<span id="index-OCTAL_005fZEROES_002c-use-of"></span></p>
|
||
<p>If the <code>C_BASES</code> option is set, hexadecimal numbers are output in the
|
||
standard C format, for example ‘<code>0xFF</code>’ instead of the usual ‘<code>16#FF</code>’.
|
||
If the option <code>OCTAL_ZEROES</code> is also set (it is not by default), octal
|
||
numbers will be treated similarly and hence appear as ‘<code>077</code>’ instead of
|
||
‘<code>8#77</code>’. This option has no effect on the output of bases other than
|
||
hexadecimal and octal, and these formats are always understood on input.</p>
|
||
<p>When an output base is specified using the ‘<code>[#``base``]</code>’ syntax, an
|
||
appropriate base prefix will be output if necessary, so that the value
|
||
output is valid syntax for input. If the <code>#</code> is doubled, for example
|
||
‘<code>[##16]</code>’, then no base prefix is output.</p>
|
||
<p>Floating point constants are recognized by the presence of a decimal
|
||
point or an exponent. The decimal point may be the first character of
|
||
the constant, but the exponent character <code>e</code> or <code>E</code> may not, as it will
|
||
be taken for a parameter name. All numeric parts (before and after the
|
||
decimal point and in the exponent) may contain underscores after the
|
||
leading digit for visual guidance; these are ignored in computation.</p>
|
||
<p><span id="index-arithmetic-operators"></span>
|
||
<span id="index-operators_002c-arithmetic"></span></p>
|
||
<p>An arithmetic expression uses nearly the same syntax and associativity
|
||
of expressions as in C.</p>
|
||
<p>In the native mode of operation, the following operators are supported
|
||
(listed in decreasing order of precedence):</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>+ - ! ~ ++ –</code><br />
|
||
unary plus/minus, logical NOT, complement, {pre,post}{in,de}crement</p>
|
||
</li>
|
||
<li>
|
||
<p><code><< >></code><br />
|
||
bitwise shift left, right</p>
|
||
</li>
|
||
<li>
|
||
<p><code>&</code><br />
|
||
bitwise AND</p>
|
||
</li>
|
||
<li>
|
||
<p><code>^</code><br />
|
||
bitwise XOR</p>
|
||
</li>
|
||
<li>
|
||
<p><code>|</code><br />
|
||
bitwise OR</p>
|
||
</li>
|
||
<li>
|
||
<p><code>**</code><br />
|
||
exponentiation</p>
|
||
</li>
|
||
<li>
|
||
<p><code>* / %</code><br />
|
||
multiplication, division, modulus (remainder)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>+ -</code><br />
|
||
addition, subtraction</p>
|
||
</li>
|
||
<li>
|
||
<p><code>< > <= >=</code><br />
|
||
comparison</p>
|
||
</li>
|
||
<li>
|
||
<p><code>== !=</code><br />
|
||
equality and inequality</p>
|
||
</li>
|
||
<li>
|
||
<p><code>&&</code><br />
|
||
logical AND</p>
|
||
</li>
|
||
<li>
|
||
<p><code>|| ^^</code><br />
|
||
logical OR, XOR</p>
|
||
</li>
|
||
<li>
|
||
<p><code>? :</code><br />
|
||
ternary operator</p>
|
||
</li>
|
||
<li>
|
||
<p><code>= += -= *= /= %= &= ^= |= <<= >>= &&= ||= ^^= **=</code><br />
|
||
assignment</p>
|
||
</li>
|
||
<li>
|
||
<p><code>,</code><br />
|
||
comma operator</p>
|
||
</li>
|
||
</ul>
|
||
<p>The operators ‘<code>&&</code>’, ‘<code>||</code>’, ‘<code>&&=</code>’, and ‘<code>||=</code>’ are short-circuiting,
|
||
and only one of the latter two expressions in a ternary operator is
|
||
evaluated. Note the precedence of the bitwise AND, OR, and XOR
|
||
operators.</p>
|
||
<p>With the option <code>C_PRECEDENCES</code> the precedences (but no other
|
||
properties) of the operators are altered to be the same as those in most
|
||
other languages that support the relevant operators:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>+ - ! ~ ++ –</code><br />
|
||
unary plus/minus, logical NOT, complement, {pre,post}{in,de}crement</p>
|
||
</li>
|
||
<li>
|
||
<p><code>**</code><br />
|
||
exponentiation</p>
|
||
</li>
|
||
<li>
|
||
<p><code>* / %</code><br />
|
||
multiplication, division, modulus (remainder)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>+ -</code><br />
|
||
addition, subtraction</p>
|
||
</li>
|
||
<li>
|
||
<p><code><< >></code><br />
|
||
bitwise shift left, right</p>
|
||
</li>
|
||
<li>
|
||
<p><code>< > <= >=</code><br />
|
||
comparison</p>
|
||
</li>
|
||
<li>
|
||
<p><code>== !=</code><br />
|
||
equality and inequality</p>
|
||
</li>
|
||
<li>
|
||
<p><code>&</code><br />
|
||
bitwise AND</p>
|
||
</li>
|
||
<li>
|
||
<p><code>^</code><br />
|
||
bitwise XOR</p>
|
||
</li>
|
||
<li>
|
||
<p><code>|</code><br />
|
||
bitwise OR</p>
|
||
</li>
|
||
<li>
|
||
<p><code>&&</code><br />
|
||
logical AND</p>
|
||
</li>
|
||
<li>
|
||
<p><code>^^</code><br />
|
||
logical XOR</p>
|
||
</li>
|
||
<li>
|
||
<p><code>||</code><br />
|
||
logical OR</p>
|
||
</li>
|
||
<li>
|
||
<p><code>? :</code><br />
|
||
ternary operator</p>
|
||
</li>
|
||
<li>
|
||
<p><code>= += -= *= /= %= &= ^= |= <<= >>= &&= ||= ^^= **=</code><br />
|
||
assignment</p>
|
||
</li>
|
||
<li>
|
||
<p><code>,</code><br />
|
||
comma operator</p>
|
||
</li>
|
||
</ul>
|
||
<p>Note the precedence of exponentiation in both cases is below that of
|
||
unary operators, hence ‘<code>-3**2</code>’ evaluates as ‘<code>9</code>’, not ‘<code>-9</code>’. Use
|
||
parentheses where necessary: ‘<code>-(3**2)</code>’. This is for compatibility with
|
||
other shells.</p>
|
||
<p><span id="index-mathematical-functions_002c-use-of"></span>
|
||
<span id="index-functions_002c-math_002c-use-of"></span></p>
|
||
<p>Mathematical functions can be called with the syntax
|
||
‘<code>func``(``args``)</code>’, where the function decides if the <code>args</code> is
|
||
used as a string or a comma-separated list of arithmetic expressions.
|
||
The shell currently defines no mathematical functions by default, but
|
||
the module <code>zsh/mathfunc</code> may be loaded with the <code>zmodload</code> builtin to
|
||
provide standard floating point mathematical functions.</p>
|
||
<p>An expression of the form ‘<code>##``x</code>’ where <code>x</code> is any character sequence
|
||
such as ‘<code>a</code>’, ‘<code>^A</code>’, or ‘<code>\M-\C-x</code>’ gives the value of this character
|
||
and an expression of the form ‘<code>#``name</code>’ gives the value of the first
|
||
character of the contents of the parameter <code>name</code>. Character values are
|
||
according to the character set used in the current locale; for multibyte
|
||
character handling the option <code>MULTIBYTE</code> must be set. Note that this
|
||
form is different from ‘<code>$#``name</code>’, a standard parameter substitution
|
||
which gives the length of the parameter <code>name</code>. ‘<code>#\</code>’ is accepted
|
||
instead of ‘<code>##</code>’, but its use is deprecated.</p>
|
||
<p>Named parameters and subscripted arrays can be referenced by name within
|
||
an arithmetic expression without using the parameter expansion syntax.
|
||
For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">((val2 = val1 * 2))
|
||
</code></pre>
|
||
</div>
|
||
<p>assigns twice the value of <code>$val1</code> to the parameter named <code>val2</code>.</p>
|
||
<p>An internal integer representation of a named parameter can be specified
|
||
with the <code>integer</code> builtin.
|
||
<span id="index-parameters_002c-integer"></span>
|
||
<span id="index-integer-parameters"></span>
|
||
<span id="index-integer_002c-use-of"></span> Arithmetic evaluation is
|
||
performed on the value of each assignment to a named parameter declared
|
||
integer in this manner. Assigning a floating point number to an integer
|
||
results in rounding towards zero.</p>
|
||
<p><span id="index-parameters_002c-floating-point"></span>
|
||
<span id="index-floating-point-parameters"></span>
|
||
<span id="index-float_002c-use-of"></span></p>
|
||
<p>Likewise, floating point numbers can be declared with the <code>float</code>
|
||
builtin; there are two types, differing only in their output format, as
|
||
described for the <code>typeset</code> builtin. The output format can be bypassed
|
||
by using arithmetic substitution instead of the parameter substitution,
|
||
i.e. ‘<code>${``float``}</code>’ uses the defined format, but ‘<code>$((``float``))</code>’
|
||
uses a generic floating point format.</p>
|
||
<p>Promotion of integer to floating point values is performed where
|
||
necessary. In addition, if any operator which requires an integer
|
||
(‘<code>&</code>’, ‘<code>|</code>’, ‘<code>^</code>’, ‘<code><<</code>’, ‘<code>>></code>’ and their equivalents with
|
||
assignment) is given a floating point argument, it will be silently
|
||
rounded towards zero except for ‘<code>~</code>’ which rounds down.</p>
|
||
<p>Users should beware that, in common with many other programming
|
||
languages but not software designed for calculation, the evaluation of
|
||
an expression in zsh is taken a term at a time and promotion of integers
|
||
to floating point does not occur in terms only containing integers. A
|
||
typical result of this is that a division such as <code>6/8</code> is truncated, in
|
||
this being rounded towards 0. The <code>FORCE_FLOAT</code> shell option can be used
|
||
in scripts or functions where floating point evaluation is required
|
||
throughout.</p>
|
||
<p>Scalar variables can hold integer or floating point values at different
|
||
times; there is no memory of the numeric type in this case.</p>
|
||
<p>If a variable is first assigned in a numeric context without previously
|
||
being declared, it will be implicitly typed as <code>integer</code> or <code>float</code> and
|
||
retain that type either until the type is explicitly changed or until
|
||
the end of the scope. This can have unforeseen consequences. For
|
||
example, in the loop</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">for (( f = 0; f < 1; f += 0.1 )); do
|
||
# use $f
|
||
done
|
||
</code></pre>
|
||
</div>
|
||
<p>if <code>f</code> has not already been declared, the first assignment will cause it
|
||
to be created as an integer, and consequently the operation ‘<code>f += 0.1</code>’
|
||
will always cause the result to be truncated to zero, so that the loop
|
||
will fail. A simple fix would be to turn the initialization into ‘<code>f = 0.0</code>’. It is therefore best to declare numeric variables with explicit
|
||
types.</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>
|
||
<!-- 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="Conditional-Expressions.html#12-conditional-expressions">12 Conditional Expressions</a></li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Conditional-Expressions"></span>
|
||
<span id="Conditional-Expressions-1"></span></p>
|
||
<h1 id="12-conditional-expressions"><a class="header" href="#12-conditional-expressions">12 Conditional Expressions</a></h1>
|
||
<p><span id="index-conditional-expressions"></span>
|
||
<span id="index-expressions_002c-conditional"></span></p>
|
||
<p>A <em>conditional expression</em> is used with the <code>[[</code> compound command to
|
||
test attributes of files and to compare strings. Each expression can be
|
||
constructed from one or more of the following unary or binary
|
||
expressions:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-a</code> <code>file</code><br />
|
||
true if <code>file</code> exists.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-b</code> <code>file</code><br />
|
||
true if <code>file</code> exists and is a block special file.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-c</code> <code>file</code><br />
|
||
true if <code>file</code> exists and is a character special file.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-d</code> <code>file</code><br />
|
||
true if <code>file</code> exists and is a directory.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-e</code> <code>file</code><br />
|
||
true if <code>file</code> exists.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-f</code> <code>file</code><br />
|
||
true if <code>file</code> exists and is a regular file.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-g</code> <code>file</code><br />
|
||
true if <code>file</code> exists and has its setgid bit set.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-h</code> <code>file</code><br />
|
||
true if <code>file</code> exists and is a symbolic link.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-k</code> <code>file</code><br />
|
||
true if <code>file</code> exists and has its sticky bit set.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-n</code> <code>string</code><br />
|
||
true if length of <code>string</code> is non-zero.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-o</code> <code>option</code><br />
|
||
true if option named <code>option</code> is on. <code>option</code> may be a single
|
||
character, in which case it is a single letter option name. (See
|
||
<a href="Options.html#Specifying-Options">Specifying Options</a>.)</p>
|
||
<p>When no option named <code>option</code> exists, and the <code>POSIX_BUILTINS</code>
|
||
option hasn’t been set, return 3 with a warning. If that option is
|
||
set, return 1 with no warning.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-p</code> <code>file</code><br />
|
||
true if <code>file</code> exists and is a FIFO special file (named pipe).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-r</code> <code>file</code><br />
|
||
true if <code>file</code> exists and is readable by current process.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-s</code> <code>file</code><br />
|
||
true if <code>file</code> exists and has size greater than zero.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-t</code> <code>fd</code><br />
|
||
true if file descriptor number <code>fd</code> is open and associated with a
|
||
terminal device. (note: <code>fd</code> is not optional)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-u</code> <code>file</code><br />
|
||
true if <code>file</code> exists and has its setuid bit set.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-v</code> <code>varname</code><br />
|
||
true if shell variable <code>varname</code> is set.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-w</code> <code>file</code><br />
|
||
<code>-x</code> <code>file</code><br />
|
||
<code>-z</code> <code>string</code><br />
|
||
true if length of <code>string</code> is zero.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-L</code> <code>file</code><br />
|
||
true if <code>file</code> exists and is a symbolic link.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-O</code> <code>file</code><br />
|
||
true if <code>file</code> exists and is owned by the effective user ID of this
|
||
process.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-G</code> <code>file</code><br />
|
||
true if <code>file</code> exists and its group matches the effective group ID
|
||
of this process.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-S</code> <code>file</code><br />
|
||
true if <code>file</code> exists and is a socket.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-N</code> <code>file</code><br />
|
||
true if <code>file</code> exists and its access time is not newer than its
|
||
modification time.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>file1</code> <code>-nt</code> <code>file2</code><br />
|
||
true if <code>file1</code> exists and is newer than <code>file2</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>file1</code> <code>-ot</code> <code>file2</code><br />
|
||
true if <code>file1</code> exists and is older than <code>file2</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>file1</code> <code>-ef</code> <code>file2</code><br />
|
||
true if <code>file1</code> and <code>file2</code> exist and refer to the same file.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>string</code> <code>=</code> <code>pattern</code><br />
|
||
<code>string</code> <code>==</code> <code>pattern</code><br />
|
||
true if <code>string</code> matches <code>pattern</code>. The two forms are exactly
|
||
equivalent. The ‘<code>=</code>’ form is the traditional shell syntax (and
|
||
hence the only one generally used with the <code>test</code> and <code>[</code> builtins);
|
||
the ‘<code>==</code>’ form provides compatibility with other sorts of computer
|
||
language.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>string</code> <code>!=</code> <code>pattern</code><br />
|
||
true if <code>string</code> does not match <code>pattern</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>string</code> <code>=~</code> <code>regexp</code><br />
|
||
true if <code>string</code> matches the regular expression <code>regexp</code>. If the
|
||
option <code>RE_MATCH_PCRE</code> is set <code>regexp</code> is tested as a PCRE regular
|
||
expression using the <code>zsh/pcre</code> module, else it is tested as a POSIX
|
||
extended regular expression using the <code>zsh/regex</code> module. Upon
|
||
successful match, some variables will be updated; no variables are
|
||
changed if the matching fails.</p>
|
||
<p>If the option <code>BASH_REMATCH</code> is not set the scalar parameter <code>MATCH</code>
|
||
is set to the substring that matched the pattern and the integer
|
||
parameters <code>MBEGIN</code> and <code>MEND</code> to the index of the start and end,
|
||
respectively, of the match in <code>string</code>, such that if <code>string</code> is
|
||
contained in variable <code>var</code> the expression ‘<code>${var[$MBEGIN,$MEND]}</code>’
|
||
is identical to ‘<code>$MATCH</code>’. The setting of the option <code>KSH_ARRAYS</code>
|
||
is respected. Likewise, the array <code>match</code> is set to the substrings
|
||
that matched parenthesised subexpressions and the arrays <code>mbegin</code>
|
||
and <code>mend</code> to the indices of the start and end positions,
|
||
respectively, of the substrings within <code>string</code>. The arrays are not
|
||
set if there were no parenthesised subexpressions. For example, if
|
||
the string ‘<code>a short string</code>’ is matched against the regular
|
||
expression ‘<code>s(...)t</code>’, then (assuming the option <code>KSH_ARRAYS</code> is
|
||
not set) <code>MATCH</code>, <code>MBEGIN</code> and <code>MEND</code> are ‘<code>short</code>’, <code>3</code> and <code>7</code>,
|
||
respectively, while <code>match</code>, <code>mbegin</code> and <code>mend</code> are single entry
|
||
arrays containing the strings ‘<code>hor</code>’, ‘<code>4</code>’ and ‘<code>6</code>’,
|
||
respectively.</p>
|
||
<p>If the option <code>BASH_REMATCH</code> is set the array <code>BASH_REMATCH</code> is set
|
||
to the substring that matched the pattern followed by the substrings
|
||
that matched parenthesised subexpressions within the pattern.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>string1</code> <code><</code> <code>string2</code><br />
|
||
true if <code>string1</code> comes before <code>string2</code> based on ASCII value of
|
||
their characters.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>string1</code> <code>></code> <code>string2</code><br />
|
||
true if <code>string1</code> comes after <code>string2</code> based on ASCII value of
|
||
their characters.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>exp1</code> <code>-eq</code> <code>exp2</code><br />
|
||
true if <code>exp1</code> is numerically equal to <code>exp2</code>. Note that for purely
|
||
numeric comparisons use of the <code>((``...``))</code> builtin described in
|
||
<a href="Arithmetic-Evaluation.html#Arithmetic-Evaluation">Arithmetic
|
||
Evaluation</a> is
|
||
more convenient than conditional expressions.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>exp1</code> <code>-ne</code> <code>exp2</code><br />
|
||
true if <code>exp1</code> is numerically not equal to <code>exp2</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>exp1</code> <code>-lt</code> <code>exp2</code><br />
|
||
true if <code>exp1</code> is numerically less than <code>exp2</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>exp1</code> <code>-gt</code> <code>exp2</code><br />
|
||
true if <code>exp1</code> is numerically greater than <code>exp2</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>exp1</code> <code>-le</code> <code>exp2</code><br />
|
||
true if <code>exp1</code> is numerically less than or equal to <code>exp2</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>exp1</code> <code>-ge</code> <code>exp2</code><br />
|
||
true if <code>exp1</code> is numerically greater than or equal to <code>exp2</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>(</code> <code>exp</code> <code>)</code><br />
|
||
true if <code>exp</code> is true.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>!</code> <code>exp</code><br />
|
||
true if <code>exp</code> is false.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>exp1</code> <code>&&</code> <code>exp2</code><br />
|
||
true if <code>exp1</code> and <code>exp2</code> are both true.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>exp1</code> <code>||</code> <code>exp2</code><br />
|
||
true if either <code>exp1</code> or <code>exp2</code> is true.</p>
|
||
</li>
|
||
</ul>
|
||
<p>For compatibility, if there is a single argument that is not
|
||
syntactically significant, typically a variable, the condition is
|
||
treated as a test for whether the expression expands as a string of
|
||
non-zero length. In other words, <code>[[ $var ]]</code> is the same as <code>[[ -n $var ]]</code>. It is recommended that the second, explicit, form be used where
|
||
possible.</p>
|
||
<p>Normal shell expansion is performed on the <code>file</code>, <code>string</code> and
|
||
<code>pattern</code> arguments, but the result of each expansion is constrained to
|
||
be a single word, similar to the effect of double quotes.</p>
|
||
<p>Filename generation is not performed on any form of argument to
|
||
conditions. However, it can be forced in any case where normal shell
|
||
expansion is valid and when the option <code>EXTENDED_GLOB</code> is in effect by
|
||
using an explicit glob qualifier of the form <code>(#q)</code> at the end of the
|
||
string. A normal glob qualifier expression may appear between the ‘<code>q</code>’
|
||
and the closing parenthesis; if none appears the expression has no
|
||
effect beyond causing filename generation. The results of filename
|
||
generation are joined together to form a single word, as with the
|
||
results of other forms of expansion.</p>
|
||
<p>This special use of filename generation is only available with the <code>[[</code>
|
||
syntax. If the condition occurs within the <code>[</code> or <code>test</code> builtin
|
||
commands then globbing occurs instead as part of normal command line
|
||
expansion before the condition is evaluated. In this case it may
|
||
generate multiple words which are likely to confuse the syntax of the
|
||
test command.</p>
|
||
<p>For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">[[ -n file*(#qN) ]]
|
||
</code></pre>
|
||
</div>
|
||
<p>produces status zero if and only if there is at least one file in the
|
||
current directory beginning with the string ‘<code>file</code>’. The globbing
|
||
qualifier <code>N</code> ensures that the expression is empty if there is no
|
||
matching file.</p>
|
||
<p>Pattern metacharacters are active for the <code>pattern</code> arguments; the
|
||
patterns are the same as those used for filename generation, see
|
||
<a href="Expansion.html#Filename-Generation">Filename Generation</a>, but there is
|
||
no special behaviour of ‘<code>/</code>’ nor initial dots, and no glob qualifiers
|
||
are allowed.</p>
|
||
<p>In each of the above expressions, if <code>file</code> is of the form
|
||
‘<code>/dev/fd/``n</code>’, where <code>n</code> is an integer, then the test applied to the
|
||
open file whose descriptor number is <code>n</code>, even if the underlying system
|
||
does not support the <code>/dev/fd</code> directory.</p>
|
||
<p>In the forms which do numeric comparison, the expressions <code>exp</code> undergo
|
||
arithmetic expansion as if they were enclosed in <code>$((``...``))</code>.</p>
|
||
<p>For example, the following:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">[[ ( -f foo || -f bar ) && $report = y* ]] && print File exists.
|
||
</code></pre>
|
||
</div>
|
||
<p>tests if either file <code>foo</code> or file <code>bar</code> exists, and if so, if the value
|
||
of the parameter <code>report</code> begins with ‘<code>y</code>’; if the complete condition
|
||
is true, the message ‘<code>File exists.</code>’ is printed.</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>
|
||
<!-- 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="Prompt-Expansion.html#13-prompt-expansion">13 Prompt Expansion</a>
|
||
<ul>
|
||
<li><a href="Prompt-Expansion.html#131-expansion-of-prompt-sequences">13.1 Expansion of Prompt Sequences</a></li>
|
||
<li><a href="Prompt-Expansion.html#132-simple-prompt-escapes">13.2 Simple Prompt Escapes</a>
|
||
<ul>
|
||
<li><a href="Prompt-Expansion.html#1321-special-characters">13.2.1 Special characters</a></li>
|
||
<li><a href="Prompt-Expansion.html#1322-login-information">13.2.2 Login information</a></li>
|
||
<li><a href="Prompt-Expansion.html#1323-shell-state">13.2.3 Shell state</a></li>
|
||
<li><a href="Prompt-Expansion.html#1324-date-and-time">13.2.4 Date and time</a></li>
|
||
<li><a href="Prompt-Expansion.html#1325-visual-effects">13.2.5 Visual effects</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Prompt-Expansion.html#133-conditional-substrings-in-prompts">13.3 Conditional Substrings in Prompts</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Prompt-Expansion"></span>
|
||
<span id="Prompt-Expansion-1"></span></p>
|
||
<h1 id="13-prompt-expansion"><a class="header" href="#13-prompt-expansion">13 Prompt Expansion</a></h1>
|
||
<hr />
|
||
<p><span id="Expansion-of-Prompt-Sequences"></span></p>
|
||
<h2 id="131-expansion-of-prompt-sequences"><a class="header" href="#131-expansion-of-prompt-sequences">13.1 Expansion of Prompt Sequences</a></h2>
|
||
<p><span id="index-prompt-expansion"></span>
|
||
<span id="index-expansion_002c-prompt"></span></p>
|
||
<p>Prompt sequences undergo a special form of expansion. This type of
|
||
expansion is also available using the <code>-P</code> option to the <code>print</code>
|
||
builtin.</p>
|
||
<p><span id="index-PROMPT_005fSUBST_002c-use-of"></span></p>
|
||
<p>If the <code>PROMPT_SUBST</code> option is set, the prompt string is first
|
||
subjected to <em>parameter expansion</em>, <em>command substitution</em> and
|
||
<em>arithmetic expansion</em>. See <a href="Expansion.html#Expansion">Expansion</a>.</p>
|
||
<p>Certain escape sequences may be recognised in the prompt string.</p>
|
||
<p><span id="index-PROMPT_005fBANG_002c-use-of"></span></p>
|
||
<p>If the <code>PROMPT_BANG</code> option is set, a ‘<code>!</code>’ in the prompt is replaced by
|
||
the current history event number. A literal ‘<code>!</code>’ may then be
|
||
represented as ‘<code>!!</code>’.</p>
|
||
<p><span id="index-PROMPT_005fPERCENT_002c-use-of"></span></p>
|
||
<p>If the <code>PROMPT_PERCENT</code> option is set, certain escape sequences that
|
||
start with ‘<code>%</code>’ are expanded. Many escapes are followed by a single
|
||
character, although some of these take an optional integer argument that
|
||
should appear between the ‘<code>%</code>’ and the next character of the sequence.
|
||
More complicated escape sequences are available to provide conditional
|
||
expansion.</p>
|
||
<hr />
|
||
<p><span id="Simple-Prompt-Escapes"></span></p>
|
||
<h2 id="132-simple-prompt-escapes"><a class="header" href="#132-simple-prompt-escapes">13.2 Simple Prompt Escapes</a></h2>
|
||
<hr />
|
||
<p><span id="Special-characters"></span></p>
|
||
<h3 id="1321-special-characters"><a class="header" href="#1321-special-characters">13.2.1 Special characters</a></h3>
|
||
<ul>
|
||
<li>
|
||
<p><code>%%</code><br />
|
||
A ‘<code>%</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%)</code><br />
|
||
A ‘<code>)</code>’.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Login-information"></span></p>
|
||
<h3 id="1322-login-information"><a class="header" href="#1322-login-information">13.2.2 Login information</a></h3>
|
||
<ul>
|
||
<li>
|
||
<p><code>%l</code><br />
|
||
The line (tty) the user is logged in on, without ‘<code>/dev/</code>’ prefix.
|
||
If the name starts with ‘<code>/dev/tty</code>’, that prefix is stripped.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%M</code><br />
|
||
The full machine hostname.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%m</code><br />
|
||
The hostname up to the first ‘<code>.</code>’. An integer may follow the ‘<code>%</code>’
|
||
to specify how many components of the hostname are desired. With a
|
||
negative integer, trailing components of the hostname are shown.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%n</code><br />
|
||
<code>$USERNAME</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%y</code><br />
|
||
The line (tty) the user is logged in on, without ‘<code>/dev/</code>’ prefix.
|
||
This does not treat ‘<code>/dev/tty</code>’ names specially.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Shell-state"></span></p>
|
||
<h3 id="1323-shell-state"><a class="header" href="#1323-shell-state">13.2.3 Shell state</a></h3>
|
||
<ul>
|
||
<li>
|
||
<p><code>%#</code><br />
|
||
A ‘<code>#</code>’ if the shell is running with privileges, a ‘<code>%</code>’ if not.
|
||
Equivalent to ‘<code>%(!.#.%%)</code>’. The definition of ‘privileged’, for
|
||
these purposes, is that either the effective user ID is zero, or, if
|
||
POSIX.1e capabilities are supported, that capability vectors.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%?</code><br />
|
||
The return status of the last command executed just before the
|
||
prompt.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%_</code><br />
|
||
The status of the parser, i.e. the shell constructs (like ‘<code>if</code>’ and
|
||
‘<code>for</code>’) that have been started on the command line. If given an
|
||
integer number that many strings will be printed; zero or negative
|
||
or no integer means print as many as there are. This is most useful
|
||
in prompts <code>PS2</code> for continuation lines and <code>PS4</code> for debugging with
|
||
the <code>XTRACE</code> option; in the latter case it will also work
|
||
non-interactively.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%^</code><br />
|
||
The status of the parser in reverse. This is the same as ‘<code>%_</code>’
|
||
other than the order of strings. It is often used in <code>RPS2</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%d</code><br />
|
||
<code>%/</code><br />
|
||
Current working directory. If an integer follows the ‘<code>%</code>’, it
|
||
specifies a number of trailing components of the current working
|
||
directory to show; zero means the whole path. A negative integer
|
||
specifies leading components, i.e. <code>%-1d</code> specifies the first
|
||
component.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%~</code><br />
|
||
As <code>%d</code> and <code>%/</code>, but if the current working directory starts with
|
||
<code>$HOME</code>, that part is replaced by a ‘<code>~</code>’. Furthermore, if it has a
|
||
named directory as its prefix, that part is replaced by a ‘<code>~</code>’
|
||
followed by the name of the directory, but only if the result is
|
||
shorter than the full path; <a href="Expansion.html#Filename-Expansion">Filename
|
||
Expansion</a>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%e</code><br />
|
||
Evaluation depth of the current sourced file, shell function, or
|
||
<code>eval</code>. This is incremented or decremented every time the value of
|
||
<code>%N</code> is set or reverted to a previous value, respectively. This is
|
||
most useful for debugging as part of <code>$PS4</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%h</code><br />
|
||
<code>%!</code><br />
|
||
Current history event number.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%i</code><br />
|
||
The line number currently being executed in the script, sourced
|
||
file, or shell function given by <code>%N</code>. This is most useful for
|
||
debugging as part of <code>$PS4</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%I</code><br />
|
||
The line number currently being executed in the file <code>%x</code>. This is
|
||
similar to <code>%i</code>, but the line number is always a line number in the
|
||
file where the code was defined, even if the code is a shell
|
||
function.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%j</code><br />
|
||
The number of jobs.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%L</code><br />
|
||
The current value of <code>$SHLVL</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%N</code><br />
|
||
The name of the script, sourced file, or shell function that zsh is
|
||
currently executing, whichever was started most recently. If there
|
||
is none, this is equivalent to the parameter <code>$0</code>. An integer may
|
||
follow the ‘<code>%</code>’ to specify a number of trailing path components to
|
||
show; zero means the full path. A negative integer specifies leading
|
||
components.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%x</code><br />
|
||
The name of the file containing the source code currently being
|
||
executed. This behaves as <code>%N</code> except that function and eval command
|
||
names are not shown, instead the file where they were defined.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%c</code><br />
|
||
<code>%.</code><br />
|
||
<code>%C</code><br />
|
||
Trailing component of the current working directory. An integer may
|
||
follow the ‘<code>%</code>’ to get more than one component. Unless ‘<code>%C</code>’ is
|
||
used, tilde contraction is performed first. These are deprecated as
|
||
<code>%c</code> and <code>%C</code> are equivalent to <code>%1~</code> and <code>%1/</code>, respectively, while
|
||
explicit positive integers have the same effect as for the latter
|
||
two sequences.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Date-and-time"></span></p>
|
||
<h3 id="1324-date-and-time"><a class="header" href="#1324-date-and-time">13.2.4 Date and time</a></h3>
|
||
<ul>
|
||
<li>
|
||
<p><code>%D</code><br />
|
||
The date in <code>yy``-``mm``-``dd</code> format.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%T</code><br />
|
||
Current time of day, in 24-hour format.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%t</code><br />
|
||
<code>%@</code><br />
|
||
Current time of day, in 12-hour, am/pm format.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%*</code><br />
|
||
Current time of day in 24-hour format, with seconds.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%w</code><br />
|
||
The date in <code>day``-``dd</code> format.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%W</code><br />
|
||
The date in <code>mm``/``dd``/``yy</code> format.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%D{``string``}</code><br />
|
||
<code>string</code> is formatted using the <code>strftime</code> function. See man page
|
||
strftime(3) for more details. Various zsh extensions provide numbers
|
||
with no leading zero or space if the number is a single digit:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>%f</code><br />
|
||
a day of the month</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%K</code><br />
|
||
the hour of the day on the 24-hour clock</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%L</code><br />
|
||
the hour of the day on the 12-hour clock</p>
|
||
</li>
|
||
</ul>
|
||
<p>In addition, if the system supports the POSIX <code>gettimeofday</code> system
|
||
call, <code>%.</code> provides decimal fractions of a second since the epoch
|
||
with leading zeroes. By default three decimal places are provided,
|
||
but a number of digits up to 9 may be given following the <code>%</code>; hence
|
||
<code>%6.</code> outputs microseconds, and <code>%9.</code> outputs nanoseconds. (The
|
||
latter requires a nanosecond-precision <code>clock_gettime</code>; systems
|
||
lacking this will return a value multiplied by the appropriate power
|
||
of 10.) A typical example of this is the format ‘<code>%D{%H:%M:%S.%.}</code>’.</p>
|
||
<p>The GNU extension <code>%N</code> is handled as a synonym for <code>%9.</code>.</p>
|
||
<p>Additionally, the GNU extension that a ‘<code>-</code>’ between the <code>%</code> and the
|
||
format character causes a leading zero or space to be stripped is
|
||
handled directly by the shell for the format characters <code>d</code>, <code>f</code>,
|
||
<code>H</code>, <code>k</code>, <code>l</code>, <code>m</code>, <code>M</code>, <code>S</code> and <code>y</code>; any other format characters
|
||
are provided to the system’s strftime(3) with any leading ‘<code>-</code>’
|
||
present, so the handling is system dependent. Further GNU (or other)
|
||
extensions are also passed to strftime(3) and may work if the system
|
||
supports them.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Visual-effects"></span></p>
|
||
<h3 id="1325-visual-effects"><a class="header" href="#1325-visual-effects">13.2.5 Visual effects</a></h3>
|
||
<ul>
|
||
<li>
|
||
<p><code>%B</code> (<code>%b</code>)<br />
|
||
Start (stop) boldface mode.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%E</code><br />
|
||
Clear to end of line.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%U</code> (<code>%u</code>)<br />
|
||
Start (stop) underline mode.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%S</code> (<code>%s</code>)<br />
|
||
Start (stop) standout mode.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%F</code> (<code>%f</code>)<br />
|
||
Start (stop) using a different foreground colour, if supported by
|
||
the terminal. The colour may be specified two ways: either as a
|
||
numeric argument, as normal, or by a sequence in braces following
|
||
the <code>%F</code>, for example <code>%F{red}</code>. In the latter case the values
|
||
allowed are as described for the <code>fg</code> <code>zle_highlight</code> attribute;
|
||
<a href="Zsh-Line-Editor.html#Character-Highlighting">Character
|
||
Highlighting</a>. This
|
||
means that numeric colours are allowed in the second format also.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%K</code> (<code>%k</code>)<br />
|
||
Start (stop) using a different bacKground colour. The syntax is
|
||
identical to that for <code>%F</code> and <code>%f</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%{</code>...<code>%}</code><br />
|
||
Include a string as a literal escape sequence. The string within the
|
||
braces should not change the cursor position. Brace pairs can nest.</p>
|
||
<p>A positive numeric argument between the <code>%</code> and the <code>{</code> is treated
|
||
as described for <code>%G</code> below.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%G</code><br />
|
||
Within a <code>%{</code>...<code>%}</code> sequence, include a ‘glitch’: that is, assume
|
||
that a single character width will be output. This is useful when
|
||
outputting characters that otherwise cannot be correctly handled by
|
||
the shell, such as the alternate character set on some terminals.
|
||
The characters in question can be included within a <code>%{</code>...<code>%}</code>
|
||
sequence together with the appropriate number of <code>%G</code> sequences to
|
||
indicate the correct width. An integer between the ‘<code>%</code>’ and ‘<code>G</code>’
|
||
indicates a character width other than one. Hence <code>%{``seq``%2G%}</code>
|
||
outputs <code>seq</code> and assumes it takes up the width of two standard
|
||
characters.</p>
|
||
<p>Multiple uses of <code>%G</code> accumulate in the obvious fashion; the
|
||
position of the <code>%G</code> is unimportant. Negative integers are not
|
||
handled.</p>
|
||
<p>Note that when prompt truncation is in use it is advisable to divide
|
||
up output into single characters within each <code>%{</code>...<code>%}</code> group so
|
||
that the correct truncation point can be found.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Conditional-Substrings-in-Prompts"></span></p>
|
||
<h2 id="133-conditional-substrings-in-prompts"><a class="header" href="#133-conditional-substrings-in-prompts">13.3 Conditional Substrings in Prompts</a></h2>
|
||
<ul>
|
||
<li>
|
||
<p><code>%v</code><br />
|
||
<span id="index-psvar_002c-use-of"></span></p>
|
||
<p>The value of the first element of the <code>psvar</code> array parameter.
|
||
Following the ‘<code>%</code>’ with an integer gives that element of the array.
|
||
Negative integers count from the end of the array.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%(``x``.``true-text``.``false-text``)</code><br />
|
||
Specifies a ternary expression. The character following the <code>x</code> is
|
||
arbitrary; the same character is used to separate the text for the
|
||
‘true’ result from that for the ‘false’ result. This separator may
|
||
not appear in the <code>true-text</code>, except as part of a %-escape
|
||
sequence. A ‘<code>)</code>’ may appear in the <code>false-text</code> as ‘<code>%)</code>’.
|
||
<code>true-text</code> and <code>false-text</code> may both contain arbitrarily-nested
|
||
escape sequences, including further ternary expressions.</p>
|
||
<p>The left parenthesis may be preceded or followed by a positive
|
||
integer <code>n</code>, which defaults to zero. A negative integer will be
|
||
multiplied by -1, except as noted below for ‘<code>l</code>’. The test
|
||
character <code>x</code> may be any of the following:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>!</code><br />
|
||
True if the shell is running with privileges.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>#</code><br />
|
||
True if the effective uid of the current process is <code>n</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>?</code><br />
|
||
True if the exit status of the last command was <code>n</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>_</code><br />
|
||
True if at least <code>n</code> shell constructs were started.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>C</code><br />
|
||
<code>/</code><br />
|
||
True if the current absolute path has at least <code>n</code> elements
|
||
relative to the root directory, hence <code>/</code> is counted as 0
|
||
elements.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>c</code><br />
|
||
<code>.</code><br />
|
||
<code>~</code><br />
|
||
True if the current path, with prefix replacement, has at least
|
||
<code>n</code> elements relative to the root directory, hence <code>/</code> is
|
||
counted as 0 elements.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>D</code><br />
|
||
True if the month is equal to <code>n</code> (January = 0).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>d</code><br />
|
||
True if the day of the month is equal to <code>n</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>e</code><br />
|
||
True if the evaluation depth is at least <code>n</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>g</code><br />
|
||
True if the effective gid of the current process is <code>n</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>j</code><br />
|
||
True if the number of jobs is at least <code>n</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>L</code><br />
|
||
True if the <code>SHLVL</code> parameter is at least <code>n</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>l</code><br />
|
||
True if at least <code>n</code> characters have already been printed on the
|
||
current line. When <code>n</code> is negative, true if at least
|
||
<code>abs``(``n``)</code> characters remain before the opposite margin
|
||
(thus the left margin for <code>RPROMPT</code>).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>S</code><br />
|
||
True if the <code>SECONDS</code> parameter is at least <code>n</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>T</code><br />
|
||
True if the time in hours is equal to <code>n</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>t</code><br />
|
||
True if the time in minutes is equal to <code>n</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>v</code><br />
|
||
True if the array <code>psvar</code> has at least <code>n</code> elements.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>V</code><br />
|
||
True if element <code>n</code> of the array <code>psvar</code> is set and non-empty.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>w</code><br />
|
||
True if the day of the week is equal to <code>n</code> (Sunday = 0).</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p><code>%<``string``<</code><br />
|
||
<code>%>``string``></code><br />
|
||
<code>%[``xstring``]</code><br />
|
||
Specifies truncation behaviour for the remainder of the prompt
|
||
string. The third, deprecated, form is equivalent to
|
||
‘<code>%``xstringx</code>’, i.e. <code>x</code> may be ‘<code><</code>’ or ‘<code>></code>’. The <code>string</code>
|
||
will be displayed in place of the truncated portion of any string;
|
||
note this does not undergo prompt expansion.</p>
|
||
<p>The numeric argument, which in the third form may appear immediately
|
||
after the ‘<code>[</code>’, specifies the maximum permitted length of the
|
||
various strings that can be displayed in the prompt. In the first
|
||
two forms, this numeric argument may be negative, in which case the
|
||
truncation length is determined by subtracting the absolute value of
|
||
the numeric argument from the number of character positions
|
||
remaining on the current prompt line. If this results in a zero or
|
||
negative length, a length of 1 is used. In other words, a negative
|
||
argument arranges that after truncation at least <code>n</code> characters
|
||
remain before the right margin (left margin for <code>RPROMPT</code>).</p>
|
||
<p>The forms with ‘<code><</code>’ truncate at the left of the string, and the
|
||
forms with ‘<code>></code>’ truncate at the right of the string. For example,
|
||
if the current directory is ‘<code>/home/pike</code>’, the prompt ‘<code>%8<..<%/</code>’
|
||
will expand to ‘<code>..e/pike</code>’. In this string, the terminating
|
||
character (‘<code><</code>’, ‘<code>></code>’ or ‘<code>]</code>’), or in fact any character, may be
|
||
quoted by a preceding ‘<code>\</code>’; note when using <code>print -P</code>, however,
|
||
that this must be doubled as the string is also subject to standard
|
||
<code>print</code> processing, in addition to any backslashes removed by a
|
||
double quoted string: the worst case is therefore ‘<code>print -P "%<\\<<..."</code>’.</p>
|
||
<p>If the <code>string</code> is longer than the specified truncation length, it
|
||
will appear in full, completely replacing the truncated string.</p>
|
||
<p>The part of the prompt string to be truncated runs to the end of the
|
||
string, or to the end of the next enclosing group of the ‘<code>%(</code>’
|
||
construct, or to the next truncation encountered at the same
|
||
grouping level (i.e. truncations inside a ‘<code>%(</code>’ are separate),
|
||
which ever comes first. In particular, a truncation with argument
|
||
zero (e.g., ‘<code>%<<</code>’) marks the end of the range of the string to be
|
||
truncated while turning off truncation from there on. For example,
|
||
the prompt ‘<code>%10<...<%~%<<%# </code>’ will print a truncated
|
||
representation of the current directory, followed by a ‘<code>%</code>’ or
|
||
‘<code>#</code>’, followed by a space. Without the ‘<code>%<<</code>’, those two
|
||
characters would be included in the string to be truncated. Note
|
||
that ‘<code>%-0<<</code>’ is not equivalent to ‘<code>%<<</code>’ but specifies that the
|
||
prompt is truncated at the right margin.</p>
|
||
<p>Truncation applies only within each individual line of the prompt,
|
||
as delimited by embedded newlines (if any). If the total length of
|
||
any line of the prompt after truncation is greater than the terminal
|
||
width, or if the part to be truncated contains embedded newlines,
|
||
truncation behavior is undefined and may change in a future version
|
||
of the shell. Use ‘<code>%-``n``(l.``true-text``.``false-text``)</code>’ to
|
||
remove parts of the prompt when the available space is less than
|
||
<code>n</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<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>
|
||
<!-- 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="Expansion.html#14-expansion">14 Expansion</a>
|
||
<ul>
|
||
<li><a href="Expansion.html#141-history-expansion">14.1 History Expansion</a>
|
||
<ul>
|
||
<li><a href="Expansion.html#1411-overview">14.1.1 Overview</a></li>
|
||
<li><a href="Expansion.html#1412-event-designators">14.1.2 Event Designators</a></li>
|
||
<li><a href="Expansion.html#1413-word-designators">14.1.3 Word Designators</a></li>
|
||
<li><a href="Expansion.html#1414-modifiers">14.1.4 Modifiers</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Expansion.html#142-process-substitution">14.2 Process Substitution</a></li>
|
||
<li><a href="Expansion.html#143-parameter-expansion">14.3 Parameter Expansion</a>
|
||
<ul>
|
||
<li><a href="Expansion.html#1431-parameter-expansion-flags">14.3.1 Parameter Expansion Flags</a></li>
|
||
<li><a href="Expansion.html#1432-rules">14.3.2 Rules</a></li>
|
||
<li><a href="Expansion.html#1433-examples">14.3.3 Examples</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Expansion.html#144-command-substitution">14.4 Command Substitution</a></li>
|
||
<li><a href="Expansion.html#145-arithmetic-expansion">14.5 Arithmetic Expansion</a></li>
|
||
<li><a href="Expansion.html#146-brace-expansion">14.6 Brace Expansion</a></li>
|
||
<li><a href="Expansion.html#147-filename-expansion">14.7 Filename Expansion</a>
|
||
<ul>
|
||
<li><a href="Expansion.html#1471-dynamic-named-directories">14.7.1 Dynamic named directories</a></li>
|
||
<li><a href="Expansion.html#1472-static-named-directories">14.7.2 Static named directories</a></li>
|
||
<li><a href="Expansion.html#1473--expansion">14.7.3 ‘=’ expansion</a></li>
|
||
<li><a href="Expansion.html#1474-notes">14.7.4 Notes</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Expansion.html#148-filename-generation">14.8 Filename Generation</a>
|
||
<ul>
|
||
<li><a href="Expansion.html#1481-glob-operators">14.8.1 Glob Operators</a></li>
|
||
<li><a href="Expansion.html#1482-ksh-like-glob-operators">14.8.2 ksh-like Glob Operators</a></li>
|
||
<li><a href="Expansion.html#1483-precedence">14.8.3 Precedence</a></li>
|
||
<li><a href="Expansion.html#1484-globbing-flags">14.8.4 Globbing Flags</a></li>
|
||
<li><a href="Expansion.html#1485-approximate-matching">14.8.5 Approximate Matching</a></li>
|
||
<li><a href="Expansion.html#1486-recursive-globbing">14.8.6 Recursive Globbing</a></li>
|
||
<li><a href="Expansion.html#1487-glob-qualifiers">14.8.7 Glob Qualifiers</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Expansion"></span> <span id="Expansion-1"></span></p>
|
||
<h1 id="14-expansion"><a class="header" href="#14-expansion">14 Expansion</a></h1>
|
||
<p><span id="index-expansion"></span></p>
|
||
<p>The following types of expansions are performed in the indicated order
|
||
in five steps:</p>
|
||
<ul>
|
||
<li>
|
||
<p><em>History Expansion</em><br />
|
||
This is performed only in interactive shells.</p>
|
||
</li>
|
||
<li>
|
||
<p><em>Alias Expansion</em><br />
|
||
Aliases are expanded immediately before the command line is parsed
|
||
as explained in <a href="Shell-Grammar.html#Aliasing">Aliasing</a>.</p>
|
||
</li>
|
||
<li>
|
||
<p><em>Process Substitution</em><br />
|
||
<em>Parameter Expansion</em><br />
|
||
<em>Command Substitution</em><br />
|
||
<em>Arithmetic Expansion</em><br />
|
||
<em>Brace Expansion</em><br />
|
||
These five are performed in left-to-right fashion. On each argument,
|
||
any of the five steps that are needed are performed one after the
|
||
other. Hence, for example, all the parts of parameter expansion are
|
||
completed before command substitution is started. After these
|
||
expansions, all unquoted occurrences of the characters ‘<code>\</code>’,‘<code>’</code>’
|
||
and ‘<code>"</code>’ are removed.</p>
|
||
</li>
|
||
<li>
|
||
<p><em>Filename Expansion</em><br />
|
||
If the <code>SH_FILE_EXPANSION</code> option is set, the order of expansion is
|
||
modified for compatibility with sh and ksh. In that case <em>filename
|
||
expansion</em> is performed immediately after <em>alias expansion</em>,
|
||
preceding the set of five expansions mentioned above.</p>
|
||
<p><span id="index-globbing"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><em>Filename Generation</em><br />
|
||
This expansion, commonly referred to as globbing, is always done
|
||
last.</p>
|
||
</li>
|
||
</ul>
|
||
<p>The following sections explain the types of expansion in detail.</p>
|
||
<hr />
|
||
<p><span id="History-Expansion"></span>
|
||
<span id="History-Expansion-1"></span></p>
|
||
<h2 id="141-history-expansion"><a class="header" href="#141-history-expansion">14.1 History Expansion</a></h2>
|
||
<p><span id="index-history"></span>
|
||
<span id="index-history-expansion"></span>
|
||
<span id="index-expansion_002c-history"></span></p>
|
||
<p>History expansion allows you to use words from previous command lines in
|
||
the command line you are typing. This simplifies spelling corrections
|
||
and the repetition of complicated commands or arguments.</p>
|
||
<p><span id="index-HISTSIZE_002c-use-of"></span></p>
|
||
<p>Immediately before execution, each command is saved in the history list,
|
||
the size of which is controlled by the <code>HISTSIZE</code> parameter. The one
|
||
most recent command is always retained in any case. Each saved command
|
||
in the history list is called a history <em>event</em> and is assigned a
|
||
number, beginning with 1 (one) when the shell starts up. The history
|
||
number that you may see in your prompt (see <a href="Prompt-Expansion.html#Prompt-Expansion">Prompt
|
||
Expansion</a>) is the number that
|
||
is to be assigned to the <em>next</em> command.</p>
|
||
<hr />
|
||
<p><span id="Overview"></span> <span id="Overview-2"></span></p>
|
||
<h3 id="1411-overview"><a class="header" href="#1411-overview">14.1.1 Overview</a></h3>
|
||
<p><span id="index-histchars_002c-use-of-1"></span></p>
|
||
<p>A history expansion begins with the first character of the <code>histchars</code>
|
||
parameter, which is ‘<code>!</code>’ by default, and may occur anywhere on the
|
||
command line, including inside double quotes (but not inside single
|
||
quotes <code>’...’</code> or C-style quotes <code>$’...’</code> nor when escaped with a
|
||
backslash).</p>
|
||
<p>The first character is followed by an optional event designator (<a href="Expansion.html#Event-Designators">Event
|
||
Designators</a>) and then an optional word designator
|
||
(<a href="Expansion.html#Word-Designators">Word Designators</a>); if neither of these designators
|
||
is present, no history expansion occurs.</p>
|
||
<p>Input lines containing history expansions are echoed after being
|
||
expanded, but before any other expansions take place and before the
|
||
command is executed. It is this expanded form that is recorded as the
|
||
history event for later references.</p>
|
||
<p>History expansions do not nest.</p>
|
||
<p>By default, a history reference with no event designator refers to the
|
||
same event as any preceding history reference on that command line; if
|
||
it is the only history reference in a command, it refers to the previous
|
||
command. <span id="index-CSH_005fJUNKIE_005fHISTORY_002c-use-of"></span>
|
||
However, if the option <code>CSH_JUNKIE_HISTORY</code> is set, then every history
|
||
reference with no event specification <em>always</em> refers to the previous
|
||
command.</p>
|
||
<p>For example, ‘<code>!</code>’ is the event designator for the previous command, so
|
||
‘<code>!!:1</code>’ always refers to the first word of the previous command, and
|
||
‘<code>!!$</code>’ always refers to the last word of the previous command. With
|
||
<code>CSH_JUNKIE_HISTORY</code> set, then ‘<code>!:1</code>’ and ‘<code>!$</code>’ function in the same
|
||
manner as ‘<code>!!:1</code>’ and ‘<code>!!$</code>’, respectively. Conversely, if
|
||
<code>CSH_JUNKIE_HISTORY</code> is unset, then ‘<code>!:1</code>’ and ‘<code>!$</code>’ refer to the
|
||
first and last words, respectively, of the same event referenced by the
|
||
nearest other history reference preceding them on the current command
|
||
line, or to the previous command if there is no preceding reference.</p>
|
||
<p>The character sequence ‘<code>^``foo``^``bar</code>’ (where ‘<code>^</code>’ is actually the
|
||
second character of the <code>histchars</code> parameter) repeats the last command,
|
||
replacing the string <code>foo</code> with <code>bar</code>. More precisely, the sequence
|
||
‘<code>^``foo``^``bar``^</code>’ is synonymous with ‘<code>!!:s``^``foo``^``bar``^</code>’,
|
||
hence other modifiers (see <a href="Expansion.html#Modifiers">Modifiers</a>) may follow the final
|
||
‘<code>^</code>’. In particular, ‘<code>^``foo``^``bar``^:G</code>’ performs a global
|
||
substitution.</p>
|
||
<p>If the shell encounters the character sequence ‘<code>!"</code>’ in the input, the
|
||
history mechanism is temporarily disabled until the current list (see
|
||
<a href="Shell-Grammar.html#Shell-Grammar">Shell Grammar</a>) is fully parsed. The
|
||
‘<code>!"</code>’ is removed from the input, and any subsequent ‘<code>!</code>’ characters
|
||
have no special significance.</p>
|
||
<p><span id="index-fc_002c-use-of"></span></p>
|
||
<p>A less convenient but more comprehensible form of command history
|
||
support is provided by the <code>fc</code> builtin.</p>
|
||
<hr />
|
||
<p><span id="Event-Designators"></span>
|
||
<span id="Event-Designators-1"></span></p>
|
||
<h3 id="1412-event-designators"><a class="header" href="#1412-event-designators">14.1.2 Event Designators</a></h3>
|
||
<p><span id="index-history-event-designators"></span>
|
||
<span id="index-event-designators_002c-history"></span></p>
|
||
<p>An event designator is a reference to a command-line entry in the
|
||
history list. In the list below, remember that the initial <code>‘!’</code> in each
|
||
item may be changed to another character by setting the <code>histchars</code>
|
||
parameter.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>!</code><br />
|
||
Start a history expansion, except when followed by a blank, newline,
|
||
‘<code>=</code>’ or ‘<code>(</code>’. If followed immediately by a word designator (<a href="Expansion.html#Word-Designators">Word
|
||
Designators</a>), this forms a history reference
|
||
with no event designator (<a href="Expansion.html#Overview">Overview</a>).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>!!</code><br />
|
||
Refer to the previous command. By itself, this expansion repeats the
|
||
previous command.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>!``n</code><br />
|
||
Refer to command-line <code>n</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>!-``n</code><br />
|
||
Refer to the current command-line minus <code>n</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>!``str</code><br />
|
||
Refer to the most recent command starting with <code>str</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>!?``str</code>[<code>?</code>]<br />
|
||
Refer to the most recent command containing <code>str</code>. The trailing
|
||
‘<code>?</code>’ is necessary if this reference is to be followed by a
|
||
modifier or followed by any text that is not to be considered part
|
||
of <code>str</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>!#</code><br />
|
||
Refer to the current command line typed in so far. The line is
|
||
treated as if it were complete up to and including the word before
|
||
the one with the ‘<code>!#</code>’ reference.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>!{</code>...<code>}</code><br />
|
||
Insulate a history reference from adjacent characters (if
|
||
necessary).</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Word-Designators"></span>
|
||
<span id="Word-Designators-1"></span></p>
|
||
<h3 id="1413-word-designators"><a class="header" href="#1413-word-designators">14.1.3 Word Designators</a></h3>
|
||
<p><span id="index-history-word-designators"></span>
|
||
<span id="index-word-designators_002c-history"></span></p>
|
||
<p>A word designator indicates which word or words of a given command line
|
||
are to be included in a history reference. A ‘<code>:</code>’ usually separates the
|
||
event specification from the word designator. It may be omitted only if
|
||
the word designator begins with a ‘<code>^</code>’, ‘<code>$</code>’, ‘<code>*</code>’, ‘<code>-</code>’ or ‘<code>%</code>’.
|
||
Word designators include:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>0</code><br />
|
||
The first input word (command).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>n</code><br />
|
||
The <code>n</code>th argument.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>^</code><br />
|
||
The first argument. That is, <code>1</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>$</code><br />
|
||
The last argument.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%</code><br />
|
||
The word matched by (the most recent) <code>?``str</code> search.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>x``-``y</code><br />
|
||
A range of words; <code>x</code> defaults to <code>0</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>*</code><br />
|
||
All the arguments, or a null value if there are none.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>x``*</code><br />
|
||
Abbreviates ‘<code>x``-$</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>x``-</code><br />
|
||
Like ‘<code>x``*</code>’ but omitting word <code>$</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<p>Note that a ‘<code>%</code>’ word designator works only when used in one of ‘<code>!%</code>’,
|
||
‘<code>!:%</code>’ or ‘<code>!?``str``?:%</code>’, and only when used after a <code>!?</code> expansion
|
||
(possibly in an earlier command). Anything else results in an error,
|
||
although the error may not be the most obvious one.</p>
|
||
<hr />
|
||
<p><span id="Modifiers"></span> <span id="Modifiers-1"></span></p>
|
||
<h3 id="1414-modifiers"><a class="header" href="#1414-modifiers">14.1.4 Modifiers</a></h3>
|
||
<p><span id="index-modifiers"></span>
|
||
<span id="index-colon-modifiers"></span>
|
||
<span id="index-history-modifiers"></span>
|
||
<span id="index-globbing-modifiers"></span>
|
||
<span id="index-parameter-modifiers"></span></p>
|
||
<p>After the optional word designator, you can add a sequence of one or
|
||
more of the following modifiers, each preceded by a ‘<code>:</code>’. These
|
||
modifiers also work on the result of <em>filename generation</em> and
|
||
<em>parameter expansion</em>, except where noted.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>a</code><br />
|
||
Turn a file name into an absolute path: prepends the current
|
||
directory, if necessary; remove ‘<code>.</code>’ path segments; and remove
|
||
‘<code>..</code>’ path segments and the segments that immediately precede
|
||
them.</p>
|
||
<p>This transformation is agnostic about what is in the filesystem,
|
||
i.e. is on the logical, not the physical directory. It takes place
|
||
in the same manner as when changing directories when neither of the
|
||
options <code>CHASE_DOTS</code> or <code>CHASE_LINKS</code> is set. For example,
|
||
‘<code>/before/here/../after</code>’ is always transformed to
|
||
‘<code>/before/after</code>’, regardless of whether ‘<code>/before/here</code>’ exists
|
||
or what kind of object (dir, file, symlink, etc.) it is.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>A</code><br />
|
||
Turn a file name into an absolute path as the ‘<code>a</code>’ modifier does,
|
||
and <em>then</em> pass the result through the <code>realpath(3)</code> library
|
||
function to resolve symbolic links.</p>
|
||
<p>Note: on systems that do not have a <code>realpath(3)</code> library function,
|
||
symbolic links are not resolved, so on those systems ‘<code>a</code>’ and ‘<code>A</code>’
|
||
are equivalent.</p>
|
||
<p>Note: <code>foo:A</code> and <code>realpath(foo)</code> are different on some inputs. For
|
||
<code>realpath(foo)</code> semantics, see the ‘<code>P</code>‘ modifier.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>c</code><br />
|
||
Resolve a command name into an absolute path by searching the
|
||
command path given by the <code>PATH</code> variable. This does not work for
|
||
commands containing directory parts. Note also that this does not
|
||
usually work as a glob qualifier unless a file of the same name is
|
||
found in the current directory.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>e</code><br />
|
||
Remove all but the part of the filename extension following the
|
||
‘<code>.</code>’; see the definition of the filename extension in the
|
||
description of the <code>r</code> modifier below. Note that according to that
|
||
definition the result will be empty if the string ends with a ‘<code>.</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>h</code> [ <code>digits</code> ]<br />
|
||
Remove a trailing pathname component, shortening the path by one
|
||
directory level: this is the ‘head’ of the pathname. This works like
|
||
‘<code>dirname</code>’. If the <code>h</code> is followed immediately (with no spaces or
|
||
other separator) by any number of decimal digits, and the value of
|
||
the resulting number is non-zero, that number of leading components
|
||
is preserved instead of the final component being removed. In an
|
||
absolute path the leading ‘<code>/</code>’ is the first component, so, for
|
||
example, if <code>var=/my/path/to/something</code>, then <code>${var:h3}</code>
|
||
substitutes <code>/my/path</code>. Consecutive ‘/’s are treated the same as a
|
||
single ‘/’. In parameter substitution, digits may only be used if
|
||
the expression is in braces, so for example the short form
|
||
substitution <code>$var:h2</code> is treated as <code>${var:h}2</code>, not as
|
||
<code>${var:h2}</code>. No restriction applies to the use of digits in history
|
||
substitution or globbing qualifiers. If more components are
|
||
requested than are present, the entire path is substituted (so this
|
||
does not trigger a ‘failed modifier’ error in history expansion).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>l</code><br />
|
||
Convert the words to all lowercase.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>p</code><br />
|
||
Print the new command but do not execute it. Only works with history
|
||
expansion.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>P</code><br />
|
||
Turn a file name into an absolute path, like <code>realpath(3)</code>. The
|
||
resulting path will be absolute, have neither ‘<code>.</code>’ nor ‘<code>..</code>’
|
||
components, and refer to the same directory entry as the input
|
||
filename.</p>
|
||
<p>Unlike <code>realpath(3)</code>, non-existent trailing components are permitted
|
||
and preserved.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>q</code><br />
|
||
Quote the substituted words, escaping further substitutions. Works
|
||
with history expansion and parameter expansion, though for
|
||
parameters it is only useful if the resulting text is to be
|
||
re-evaluated such as by <code>eval</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>Q</code><br />
|
||
Remove one level of quotes from the substituted words.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>r</code><br />
|
||
Remove a filename extension leaving the root name. Strings with no
|
||
filename extension are not altered. A filename extension is a ‘<code>.</code>’
|
||
followed by any number of characters (including zero) that are
|
||
neither ‘<code>.</code>’ nor ‘<code>/</code>’ and that continue to the end of the string.
|
||
For example, the extension of ‘<code>foo.orig.c</code>’ is ‘<code>.c</code>’, and
|
||
‘<code>dir.c/foo</code>’ has no extension.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>s/``l``/``r</code>[<code>/</code>]<br />
|
||
Substitute <code>r</code> for <code>l</code> as described below. The substitution is done
|
||
only for the first string that matches <code>l</code>. For arrays and for
|
||
filename generation, this applies to each word of the expanded text.
|
||
See below for further notes on substitutions.</p>
|
||
<p>The forms ‘<code>gs/``l``/``r</code>’ and ‘<code>s/``l``/``r``/:G</code>’ perform global
|
||
substitution, i.e. substitute every occurrence of <code>r</code> for <code>l</code>. Note
|
||
that the <code>g</code> or <code>:G</code> must appear in exactly the position shown.</p>
|
||
<p>See further notes on this form of substitution below.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>&</code><br />
|
||
Repeat the previous <code>s</code> substitution. Like <code>s</code>, may be preceded
|
||
immediately by a <code>g</code>. In parameter expansion the <code>&</code> must appear
|
||
inside braces, and in filename generation it must be quoted with a
|
||
backslash.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>t</code> [ <code>digits</code> ]<br />
|
||
Remove all leading pathname components, leaving the final component
|
||
(tail). This works like ‘<code>basename</code>’. Any trailing slashes are first
|
||
removed. Decimal digits are handled as described above for (h), but
|
||
in this case that number of trailing components is preserved instead
|
||
of the default 1; 0 is treated the same as 1.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>u</code><br />
|
||
Convert the words to all uppercase.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>x</code><br />
|
||
Like <code>q</code>, but break into words at whitespace. Does not work with
|
||
parameter expansion.</p>
|
||
</li>
|
||
</ul>
|
||
<p>The <code>s/``l``/``r``/</code> substitution works as follows. By default the
|
||
left-hand side of substitutions are not patterns, but character strings.
|
||
Any character can be used as the delimiter in place of ‘<code>/</code>’. A
|
||
backslash quotes the delimiter character. The character ‘<code>&</code>’, in the
|
||
right-hand-side <code>r</code>, is replaced by the text from the left-hand-side
|
||
<code>l</code>. The ‘<code>&</code>’ can be quoted with a backslash. A null <code>l</code> uses the
|
||
previous string either from the previous <code>l</code> or from the contextual scan
|
||
string <code>s</code> from ‘<code>!?``s</code>’. You can omit the rightmost delimiter if a
|
||
newline immediately follows <code>r</code>; the rightmost ‘<code>?</code>’ in a context scan
|
||
can similarly be omitted. Note the same record of the last <code>l</code> and <code>r</code>
|
||
is maintained across all forms of expansion.</p>
|
||
<p>Note that if a ‘<code>&</code>’ is used within glob qualifiers an extra backslash
|
||
is needed as a <code>&</code> is a special character in this case.</p>
|
||
<p>Also note that the order of expansions affects the interpretation of <code>l</code>
|
||
and <code>r</code>. When used in a history expansion, which occurs before any other
|
||
expansions, <code>l</code> and <code>r</code> are treated as literal strings (except as
|
||
explained for <code>HIST_SUBST_PATTERN</code> below). When used in parameter
|
||
expansion, the replacement of <code>r</code> into the parameter’s value is done
|
||
first, and then any additional process, parameter, command, arithmetic,
|
||
or brace references are applied, which may evaluate those substitutions
|
||
and expansions more than once if <code>l</code> appears more than once in the
|
||
starting value. When used in a glob qualifier, any substitutions or
|
||
expansions are performed once at the time the qualifier is parsed, even
|
||
before the ‘<code>:s</code>’ expression itself is divided into <code>l</code> and <code>r</code> sides.</p>
|
||
<p>If the option <code>HIST_SUBST_PATTERN</code> is set, <code>l</code> is treated as a pattern
|
||
of the usual form described in <a href="Expansion.html#Filename-Generation">Filename
|
||
Generation</a>. This can be used in all the places
|
||
where modifiers are available; note, however, that in globbing
|
||
qualifiers parameter substitution has already taken place, so parameters
|
||
in the replacement string should be quoted to ensure they are replaced
|
||
at the correct time. Note also that complicated patterns used in
|
||
globbing qualifiers may need the extended glob qualifier notation
|
||
<code>(#q:s/``...``/``...``/)</code> in order for the shell to recognize the
|
||
expression as a glob qualifier. Further, note that bad patterns in the
|
||
substitution are not subject to the <code>NO_BAD_PATTERN</code> option so will
|
||
cause an error.</p>
|
||
<p>When <code>HIST_SUBST_PATTERN</code> is set, <code>l</code> may start with a <code>#</code> to indicate
|
||
that the pattern must match at the start of the string to be
|
||
substituted, and a <code>%</code> may appear at the start or after an <code>#</code> to
|
||
indicate that the pattern must match at the end of the string to be
|
||
substituted. The <code>%</code> or <code>#</code> may be quoted with two backslashes.</p>
|
||
<p>For example, the following piece of filename generation code with the
|
||
<code>EXTENDED_GLOB</code> option:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">print -r -- *.c(#q:s/#%(#b)s(*).c/'S${match[1]}.C'/)
|
||
</code></pre>
|
||
</div>
|
||
<p>takes the expansion of <code>*.c</code> and applies the glob qualifiers in the
|
||
<code>(#q``...``)</code> expression, which consists of a substitution modifier
|
||
anchored to the start and end of each word (<code>#%</code>). This turns on
|
||
backreferences (<code>(#b)</code>), so that the parenthesised subexpression is
|
||
available in the replacement string as <code>${match[1]}</code>. The replacement
|
||
string is quoted so that the parameter is not substituted before the
|
||
start of filename generation.</p>
|
||
<p>The following <code>f</code>, <code>F</code>, <code>w</code> and <code>W</code> modifiers work only with parameter
|
||
expansion and filename generation. They are listed here to provide a
|
||
single point of reference for all modifiers.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>f</code><br />
|
||
Repeats the immediately (without a colon) following modifier until
|
||
the resulting word doesn’t change any more.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>F:``expr``:</code><br />
|
||
Like <code>f</code>, but repeats only <code>n</code> times if the expression <code>expr</code>
|
||
evaluates to <code>n</code>. Any character can be used instead of the ‘<code>:</code>’; if
|
||
‘<code>(</code>’, ‘<code>[</code>’, or ‘<code>{</code>’ is used as the opening delimiter, the closing
|
||
delimiter should be ’<code>)</code>’, ‘<code>]</code>’, or ‘<code>}</code>’, respectively.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>w</code><br />
|
||
Makes the immediately following modifier work on each word in the
|
||
string.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>W:``sep``:</code><br />
|
||
Like <code>w</code> but words are considered to be the parts of the string that
|
||
are separated by <code>sep</code>. Any character can be used instead of the
|
||
‘<code>:</code>’; opening parentheses are handled specially, see above.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Process-Substitution"></span>
|
||
<span id="Process-Substitution-1"></span></p>
|
||
<h2 id="142-process-substitution"><a class="header" href="#142-process-substitution">14.2 Process Substitution</a></h2>
|
||
<p><span id="index-process-substitution"></span>
|
||
<span id="index-substitution_002c-process"></span></p>
|
||
<p>Each part of a command argument that takes the form ‘<code><(``list``)</code>’,
|
||
‘<code>>(``list``)</code>’ or ‘<code>=(``list``)</code>’ is subject to process substitution.
|
||
The expression may be preceded or followed by other strings except that,
|
||
to prevent clashes with commonly occurring strings and patterns, the
|
||
last form must occur at the start of a command argument, and the forms
|
||
are only expanded when first parsing command or assignment arguments.
|
||
Process substitutions may be used following redirection operators; in
|
||
this case, the substitution must appear with no trailing string.</p>
|
||
<p>Note that ‘<code><<(``list``)</code>’ is not a special syntax; it is equivalent to
|
||
‘<code>< <(``list``)</code>’, redirecting standard input from the result of
|
||
process substitution. Hence all the following documentation applies. The
|
||
second form (with the space) is recommended for clarity.</p>
|
||
<p>In the case of the <code><</code> or <code>></code> forms, the shell runs the commands in
|
||
<code>list</code> as a subprocess of the job executing the shell command line. If
|
||
the system supports the <code>/dev/fd</code> mechanism, the command argument is the
|
||
name of the device file corresponding to a file descriptor; otherwise,
|
||
if the system supports named pipes (FIFOs), the command argument will be
|
||
a named pipe. If the form with <code>></code> is selected then writing on this
|
||
special file will provide input for <code>list</code>. If <code><</code> is used, then the
|
||
file passed as an argument will be connected to the output of the <code>list</code>
|
||
process. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">paste <(cut -f1 file1) <(cut -f3 file2) |
|
||
tee >(process1) >(process2) >/dev/null
|
||
</code></pre>
|
||
</div>
|
||
<p>cuts fields 1 and 3 from the files <code>file1</code> and <code>file2</code> respectively,
|
||
pastes the results together, and sends it to the processes <code>process1</code>
|
||
and <code>process2</code>.</p>
|
||
<p>If <code>=(``...``)</code> is used instead of <code><(``...``)</code>, then the file passed as
|
||
an argument will be the name of a temporary file containing the output
|
||
of the <code>list</code> process. This may be used instead of the <code><</code> form for a
|
||
program that expects to lseek (see man page lseek(2)) on the input file.</p>
|
||
<p>There is an optimisation for substitutions of the form <code>=(<<<``arg``)</code>,
|
||
where <code>arg</code> is a single-word argument to the here-string redirection
|
||
<code><<<</code>. This form produces a file name containing the value of <code>arg</code>
|
||
after any substitutions have been performed. This is handled entirely
|
||
within the current shell. This is effectively the reverse of the special
|
||
form <code>$(<``arg``)</code> which treats <code>arg</code> as a file name and replaces it
|
||
with the file’s contents.</p>
|
||
<p>The <code>=</code> form is useful as both the <code>/dev/fd</code> and the named pipe
|
||
implementation of <code><(``...``)</code> have drawbacks. In the former case, some
|
||
programmes may automatically close the file descriptor in question
|
||
before examining the file on the command line, particularly if this is
|
||
necessary for security reasons such as when the programme is running
|
||
setuid. In the second case, if the programme does not actually open the
|
||
file, the subshell attempting to read from or write to the pipe will (in
|
||
a typical implementation, different operating systems may have different
|
||
behaviour) block for ever and have to be killed explicitly. In both
|
||
cases, the shell actually supplies the information using a pipe, so that
|
||
programmes that expect to lseek (see man page lseek(2)) on the file will
|
||
not work.</p>
|
||
<p>Also note that the previous example can be more compactly and
|
||
efficiently written (provided the <code>MULTIOS</code> option is set) as:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">paste <(cut -f1 file1) <(cut -f3 file2) > >(process1) > >(process2)
|
||
</code></pre>
|
||
</div>
|
||
<p>The shell uses pipes instead of FIFOs to implement the latter two
|
||
process substitutions in the above example.</p>
|
||
<p>There is an additional problem with <code>>(``process``)</code>; when this is
|
||
attached to an external command, the parent shell does not wait for
|
||
<code>process</code> to finish and hence an immediately following command cannot
|
||
rely on the results being complete. The problem and solution are the
|
||
same as described in the section <em>MULTIOS</em> in
|
||
<a href="Redirection.html#Redirection">Redirection</a>. Hence in a simplified
|
||
version of the example above:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">paste <(cut -f1 file1) <(cut -f3 file2) > >(process)
|
||
</code></pre>
|
||
</div>
|
||
<p>(note that no <code>MULTIOS</code> are involved), <code>process</code> will be run
|
||
asynchronously as far as the parent shell is concerned. The workaround
|
||
is:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">{ paste <(cut -f1 file1) <(cut -f3 file2) } > >(process)
|
||
</code></pre>
|
||
</div>
|
||
<p>The extra processes here are spawned from the parent shell which will
|
||
wait for their completion.</p>
|
||
<p>Another problem arises any time a job with a substitution that requires
|
||
a temporary file is disowned by the shell, including the case where
|
||
‘<code>&!</code>’ or ‘<code>&|</code>’ appears at the end of a command containing a
|
||
substitution. In that case the temporary file will not be cleaned up as
|
||
the shell no longer has any memory of the job. A workaround is to use a
|
||
subshell, for example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">(mycmd =(myoutput)) &!
|
||
</code></pre>
|
||
</div>
|
||
<p>as the forked subshell will wait for the command to finish then remove
|
||
the temporary file.</p>
|
||
<p>A general workaround to ensure a process substitution endures for an
|
||
appropriate length of time is to pass it as a parameter to an anonymous
|
||
shell function (a piece of shell code that is run immediately with
|
||
function scope). For example, this code:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">() {
|
||
print File $1:
|
||
cat $1
|
||
} =(print This be the verse)
|
||
</code></pre>
|
||
</div>
|
||
<p>outputs something resembling the following</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">File /tmp/zsh6nU0kS:
|
||
This be the verse
|
||
</code></pre>
|
||
</div>
|
||
<p>The temporary file created by the process substitution will be deleted
|
||
when the function exits.</p>
|
||
<hr />
|
||
<p><span id="Parameter-Expansion"></span>
|
||
<span id="Parameter-Expansion-1"></span></p>
|
||
<h2 id="143-parameter-expansion"><a class="header" href="#143-parameter-expansion">14.3 Parameter Expansion</a></h2>
|
||
<p><span id="index-parameter-expansion"></span>
|
||
<span id="index-expansion_002c-parameter"></span></p>
|
||
<p>The character ‘<code>$</code>’ is used to introduce parameter expansions. See
|
||
<a href="Parameters.html#Parameters">Parameters</a> for a description of
|
||
parameters, including arrays, associative arrays, and subscript notation
|
||
to access individual array elements.</p>
|
||
<p>Note in particular the fact that words of unquoted parameters are not
|
||
automatically split on whitespace unless the option <code>SH_WORD_SPLIT</code> is
|
||
set; see references to this option below for more details. This is an
|
||
important difference from other shells. However, as in other shells,
|
||
null words are elided from unquoted parameters’ expansions.</p>
|
||
<p>With default options, after the assignments:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">array=("first word" "" "third word")
|
||
scalar="only word"
|
||
</code></pre>
|
||
</div>
|
||
<p>then <code>$array</code> substitutes two words, ‘<code>first word</code>’ and ‘<code>third word</code>’,
|
||
and <code>$scalar</code> substitutes a single word ‘<code>only word</code>’. Note that second
|
||
element of <code>array</code> was elided. Scalar parameters can be elided too if
|
||
their value is null (empty). To avoid elision, use quoting as follows:
|
||
<code>"$scalar"</code> for scalars and <code>"${array[@]}"</code> or <code>"${(@)array}"</code> for
|
||
arrays. (The last two forms are equivalent.)</p>
|
||
<p>Parameter expansions can involve <em>flags</em>, as in ‘<code>${(@kv)aliases}</code>’, and
|
||
other operators, such as ‘<code>${PREFIX:-"/usr/local"}</code>’. Parameter
|
||
expansions can also be nested. These topics will be introduced below.
|
||
The full rules are complicated and are noted at the end.</p>
|
||
<p>In the expansions discussed below that require a pattern, the form of
|
||
the pattern is the same as that used for filename generation; see
|
||
<a href="Expansion.html#Filename-Generation">Filename Generation</a>. Note that these patterns,
|
||
along with the replacement text of any substitutions, are themselves
|
||
subject to parameter expansion, command substitution, and arithmetic
|
||
expansion. In addition to the following operations, the colon modifiers
|
||
described in <a href="Expansion.html#Modifiers">Modifiers</a> in <a href="Expansion.html#History-Expansion">History
|
||
Expansion</a> can be applied: for example,
|
||
<code>${i:s/foo/bar/}</code> performs string substitution on the expansion of
|
||
parameter <code>$i</code>.</p>
|
||
<p>In the following descriptions, ‘<code>word</code>’ refers to a single word
|
||
substituted on the command line, not necessarily a space delimited word.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>${``name``}</code><br />
|
||
The value, if any, of the parameter <code>name</code> is substituted. The
|
||
braces are required if the expansion is to be followed by a letter,
|
||
digit, or underscore that is not to be interpreted as part of
|
||
<code>name</code>. In addition, more complicated forms of substitution usually
|
||
require the braces to be present; exceptions, which only apply if
|
||
the option <code>KSH_ARRAYS</code> is not set, are a single subscript or any
|
||
colon modifiers appearing after the name, or any of the characters
|
||
‘<code>^</code>’, ‘<code>=</code>’, ‘<code>~</code>’, ‘<code>#</code>’ or ‘<code>+</code>’ appearing before the name, all
|
||
of which work with or without braces.</p>
|
||
<p>If <code>name</code> is an array parameter, and the <code>KSH_ARRAYS</code> option is not
|
||
set, then the value of each element of <code>name</code> is substituted, one
|
||
element per word. Otherwise, the expansion results in one word only;
|
||
with <code>KSH_ARRAYS</code>, this is the first element of an array. No field
|
||
splitting is done on the result unless the <code>SH_WORD_SPLIT</code> option is
|
||
set. See also the flags <code>=</code> and <code>s:``string``:</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>${+``name``}</code><br />
|
||
If <code>name</code> is the name of a set parameter ‘<code>1</code>’ is substituted,
|
||
otherwise ‘<code>0</code>’ is substituted.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>${``name``-``word``}</code><br />
|
||
<code>${``name``:-``word``}</code><br />
|
||
If <code>name</code> is set, or in the second form is non-null, then substitute
|
||
its value; otherwise substitute <code>word</code>. In the second form <code>name</code>
|
||
may be omitted, in which case <code>word</code> is always substituted.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>${``name``+``word``}</code><br />
|
||
<code>${``name``:+``word``}</code><br />
|
||
If <code>name</code> is set, or in the second form is non-null, then substitute
|
||
<code>word</code>; otherwise substitute nothing.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>${``name``=``word``}</code><br />
|
||
<code>${``name``:=``word``}</code><br />
|
||
<code>${``name``::=``word``}</code><br />
|
||
In the first form, if <code>name</code> is unset then set it to <code>word</code>; in the
|
||
second form, if <code>name</code> is unset or null then set it to <code>word</code>; and
|
||
in the third form, unconditionally set <code>name</code> to <code>word</code>. In all
|
||
forms, the value of the parameter is then substituted.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>${``name``?``word``}</code><br />
|
||
<code>${``name``:?``word``}</code><br />
|
||
In the first form, if <code>name</code> is set, or in the second form if <code>name</code>
|
||
is both set and non-null, then substitute its value; otherwise,
|
||
print <code>word</code> and exit from the shell. Interactive shells instead
|
||
return to the prompt. If <code>word</code> is omitted, then a standard message
|
||
is printed.</p>
|
||
</li>
|
||
</ul>
|
||
<p>In any of the above expressions that test a variable and substitute an
|
||
alternate <code>word</code>, note that you can use standard shell quoting in the
|
||
<code>word</code> value to selectively override the splitting done by the
|
||
<code>SH_WORD_SPLIT</code> option and the <code>=</code> flag, but not splitting by the
|
||
<code>s:``string``:</code> flag.</p>
|
||
<p>In the following expressions, when <code>name</code> is an array and the
|
||
substitution is not quoted, or if the ‘<code>(@)</code>’ flag or the <code>name``[@]</code>
|
||
syntax is used, matching and replacement is performed on each array
|
||
element separately.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>${``name``#``pattern``}</code><br />
|
||
<code>${``name``##``pattern``}</code><br />
|
||
If the <code>pattern</code> matches the beginning of the value of <code>name</code>, then
|
||
substitute the value of <code>name</code> with the matched portion deleted;
|
||
otherwise, just substitute the value of <code>name</code>. In the first form,
|
||
the smallest matching pattern is preferred; in the second form, the
|
||
largest matching pattern is preferred.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>${``name``%``pattern``}</code><br />
|
||
<code>${``name``%%``pattern``}</code><br />
|
||
If the <code>pattern</code> matches the end of the value of <code>name</code>, then
|
||
substitute the value of <code>name</code> with the matched portion deleted;
|
||
otherwise, just substitute the value of <code>name</code>. In the first form,
|
||
the smallest matching pattern is preferred; in the second form, the
|
||
largest matching pattern is preferred.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>${``name``:#``pattern``}</code><br />
|
||
If the <code>pattern</code> matches the value of <code>name</code>, then substitute the
|
||
empty string; otherwise, just substitute the value of <code>name</code>. If
|
||
<code>name</code> is an array the matching array elements are removed (use the
|
||
‘<code>(M)</code>’ flag to remove the non-matched elements).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>${``name``:|``arrayname``}</code><br />
|
||
If <code>arrayname</code> is the name (N.B., not contents) of an array
|
||
variable, then any elements contained in <code>arrayname</code> are removed
|
||
from the substitution of <code>name</code>. If the substitution is scalar,
|
||
either because <code>name</code> is a scalar variable or the expression is
|
||
quoted, the elements of <code>arrayname</code> are instead tested against the
|
||
entire expression.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>${``name``:*``arrayname``}</code><br />
|
||
Similar to the preceding substitution, but in the opposite sense, so
|
||
that entries present in both the original substitution and as
|
||
elements of <code>arrayname</code> are retained and others removed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>${``name``:^``arrayname``}</code><br />
|
||
<code>${``name``:^^``arrayname``}</code><br />
|
||
Zips two arrays, such that the output array is twice as long as the
|
||
shortest (longest for ‘<code>:^^</code>’) of <code>name</code> and <code>arrayname</code>, with the
|
||
elements alternatingly being picked from them. For ‘<code>:^</code>’, if one of
|
||
the input arrays is longer, the output will stop when the end of the
|
||
shorter array is reached. Thus,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">a=(1 2 3 4); b=(a b); print ${a:^b}
|
||
</code></pre>
|
||
</div>
|
||
<p>will output ‘<code>1 a 2 b</code>’. For ‘<code>:^^</code>’, then the input is repeated
|
||
until all of the longer array has been used up and the above will
|
||
output ‘<code>1 a 2 b 3 a 4 b</code>’.</p>
|
||
<p>Either or both inputs may be a scalar, they will be treated as an
|
||
array of length 1 with the scalar as the only element. If either
|
||
array is empty, the other array is output with no extra elements
|
||
inserted.</p>
|
||
<p>Currently the following code will output ‘<code>a b</code>’ and ‘<code>1</code>’ as two
|
||
separate elements, which can be unexpected. The second print
|
||
provides a workaround which should continue to work if this is
|
||
changed.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">a=(a b); b=(1 2); print -l "${a:^b}"; print -l "${${a:^b}}"
|
||
</code></pre>
|
||
</div>
|
||
</li>
|
||
<li>
|
||
<p><code>${``name``:``offset``}</code><br />
|
||
<code>${``name``:``offset``:``length``}</code><br />
|
||
This syntax gives effects similar to parameter subscripting in the
|
||
form <code>$``name``[``start``,``end``]</code>, but is compatible with other
|
||
shells; note that both <code>offset</code> and <code>length</code> are interpreted
|
||
differently from the components of a subscript.</p>
|
||
<p>If <code>offset</code> is non-negative, then if the variable <code>name</code> is a scalar
|
||
substitute the contents starting <code>offset</code> characters from the first
|
||
character of the string, and if <code>name</code> is an array substitute
|
||
elements starting <code>offset</code> elements from the first element. If
|
||
<code>length</code> is given, substitute that many characters or elements,
|
||
otherwise the entire rest of the scalar or array.</p>
|
||
<p>A positive <code>offset</code> is always treated as the offset of a character
|
||
or element in <code>name</code> from the first character or element of the
|
||
array (this is different from native zsh subscript notation). Hence
|
||
0 refers to the first character or element regardless of the setting
|
||
of the option <code>KSH_ARRAYS</code>.</p>
|
||
<p>A negative offset counts backwards from the end of the scalar or
|
||
array, so that -1 corresponds to the last character or element, and
|
||
so on.</p>
|
||
<p>When positive, <code>length</code> counts from the <code>offset</code> position toward the
|
||
end of the scalar or array. When negative, <code>length</code> counts back from
|
||
the end. If this results in a position smaller than <code>offset</code>, a
|
||
diagnostic is printed and nothing is substituted.</p>
|
||
<p>The option <code>MULTIBYTE</code> is obeyed, i.e. the offset and length count
|
||
multibyte characters where appropriate.</p>
|
||
<p><code>offset</code> and <code>length</code> undergo the same set of shell substitutions as
|
||
for scalar assignment; in addition, they are then subject to
|
||
arithmetic evaluation. Hence, for example</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">print ${foo:3}
|
||
print ${foo: 1 + 2}
|
||
print ${foo:$(( 1 + 2))}
|
||
print ${foo:$(echo 1 + 2)}
|
||
</code></pre>
|
||
</div>
|
||
<p>all have the same effect, extracting the string starting at the
|
||
fourth character of <code>$foo</code> if the substitution would otherwise
|
||
return a scalar, or the array starting at the fourth element if
|
||
<code>$foo</code> would return an array. Note that with the option <code>KSH_ARRAYS</code>
|
||
<code>$foo</code> always returns a scalar (regardless of the use of the offset
|
||
syntax) and a form such as <code>${foo[*]:3}</code> is required to extract
|
||
elements of an array named <code>foo</code>.</p>
|
||
<p>If <code>offset</code> is negative, the <code>-</code> may not appear immediately after
|
||
the <code>:</code> as this indicates the <code>${``name``:-``word``}</code> form of
|
||
substitution. Instead, a space may be inserted before the <code>-</code>.
|
||
Furthermore, neither <code>offset</code> nor <code>length</code> may begin with an
|
||
alphabetic character or <code>&</code> as these are used to indicate
|
||
history-style modifiers. To substitute a value from a variable, the
|
||
recommended approach is to precede it with a <code>$</code> as this signifies
|
||
the intention (parameter substitution can easily be rendered
|
||
unreadable); however, as arithmetic substitution is performed, the
|
||
expression <code>${var: offs}</code> does work, retrieving the offset from
|
||
<code>$offs</code>.</p>
|
||
<p>For further compatibility with other shells there is a special case
|
||
for array offset 0. This usually accesses the first element of the
|
||
array. However, if the substitution refers to the positional
|
||
parameter array, e.g. <code>$@</code> or <code>$*</code>, then offset 0 instead refers to
|
||
<code>$0</code>, offset 1 refers to <code>$1</code>, and so on. In other words, the
|
||
positional parameter array is effectively extended by prepending
|
||
<code>$0</code>. Hence <code>${*:0:1}</code> substitutes <code>$0</code> and <code>${*:1:1}</code> substitutes
|
||
<code>$1</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>${``name``/``pattern``/``repl``}</code><br />
|
||
<code>${``name``//``pattern``/``repl``}</code><br />
|
||
<code>${``name``:/``pattern``/``repl``}</code><br />
|
||
Replace the longest possible match of <code>pattern</code> in the expansion of
|
||
parameter <code>name</code> by string <code>repl</code>. The first form replaces just the
|
||
first occurrence, the second form all occurrences, and the third
|
||
form replaces only if <code>pattern</code> matches the entire string. Both
|
||
<code>pattern</code> and <code>repl</code> are subject to double-quoted substitution, so
|
||
that expressions like <code>${name/$opat/$npat}</code> will work, but obey the
|
||
usual rule that pattern characters in <code>$opat</code> are not treated
|
||
specially unless either the option <code>GLOB_SUBST</code> is set, or <code>$opat</code>
|
||
is instead substituted as <code>${~opat}</code>.</p>
|
||
<p>The <code>pattern</code> may begin with a ‘<code>#</code>’, in which case the <code>pattern</code>
|
||
must match at the start of the string, or ‘<code>%</code>’, in which case it
|
||
must match at the end of the string, or ‘<code>#%</code>’ in which case the
|
||
<code>pattern</code> must match the entire string. The <code>repl</code> may be an empty
|
||
string, in which case the final ‘<code>/</code>’ may also be omitted. To quote
|
||
the final ‘<code>/</code>’ in other cases it should be preceded by a single
|
||
backslash; this is not necessary if the ‘<code>/</code>’ occurs inside a
|
||
substituted parameter. Note also that the ‘<code>#</code>’, ‘<code>%</code>’ and ‘<code>#%</code> are
|
||
not active if they occur inside a substituted parameter, even at the
|
||
start.</p>
|
||
<p>If, after quoting rules apply, <code>${``name``}</code> expands to an array,
|
||
the replacements act on each element individually. Note also the
|
||
effect of the <code>I</code> and <code>S</code> parameter expansion flags below; however,
|
||
the flags <code>M</code>, <code>R</code>, <code>B</code>, <code>E</code> and <code>N</code> are not useful.</p>
|
||
<p>For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">foo="twinkle twinkle little star" sub="t*e" rep="spy"
|
||
print ${foo//${~sub}/$rep}
|
||
print ${(S)foo//${~sub}/$rep}
|
||
</code></pre>
|
||
</div>
|
||
<p>Here, the ‘<code>~</code>’ ensures that the text of <code>$sub</code> is treated as a
|
||
pattern rather than a plain string. In the first case, the longest
|
||
match for <code>t*e</code> is substituted and the result is ‘<code>spy star</code>’, while
|
||
in the second case, the shortest matches are taken and the result is
|
||
‘<code>spy spy lispy star</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>${#``spec``}</code><br />
|
||
If <code>spec</code> is one of the above substitutions, substitute the length
|
||
in characters of the result instead of the result itself. If <code>spec</code>
|
||
is an array expression, substitute the number of elements of the
|
||
result. This has the side-effect that joining is skipped even in
|
||
quoted forms, which may affect other sub-expressions in <code>spec</code>. Note
|
||
that ‘<code>^</code>’, ‘<code>=</code>’, and ‘<code>~</code>’, below, must appear to the left of
|
||
‘<code>#</code>’ when these forms are combined.</p>
|
||
<p>If the option <code>POSIX_IDENTIFIERS</code> is not set, and <code>spec</code> is a simple
|
||
name, then the braces are optional; this is true even for special
|
||
parameters so e.g. <code>$#-</code> and <code>$#*</code> take the length of the string
|
||
<code>$-</code> and the array <code>$*</code> respectively. If <code>POSIX_IDENTIFIERS</code> is set,
|
||
then braces are required for the <code>#</code> to be treated in this fashion.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>${^``spec``}</code><br />
|
||
<span id="index-RC_005fEXPAND_005fPARAM_002c-toggle"></span>
|
||
<span id="index-array-expansion-style_002c-rc"></span>
|
||
<span id="index-rc_002c-array-expansion-style"></span></p>
|
||
<p>Turn on the <code>RC_EXPAND_PARAM</code> option for the evaluation of <code>spec</code>;
|
||
if the ‘<code>^</code>’ is doubled, turn it off. When this option is set, array
|
||
expansions of the form <code>foo``${``xx``}``bar</code>, where the parameter
|
||
<code>xx</code> is set to <code>(``a b c``)</code>, are substituted with ‘<code>fooabar foobbar foocbar</code>’ instead of the default ‘<code>fooa b cbar</code>’. Note that an empty
|
||
array will therefore cause all arguments to be removed.</p>
|
||
<p>Internally, each such expansion is converted into the equivalent
|
||
list for brace expansion. E.g., <code>${^var}</code> becomes
|
||
<code>{$var[1],$var[2],</code>...<code>}</code>, and is processed as described in <a href="Expansion.html#Brace-Expansion">Brace
|
||
Expansion</a> below: note, however, the expansion
|
||
happens immediately, with any explicit brace expansion happening
|
||
later. If word splitting is also in effect the <code>$var[``N``]</code> may
|
||
themselves be split into different list elements.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>${=``spec``}</code><br />
|
||
<span id="index-SH_005fWORD_005fSPLIT_002c-toggle"></span>
|
||
<span id="index-field-splitting_002c-sh-style_002c-parameter"></span>
|
||
<span id="index-sh_002c-field-splitting-style_002c-parameter"></span></p>
|
||
<p>Perform word splitting using the rules for <code>SH_WORD_SPLIT</code> during
|
||
the evaluation of <code>spec</code>, but regardless of whether the parameter
|
||
appears in double quotes; if the ‘<code>=</code>’ is doubled, turn it off.
|
||
<span id="index-IFS_002c-use-of"></span> This forces parameter
|
||
expansions to be split into separate words before substitution,
|
||
using <code>IFS</code> as a delimiter. This is done by default in most other
|
||
shells.</p>
|
||
<p>Note that splitting is applied to <code>word</code> in the assignment forms of
|
||
<code>spec</code> <em>before</em> the assignment to <code>name</code> is performed. This affects
|
||
the result of array assignments with the <code>A</code> flag.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>${~``spec``}</code><br />
|
||
<span id="index-GLOB_005fSUBST_002c-toggle"></span></p>
|
||
<p>Turn on the <code>GLOB_SUBST</code> option for the evaluation of <code>spec</code>; if the
|
||
‘<code>~</code>’ is doubled, turn it off. When this option is set, the string
|
||
resulting from the expansion will be interpreted as a pattern
|
||
anywhere that is possible, such as in filename expansion and
|
||
filename generation and pattern-matching contexts like the right
|
||
hand side of the ‘<code>=</code>’ and ‘<code>!=</code>’ operators in conditions.</p>
|
||
<p>In nested substitutions, note that the effect of the <code>~</code> applies to
|
||
the result of the current level of substitution. A surrounding
|
||
pattern operation on the result may cancel it. Hence, for example,
|
||
if the parameter <code>foo</code> is set to <code>*</code>, <code>${~foo//\*/*.c}</code> is
|
||
substituted by the pattern <code>*.c</code>, which may be expanded by filename
|
||
generation, but <code>${${~foo}//\*/*.c}</code> substitutes to the string
|
||
<code>*.c</code>, which will not be further expanded.</p>
|
||
</li>
|
||
</ul>
|
||
<p>If a <code>${</code>...<code>}</code> type parameter expression or a <code>$(</code>...<code>)</code> type command
|
||
substitution is used in place of <code>name</code> above, it is expanded first and
|
||
the result is used as if it were the value of <code>name</code>. Thus it is
|
||
possible to perform nested operations: <code>${${foo#head}%tail}</code> substitutes
|
||
the value of <code>$foo</code> with both ‘<code>head</code>’ and ‘<code>tail</code>’ deleted. The form
|
||
with <code>$(</code>...<code>)</code> is often useful in combination with the flags described
|
||
next; see the examples below. Each <code>name</code> or nested <code>${</code>...<code>}</code> in a
|
||
parameter expansion may also be followed by a subscript expression as
|
||
described in <a href="Parameters.html#Array-Parameters">Array Parameters</a>.</p>
|
||
<p>Note that double quotes may appear around nested expressions, in which
|
||
case only the part inside is treated as quoted; for example,
|
||
<code>${(f)"$(foo)"}</code> quotes the result of <code>$(foo)</code>, but the flag ‘<code>(f)</code>’
|
||
(see below) is applied using the rules for unquoted expansions. Note
|
||
further that quotes are themselves nested in this context; for example,
|
||
in <code>"${(@f)"$(foo)"}"</code>, there are two sets of quotes, one surrounding
|
||
the whole expression, the other (redundant) surrounding the <code>$(foo)</code> as
|
||
before.</p>
|
||
<hr />
|
||
<p><span id="Parameter-Expansion-Flags"></span></p>
|
||
<h3 id="1431-parameter-expansion-flags"><a class="header" href="#1431-parameter-expansion-flags">14.3.1 Parameter Expansion Flags</a></h3>
|
||
<p><span id="index-parameter-expansion-flags"></span>
|
||
<span id="index-flags_002c-parameter-expansion"></span>
|
||
<span id="index-substitution_002c-parameter_002c-flags"></span></p>
|
||
<p>If the opening brace is directly followed by an opening parenthesis, the
|
||
string up to the matching closing parenthesis will be taken as a list of
|
||
flags. In cases where repeating a flag is meaningful, the repetitions
|
||
need not be consecutive; for example, ‘(<code>q%q%q</code>)’ means the same thing
|
||
as the more readable ‘(<code>%%qqq</code>)’. The following flags are supported:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>#</code><br />
|
||
Evaluate the resulting words as numeric expressions and output the
|
||
characters corresponding to the resulting integer. Note that this
|
||
form is entirely distinct from use of the <code>#</code> without parentheses.</p>
|
||
<p>If the <code>MULTIBYTE</code> option is set and the number is greater than 127
|
||
(i.e. not an ASCII character) it is treated as a Unicode character.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%</code><br />
|
||
Expand all <code>%</code> escapes in the resulting words in the same way as in
|
||
prompts (see <a href="Prompt-Expansion.html#Prompt-Expansion">Prompt
|
||
Expansion</a>). If this flag is
|
||
given twice, full prompt expansion is done on the resulting words,
|
||
depending on the setting of the <code>PROMPT_PERCENT</code>, <code>PROMPT_SUBST</code> and
|
||
<code>PROMPT_BANG</code> options.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>@</code><br />
|
||
In double quotes, array elements are put into separate words. E.g.,
|
||
‘<code>"${(@)foo}"</code>’ is equivalent to ‘<code>"${foo[@]}"</code>’ and
|
||
‘<code>"${(@)foo[1,2]}"</code>’ is the same as ‘<code>"$foo[1]" "$foo[2]"</code>’. This
|
||
is distinct from <em>field splitting</em> by the <code>f</code>, <code>s</code> or <code>z</code> flags,
|
||
which still applies within each array element.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>A</code><br />
|
||
Convert the substitution into an array expression, even if it
|
||
otherwise would be scalar. This has lower precedence than
|
||
subscripting, so one level of nested expansion is required in order
|
||
that subscripts apply to array elements. Thus
|
||
<code>${${(A``)``name``}[1]}</code> yields the full value of <code>name</code> when <code>name</code>
|
||
is scalar.</p>
|
||
<p>This assigns an array parameter with ‘<code>${</code>...<code>=</code>...<code>}</code>’,
|
||
‘<code>${</code>...<code>:=</code>...<code>}</code>’ or ‘<code>${</code>...<code>::=</code>...<code>}</code>’. If this flag is
|
||
repeated (as in ‘<code>AA</code>’), assigns an associative array parameter.
|
||
Assignment is made before sorting or padding; if field splitting is
|
||
active, the <code>word</code> part is split before assignment. The <code>name</code> part
|
||
may be a subscripted range for ordinary arrays; when assigning an
|
||
associative array, the <code>word</code> part <em>must</em> be converted to an array,
|
||
for example by using ‘<code>${(AA)=``name``=</code>...<code>}</code>’ to activate field
|
||
splitting.</p>
|
||
<p>Surrounding context such as additional nesting or use of the value
|
||
in a scalar assignment may cause the array to be joined back into a
|
||
single string again.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>a</code><br />
|
||
Sort in array index order; when combined with ‘<code>O</code>’ sort in reverse
|
||
array index order. Note that ‘<code>a</code>’ is therefore equivalent to the
|
||
default but ‘<code>Oa</code>’ is useful for obtaining an array’s elements in
|
||
reverse order.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>b</code><br />
|
||
Quote with backslashes only characters that are special to pattern
|
||
matching. This is useful when the contents of the variable are to be
|
||
tested using <code>GLOB_SUBST</code>, including the <code>${~``...``}</code> switch.</p>
|
||
<p>Quoting using one of the <code>q</code> family of flags does not work for this
|
||
purpose since quotes are not stripped from non-pattern characters by
|
||
<code>GLOB_SUBST</code>. In other words,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">pattern=${(q)str}
|
||
[[ $str = ${~pattern} ]]
|
||
</code></pre>
|
||
</div>
|
||
<p>works if <code>$str</code> is ‘<code>a*b</code>’ but not if it is ‘<code>a b</code>’, whereas</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">pattern=${(b)str}
|
||
[[ $str = ${~pattern} ]]
|
||
</code></pre>
|
||
</div>
|
||
<p>is always true for any possible value of <code>$str</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>c</code><br />
|
||
With <code>${#``name``}</code>, count the total number of characters in an
|
||
array, as if the elements were concatenated with spaces between
|
||
them. This is not a true join of the array, so other expressions
|
||
used with this flag may have an effect on the elements of the array
|
||
before it is counted.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>C</code><br />
|
||
Capitalize the resulting words. ‘Words’ in this case refers to
|
||
sequences of alphanumeric characters separated by non-alphanumerics,
|
||
<em>not</em> to words that result from field splitting.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>D</code><br />
|
||
Assume the string or array elements contain directories and attempt
|
||
to substitute the leading part of these by names. The remainder of
|
||
the path (the whole of it if the leading part was not substituted)
|
||
is then quoted so that the whole string can be used as a shell
|
||
argument. This is the reverse of ‘<code>~</code>’ substitution: see <a href="Expansion.html#Filename-Expansion">Filename
|
||
Expansion</a>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>e</code><br />
|
||
Perform single word shell expansions, namely <em>parameter expansion</em>,
|
||
<em>command substitution</em> and <em>arithmetic expansion</em>, on the result.
|
||
Such expansions can be nested but too deep recursion may have</p>
|
||
</li>
|
||
<li>
|
||
<p><code>f</code><br />
|
||
Split the result of the expansion at newlines. This is a shorthand
|
||
for ‘<code>ps:\n:</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>F</code><br />
|
||
Join the words of arrays together using newline as a separator. This
|
||
is a shorthand for ‘<code>pj:\n:</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>g:``opts``:</code><br />
|
||
Process escape sequences like the echo builtin when no options are
|
||
given (<code>g::</code>). With the <code>o</code> option, octal escapes don’t take a
|
||
leading zero. With the <code>c</code> option, sequences like ‘<code>^X</code>’ are also
|
||
processed. With the <code>e</code> option, processes ‘<code>\M-t</code>’ and similar
|
||
sequences like the print builtin. With both of the <code>o</code> and <code>e</code>
|
||
options, behaves like the print builtin except that in none of these
|
||
modes is ‘<code>\c</code>’ interpreted.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>i</code><br />
|
||
Sort case-insensitively. May be combined with ‘<code>n</code>’ or ‘<code>O</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>k</code><br />
|
||
If <code>name</code> refers to an associative array, substitute the <em>keys</em>
|
||
(element names) rather than the values of the elements. Used with
|
||
subscripts (including ordinary arrays), force indices or keys to be
|
||
substituted even if the subscript form refers to values. However,
|
||
this flag may not be combined with subscript ranges. With the
|
||
<code>KSH_ARRAYS</code> option a subscript ‘<code>[*]</code>’ or ‘<code>[@]</code>’ is needed to
|
||
operate on the whole array, as usual.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>L</code><br />
|
||
Convert all letters in the result to lower case.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>n</code><br />
|
||
Sort decimal integers numerically; if the first differing characters
|
||
of two test strings are not digits, sorting is lexical. Integers
|
||
with more initial zeroes are sorted before those with fewer or none.
|
||
Hence the array ‘<code>foo1 foo02 foo2 foo3 foo20 foo23</code>’ is sorted into
|
||
the order shown. May be combined with ‘<code>i</code>’ or ‘<code>O</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>o</code><br />
|
||
Sort the resulting words in ascending order; if this appears on its
|
||
own the sorting is lexical and case-sensitive (unless the locale
|
||
renders it case-insensitive). Sorting in ascending order is the
|
||
default for other forms of sorting, so this is ignored if combined
|
||
with ‘<code>a</code>’, ‘<code>i</code>’ or ‘<code>n</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>O</code><br />
|
||
Sort the resulting words in descending order; ‘<code>O</code>’ without ‘<code>a</code>’,
|
||
‘<code>i</code>’ or ‘<code>n</code>’ sorts in reverse lexical order. May be combined
|
||
with ‘<code>a</code>’, ‘<code>i</code>’ or ‘<code>n</code>’ to reverse the order of sorting.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>P</code><br />
|
||
This forces the value of the parameter <code>name</code> to be interpreted as a
|
||
further parameter name, whose value will be used where appropriate.
|
||
Note that flags set with one of the <code>typeset</code> family of commands (in
|
||
particular case transformations) are not applied to the value of
|
||
<code>name</code> used in this fashion.</p>
|
||
<p>If used with a nested parameter or command substitution, the result
|
||
of that will be taken as a parameter name in the same way. For
|
||
example, if you have ‘<code>foo=bar</code>’ and ‘<code>bar=baz</code>’, the strings
|
||
<code>${(P)foo}</code>, <code>${(P)${foo}}</code>, and <code>${(P)$(echo bar)}</code> will be
|
||
expanded to ‘<code>baz</code>’.</p>
|
||
<p>Likewise, if the reference is itself nested, the expression with the
|
||
flag is treated as if it were directly replaced by the parameter
|
||
name. It is an error if this nested substitution produces an array
|
||
with more than one word. For example, if ‘<code>name=assoc</code>’ where the
|
||
parameter <code>assoc</code> is an associative array, then
|
||
‘<code>${${(P)name}[elt]}</code>’ refers to the element of the associative
|
||
subscripted ‘<code>elt</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>q</code><br />
|
||
Quote characters that are special to the shell in the resulting
|
||
words with <code>$’\``NNN``’</code> form, with separate quotes for each octet.</p>
|
||
<p>If this flag is given twice, the resulting words are quoted in
|
||
single quotes and if it is given three times, the words are quoted
|
||
in double characters is attempted. If the flag is given four times,
|
||
the words are quoted in single quotes preceded by a <code>$</code>. Note that
|
||
in all three of these forms quoting is done unconditionally, even if
|
||
this does not change the way the resulting string would be
|
||
interpreted by the shell.</p>
|
||
<p>If a <code>q-</code> is given (only a single <code>q</code> may appear), a minimal form of
|
||
single quoting is used that only quotes the string if needed to
|
||
protect special characters. Typically this form gives the most
|
||
readable output.</p>
|
||
<p>If a <code>q+</code> is given, an extended form of minimal quoting is used that
|
||
This quoting is similar to that used by the output of values by the
|
||
<code>typeset</code> family of commands.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>Q</code><br />
|
||
Remove one level of quotes from the resulting words.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>t</code><br />
|
||
Use a string describing the type of the parameter where the value of
|
||
the parameter would usually appear. This string consists of keywords
|
||
separated by hyphens (‘<code>-</code>’). The first keyword in the string
|
||
describes the main type, it can be one of ‘<code>scalar</code>’, ‘<code>array</code>’,
|
||
‘<code>integer</code>’, ‘<code>float</code>’ or ‘<code>association</code>’. The other keywords
|
||
describe the type in more detail:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>local</code><br />
|
||
for local parameters</p>
|
||
</li>
|
||
<li>
|
||
<p><code>left</code><br />
|
||
for left justified parameters</p>
|
||
</li>
|
||
<li>
|
||
<p><code>right_blanks</code><br />
|
||
for right justified parameters with leading blanks</p>
|
||
</li>
|
||
<li>
|
||
<p><code>right_zeros</code><br />
|
||
for right justified parameters with leading zeros</p>
|
||
</li>
|
||
<li>
|
||
<p><code>lower</code><br />
|
||
for parameters whose value is converted to all lower case when
|
||
it is expanded</p>
|
||
</li>
|
||
<li>
|
||
<p><code>upper</code><br />
|
||
for parameters whose value is converted to all upper case when
|
||
it is expanded</p>
|
||
</li>
|
||
<li>
|
||
<p><code>readonly</code><br />
|
||
for readonly parameters</p>
|
||
</li>
|
||
<li>
|
||
<p><code>tag</code><br />
|
||
for tagged parameters</p>
|
||
</li>
|
||
<li>
|
||
<p><code>export</code><br />
|
||
for exported parameters</p>
|
||
</li>
|
||
<li>
|
||
<p><code>unique</code><br />
|
||
for arrays which keep only the first occurrence of duplicated
|
||
values</p>
|
||
</li>
|
||
<li>
|
||
<p><code>hide</code><br />
|
||
for parameters with the ‘hide’ flag</p>
|
||
</li>
|
||
<li>
|
||
<p><code>hideval</code><br />
|
||
for parameters with the ‘hideval’ flag</p>
|
||
</li>
|
||
<li>
|
||
<p><code>special</code><br />
|
||
for special parameters defined by the shell</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p><code>u</code><br />
|
||
Expand only the first occurrence of each unique word.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>U</code><br />
|
||
Convert all letters in the result to upper case.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>v</code><br />
|
||
Used with <code>k</code>, substitute (as two consecutive words) both the key
|
||
and the value of each associative array element. Used with
|
||
subscripts, force values to be substituted even if the subscript
|
||
form refers to indices or keys.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>V</code><br />
|
||
Make any special characters in the resulting words visible.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>w</code><br />
|
||
With <code>${#``name``}</code>, count words in arrays or strings; the <code>s</code> flag
|
||
may be used to set a word delimiter.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>W</code><br />
|
||
Similar to <code>w</code> with the difference that empty words between repeated
|
||
delimiters are also counted.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>X</code><br />
|
||
With this flag, parsing errors occurring with the <code>Q</code>, <code>e</code> and <code>#</code>
|
||
flags or the pattern matching forms such as
|
||
‘<code>${``name``#``pattern``}</code>’ are reported. Without the flag, errors
|
||
are silently ignored.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>z</code><br />
|
||
Split the result of the expansion into words using shell parsing to
|
||
find the words, i.e. taking into account any quoting in the value.
|
||
Comments are not treated specially but as ordinary strings, similar
|
||
to interactive shells with the <code>INTERACTIVE_COMMENTS</code> option unset
|
||
(however, see the <code>Z</code> flag below for related options)</p>
|
||
<p>Note that this is done very late, even later than the ‘<code>(s)</code>’ flag.
|
||
So to access single words in the result use nested expansions as in
|
||
‘<code>${${(z)foo}[2]}</code>’. Likewise, to remove the quotes in the
|
||
resulting words use ‘<code>${(Q)${(z)foo}}</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>0</code><br />
|
||
Split the result of the expansion on null bytes. This is a shorthand
|
||
for ‘<code>ps:\0:</code>’.</p>
|
||
</li>
|
||
</ul>
|
||
<p>The following flags (except <code>p</code>) are followed by one or more arguments
|
||
as shown. Any character, or the matching pairs ‘<code>(</code>...<code>)</code>’, ‘<code>{</code>...<code>}</code>’,
|
||
‘<code>[</code>...<code>]</code>’, or ‘<code><</code>...<code>></code>’, may be used in place of a colon as
|
||
delimiters, but note that when a flag takes more than one argument, a
|
||
matched pair of delimiters must surround each argument.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>p</code><br />
|
||
Recognize the same escape sequences as the <code>print</code> builtin in string
|
||
arguments to any of the flags described below that follow this
|
||
argument.</p>
|
||
<p>Alternatively, with this option string arguments may be in the form
|
||
<code>$``var</code> in which case the value of the variable is substituted.
|
||
Note this form is strict; the string argument does not undergo
|
||
general parameter expansion.</p>
|
||
<p>For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">sep=:
|
||
val=a:b:c
|
||
print ${(ps.$sep.)val}
|
||
</code></pre>
|
||
</div>
|
||
<p>splits the variable on a <code>:</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>~</code><br />
|
||
Strings inserted into the expansion by any of the flags below are to
|
||
be treated as patterns. This applies to the string arguments of
|
||
flags that follow <code>~</code> within the same set of parentheses. Compare
|
||
with <code>~</code> outside parentheses, which forces the entire substituted
|
||
string to be treated as a pattern. Hence, for example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">[[ "?" = ${(~j.|.)array} ]]
|
||
</code></pre>
|
||
</div>
|
||
<p>treats ‘<code>|</code>’ as a pattern and succeeds if and only if <code>$array</code>
|
||
contains the string ‘<code>?</code>’ as an element. The <code>~</code> may be repeated to
|
||
toggle the behaviour; its effect only lasts to the end of the
|
||
parenthesised group.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>j:``string``:</code><br />
|
||
Join the words of arrays together using <code>string</code> as a separator.
|
||
<span id="index-SH_005fWORD_005fSPLIT_002c-use-of"></span> Note that
|
||
this occurs before field splitting by the <code>s:``string``:</code> flag or
|
||
the <code>SH_WORD_SPLIT</code> option.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>l:``expr``::``string1``::``string2``:</code><br />
|
||
Pad the resulting words on the left. Each word will be truncated if
|
||
required and placed in a field <code>expr</code> characters wide.</p>
|
||
<p>The arguments <code>:``string1``:</code> and <code>:``string2``:</code> are optional;
|
||
neither, the first, or both may be given. Note that the same pairs
|
||
of delimiters must be used for each of the three arguments. The
|
||
space to the left will be filled with <code>string1</code> (concatenated as
|
||
often as needed) or spaces if <code>string1</code> is not given. If both
|
||
<code>string1</code> and <code>string2</code> are given, <code>string2</code> is inserted once
|
||
directly to the left of each word, truncated if necessary, before
|
||
<code>string1</code> is used to produce any remaining padding.</p>
|
||
<p>If either of <code>string1</code> or <code>string2</code> is present but empty, i.e. there
|
||
are two delimiters together at that point, the first character of
|
||
<code>$IFS</code> is used instead.</p>
|
||
<p>If the <code>MULTIBYTE</code> option is in effect, the flag <code>m</code> may also be
|
||
given, in which case widths will be used for the calculation of
|
||
padding; otherwise individual multibyte characters are treated as
|
||
occupying one unit of width.</p>
|
||
<p>If the <code>MULTIBYTE</code> option is not in effect, each byte in the string
|
||
is treated as occupying one unit of width.</p>
|
||
<p>Control characters are always assumed to be one unit wide; this
|
||
allows the mechanism to be used for generating repetitions of
|
||
control characters.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>m</code><br />
|
||
Only useful together with one of the flags <code>l</code> or <code>r</code> or with the
|
||
<code>#</code> length operator when the <code>MULTIBYTE</code> option is in effect. Use
|
||
the character width reported by the system in calculating how much
|
||
of the string it occupies or the overall unit, however certain Asian
|
||
character sets and certain special effects use wider characters;
|
||
combining characters have zero width. would actually be displayed
|
||
will vary.</p>
|
||
<p>If the <code>m</code> is repeated, the character either counts zero (if it has
|
||
effect of counting the number of glyphs (visibly separate
|
||
characters), except for the case where combining characters
|
||
themselves have non-zero width (true in certain alphabets).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>r:``expr``::``string1``::``string2``:</code><br />
|
||
As <code>l</code>, but pad the words on the right and insert <code>string2</code>
|
||
immediately to the right of the string to be padded.</p>
|
||
<p>Left and right padding may be used together. In this case the
|
||
strategy is to apply left padding to the first half width of each of
|
||
the resulting words, and right padding to the second half. If the
|
||
string to be padded has odd width the extra padding is applied on
|
||
the left.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>s:``string``:</code><br />
|
||
Force field splitting at the separator <code>string</code>. Note that a
|
||
<code>string</code> of two or more characters means that all of them must match
|
||
in sequence; this differs from the treatment of two or more
|
||
characters in the <code>IFS</code> parameter. See also the <code>=</code> flag and the
|
||
<code>SH_WORD_SPLIT</code> option. An empty string may also be given in which
|
||
case every character will be a separate element.</p>
|
||
<p>For historical reasons, the usual behaviour that empty array
|
||
elements are retained inside double quotes is disabled for arrays
|
||
generated by splitting; hence the following:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">line="one::three"
|
||
print -l "${(s.:.)line}"
|
||
</code></pre>
|
||
</div>
|
||
<p>produces two lines of output for <code>one</code> and <code>three</code> and elides the
|
||
empty field. To override this behaviour, supply the ‘<code>(@)</code>’ flag as
|
||
well, i.e. <code>"${(@s.:.)line}"</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>Z:``opts``:</code><br />
|
||
As <code>z</code> but takes a combination of option letters between a following
|
||
pair of delimiter characters. With no options the effect is
|
||
identical to <code>z</code>. <code>(Z+c+)</code> causes comments to be parsed as a string
|
||
and retained; any field in the resulting array beginning with an
|
||
unquoted comment character is a comment. <code>(Z+C+)</code> causes comments to
|
||
be parsed and removed. The rule for comments is standard: anything
|
||
between a word starting with the third character of <code>$HISTCHARS</code>,
|
||
default <code>#</code>, up to the next newline is a comment. <code>(Z+n+)</code> causes
|
||
unquoted newlines to be treated as ordinary whitespace, else they
|
||
are treated as if they are shell code delimiters and converted to
|
||
semicolons. Options are combined within the same set of delimiters,
|
||
e.g. <code>(Z+Cn+)</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>_:``flags``:</code><br />
|
||
The underscore (<code>_</code>) flag is reserved for future use. As of this
|
||
revision of zsh, there are no valid <code>flags</code>; anything following an
|
||
underscore, other than an empty pair of delimiters, is treated as an
|
||
error, and the flag itself has no effect.</p>
|
||
</li>
|
||
</ul>
|
||
<p>The following flags are meaningful with the <code>${</code>...<code>#</code>...<code>}</code> or
|
||
<code>${</code>...<code>%</code>...<code>}</code> forms. The <code>S</code> and <code>I</code> flags may also be used with the
|
||
<code>${</code>...<code>/</code>...<code>}</code> forms.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>S</code><br />
|
||
With <code>#</code> or <code>##</code>, search for the match that starts closest to the
|
||
start of the string (a ‘substring match’). Of all matches at a
|
||
particular position, <code>#</code> selects the shortest and <code>##</code> the longest:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">% str="aXbXc"
|
||
% echo ${(S)str#X*}
|
||
abXc
|
||
% echo ${(S)str##X*}
|
||
a
|
||
%
|
||
</code></pre>
|
||
</div>
|
||
<p>With <code>%</code> or <code>%%</code>, search for the match that starts closest to the
|
||
end of the string:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">% str="aXbXc"
|
||
% echo ${(S)str%X*}
|
||
aXbc
|
||
% echo ${(S)str%%X*}
|
||
aXb
|
||
%
|
||
</code></pre>
|
||
</div>
|
||
<p>(Note that <code>%</code> and <code>%%</code> don’t search for the match that ends closest
|
||
to the end of the string, as one might expect.)</p>
|
||
<p>With substitution via <code>${</code>...<code>/</code>...<code>}</code> or <code>${</code>...<code>//</code>...<code>}</code>,
|
||
specifies non-greedy matching, i.e. that the shortest instead of the
|
||
longest match should be replaced:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">% str="abab"
|
||
% echo ${str/*b/_}
|
||
_
|
||
% echo ${(S)str/*b/_}
|
||
_ab
|
||
%
|
||
</code></pre>
|
||
</div>
|
||
</li>
|
||
<li>
|
||
<p><code>I:``expr``:</code><br />
|
||
Search the <code>expr</code>th match (where <code>expr</code> evaluates to a number). This
|
||
only applies when searching for substrings, either with the <code>S</code>
|
||
flag, or with <code>${</code>...<code>/</code>...<code>}</code> (only the <code>expr</code>th match is
|
||
substituted) or <code>${</code>...<code>//</code>...<code>}</code> (all matches from the <code>expr</code>th on
|
||
are substituted). The default is to take the first match.</p>
|
||
<p>The <code>expr</code>th match is counted such that there is either one or zero
|
||
matches from each starting position in the string, although for
|
||
global substitution matches overlapping previous replacements are
|
||
ignored. With the <code>${</code>...<code>%</code>...<code>}</code> and <code>${</code>...<code>%%</code>...<code>}</code> forms, the
|
||
starting position for the match moves backwards from the end as the
|
||
index increases, while with the other forms it moves forward from
|
||
the start.</p>
|
||
<p>Hence with the string</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">which switch is the right switch for Ipswich?
|
||
</code></pre>
|
||
</div>
|
||
<p>substitutions of the form <code>${</code>(<code>SI:``N``:</code>)<code>string#w*ch}</code> as <code>N</code>
|
||
increases from 1 will match and remove ‘<code>which</code>’, ‘<code>witch</code>’,
|
||
‘<code>witch</code>’ and ‘<code>wich</code>’; the form using ‘<code>##</code>’ will match and
|
||
remove ‘<code>which switch is the right switch for Ipswich</code>’, ‘<code>witch is the right switch for Ipswich</code>’, ‘<code>witch for Ipswich</code>’ and ‘<code>wich</code>’.
|
||
The form using ‘<code>%</code>’ will remove the same matches as for ‘<code>#</code>’, but
|
||
in reverse order, and the form using ‘<code>%%</code>’ will remove the same
|
||
matches as for ‘<code>##</code>’ in reverse order.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>B</code><br />
|
||
Include the index of the beginning of the match in the result.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>E</code><br />
|
||
Include the index one character past the end of the match in the
|
||
result (note this is inconsistent with other uses of parameter
|
||
index).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>M</code><br />
|
||
Include the matched portion in the result.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>N</code><br />
|
||
Include the length of the match in the result.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>R</code><br />
|
||
Include the unmatched portion in the result (the <em>R</em>est).</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Rules"></span></p>
|
||
<h3 id="1432-rules"><a class="header" href="#1432-rules">14.3.2 Rules</a></h3>
|
||
<p>Here is a summary of the rules for substitution; this assumes that
|
||
braces are present around the substitution, i.e. <code>${``...``}</code>. Some
|
||
particular examples are given below. Note that the Zsh Development Group
|
||
accepts <em>no responsibility</em> for any brain damage which may occur during
|
||
the reading of the following rules.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>1.</code> <em>Nested substitution</em><br />
|
||
If multiple nested <code>${``...``}</code> forms are present, substitution is
|
||
performed from the inside outwards. At each level, the substitution
|
||
takes account of whether the current value is a scalar or an array,
|
||
whether the whole substitution is in double quotes, and what flags
|
||
are supplied to the current level of substitution, just as if the
|
||
nested substitution were the outermost. The flags are not propagated
|
||
up to enclosing substitutions; the nested substitution will return
|
||
either a scalar or an array as determined by the flags, possibly
|
||
adjusted for quoting. All the following steps take place where
|
||
applicable at all levels of substitution.</p>
|
||
<p>Note that, unless the ‘<code>(P)</code>’ flag is present, the flags and any
|
||
subscripts apply directly to the value of the nested substitution;
|
||
for example, the expansion <code>${${foo}}</code> behaves exactly the same as
|
||
<code>${foo}</code>. When the ‘<code>(P)</code>’ flag is present in a nested substitution,
|
||
the other substitution rules are applied to the value <em>before</em> it is
|
||
interpreted as a name, so <code>${${(P)foo}}</code> may differ from
|
||
<code>${(P)foo}</code>.</p>
|
||
<p>At each nested level of substitution, the substituted words undergo
|
||
all forms of single-word substitution (i.e. not filename
|
||
generation), including command substitution, arithmetic expansion
|
||
and filename expansion (i.e. leading <code>~</code> and <code>=</code>). Thus, for
|
||
example, <code>${${:-=cat}:h}</code> expands to the directory where the <code>cat</code>
|
||
program resides. (Explanation: the internal substitution has no
|
||
parameter but a default value <code>=cat</code>, which is expanded by filename
|
||
expansion to a full path; the outer substitution then applies the
|
||
modifier <code>:h</code> and takes the directory part of the path.)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>2.</code> <em>Internal parameter flags</em><br />
|
||
Any parameter flags set by one of the <code>typeset</code> family of commands,
|
||
in particular the <code>-L</code>, <code>-R</code>, <code>-Z</code>, <code>-u</code> and <code>-l</code> options for
|
||
padding and capitalization, are applied directly to the parameter
|
||
value. Note these flags are options to the command, e.g. ‘<code>typeset -Z</code>’; they are not the same as the flags used within parameter
|
||
substitutions.</p>
|
||
<p>At the outermost level of substitution, the ‘<code>(P)</code>’ flag (rule <code>4.</code>)
|
||
ignores these transformations and uses the unmodified value of the
|
||
parameter as the name to be replaced. This is usually the desired
|
||
behavior because padding may make the value syntactically illegal as
|
||
a parameter name, but if capitalization changes are desired, use the
|
||
<code>${${(P)foo}}</code> form (rule <code>25.</code>).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>3.</code> <em>Parameter subscripting</em><br />
|
||
If the value is a raw parameter reference with a subscript, such as
|
||
<code>${``var``[3]}</code>, the effect of subscripting is applied directly to
|
||
the parameter. Subscripts are evaluated left to right; subsequent
|
||
subscripts apply to the scalar or array value yielded by the
|
||
previous subscript. Thus if <code>var</code> is an array, <code>${var[1][2]}</code> is the
|
||
second character of the first word, but <code>${var[2,4][2]}</code> is the
|
||
entire third word (the second word of the range of words two through
|
||
four of the original array). Any number of subscripts may appear.
|
||
Flags such as ‘<code>(k)</code>’ and ‘<code>(v)</code>’ which alter the result of
|
||
subscripting are applied.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>4.</code> <em>Parameter name replacement</em><br />
|
||
At the outermost level of nesting only, the ‘<code>(P)</code>’ flag is applied.
|
||
This treats the value so far as a parameter name (which may include
|
||
a subscript expression) and replaces that with the corresponding
|
||
value. This replacement occurs later if the ‘<code>(P)</code>’ flag appears in
|
||
a nested substitution.</p>
|
||
<p>If the value so far names a parameter that has internal flags (rule
|
||
<code>2.</code>), those internal flags are applied to the new value after
|
||
replacement.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>5.</code> <em>Double-quoted joining</em><br />
|
||
If the value after this process is an array, and the substitution
|
||
appears in double quotes, and neither an ‘<code>(@)</code>’ flag nor a ‘<code>#</code>’
|
||
length operator is present at the current level, then words of the
|
||
value are joined with the first character of the parameter <code>$IFS</code>,
|
||
by default a space, between each word (single word arrays are not
|
||
modified). If the ‘<code>(j)</code>’ flag is present, that is used for joining
|
||
instead of <code>$IFS</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>6.</code> <em>Nested subscripting</em><br />
|
||
Any remaining subscripts (i.e. of a nested substitution) are
|
||
evaluated at this point, based on whether the value is an array or a
|
||
scalar. As with <code>3.</code>, multiple subscripts can appear. Note that
|
||
<code>${foo[2,4][2]}</code> is thus equivalent to <code>${${foo[2,4]}[2]}</code> and also
|
||
to <code>"${${(@)foo[2,4]}[2]}"</code> (the nested substitution returns an
|
||
array in both cases), but not to <code>"${${foo[2,4]}[2]}"</code> (the nested
|
||
substitution returns a scalar because of the quotes).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>7.</code> <em>Modifiers</em><br />
|
||
Any modifiers, as specified by a trailing ‘<code>#</code>’, ‘<code>%</code>’, ‘<code>/</code>’
|
||
(possibly doubled) or by a set of modifiers of the form ‘<code>:...</code>’
|
||
(see <a href="Expansion.html#Modifiers">Modifiers</a> in <a href="Expansion.html#History-Expansion">History
|
||
Expansion</a>), are applied to the words of the
|
||
value at this level.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>8.</code> <em>Character evaluation</em><br />
|
||
Any ‘<code>(#)</code>’ flag is applied, evaluating the result so far
|
||
numerically as a character.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>9.</code> <em>Length</em><br />
|
||
Any initial ‘<code>#</code>’ modifier, i.e. in the form <code>${#``var``}</code>, is used
|
||
to evaluate the length of the expression so far.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>10.</code> <em>Forced joining</em><br />
|
||
If the ‘<code>(j)</code>’ flag is present, or no ‘<code>(j)</code>’ flag is present but
|
||
the string is to be split as given by rule <code>11.</code>, and joining did
|
||
not take place at rule <code>5.</code>, any words in the value are joined
|
||
together using the given string or the first character of <code>$IFS</code> if
|
||
none. Note that the ‘<code>(F)</code>’ flag implicitly supplies a string for
|
||
joining in this manner.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>11.</code> <em>Simple word splitting</em><br />
|
||
If one of the ‘<code>(s)</code>’ or ‘<code>(f)</code>’ flags are present, or the ‘<code>=</code>’
|
||
specifier was present (e.g. <code>${=``var``}</code>), the word is split on
|
||
occurrences of the specified string, or (for <code>=</code> with neither of the
|
||
two flags present) any of the characters in <code>$IFS</code>.</p>
|
||
<p>If no ‘<code>(s)</code>’, ‘<code>(f)</code>’ or ‘<code>=</code>’ was given, but the word is not
|
||
quoted and the option <code>SH_WORD_SPLIT</code> is set, the word is split on
|
||
occurrences of any of the characters in <code>$IFS</code>. Note this step, too,
|
||
takes place at all levels of a nested substitution.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>12.</code> <em>Case modification</em><br />
|
||
Any case modification from one of the flags ‘<code>(L)</code>’, ‘<code>(U)</code>’ or
|
||
‘<code>(C)</code>’ is applied.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>13.</code> <em>Escape sequence replacement</em><br />
|
||
First any replacements from the ‘<code>(g)</code>’ flag are performed, then any
|
||
prompt-style formatting from the ‘<code>(%)</code>’ family of flags is applied.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>14.</code> <em>Quote application</em><br />
|
||
Any quoting or unquoting using ‘<code>(q)</code>’ and ‘<code>(Q)</code>’ and related flags
|
||
is applied.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>15.</code> <em>Directory naming</em><br />
|
||
Any directory name substitution using ‘<code>(D)</code>’ flag is applied.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>16.</code> <em>Visibility enhancement</em><br />
|
||
Any modifications to make characters visible using the ‘<code>(V)</code>’ flag
|
||
are applied.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>17.</code> <em>Lexical word splitting</em><br />
|
||
If the ’<code>(z)</code>’ flag or one of the forms of the ’<code>(Z)</code>’ flag is
|
||
present, the word is split as if it were a shell command line, so
|
||
that quotation marks and other metacharacters are used to decide
|
||
what constitutes a word. Note this form of splitting is entirely
|
||
distinct from that described by rule <code>11.</code>: it does not use <code>$IFS</code>,
|
||
and does not cause forced joining.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>18.</code> <em>Uniqueness</em><br />
|
||
If the result is an array and the ‘<code>(u)</code>’ flag was present,
|
||
duplicate elements are removed from the array.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>19.</code> <em>Ordering</em><br />
|
||
If the result is still an array and one of the ‘<code>(o)</code>’ or ‘<code>(O)</code>’
|
||
flags was present, the array is reordered.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>20.</code> <code>RC_EXPAND_PARAM</code><br />
|
||
At this point the decision is made whether any resulting array
|
||
elements are to be combined element by element with surrounding
|
||
text, as given by either the <code>RC_EXPAND_PARAM</code> option or the ‘<code>^</code>’
|
||
flag.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>21.</code> <em>Re-evaluation</em><br />
|
||
Any ‘<code>(e)</code>’ flag is applied to the value, forcing it to be
|
||
re-examined for new parameter substitutions, but also for command
|
||
and arithmetic substitutions.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>22.</code> <em>Padding</em><br />
|
||
Any padding of the value by the ‘<code>(l.``fill``.)</code>’ or
|
||
‘<code>(r.``fill``.)</code>’ flags is applied.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>23.</code> <em>Semantic joining</em><br />
|
||
In contexts where expansion semantics requires a single word to
|
||
result, all words are rejoined with the first character of <code>IFS</code>
|
||
between. So in ‘<code>${(P``)${(f``)lines}}</code>’ the value of <code>${lines}</code> is
|
||
split at newlines, but then must be joined again before the ‘<code>(P)</code>’
|
||
flag can be applied.</p>
|
||
<p>If a single word is not required, this rule is skipped.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>24.</code> <em>Empty argument removal</em><br />
|
||
If the substitution does not appear in double quotes, any resulting
|
||
zero-length argument, whether from a scalar or an element of an
|
||
array, is elided from the list of arguments inserted into the
|
||
command line.</p>
|
||
<p>Strictly speaking, the removal happens later as the same happens
|
||
with other forms of substitution; the point to note here is simply
|
||
that it occurs after any of the above parameter operations.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>25.</code> <em>Nested parameter name replacement</em><br />
|
||
If the ‘<code>(P)</code>’ flag is present and rule <code>4.</code> has not applied, the
|
||
value so far is treated as a parameter name (which may include a
|
||
subscript expression) and replaced with the corresponding value,
|
||
with internal flags (rule <code>2.</code>) applied to the new value.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Examples-1"></span></p>
|
||
<h3 id="1433-examples"><a class="header" href="#1433-examples">14.3.3 Examples</a></h3>
|
||
<p>The flag <code>f</code> is useful to split a double-quoted substitution line by
|
||
line. For example, <code>${(f)"$(<``file``)"}</code> substitutes the contents of
|
||
<code>file</code> divided so that each line is an element of the resulting array.
|
||
Compare this with the effect of <code>$``(<``file``)</code> alone, which divides
|
||
the file up by words, or the same inside double quotes, which makes the
|
||
entire content of the file a single string.</p>
|
||
<p>The following illustrates the rules for nested parameter expansions.
|
||
Suppose that <code>$foo</code> contains the array <code>(bar baz``)</code>:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>"${(@)${foo}[1]}"</code><br />
|
||
This produces the result <code>b</code>. First, the inner substitution
|
||
<code>"${foo}"</code>, which has no array (<code>@</code>) flag, produces a single word
|
||
result <code>"bar baz"</code>. The outer substitution <code>"${(@)...[1]}"</code> detects
|
||
that this is a scalar, so that (despite the ‘<code>(@)</code>’ flag) the
|
||
subscript picks the first character.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>"${${(@)foo}[1]}"</code><br />
|
||
This produces the result ‘<code>bar</code>’. In this case, the inner
|
||
substitution <code>"${(@)foo}"</code> produces the array ‘<code>(bar baz``)</code>’. The
|
||
outer substitution <code>"${...[1]}"</code> detects that this is an array and
|
||
picks the first word. This is similar to the simple case
|
||
<code>"${foo[1]}"</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<p>As an example of the rules for word splitting and joining, suppose
|
||
<code>$foo</code> contains the array ‘<code>(ax1 bx1``)</code>’. Then</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>${(s/x/)foo}</code><br />
|
||
produces the words ‘<code>a</code>’, ‘<code>1 b</code>’ and ‘<code>1</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>${(j/x/s/x/)foo}</code><br />
|
||
produces ‘<code>a</code>’, ‘<code>1</code>’, ‘<code>b</code>’ and ‘<code>1</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>${(s/x/)foo%%1*}</code><br />
|
||
produces ‘<code>a</code>’ and ‘<code> b</code>’ (note the extra space). As substitution
|
||
occurs before either joining or splitting, the operation first
|
||
generates the modified array <code>(ax bx``)</code>, which is joined to give
|
||
<code>"ax bx"</code>, and then split to give ‘<code>a</code>’, ‘<code> b</code>’ and ‘’. The final
|
||
empty string will then be elided, as it is not in double quotes.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Command-Substitution"></span>
|
||
<span id="Command-Substitution-1"></span></p>
|
||
<h2 id="144-command-substitution"><a class="header" href="#144-command-substitution">14.4 Command Substitution</a></h2>
|
||
<p><span id="index-command-substitution"></span>
|
||
<span id="index-substitution_002c-command"></span></p>
|
||
<p>A command enclosed in parentheses preceded by a dollar sign, like
|
||
‘<code>$(</code>...<code>)</code>’, or quoted with grave accents, like ‘<code>‘</code>...<code>‘</code>’, is
|
||
replaced with its standard output, with any trailing newlines deleted.
|
||
If the substitution is not enclosed in double quotes, the output is
|
||
broken into words using the <code>IFS</code> parameter.
|
||
<span id="index-IFS_002c-use-of-1"></span></p>
|
||
<p>The substitution ‘<code>$(cat</code> <code>foo``)</code>’ may be replaced by the faster
|
||
‘<code>$(<``foo``)</code>’. In this case <code>foo</code> undergoes single word shell
|
||
expansions (<em>parameter expansion</em>, <em>command substitution</em> and
|
||
<em>arithmetic expansion</em>), but not filename generation.</p>
|
||
<p>If the option <code>GLOB_SUBST</code> is set, the result of any unquoted command
|
||
substitution, including the special form just mentioned, is eligible for
|
||
filename generation.</p>
|
||
<hr />
|
||
<p><span id="Arithmetic-Expansion"></span>
|
||
<span id="Arithmetic-Expansion-1"></span></p>
|
||
<h2 id="145-arithmetic-expansion"><a class="header" href="#145-arithmetic-expansion">14.5 Arithmetic Expansion</a></h2>
|
||
<p><span id="index-arithmetic-expansion"></span>
|
||
<span id="index-expansion_002c-arithmetic"></span></p>
|
||
<p>A string of the form ‘<code>$[``exp``]</code>’ or ‘<code>$((``exp``))</code>’ is substituted
|
||
with the value of the arithmetic expression <code>exp</code>. <code>exp</code> is subjected to
|
||
<em>parameter expansion</em>, <em>command substitution</em> and <em>arithmetic expansion</em>
|
||
before it is evaluated. See <a href="Arithmetic-Evaluation.html#Arithmetic-Evaluation">Arithmetic
|
||
Evaluation</a>.</p>
|
||
<hr />
|
||
<p><span id="Brace-Expansion"></span> <span id="Brace-Expansion-1"></span></p>
|
||
<h2 id="146-brace-expansion"><a class="header" href="#146-brace-expansion">14.6 Brace Expansion</a></h2>
|
||
<p><span id="index-brace-expansion"></span>
|
||
<span id="index-expansion_002c-brace"></span></p>
|
||
<p>A string of the form ‘<code>foo``{``xx``,``yy``,``zz``}``bar</code>’ is expanded to
|
||
the individual words ‘<code>fooxxbar</code>’, ‘<code>fooyybar</code>’ and ‘<code>foozzbar</code>’.
|
||
Left-to-right order is preserved. This construct may be nested. Commas
|
||
may be quoted in order to include them literally in a word.</p>
|
||
<p>An expression of the form ‘<code>{``n1``..``n2``}</code>’, where <code>n1</code> and <code>n2</code> are
|
||
integers, is expanded to every number between <code>n1</code> and <code>n2</code> inclusive.
|
||
If either number begins with a zero, all the resulting numbers will be
|
||
padded with leading zeroes to that minimum width, but for negative
|
||
numbers the <code>-</code> character is also included in the width. If the numbers
|
||
are in decreasing order the resulting sequence will also be in
|
||
decreasing order.</p>
|
||
<p>An expression of the form ‘<code>{``n1``..``n2``..``n3``}</code>’, where <code>n1</code>,
|
||
<code>n2</code>, and <code>n3</code> are integers, is expanded as above, but only every <code>n3</code>th
|
||
number starting from <code>n1</code> is output. If <code>n3</code> is negative the numbers are
|
||
output in reverse order, this is slightly different from simply swapping
|
||
<code>n1</code> and <code>n2</code> in the case that the step <code>n3</code> doesn’t evenly divide the
|
||
range. Zero padding can be specified in any of the three numbers,
|
||
specifying it in the third can be useful to pad for example
|
||
‘<code>{-99..100..01}</code>’ which is not possible to specify by putting a 0 on
|
||
either of the first two numbers (i.e. pad to two characters).</p>
|
||
<p>An expression of the form ‘<code>{``c1``..``c2``}</code>’, where <code>c1</code> and <code>c2</code> are
|
||
single characters (which may be multibyte characters), is expanded to
|
||
every character in the range from <code>c1</code> to <code>c2</code> in whatever character
|
||
sequence is used internally. For characters with code points below 128
|
||
this is US ASCII (this is the only case most users will need). If any
|
||
intervening character is not If the character sequence is reversed, the
|
||
output is in reverse order, e.g. ‘<code>{d..a}</code>’ is substituted as ‘<code>d c b a</code>’.</p>
|
||
<p>If a brace expression matches none of the above forms, it is left
|
||
unchanged, unless the option <code>BRACE_CCL</code> (an abbreviation for ‘brace
|
||
character class’) is set.
|
||
<span id="index-BRACE_005fCCL_002c-use-of"></span> In that case, it is
|
||
expanded to a list of the individual characters between the braces
|
||
sorted into the order of the characters in the ASCII character set
|
||
(multibyte characters are not currently handled). The syntax is similar
|
||
to a <code>[</code>...<code>]</code> expression in filename generation: ‘<code>-</code>’ is treated
|
||
specially to denote a range of characters, but ‘<code>^</code>’ or ‘<code>!</code>’ as the
|
||
first character is treated normally. For example, ‘<code>{abcdef0-9}</code>’
|
||
expands to 16 words <code>0 1 2 3 4 5 6 7 8 9 a b c d e f</code>.</p>
|
||
<p>Note that brace expansion is not part of filename generation (globbing);
|
||
an expression such as <code>*/{foo,bar}</code> is split into two separate words
|
||
<code>*/foo</code> and <code>*/bar</code> before filename generation takes place. In
|
||
particular, note that this is liable to produce a ‘no match’ error if
|
||
<em>either</em> of the two expressions does not match; this is to be contrasted
|
||
with <code>*/(foo|bar)</code>, which is treated as a single pattern but otherwise
|
||
has similar effects.</p>
|
||
<p>To combine brace expansion with array expansion, see the <code>${^``spec``}</code>
|
||
form described in <a href="Expansion.html#Parameter-Expansion">Parameter Expansion</a> above.</p>
|
||
<hr />
|
||
<p><span id="Filename-Expansion"></span>
|
||
<span id="Filename-Expansion-1"></span></p>
|
||
<h2 id="147-filename-expansion"><a class="header" href="#147-filename-expansion">14.7 Filename Expansion</a></h2>
|
||
<p><span id="index-filename-expansion"></span>
|
||
<span id="index-expansion_002c-filename"></span></p>
|
||
<p>Each word is checked to see if it begins with an unquoted ‘<code>~</code>’. If it
|
||
does, then the word up to a ‘<code>/</code>’, or the end of the word if there is no
|
||
‘<code>/</code>’, is checked to see if it can be substituted in one of the ways
|
||
described here. If so, then the ‘<code>~</code>’ and the checked portion are
|
||
replaced with the appropriate substitute value.</p>
|
||
<p>A ‘<code>~</code>’ by itself is replaced by the value of <code>$HOME</code>. A ‘<code>~</code>’ followed
|
||
by a ‘<code>+</code>’ or a ‘<code>-</code>’ is replaced by current or previous working
|
||
directory, respectively.</p>
|
||
<p>A ‘<code>~</code>’ followed by a number is replaced by the directory at that
|
||
position in the directory stack. ‘<code>~0</code>’ is equivalent to ‘<code>~+</code>’, and
|
||
‘<code>~1</code>’ is the top of the stack. ‘<code>~+</code>’ followed by a number is
|
||
replaced by the directory at that position in the directory stack.
|
||
‘<code>~+0</code>’ is equivalent to ‘<code>~+</code>’, and ‘<code>~+1</code>’ is the top of the stack.
|
||
‘<code>~-</code>’ followed by a number is replaced by the directory that many
|
||
positions from the bottom of the stack. ‘<code>~-0</code>’ is the bottom of the
|
||
stack. <span id="index-PUSHD_005fMINUS_002c-use-of"></span> The
|
||
<code>PUSHD_MINUS</code> option exchanges the effects of ‘<code>~+</code>’ and ‘<code>~-</code>’ where
|
||
they are followed by a number.</p>
|
||
<hr />
|
||
<p><span id="Dynamic-named-directories"></span></p>
|
||
<h3 id="1471-dynamic-named-directories"><a class="header" href="#1471-dynamic-named-directories">14.7.1 Dynamic named directories</a></h3>
|
||
<p><span id="index-directories_002c-named_002c-dynamic"></span>
|
||
<span id="index-named-directories_002c-dynamic"></span>
|
||
<span id="index-dynamic-named-directories"></span></p>
|
||
<p>If the function <code>zsh_directory_name</code> exists, or the shell variable
|
||
<code>zsh_directory_name_functions</code> exists and contains an array of function
|
||
names, then the functions are used to implement dynamic directory
|
||
naming. The functions are tried in order until one returns status zero,
|
||
so it is important that functions test whether they can handle the case
|
||
in question and return an appropriate status.</p>
|
||
<p>A ‘<code>~</code>’ followed by a string <code>namstr</code> in unquoted square brackets is
|
||
treated specially as a dynamic directory name. Note that the first
|
||
unquoted closing square bracket always terminates <code>namstr</code>. The shell
|
||
function is passed two arguments: the string <code>n</code> (for name) and
|
||
<code>namstr</code>. It should either set the array <code>reply</code> to a single element
|
||
which is the directory corresponding to the name and return status zero
|
||
(executing an assignment as the last statement is usually sufficient),
|
||
or it should return status non-zero. In the former case the element of
|
||
reply is used as the directory; in the latter case the substitution is
|
||
deemed to have failed. If all functions fail and the option <code>NOMATCH</code> is
|
||
set, an error results.</p>
|
||
<p>The functions defined as above are also used to see if a directory can
|
||
be turned into a name, for example when printing the directory stack or
|
||
when expanding <code>%~</code> in prompts. In this case each function is passed two
|
||
arguments: the string <code>d</code> (for directory) and the candidate for dynamic
|
||
naming. The function should either return non-zero status, if the
|
||
directory cannot be named by the function, or it should set the array
|
||
reply to consist of two elements: the first is the dynamic name for the
|
||
directory (as would appear within ‘<code>~[``...``]</code>’), and the second is the
|
||
prefix length of the directory to be replaced. For example, if the trial
|
||
directory is <code>/home/myname/src/zsh</code> and the dynamic name for
|
||
<code>/home/myname/src</code> (which has 16 characters) is <code>s</code>, then the function
|
||
sets</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">reply=(s 16)
|
||
</code></pre>
|
||
</div>
|
||
<p>The directory name so returned is compared with possible static names
|
||
for parts of the directory path, as described below; it is used if the
|
||
prefix length matched (16 in the example) is longer than that matched by
|
||
any static name.</p>
|
||
<p>It is not a requirement that a function implements both <code>n</code> and <code>d</code>
|
||
calls; for example, it might be appropriate for certain dynamic forms of
|
||
expansion not to be contracted to names. In that case any call with the
|
||
first argument <code>d</code> should cause a non-zero status to be returned.</p>
|
||
<p>The completion system calls ‘<code>zsh_directory_name c</code>’ followed by
|
||
equivalent calls to elements of the array
|
||
<code>zsh_directory_name_functions</code>, if it exists, in order to complete
|
||
dynamic names for directories. The code for this should be as for any
|
||
other completion function as described in <a href="Completion-System.html#Completion-System">Completion
|
||
System</a>.</p>
|
||
<p>As a working example, here is a function that expands any dynamic names
|
||
beginning with the string <code>p:</code> to directories below
|
||
<code>/home/pws/perforce</code>. In this simple case a static name for the
|
||
directory would be just as effective.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zsh_directory_name() {
|
||
emulate -L zsh
|
||
setopt extendedglob
|
||
local -a match mbegin mend
|
||
if [[ $1 = d ]]; then
|
||
# turn the directory into a name
|
||
if [[ $2 = (#b)(/home/pws/perforce/)([^/]##)* ]]; then
|
||
typeset -ga reply
|
||
reply=(p:$match[2] $(( ${#match[1]} + ${#match[2]} )) )
|
||
else
|
||
return 1
|
||
fi
|
||
elif [[ $1 = n ]]; then
|
||
# turn the name into a directory
|
||
[[ $2 != (#b)p:(?*) ]] && return 1
|
||
typeset -ga reply
|
||
reply=(/home/pws/perforce/$match[1])
|
||
elif [[ $1 = c ]]; then
|
||
# complete names
|
||
local expl
|
||
local -a dirs
|
||
dirs=(/home/pws/perforce/*(/:t))
|
||
dirs=(p:${^dirs})
|
||
_wanted dynamic-dirs expl 'dynamic directory' compadd -S\] -a dirs
|
||
return
|
||
else
|
||
return 1
|
||
fi
|
||
return 0
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<hr />
|
||
<p><span id="Static-named-directories"></span></p>
|
||
<h3 id="1472-static-named-directories"><a class="header" href="#1472-static-named-directories">14.7.2 Static named directories</a></h3>
|
||
<p><span id="index-directories_002c-named_002c-static"></span>
|
||
<span id="index-named-directories_002c-static"></span>
|
||
<span id="index-static-named-directories"></span></p>
|
||
<p>A ‘<code>~</code>’ followed by anything not already covered consisting of any
|
||
number of alphanumeric characters or underscore (‘<code>_</code>’), hyphen (‘<code>-</code>’),
|
||
or dot (‘<code>.</code>’) is looked up as a named directory, and replaced by the
|
||
value of that named directory if found. Named directories are typically
|
||
home directories for users on the system. They may also be defined if
|
||
the text after the ‘<code>~</code>’ is the name of a string shell parameter whose
|
||
value begins with a ‘<code>/</code>’. Note that trailing slashes will be removed
|
||
from the path to the directory (though the original parameter is not
|
||
modified).</p>
|
||
<p>It is also possible to define directory names using the <code>-d</code> option to
|
||
the <code>hash</code> builtin.</p>
|
||
<p>When the shell prints a path (e.g. when expanding <code>%~</code> in prompts or
|
||
when printing the directory stack), the path is checked to see if it has
|
||
a named directory as its prefix. If so, then the prefix portion is
|
||
replaced with a ‘<code>~</code>’ followed by the name of the directory. The shorter
|
||
of the two ways of referring to the directory is used, i.e. either the
|
||
directory name or the full path; the name is used if they are the same
|
||
length. The parameters <code>$PWD</code> and <code>$OLDPWD</code> are never abbreviated in
|
||
this fashion.</p>
|
||
<hr />
|
||
<p><span id="g_t_0060_003d_0027-expansion"></span></p>
|
||
<h3 id="1473--expansion"><a class="header" href="#1473--expansion">14.7.3 ‘=’ expansion</a></h3>
|
||
<p>If a word begins with an unquoted ‘<code>=</code>’ and the <code>EQUALS</code> option is set,
|
||
the remainder of the word is taken as the name of a command. If a
|
||
command exists by that name, the word is replaced by the full pathname
|
||
of the command.</p>
|
||
<hr />
|
||
<p><span id="Notes"></span></p>
|
||
<h3 id="1474-notes"><a class="header" href="#1474-notes">14.7.4 Notes</a></h3>
|
||
<p>Filename expansion is performed on the right hand side of a parameter
|
||
assignment, including those appearing after commands of the <code>typeset</code>
|
||
family. In this case, the right hand side will be treated as a
|
||
colon-separated list in the manner of the <code>PATH</code> parameter, so that a
|
||
‘<code>~</code>’ or an ‘<code>=</code>’ following a ‘<code>:</code>’ is eligible for expansion. All
|
||
such behaviour can be disabled by quoting the ‘<code>~</code>’, the ‘<code>=</code>’, or the
|
||
whole expression (but not simply the colon); the <code>EQUALS</code> option is also
|
||
respected.</p>
|
||
<p>If the option <code>MAGIC_EQUAL_SUBST</code> is set, any unquoted shell argument in
|
||
the form ‘<code>identifier``=``expression</code>’ becomes eligible for file
|
||
expansion as described in the previous paragraph. Quoting the first
|
||
‘<code>=</code>’ also inhibits this.</p>
|
||
<hr />
|
||
<p><span id="Filename-Generation"></span>
|
||
<span id="Filename-Generation-1"></span></p>
|
||
<h2 id="148-filename-generation"><a class="header" href="#148-filename-generation">14.8 Filename Generation</a></h2>
|
||
<p><span id="index-filename-generation"></span></p>
|
||
<p>If a word contains an unquoted instance of one of the characters ‘<code>*</code>’,
|
||
‘<code>(</code>’, ‘<code>|</code>’, ‘<code><</code>’, ‘<code>[</code>’, or ‘<code>?</code>’, it is regarded as a pattern for
|
||
filename generation, unless the <code>GLOB</code> option is unset.
|
||
<span id="index-GLOB_002c-use-of"></span> If the <code>EXTENDED_GLOB</code> option
|
||
is set, <span id="index-EXTENDED_005fGLOB_002c-use-of"></span> the ‘<code>^</code>’
|
||
and ‘<code>#</code>’ characters also denote a pattern; otherwise they are not
|
||
treated specially by the shell.</p>
|
||
<p>The word is replaced with a list of sorted filenames that match the
|
||
pattern. If no matching pattern is found, the shell gives an error
|
||
message, unless the <code>NULL_GLOB</code> option is set,
|
||
<span id="index-NULL_005fGLOB_002c-use-of"></span> in which case the
|
||
word is deleted; or unless the <code>NOMATCH</code> option is unset, in which case
|
||
the word is left unchanged. <span id="index-NOMATCH_002c-use-of"></span></p>
|
||
<p>In filename generation, the character ‘<code>/</code>’ must be matched explicitly;
|
||
also, a ‘<code>.</code>’ must be matched explicitly at the beginning of a pattern
|
||
or after a ‘<code>/</code>’, unless the <code>GLOB_DOTS</code> option is set.
|
||
<span id="index-GLOB_005fDOTS_002c-use-of"></span> No filename
|
||
generation pattern matches the files ‘<code>.</code>’ or ‘<code>..</code>’. In other instances
|
||
of pattern matching, the ‘<code>/</code>’ and ‘<code>.</code>’ are not treated specially.</p>
|
||
<hr />
|
||
<p><span id="Glob-Operators"></span></p>
|
||
<h3 id="1481-glob-operators"><a class="header" href="#1481-glob-operators">14.8.1 Glob Operators</a></h3>
|
||
<ul>
|
||
<li>
|
||
<p><code>*</code><br />
|
||
Matches any string, including the null string.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>?</code><br />
|
||
Matches any character.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>[</code>...<code>]</code><br />
|
||
Matches any of the enclosed characters. Ranges of characters can be
|
||
specified by separating two characters by a ‘<code>-</code>’. A ‘<code>-</code>’ or ‘<code>]</code>’
|
||
may be matched by including it as the first character in the list.
|
||
<span id="index-character-classes"></span> There are also several
|
||
named classes of characters, in the form ‘<code>[:``name``:]</code>’ with the
|
||
following meanings. The first set use the macros provided by the
|
||
operating system to test for the given character combinations,
|
||
including any modifications due to local language settings, see man
|
||
page ctype(3):</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>[:alnum:]</code><br />
|
||
The character is alphanumeric</p>
|
||
</li>
|
||
<li>
|
||
<p><code>[:alpha:]</code><br />
|
||
The character is alphabetic</p>
|
||
</li>
|
||
<li>
|
||
<p><code>[:ascii:]</code><br />
|
||
The character is 7-bit, i.e. is a single-byte character without
|
||
the top bit set.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>[:blank:]</code><br />
|
||
The character is a blank character</p>
|
||
</li>
|
||
<li>
|
||
<p><code>[:cntrl:]</code><br />
|
||
The character is a control character</p>
|
||
</li>
|
||
<li>
|
||
<p><code>[:digit:]</code><br />
|
||
The character is a decimal digit</p>
|
||
</li>
|
||
<li>
|
||
<p><code>[:graph:]</code><br />
|
||
<code>[:lower:]</code><br />
|
||
The character is a lowercase letter</p>
|
||
</li>
|
||
<li>
|
||
<p><code>[:print:]</code><br />
|
||
<code>[:punct:]</code><br />
|
||
<code>[:space:]</code><br />
|
||
The character is whitespace</p>
|
||
</li>
|
||
<li>
|
||
<p><code>[:upper:]</code><br />
|
||
The character is an uppercase letter</p>
|
||
</li>
|
||
<li>
|
||
<p><code>[:xdigit:]</code><br />
|
||
The character is a hexadecimal digit</p>
|
||
</li>
|
||
</ul>
|
||
<p>Another set of named classes is handled internally by the shell and
|
||
is not sensitive to the locale:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>[:IDENT:]</code><br />
|
||
The character is allowed to form part of a shell identifier,
|
||
such as a parameter name</p>
|
||
</li>
|
||
<li>
|
||
<p><code>[:IFS:]</code><br />
|
||
The character is used as an input field separator, i.e. is
|
||
contained in the <code>IFS</code> parameter</p>
|
||
</li>
|
||
<li>
|
||
<p><code>[:IFSSPACE:]</code><br />
|
||
The character is an IFS white space character; see the
|
||
documentation for <code>IFS</code> in <a href="Parameters.html#Parameters-Used-By-The-Shell">Parameters Used By The
|
||
Shell</a>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>[:INCOMPLETE:]</code><br />
|
||
Matches a byte that starts an incomplete multibyte character.
|
||
Note that there may be a sequence of more than one bytes that
|
||
taken together form the prefix of a multibyte character. To test
|
||
for a potentially incomplete byte sequence, use the pattern
|
||
‘<code>[[:INCOMPLETE:]]*</code>’. This will never match a sequence
|
||
starting with a valid multibyte character.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>[:INVALID:]</code><br />
|
||
Matches a byte that does not start a valid multibyte character.
|
||
Note this may be a continuation byte of an incomplete multibyte
|
||
character as any part of a multibyte string consisting of
|
||
invalid and incomplete multibyte characters is treated as single
|
||
bytes.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>[:WORD:]</code><br />
|
||
The character is treated as part of a word; this test is
|
||
sensitive to the value of the <code>WORDCHARS</code> parameter</p>
|
||
</li>
|
||
</ul>
|
||
<p>Note that the square brackets are additional to those enclosing the
|
||
whole set of characters, so to test for a single alphanumeric
|
||
character you need ‘<code>[[:alnum:]]</code>’. Named character sets can be used
|
||
alongside other types, e.g. ‘<code>[[:alpha:]0-9]</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>[^</code>...<code>]</code><br />
|
||
<code>[!</code>...<code>]</code><br />
|
||
Like <code>[</code>...<code>]</code>, except that it matches any character which is not in
|
||
the given set.</p>
|
||
</li>
|
||
<li>
|
||
<p><code><</code>[<code>x</code>]<code>-</code>[<code>y</code>]<code>></code><br />
|
||
Matches any number in the range <code>x</code> to <code>y</code>, inclusive. Either of the
|
||
numbers may be omitted to make the range open-ended; hence ‘<code><-></code>’
|
||
matches any number. To match individual digits, the <code>[</code>...<code>]</code> form
|
||
is more efficient.</p>
|
||
<p>Be careful when using other wildcards adjacent to patterns of this
|
||
form; for example, <code><0-9>*</code> will actually match any number
|
||
whatsoever at the start of the string, since the ‘<code><0-9></code>’ will
|
||
match the first digit, and the ‘<code>*</code>’ will match any others. This is
|
||
a trap for the unwary, but is match always succeeds. Expressions
|
||
such as ‘<code><0-9>[^[:digit:]]*</code>’ can be used instead.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>(</code>...<code>)</code><br />
|
||
Matches the enclosed pattern. This is used for grouping. If the
|
||
<code>KSH_GLOB</code> option is set, then a ‘<code>@</code>’, ‘<code>*</code>’, ‘<code>+</code>’, ‘<code>?</code>’ or ‘<code>!</code>’
|
||
immediately preceding the ‘<code>(</code>’ is treated specially, as detailed
|
||
below. The option <code>SH_GLOB</code> prevents bare parentheses from being
|
||
used in this way, though the <code>KSH_GLOB</code> option is still available.</p>
|
||
<p>Note that grouping cannot extend over multiple directories: it is an
|
||
error to have a ‘<code>/</code>’ within a group (this only applies for patterns
|
||
used in filename generation). There is one exception: a group of the
|
||
form <code>(``pat``/)#</code> appearing as a complete path segment can match a
|
||
sequence of directories. For example, <code>foo/(a*/)#bar</code> matches
|
||
<code>foo/bar</code>, <code>foo/any/bar</code>, <code>foo/any/anyother/bar</code>, and so on.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>x``|``y</code><br />
|
||
Matches either <code>x</code> or <code>y</code>. This operator has lower precedence than
|
||
any other. The ‘<code>|</code>’ character must be within parentheses, to avoid
|
||
interpretation as a pipeline. The alternatives are tried in order
|
||
from left to right.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>^``x</code><br />
|
||
(Requires <code>EXTENDED_GLOB</code> to be set.) Matches anything except the
|
||
pattern <code>x</code>. This has a higher precedence than ‘<code>/</code>’, so
|
||
‘<code>^foo/bar</code>’ will search directories in ‘<code>.</code>’ except ‘<code>./foo</code>’
|
||
for a file named ‘<code>bar</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>x``~``y</code><br />
|
||
(Requires <code>EXTENDED_GLOB</code> to be set.) Match anything that matches
|
||
the pattern <code>x</code> but does not match <code>y</code>. This has lower precedence
|
||
than any operator except ‘<code>|</code>’, so ‘<code>*/*~foo/bar</code>’ will search for
|
||
all files in all directories in ‘<code>.</code>’ and then exclude ‘<code>foo/bar</code>’
|
||
if there was such a match. Multiple patterns can be excluded by
|
||
‘<code>foo``~``bar``~``baz</code>’. In the exclusion pattern (<code>y</code>), ‘<code>/</code>’ and
|
||
‘<code>.</code>’ are not treated specially the way they usually are in
|
||
globbing.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>x``#</code><br />
|
||
(Requires <code>EXTENDED_GLOB</code> to be set.) Matches zero or more
|
||
occurrences of the pattern <code>x</code>. This operator has high precedence;
|
||
‘<code>12#</code>’ is equivalent to ‘<code>1(2#)</code>’, rather than ‘<code>(12)#</code>’. It is
|
||
an error for an unquoted ‘<code>#</code>’ to follow something which cannot be
|
||
repeated; this includes an empty string, a pattern already followed
|
||
by ‘<code>##</code>’, or parentheses when part of a <code>KSH_GLOB</code> pattern (for
|
||
example, ‘<code>!(``foo``)#</code>’ is invalid and must be replaced by
|
||
‘<code>*(!(``foo``))</code>’).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>x``##</code><br />
|
||
(Requires <code>EXTENDED_GLOB</code> to be set.) Matches one or more
|
||
occurrences of the pattern <code>x</code>. This operator has high precedence;
|
||
‘<code>12##</code>’ is equivalent to ‘<code>1(2##)</code>’, rather than ‘<code>(12)##</code>’. No
|
||
more than two active ‘<code>#</code>’ characters may appear together. (Note the
|
||
potential clash with glob qualifiers in the form ‘<code>1(2##)</code>’ which
|
||
should therefore be avoided.)</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="ksh_002dlike-Glob-Operators"></span></p>
|
||
<h3 id="1482-ksh-like-glob-operators"><a class="header" href="#1482-ksh-like-glob-operators">14.8.2 ksh-like Glob Operators</a></h3>
|
||
<p><span id="index-KSH_005fGLOB_002c-use-of"></span></p>
|
||
<p>If the <code>KSH_GLOB</code> option is set, the effects of parentheses can be
|
||
modified by a preceding ‘<code>@</code>’, ‘<code>*</code>’, ‘<code>+</code>’, ‘<code>?</code>’ or ‘<code>!</code>’. This
|
||
character need not be unquoted to have special effects, but the ‘<code>(</code>’
|
||
must be.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>@(</code>...<code>)</code><br />
|
||
Match the pattern in the parentheses. (Like ‘<code>(</code>...<code>)</code>’.)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>*(</code>...<code>)</code><br />
|
||
Match any number of occurrences. (Like ‘<code>(</code>...<code>)#</code>’, except that
|
||
recursive directory searching is not supported.)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>+(</code>...<code>)</code><br />
|
||
Match at least one occurrence. (Like ‘<code>(</code>...<code>)##</code>’, except that
|
||
recursive directory searching is not supported.)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>?(</code>...<code>)</code><br />
|
||
Match zero or one occurrence. (Like ‘<code>(|</code>...<code>)</code>’.)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>!(</code>...<code>)</code><br />
|
||
Match anything but the expression in parentheses. (Like
|
||
‘<code>(^(</code>...<code>))</code>’.)</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Precedence"></span></p>
|
||
<h3 id="1483-precedence"><a class="header" href="#1483-precedence">14.8.3 Precedence</a></h3>
|
||
<p><span id="index-precedence-of-glob-operators"></span></p>
|
||
<p>The precedence of the operators given above is (highest) ‘<code>^</code>’, ‘<code>/</code>’,
|
||
‘<code>~</code>’, ‘<code>|</code>’ (lowest); the remaining operators are simply treated from
|
||
left to right as part of a string, with ‘<code>#</code>’ and ‘<code>##</code>’ applying to the
|
||
shortest possible preceding unit (i.e. a character, ‘<code>?</code>’, ‘<code>[</code>...<code>]</code>’,
|
||
‘<code><</code>...<code>></code>’, or a parenthesised expression). As mentioned above, a
|
||
‘<code>/</code>’ used as a directory separator may not appear inside parentheses,
|
||
while a ‘<code>|</code>’ must do so; in patterns used in other contexts than
|
||
filename generation (for example, in <code>case</code> statements and tests within
|
||
‘<code>[[</code>...<code>]]</code>’), a ‘<code>/</code>’ is not special; and ‘<code>/</code>’ is also not special
|
||
after a ‘<code>~</code>’ appearing outside parentheses in a filename pattern.</p>
|
||
<hr />
|
||
<p><span id="Globbing-Flags"></span></p>
|
||
<h3 id="1484-globbing-flags"><a class="header" href="#1484-globbing-flags">14.8.4 Globbing Flags</a></h3>
|
||
<p>There are various flags which affect any text to their right up to the
|
||
end of the enclosing group or to the end of the pattern; they require
|
||
the <code>EXTENDED_GLOB</code> option. All take the form <code>(#``X``)</code> where <code>X</code> may
|
||
have one of the following forms:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>i</code><br />
|
||
Case insensitive: upper or lower case characters in the pattern
|
||
match upper or lower case characters.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>l</code><br />
|
||
Lower case characters in the pattern match upper or lower case
|
||
characters; upper case characters in the pattern still only match
|
||
upper case characters.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>I</code><br />
|
||
Case sensitive: locally negates the effect of <code>i</code> or <code>l</code> from that
|
||
point on.</p>
|
||
<p><span id="index-match"></span> <span id="index-mbegin"></span>
|
||
<span id="index-mend"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>b</code><br />
|
||
Activate backreferences for parenthesised groups in the pattern;
|
||
this does not work in filename generation. When a pattern with a set
|
||
of active parentheses is matched, the strings matched by the groups
|
||
are stored in the array <code>$match</code>, the indices of the beginning of
|
||
the matched parentheses in the array <code>$mbegin</code>, and the indices of
|
||
the end in the array <code>$mend</code>, with the first element of each array
|
||
corresponding to the first parenthesised group, and so on. These
|
||
arrays are not otherwise special to the shell. The indices use the
|
||
same convention as does parameter substitution, so that elements of
|
||
<code>$mend</code> and <code>$mbegin</code> may be used in subscripts; the <code>KSH_ARRAYS</code>
|
||
option is respected. Sets of globbing flags are not considered
|
||
parenthesised groups; only the first nine active parentheses can be
|
||
referenced.</p>
|
||
<p>For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">foo="a_string_with_a_message"
|
||
if [[ $foo = (a|an)_(#b)(*) ]]; then
|
||
print ${foo[$mbegin[1],$mend[1]]}
|
||
fi
|
||
</code></pre>
|
||
</div>
|
||
<p>prints ‘<code>string_with_a_message</code>’. Note that the first set of
|
||
parentheses is before the <code>(#b)</code> and does not create a
|
||
backreference.</p>
|
||
<p>Backreferences work with all forms of pattern matching other than
|
||
filename generation, but note that when performing matches on an
|
||
entire array, such as <code>${``array``#``pattern``}</code>, or a global
|
||
substitution, such as <code>${``param``//``pat``/``repl``}</code>, only the
|
||
data for the last match remains available. In the case of global
|
||
replacements this may still be useful. See the example for the <code>m</code>
|
||
flag below.</p>
|
||
<p>The numbering of backreferences strictly follows the order of the
|
||
opening parentheses from left to right in the pattern string,
|
||
although sets of parentheses may be nested. There are special rules
|
||
for parentheses followed by ‘<code>#</code>’ or ‘<code>##</code>’. Only the last match of
|
||
the parenthesis is remembered: for example, in ‘<code>[[ abab = (#b)([ab])# ]]</code>’, only the final ‘<code>b</code>’ is stored in <code>match[1]</code>. Thus
|
||
extra parentheses may be necessary to match the complete segment:
|
||
for example, use ‘<code>X((ab|cd)#)Y</code>’ to match a whole string of either
|
||
‘<code>ab</code>’ or ‘<code>cd</code>’ between ‘<code>X</code>’ and ‘<code>Y</code>’, using the value of
|
||
<code>$match[1]</code> rather than <code>$match[2]</code>.</p>
|
||
<p>If the match fails none of the parameters is altered, so in some
|
||
cases it may be necessary to initialise them beforehand. If some of
|
||
the backreferences fail to match — which happens if they are in an
|
||
alternate branch which fails to match, or if they are followed by
|
||
<code>#</code> and matched zero times — then the matched string is set to the
|
||
empty string, and the start and end indices are set to -1.</p>
|
||
<p>Pattern matching with backreferences is slightly slower than
|
||
without.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>B</code><br />
|
||
Deactivate backreferences, negating the effect of the <code>b</code> flag from
|
||
that point on.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>c``N``,``M</code><br />
|
||
The flag <code>(#c``N``,``M``)</code> can be used anywhere that the <code>#</code> or <code>##</code>
|
||
operators can be used except in the expressions ‘<code>(*/)#</code>’ and
|
||
‘<code>(*/)##</code>’ in filename generation, where ‘<code>/</code>’ has special
|
||
meaning; it cannot be combined with other globbing flags and a bad
|
||
pattern error occurs if it is misplaced. It is equivalent to the
|
||
form <code>{``N``,``M``}</code> in regular expressions. The previous character
|
||
or group is required to match between <code>N</code> and <code>M</code> times, inclusive.
|
||
The form <code>(#c``N``)</code> requires exactly <code>N</code> matches; <code>(#c,``M``)</code> is
|
||
equivalent to specifying <code>N</code> as 0; <code>(#c``N``,)</code> specifies that there
|
||
is no maximum limit on the number of matches.</p>
|
||
<p><span id="index-MATCH"></span> <span id="index-MBEGIN"></span>
|
||
<span id="index-MEND"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>m</code><br />
|
||
Set references to the match data for the entire string matched; this
|
||
is similar to backreferencing and does not work in filename
|
||
generation. The flag must be in effect at the end of the pattern,
|
||
i.e. not local to a group. The parameters <code>$MATCH</code>, <code>$MBEGIN</code> and
|
||
<code>$MEND</code> will be set to the string matched and to the indices of the
|
||
beginning and end of the string, respectively. This is most useful
|
||
in parameter substitutions, as otherwise the string matched is
|
||
obvious.</p>
|
||
<p>For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">arr=(veldt jynx grimps waqf zho buck)
|
||
print ${arr//(#m)[aeiou]/${(U)MATCH}}
|
||
</code></pre>
|
||
</div>
|
||
<p>forces all the matches (i.e. all vowels) into uppercase, printing
|
||
‘<code>vEldt jynx grImps wAqf zhO bUck</code>’.</p>
|
||
<p>Unlike backreferences, there is no speed penalty for using match
|
||
references, other than the extra substitutions required for the
|
||
replacement strings in cases such as the example shown.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>M</code><br />
|
||
Deactivate the <code>m</code> flag, hence no references to match data will be
|
||
created.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>a``num</code><br />
|
||
Approximate matching: <code>num</code> errors are allowed in the string matched
|
||
by the pattern. The rules for this are described in the next
|
||
subsection.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>s</code>, <code>e</code><br />
|
||
Unlike the other flags, these have only a local effect, and each
|
||
must appear on its own: ‘<code>(#s)</code>’ and ‘<code>(#e)</code>’ are the only valid
|
||
forms. The ‘<code>(#s)</code>’ flag succeeds only at the start of the test
|
||
string, and the ‘<code>(#e)</code>’ flag succeeds only at the end of the test
|
||
string; they correspond to ‘<code>^</code>’ and ‘<code>$</code>’ in standard regular
|
||
expressions. They are useful for matching path segments in patterns
|
||
other than those in filename generation (where path segments are in
|
||
any case treated separately). For example,
|
||
‘<code>*((#s)|/)test((#e)|/)*</code>’ matches a path segment ‘<code>test</code>’ in
|
||
any of the following strings: <code>test</code>, <code>test/at/start</code>,
|
||
<code>at/end/test</code>, <code>in/test/middle</code>.</p>
|
||
<p>Another use is in parameter substitution; for example
|
||
‘<code>${array/(#s)A*Z(#e)}</code>’ will remove only elements of an array
|
||
which match the complete pattern ‘<code>A*Z</code>’. There are other ways of
|
||
performing many operations of this type, however the combination of
|
||
the substitution operations ‘<code>/</code>’ and ‘<code>//</code>’ with the ‘<code>(#s)</code>’ and
|
||
‘<code>(#e)</code>’ flags provides a single simple and memorable method.</p>
|
||
<p>Note that assertions of the form ‘<code>(^(#s))</code>’ also work, i.e. match
|
||
anywhere except at the start of the string, although this actually
|
||
means ‘anything except a zero-length portion at the start of the
|
||
string’; you need to use ‘<code>(""~(#s))</code>’ to match a zero-length
|
||
portion of the string not at the start.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>q</code><br />
|
||
A ‘<code>q</code>’ and everything up to the closing parenthesis of the globbing
|
||
flags are ignored by the pattern matching code. This is intended to
|
||
support the use of glob qualifiers, see below. The result is that
|
||
the pattern ‘<code>(#b)(*).c(#q.)</code>’ can be used both for globbing and for
|
||
matching against a string. In the former case, the ‘<code>(#q.)</code>’ will be
|
||
treated as a glob qualifier and the ‘<code>(#b)</code>’ will not be useful,
|
||
while in the latter case the ‘<code>(#b)</code>’ is useful for backreferences
|
||
and the ‘<code>(#q.)</code>’ will be ignored. Note that colon modifiers in the
|
||
glob qualifiers are also not applied in ordinary pattern matching.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>u</code><br />
|
||
Respect the current locale in determining the presence of multibyte
|
||
characters in a pattern, provided the shell was compiled with
|
||
<code>MULTIBYTE_SUPPORT</code>. This overrides the <code>MULTIBYTE</code> option; the
|
||
default behaviour is taken from the option. Compare <code>U</code>. (Mnemonic:
|
||
typically multibyte characters are from Unicode in the UTF-8
|
||
encoding, although any extension of ASCII supported by the system
|
||
library may be used.)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>U</code><br />
|
||
All characters are considered to be a single byte long. The opposite
|
||
of <code>u</code>. This overrides the <code>MULTIBYTE</code> option.</p>
|
||
</li>
|
||
</ul>
|
||
<p>For example, the test string <code>fooxx</code> can be matched by the pattern
|
||
<code>(#i``)FOOXX</code>, but not by <code>(#l``)FOOXX</code>, <code>(#i``)FOO``(#I``)XX</code> or
|
||
<code>((#i``)FOOX``)X</code>. The string <code>(#ia2``)readme</code> specifies
|
||
case-insensitive matching of <code>readme</code> with up to two errors.</p>
|
||
<p>When using the ksh syntax for grouping both <code>KSH_GLOB</code> and
|
||
<code>EXTENDED_GLOB</code> must be set and the left parenthesis should be preceded
|
||
by <code>@</code>. Note also that the flags do not affect letters inside <code>[</code>...<code>]</code>
|
||
groups, in other words <code>(#i``)[a-z]</code> still matches only lowercase
|
||
letters. Finally, note that when examining whole paths
|
||
case-insensitively every directory must be searched for all files which
|
||
match, so that a pattern of the form <code>(#i``)/foo/bar/...</code> is potentially
|
||
slow.</p>
|
||
<hr />
|
||
<p><span id="Approximate-Matching"></span></p>
|
||
<h3 id="1485-approximate-matching"><a class="header" href="#1485-approximate-matching">14.8.5 Approximate Matching</a></h3>
|
||
<p>When matching approximately, the shell keeps a count of the errors
|
||
found, which cannot exceed the number specified in the <code>(#a``num``)</code>
|
||
flags. Four types of error are recognised:</p>
|
||
<ul>
|
||
<li>
|
||
<p>1.<br />
|
||
Different characters, as in <code>fooxbar</code> and <code>fooybar</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p>2.<br />
|
||
Transposition of characters, as in <code>banana</code> and <code>abnana</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p>3.<br />
|
||
A character missing in the target string, as with the pattern <code>road</code>
|
||
and target string <code>rod</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p>4.<br />
|
||
An extra character appearing in the target string, as with <code>stove</code>
|
||
and <code>strove</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<p>Thus, the pattern <code>(#a3``)abcd</code> matches <code>dcba</code>, with the errors
|
||
occurring by using the first rule twice and the second once, grouping
|
||
the string as <code>[d][cb][a]</code> and <code>[a][bc][d]</code>.</p>
|
||
<p>Non-literal parts of the pattern must match exactly, including
|
||
characters in character ranges: hence <code>(#a1``)???</code> matches strings of
|
||
length four, by applying rule 4 to an empty part of the pattern, but not
|
||
strings of length two, since all the <code>?</code> must match. Other characters
|
||
which must match exactly are initial dots in filenames (unless the
|
||
<code>GLOB_DOTS</code> option is set), and all slashes in filenames, so that <code>a/bc</code>
|
||
is two errors from <code>ab/c</code> (the slash cannot be transposed with another
|
||
character). Similarly, errors are counted separately for non-contiguous
|
||
strings in the pattern, so that <code>(ab|cd``)ef</code> is two errors from <code>aebf</code>.</p>
|
||
<p>When using exclusion via the <code>~</code> operator, approximate matching is
|
||
treated entirely separately for the excluded part and must be activated
|
||
separately. Thus, <code>(#a1``)README~READ_ME</code> matches <code>READ.ME</code> but not
|
||
<code>READ_ME</code>, as the trailing <code>READ_ME</code> is matched without approximation.
|
||
However, <code>(#a1``)README~(#a1``)READ_ME</code> does not match any pattern of
|
||
the form <code>READ``?``ME</code> as all such forms are now excluded.</p>
|
||
<p>Apart from exclusions, there is only one overall error count; however,
|
||
the maximum errors allowed may be altered locally, and this can be
|
||
delimited by grouping. For example, <code>(#a1``)cat``((#a0``)dog``)fox</code>
|
||
allows one error in total, which may not occur in the <code>dog</code> section, and
|
||
the pattern <code>(#a1``)cat``(#a0``)dog``(#a1``)fox</code> is equivalent. Note
|
||
that the point at which an error is first found is the crucial one for
|
||
establishing whether to use approximation; for example,
|
||
<code>(#a1)abc(#a0)xyz</code> will not match <code>abcdxyz</code>, because the error occurs at
|
||
the ‘<code>x</code>’, where approximation is turned off.</p>
|
||
<p>Entire path segments may be matched approximately, so that
|
||
‘<code>(#a1)/foo/d/is/available/at/the/bar</code>’ allows one error in any path
|
||
segment. This is much less efficient than without the <code>(#a1)</code>, however,
|
||
since every directory in the path must be scanned for a possible
|
||
approximate match. It is best to place the <code>(#a1)</code> after any path
|
||
segments which are known to be correct.</p>
|
||
<hr />
|
||
<p><span id="Recursive-Globbing"></span></p>
|
||
<h3 id="1486-recursive-globbing"><a class="header" href="#1486-recursive-globbing">14.8.6 Recursive Globbing</a></h3>
|
||
<p>A pathname component of the form ‘<code>(``foo``/)#</code>’ matches a path
|
||
consisting of zero or more directories matching the pattern <code>foo</code>.</p>
|
||
<p>As a shorthand, ‘<code>**/</code>’ is equivalent to ‘<code>(*/)#</code>’; note that this
|
||
therefore matches files in the current directory as well as
|
||
subdirectories. Thus:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">ls -ld -- (*/)#bar
|
||
</code></pre>
|
||
</div>
|
||
<p>or</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">ls -ld -- **/bar
|
||
</code></pre>
|
||
</div>
|
||
<p>does a recursive directory search for files named ‘<code>bar</code>’ (potentially
|
||
including the file ‘<code>bar</code>’ in the current directory). This form does not
|
||
follow symbolic links; the alternative form ‘<code>***/</code>’ does, but is
|
||
otherwise identical. Neither of these can be combined with other forms
|
||
of globbing within the same path segment; in that case, the ‘<code>*</code>’
|
||
operators revert to their usual effect.</p>
|
||
<p>Even shorter forms are available when the option <code>GLOB_STAR_SHORT</code> is
|
||
set. In that case if no <code>/</code> immediately follows a <code>**</code> or <code>***</code> they are
|
||
treated as if both a <code>/</code> plus a further <code>*</code> are present. Hence:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">setopt GLOBSTARSHORT
|
||
ls -ld -- **.c
|
||
</code></pre>
|
||
</div>
|
||
<p>is equivalent to</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">ls -ld -- **/*.c
|
||
</code></pre>
|
||
</div>
|
||
<hr />
|
||
<p><span id="Glob-Qualifiers"></span></p>
|
||
<h3 id="1487-glob-qualifiers"><a class="header" href="#1487-glob-qualifiers">14.8.7 Glob Qualifiers</a></h3>
|
||
<p><span id="index-globbing_002c-qualifiers"></span>
|
||
<span id="index-qualifiers_002c-globbing"></span></p>
|
||
<p>Patterns used for filename generation may end in a list of qualifiers
|
||
enclosed in parentheses. The qualifiers specify which filenames that
|
||
otherwise match the given pattern will be inserted in the argument list.</p>
|
||
<p><span id="index-BARE_005fGLOB_005fQUAL_002c-use-of"></span></p>
|
||
<p>If the option <code>BARE_GLOB_QUAL</code> is set, then a trailing set of
|
||
parentheses containing no ‘<code>|</code>’ or ‘<code>(</code>’ characters (or ‘<code>~</code>’ if it is
|
||
special) is taken as a set of glob qualifiers. A glob subexpression that
|
||
would normally be taken as glob qualifiers, for example ‘<code>(^x)</code>’, can be
|
||
forced to be treated as part of the glob pattern by doubling the
|
||
parentheses, in this case producing ‘<code>((^x))</code>’.</p>
|
||
<p>If the option <code>EXTENDED_GLOB</code> is set, a different syntax for glob
|
||
qualifiers is available, namely ‘<code>(#q``x``)</code>’ where <code>x</code> is any of the
|
||
same glob qualifiers used in the other format. The qualifiers must still
|
||
appear at the end of the pattern. However, with this syntax multiple
|
||
glob qualifiers may be chained together. They are treated as a logical
|
||
AND of the individual sets of flags. Also, as the syntax is unambiguous,
|
||
the expression will be treated as glob qualifiers just as long any
|
||
parentheses contained within it are balanced; appearance of ‘<code>|</code>’, ‘<code>(</code>’
|
||
or ‘<code>~</code>’ does not negate the effect. Note that qualifiers will be
|
||
recognised in this form even if a bare glob qualifier exists at the end
|
||
of files if both options are set; however, mixed syntax should probably
|
||
be avoided for the sake of clarity. Note that within conditions using
|
||
the ‘<code>[[</code>’ form the presence of a parenthesised expression <code>(#q``...``)</code>
|
||
at the end of a string indicates that globbing should be performed; the
|
||
expression may include glob qualifiers, but it is also valid if it is
|
||
simply <code>(#q)</code>. This does not apply to the right hand side of pattern
|
||
match operators as the syntax already has special significance.</p>
|
||
<p>A qualifier may be any one of the following:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>/</code><br />
|
||
directories</p>
|
||
</li>
|
||
<li>
|
||
<p><code>F</code><br />
|
||
‘full’ (i.e. non-empty) directories. Note that the opposite sense
|
||
<code>(^F``)</code> expands to empty directories and all non-directories. Use
|
||
<code>(/^F``)</code> for empty directories.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>.</code><br />
|
||
plain files</p>
|
||
</li>
|
||
<li>
|
||
<p><code>@</code><br />
|
||
symbolic links</p>
|
||
</li>
|
||
<li>
|
||
<p><code>=</code><br />
|
||
sockets</p>
|
||
</li>
|
||
<li>
|
||
<p><code>p</code><br />
|
||
named pipes (FIFOs)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>*</code><br />
|
||
<code>%</code><br />
|
||
device files (character or block special)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%b</code><br />
|
||
block special files</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%c</code><br />
|
||
character special files</p>
|
||
</li>
|
||
<li>
|
||
<p><code>r</code><br />
|
||
owner-readable files (0400)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>w</code><br />
|
||
<code>x</code><br />
|
||
<code>A</code><br />
|
||
group-readable files (0040)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>I</code><br />
|
||
<code>E</code><br />
|
||
<code>R</code><br />
|
||
world-readable files (0004)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>W</code><br />
|
||
<code>X</code><br />
|
||
<code>s</code><br />
|
||
setuid files (04000)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>S</code><br />
|
||
setgid files (02000)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>t</code><br />
|
||
files with the sticky bit (01000)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>f``spec</code><br />
|
||
files with access rights matching <code>spec</code>. This <code>spec</code> may be a octal
|
||
number optionally preceded by a ‘<code>=</code>’, a ‘<code>+</code>’, or a ‘<code>-</code>’. If none
|
||
of these characters is given, the behavior is the same as for ‘<code>=</code>’.
|
||
The octal number describes the mode bits to be expected, if combined
|
||
with a ‘<code>=</code>’, the value given must match the file-modes exactly,
|
||
with a ‘<code>+</code>’, at least the bits in the given number must be set in
|
||
the file-modes, and with a ‘<code>-</code>’, the bits in the number must not be
|
||
set. Giving a ‘<code>?</code>’ instead of a octal digit anywhere in the number
|
||
ensures that the corresponding bits in the file-modes are not
|
||
checked, this is only useful in combination with ‘<code>=</code>’.</p>
|
||
<p>If the qualifier ‘<code>f</code>’ is followed by any other character anything
|
||
up to the next matching character (‘<code>[</code>’, ‘<code>{</code>’, and ‘<code><</code>’ match
|
||
‘<code>]</code>’, ‘<code>}</code>’, and ‘<code>></code>’ respectively, any other character matches
|
||
itself) is taken as a list of comma-separated <code>sub-spec</code>s. Each
|
||
<code>sub-spec</code> may be either an octal number as described above or a
|
||
list of any of the characters ‘<code>u</code>’, ‘<code>g</code>’, ‘<code>o</code>’, and ‘<code>a</code>’,
|
||
followed by a ‘<code>=</code>’, a ‘<code>+</code>’, or a ‘<code>-</code>’, followed by a list of any
|
||
of the characters ‘<code>r</code>’, ‘<code>w</code>’, ‘<code>x</code>’, ‘<code>s</code>’, and ‘<code>t</code>’, or an octal
|
||
digit. The first list of characters specify which access rights are
|
||
to be checked. If a ‘<code>u</code>’ is given, those for the owner of the file
|
||
are used, if a ‘<code>g</code>’ is given, those of the group are checked, a
|
||
‘<code>o</code>’ means to test those of other users, and the ‘<code>a</code>’ says to
|
||
test all three groups. The ‘<code>=</code>’, ‘<code>+</code>’, and ‘<code>-</code>’ again says how
|
||
the modes are to be checked and have the same meaning as described
|
||
for the first form above. The second list of characters finally says
|
||
which access rights are to be expected: ‘<code>r</code>’ for read access, ‘<code>w</code>’
|
||
for write access, ‘<code>x</code>’ for the right to execute the file (or to
|
||
search a directory), ‘<code>s</code>’ for the setuid and setgid bits, and ‘<code>t</code>’
|
||
for the sticky bit.</p>
|
||
<p>Thus, ‘<code>*(f70?)</code>’ gives the files for which the owner has read,
|
||
write, and execute permission, and for which other group members
|
||
have no rights, independent of the permissions for other users. The
|
||
pattern ‘<code>*(f-100)</code>’ gives all files for which the owner does not
|
||
have execute permission, and ‘<code>*(f:gu+w,o-rx:)</code>’ gives the files for
|
||
which the owner and the other members of the group have at least
|
||
write permission, and for which other users don’t have read or
|
||
execute permission.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>e``string</code><br />
|
||
<code>+``cmd</code><br />
|
||
The <code>string</code> will be executed as shell code. The filename will be
|
||
included in the list if and only if the code returns a zero status
|
||
(usually the status of the last command).</p>
|
||
<p>In the first form, the first character after the ‘<code>e</code>’ will be used
|
||
as a separator and anything up to the next matching separator will
|
||
be taken as the <code>string</code>; ‘<code>[</code>’, ‘<code>{</code>’, and ‘<code><</code>’ match ‘<code>]</code>’,
|
||
‘<code>}</code>’, and ‘<code>></code>’, respectively, while any other character
|
||
matches itself. Note that expansions must be quoted in the <code>string</code>
|
||
to prevent them from being expanded before globbing is done.
|
||
<code>string</code> is then executed as shell code. The string <code>globqual</code> is
|
||
appended to the array <code>zsh_eval_context</code> the duration of execution.</p>
|
||
<p><span id="index-REPLY_002c-use-of-1"></span>
|
||
<span id="index-reply_002c-use-of"></span></p>
|
||
<p>During the execution of <code>string</code> the filename currently being tested
|
||
is available in the parameter <code>REPLY</code>; the parameter may be altered
|
||
to a string to be inserted into the list instead of the original
|
||
filename. In addition, the parameter <code>reply</code> may be set to an array
|
||
or a string, which overrides the value of <code>REPLY</code>. If set to an
|
||
array, the latter is inserted into the command line word by word.</p>
|
||
<p>For example, suppose a directory contains a single file ‘<code>lonely</code>’.
|
||
Then the expression ‘<code>*(e:’reply=(${REPLY}{1,2})’:)</code>’ will cause the
|
||
words ‘<code>lonely1</code>’ and ‘<code>lonely2</code>’ to be inserted into the command
|
||
line. Note the quoting of <code>string</code>.</p>
|
||
<p>The form <code>+``cmd</code> has the same effect, but no delimiters appear
|
||
around <code>cmd</code>. Instead, <code>cmd</code> is taken as the longest sequence of
|
||
characters following the <code>+</code> that are alphanumeric or underscore.
|
||
Typically <code>cmd</code> will be the name of a shell function that contains
|
||
the appropriate test. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">nt() { [[ $REPLY -nt $NTREF ]] }
|
||
NTREF=reffile
|
||
ls -ld -- *(+nt)
|
||
</code></pre>
|
||
</div>
|
||
<p>lists all files in the directory that have been modified more
|
||
recently than <code>reffile</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>d``dev</code><br />
|
||
files on the device <code>dev</code></p>
|
||
</li>
|
||
<li>
|
||
<p><code>l</code>[<code>-</code>|<code>+</code>]<code>ct</code><br />
|
||
files having a link count less than <code>ct</code> (<code>-</code>), greater than <code>ct</code>
|
||
(<code>+</code>), or equal to <code>ct</code></p>
|
||
</li>
|
||
<li>
|
||
<p><code>U</code><br />
|
||
files owned by the effective user ID</p>
|
||
</li>
|
||
<li>
|
||
<p><code>G</code><br />
|
||
files owned by the effective group ID</p>
|
||
</li>
|
||
<li>
|
||
<p><code>u``id</code><br />
|
||
files owned by user ID <code>id</code> if that is a number. Otherwise, <code>id</code>
|
||
specifies a user name: the character after the ‘<code>u</code>’ will be taken
|
||
as a separator and the string between it and the next matching
|
||
separator will be taken as a user name. The starting separators
|
||
‘<code>[</code>’, ‘<code>{</code>’, and ‘<code><</code>’ match the final separators ‘<code>]</code>’, ‘<code>}</code>’,
|
||
and ‘<code>></code>’, respectively; any other character matches itself. The
|
||
selected files are those owned by this user. For example, ‘<code>u:foo:</code>’
|
||
or ‘<code>u[foo]</code>’ selects files owned by user ‘<code>foo</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>g``id</code><br />
|
||
like <code>u``id</code> but with group IDs or names</p>
|
||
</li>
|
||
<li>
|
||
<p><code>a</code>[<code>Mwhms</code>][<code>-</code>|<code>+</code>]<code>n</code><br />
|
||
files accessed exactly <code>n</code> days ago. Files accessed within the last
|
||
<code>n</code> days are selected using a negative value for <code>n</code> (<code>-``n</code>). Files
|
||
accessed more than <code>n</code> days ago are selected by a positive <code>n</code> value
|
||
(<code>+``n</code>). Optional unit specifiers ‘<code>M</code>’, ‘<code>w</code>’, ‘<code>h</code>’, ‘<code>m</code>’ or
|
||
‘<code>s</code>’ (e.g. ‘<code>ah5</code>’) cause the check to be performed with months
|
||
(of 30 days), weeks, hours, minutes or seconds instead of days,
|
||
respectively. An explicit ‘<code>d</code>’ for days is also allowed.</p>
|
||
<p>Any fractional part of the difference between the access time and
|
||
the current part in the appropriate units is ignored in the
|
||
comparison. For instance, ‘<code>echo *(ah-5)</code>’ would echo files accessed
|
||
within the last five hours, while ‘<code>echo *(ah+5)</code>’ would echo files
|
||
accessed at least six hours ago, as times strictly between five and
|
||
six hours are treated as five hours.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>m</code>[<code>Mwhms</code>][<code>-</code>|<code>+</code>]<code>n</code><br />
|
||
like the file access qualifier, except that it uses the file
|
||
modification time.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>c</code>[<code>Mwhms</code>][<code>-</code>|<code>+</code>]<code>n</code><br />
|
||
like the file access qualifier, except that it uses the file inode
|
||
change time.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>L</code>[<code>+</code>|<code>-</code>]<code>n</code><br />
|
||
files less than <code>n</code> bytes (<code>-</code>), more than <code>n</code> bytes (<code>+</code>), or
|
||
exactly <code>n</code> bytes in length.</p>
|
||
<p>If this flag is directly followed by a <em>size specifier</em> ‘<code>k</code>’
|
||
(‘<code>K</code>’), ‘<code>m</code>’ (‘<code>M</code>’), or ‘<code>p</code>’ (‘<code>P</code>’) (e.g. ‘<code>Lk-50</code>’) the
|
||
check is performed with kilobytes, megabytes, or blocks (of 512
|
||
bytes) instead. (On some systems additional specifiers are available
|
||
for gigabytes, ‘<code>g</code>’ or ‘<code>G</code>’, and terabytes, ‘<code>t</code>’ or ‘<code>T</code>’.) If a
|
||
size specifier is used a file is regarded as "exactly" the size if
|
||
the file size rounded up to the next unit is equal to the test size.
|
||
Hence ‘<code>*(Lm1)</code>’ matches files from 1 byte up to 1 Megabyte
|
||
inclusive. Note also that the set of files "less than" the test size
|
||
only includes files that would not match the equality test; hence
|
||
‘<code>*(Lm-1)</code>’ only matches files of zero size.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>^</code><br />
|
||
negates all qualifiers following it</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-</code><br />
|
||
toggles between making the qualifiers work on symbolic links (the
|
||
default) and the files they point to</p>
|
||
</li>
|
||
<li>
|
||
<p><code>M</code><br />
|
||
sets the <code>MARK_DIRS</code> option for the current pattern
|
||
<span id="index-MARK_005fDIRS_002c-setting-in-pattern"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>T</code><br />
|
||
appends a trailing qualifier mark to the filenames, analogous to the
|
||
<code>LIST_TYPES</code> option, for the current pattern (overrides <code>M</code>)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>N</code><br />
|
||
sets the <code>NULL_GLOB</code> option for the current pattern
|
||
<span id="index-NULL_005fGLOB_002c-setting-in-pattern"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>D</code><br />
|
||
sets the <code>GLOB_DOTS</code> option for the current pattern
|
||
<span id="index-GLOB_005fDOTS_002c-setting-in-pattern"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>n</code><br />
|
||
sets the <code>NUMERIC_GLOB_SORT</code> option for the current pattern
|
||
<span id="index-NUMERIC_005fGLOB_005fSORT_002c-setting-in-pattern"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>Y``n</code><br />
|
||
enables short-circuit mode: the pattern will expand to at most <code>n</code>
|
||
filenames. If more than <code>n</code> matches exist, only the first <code>n</code>
|
||
matches in directory traversal order will be considered.</p>
|
||
<p>Implies <code>oN</code> when no <code>o``c</code> qualifier is used.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>o``c</code><br />
|
||
specifies how the names of the files should be sorted. If <code>c</code> is <code>n</code>
|
||
they are sorted by name; if it is <code>L</code> they are sorted depending on
|
||
the size (length) of the files; if <code>l</code> they are sorted by the number
|
||
of links; if <code>a</code>, <code>m</code>, or <code>c</code> they are sorted by the time of the
|
||
last access, modification, or inode change respectively; if <code>d</code>,
|
||
files in subdirectories appear before those in the current directory
|
||
at each level of the search — this is best combined with other
|
||
criteria, for example ‘<code>odon</code>’ to sort on names for files within the
|
||
same directory; if <code>N</code>, no sorting is performed. Note that <code>a</code>, <code>m</code>,
|
||
and <code>c</code> compare the age against the current time, hence the first
|
||
name in the list is the youngest file. Also note that the modifiers
|
||
<code>^</code> and <code>-</code> are used, so ‘<code>*(^-oL)</code>’ gives a list of all files
|
||
sorted by file size in descending order, following any symbolic
|
||
links. Unless <code>oN</code> is used, multiple order specifiers may occur to
|
||
resolve ties.</p>
|
||
<p>The default sorting is <code>n</code> (by name) unless the <code>Y</code> glob qualifier
|
||
is used, in which case it is <code>N</code> (unsorted).</p>
|
||
<p><code>oe</code> and <code>o+</code> are special cases; they are each followed by shell
|
||
code, delimited as for the <code>e</code> glob qualifier and the <code>+</code> glob
|
||
qualifier respectively (see above). The code is executed for each
|
||
matched file with the parameter <code>REPLY</code> set to the name of the file
|
||
on entry and <code>globsort</code> appended to <code>zsh_eval_context</code>. The code
|
||
should modify the parameter <code>REPLY</code> in some fashion. On return, the
|
||
value of the parameter is used instead of the file name as the
|
||
string on which to sort. Unlike other sort operators, <code>oe</code> and <code>o+</code>
|
||
may be repeated, but note that the maximum number of sort operators
|
||
of any kind that may appear in any glob expression is 12.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>O``c</code><br />
|
||
like ‘<code>o</code>’, but sorts in descending order; i.e. ‘<code>*(^oc)</code>’ is the
|
||
same as ‘<code>*(Oc)</code>’ and ‘<code>*(^Oc)</code>’ is the same as ‘<code>*(oc)</code>’; ‘<code>Od</code>’
|
||
puts files in the current directory before those in subdirectories
|
||
at each level of the search.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>[``beg</code>[<code>,``end</code>]<code>]</code><br />
|
||
specifies which of the matched filenames should be included in the
|
||
returned list. The syntax is the same as for array subscripts. <code>beg</code>
|
||
and the optional <code>end</code> may be mathematical expressions. As in
|
||
parameter subscripting they may be negative to make them count from
|
||
the last match backward. E.g.: ‘<code>*(-OL[1,3])</code>’ gives a list of the
|
||
names of the three largest files.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>P``string</code><br />
|
||
The <code>string</code> will be prepended to each glob match as a separate
|
||
word. <code>string</code> is delimited in the same way as arguments to the <code>e</code>
|
||
glob qualifier described above. The qualifier can be repeated; the
|
||
words are prepended separately so that the resulting command line
|
||
contains the words in the same order they were given in the list of
|
||
glob qualifiers.</p>
|
||
<p>A typical use for this is to prepend an option before all
|
||
occurrences of a file name; for example, the pattern ‘<code>*(P:-f:)</code>’
|
||
produces the command line arguments ‘<code>-f</code> <code>file1</code> <code>-f</code> <code>file2</code> ...’</p>
|
||
<p>If the modifier <code>^</code> is active, then <code>string</code> will be appended
|
||
instead of prepended. Prepending and appending is done independently
|
||
so both can be used on the same glob expression; for example by
|
||
writing ‘<code>*(P:foo:^P:bar:^P:baz:)</code>’ which produces the command line
|
||
arguments ‘<code>foo</code> <code>baz</code> <code>file1</code> <code>bar</code> ...’</p>
|
||
</li>
|
||
</ul>
|
||
<p>More than one of these lists can be combined, separated by commas. The
|
||
whole list matches if at least one of the sublists matches (they are
|
||
‘or’ed, the qualifiers in the sublists are ‘and’ed). Some
|
||
qualifiers, however, affect all matches generated, independent of the
|
||
sublist in which they are given. These are the qualifiers ‘<code>M</code>’, ‘<code>T</code>’,
|
||
‘<code>N</code>’, ‘<code>D</code>’, ‘<code>n</code>’, ‘<code>o</code>’, ‘<code>O</code>’ and the subscripts given in brackets
|
||
(‘<code>[``...``]</code>’).</p>
|
||
<p>If a ‘<code>:</code>’ appears in a qualifier list, the remainder of the expression
|
||
in parenthesis is interpreted as a modifier (see <a href="Expansion.html#Modifiers">Modifiers</a>
|
||
in <a href="Expansion.html#History-Expansion">History Expansion</a>). Each modifier must be
|
||
introduced by a separate ‘<code>:</code>’. Note also that the result after
|
||
modification does not have to be an existing file. The name of any
|
||
existing file can be followed by a modifier of the form ‘<code>(:``...``)</code>’
|
||
even if no actual filename generation is performed, although note that
|
||
the presence of the parentheses causes the entire expression to be
|
||
subjected to any global pattern matching options such as <code>NULL_GLOB</code>.
|
||
Thus:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">ls -ld -- *(-/)
|
||
</code></pre>
|
||
</div>
|
||
<p>lists all directories and symbolic links that point to directories, and</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">ls -ld -- *(-@)
|
||
</code></pre>
|
||
</div>
|
||
<p>lists all broken symbolic links, and</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">ls -ld -- *(%W)
|
||
</code></pre>
|
||
</div>
|
||
<div class="example">
|
||
<pre><code class="language-example">ls -ld -- *(W,X)
|
||
</code></pre>
|
||
</div>
|
||
<p>lists all files in the current directory that are</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">print -rC1 /tmp/foo*(u0^@:t)
|
||
</code></pre>
|
||
</div>
|
||
<p>outputs the basename of all root-owned files beginning with the string
|
||
‘<code>foo</code>’ in <code>/tmp</code>, ignoring symlinks, and</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">ls -ld -- *.*~(lex|parse).[ch](^D^l1)
|
||
</code></pre>
|
||
</div>
|
||
<p>lists all files having a link count of one whose names contain a dot
|
||
(but not those starting with a dot, since <code>GLOB_DOTS</code> is explicitly
|
||
switched off) except for <code>lex.c</code>, <code>lex.h</code>, <code>parse.c</code> and <code>parse.h</code>.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">print -rC1 b*.pro(#q:s/pro/shmo/)(#q.:s/builtin/shmiltin/)
|
||
</code></pre>
|
||
</div>
|
||
<p>demonstrates how colon modifiers and other qualifiers may be chained
|
||
together. The ordinary qualifier ‘<code>.</code>’ is applied first, then the colon
|
||
modifiers in order from left to right. So if <code>EXTENDED_GLOB</code> is set and
|
||
the base pattern matches the regular file <code>builtin.pro</code>, the shell will
|
||
print ‘<code>shmiltin.shmo</code>’.</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>
|
||
<!-- 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="Parameters.html#15-parameters">15 Parameters</a>
|
||
<ul>
|
||
<li><a href="Parameters.html#151-description">15.1 Description</a></li>
|
||
<li><a href="Parameters.html#152-array-parameters">15.2 Array Parameters</a>
|
||
<ul>
|
||
<li><a href="Parameters.html#1521-array-subscripts">15.2.1 Array Subscripts</a></li>
|
||
<li><a href="Parameters.html#1522-array-element-assignment">15.2.2 Array Element Assignment</a></li>
|
||
<li><a href="Parameters.html#1523-subscript-flags">15.2.3 Subscript Flags</a></li>
|
||
<li><a href="Parameters.html#1524-subscript-parsing">15.2.4 Subscript Parsing</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Parameters.html#153-positional-parameters">15.3 Positional Parameters</a></li>
|
||
<li><a href="Parameters.html#154-local-parameters">15.4 Local Parameters</a></li>
|
||
<li><a href="Parameters.html#155-parameters-set-by-the-shell">15.5 Parameters Set By The Shell</a></li>
|
||
<li><a href="Parameters.html#156-parameters-used-by-the-shell">15.6 Parameters Used By The Shell</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Parameters"></span> <span id="Parameters-1"></span></p>
|
||
<h1 id="15-parameters"><a class="header" href="#15-parameters">15 Parameters</a></h1>
|
||
<p><span id="index-parameters"></span> <span id="index-variables"></span></p>
|
||
<hr />
|
||
<p><span id="Description-5"></span></p>
|
||
<h2 id="151-description"><a class="header" href="#151-description">15.1 Description</a></h2>
|
||
<p>A parameter has a name, a value, and a number of attributes. A name may
|
||
be any sequence of alphanumeric characters and underscores, or the
|
||
single characters ‘<code>*</code>’, ‘<code>@</code>’, ‘<code>#</code>’, ‘<code>?</code>’, ‘<code>-</code>’, ‘<code>$</code>’, or ‘<code>!</code>’. A
|
||
parameter whose name begins with an alphanumeric or underscore is also
|
||
referred to as a <em>variable</em>.</p>
|
||
<p><span id="index-scalar"></span>
|
||
<span id="index-parameters_002c-scalar"></span>
|
||
<span id="index-parameters_002c-array"></span>
|
||
<span id="index-parameters_002c-associative-array"></span>
|
||
<span id="index-hash"></span></p>
|
||
<p>The attributes of a parameter determine the <em>type</em> of its value, often
|
||
referred to as the parameter type or variable type, and also control
|
||
other processing that may be applied to the value when it is referenced.
|
||
The value type may be a <em>scalar</em> (a string, an integer, or a floating
|
||
point number), an array (indexed numerically), or an <em>associative</em> array
|
||
(an unordered set of name-value pairs, indexed by name, also referred to
|
||
as a <em>hash</em>).</p>
|
||
<p><span id="index-export"></span> <span id="index-environment"></span>
|
||
<span id="index-environment-variables"></span>
|
||
<span id="index-variables_002c-environment"></span></p>
|
||
<p>Named scalar parameters may have the <em>exported</em>, <code>-x</code>, attribute, to
|
||
copy them into the process environment, which is then passed from the
|
||
shell to any new processes that it starts. Exported parameters are
|
||
called <em>environment variables</em>. The shell also <em>imports</em> environment
|
||
variables at startup time and automatically marks the corresponding
|
||
parameters as exported. Some environment variables are not imported for
|
||
reasons of security or because they would interfere with the correct
|
||
operation of other shell features.</p>
|
||
<p><span id="index-special-parameters"></span>
|
||
<span id="index-parameters_002c-special"></span></p>
|
||
<p>Parameters may also be <em>special</em>, that is, they have a predetermined
|
||
meaning to the shell. Special parameters cannot have their type changed
|
||
or their readonly attribute turned off, and if a special parameter is
|
||
unset, then later recreated, the special properties will be retained.</p>
|
||
<p>To declare the type of a parameter, or to assign a string or numeric
|
||
value to a scalar parameter, use the <code>typeset</code> builtin.
|
||
<span id="index-typeset_002c-use-of"></span></p>
|
||
<p>The value of a scalar parameter may also be assigned by writing:
|
||
<span id="index-assignment"></span></p>
|
||
<blockquote>
|
||
<p><code>name``=``value</code></p>
|
||
</blockquote>
|
||
<p>In scalar assignment, <code>value</code> is expanded as a single string, in which
|
||
the elements of arrays are joined together; filename expansion is not
|
||
performed unless the option <code>GLOB_ASSIGN</code> is set.</p>
|
||
<p>When the integer attribute, <code>-i</code>, or a floating point attribute, <code>-E</code> or
|
||
<code>-F</code>, is set for <code>name</code>, the <code>value</code> is subject to arithmetic
|
||
evaluation. Furthermore, by replacing ‘<code>=</code>’ with ‘<code>+=</code>’, a parameter can
|
||
be incremented or appended to. See <a href="Parameters.html#Array-Parameters">Array Parameters</a>
|
||
and <a href="Arithmetic-Evaluation.html#Arithmetic-Evaluation">Arithmetic
|
||
Evaluation</a> for
|
||
additional forms of assignment.</p>
|
||
<p>Note that assignment may implicitly change the attributes of a
|
||
parameter. For example, assigning a number to a variable in arithmetic
|
||
evaluation may change its type to integer or float, and with
|
||
<code>GLOB_ASSIGN</code> assigning a pattern to a variable may change its type to
|
||
an array.</p>
|
||
<p>To reference the value of a parameter, write ‘<code>$``name</code>’ or
|
||
‘<code>${``name``}</code>’. See <a href="Expansion.html#Parameter-Expansion">Parameter
|
||
Expansion</a> for complete details.
|
||
That section also explains the effect of the difference between scalar
|
||
and array assignment on parameter expansion.</p>
|
||
<hr />
|
||
<p><span id="Array-Parameters"></span>
|
||
<span id="Array-Parameters-1"></span></p>
|
||
<h2 id="152-array-parameters"><a class="header" href="#152-array-parameters">15.2 Array Parameters</a></h2>
|
||
<p>To assign an array value, write one of:
|
||
<span id="index-set_002c-use-of"></span>
|
||
<span id="index-array-assignment"></span></p>
|
||
<blockquote>
|
||
<p><code>set -A</code> <code>name</code> <code>value</code> ...</p>
|
||
</blockquote>
|
||
<blockquote>
|
||
<p><code>name``=(``value</code> ...<code>)</code></p>
|
||
</blockquote>
|
||
<blockquote>
|
||
<p><code>name``=(``[``key``]=``value</code> ...<code>)</code></p>
|
||
</blockquote>
|
||
<p>If no parameter <code>name</code> exists, an ordinary array parameter is created.
|
||
If the parameter <code>name</code> exists and is a scalar, it is replaced by a new
|
||
array.</p>
|
||
<p>In the third form, <code>key</code> is an expression that will be evaluated in
|
||
arithmetic context (in its simplest form, an integer) that gives the
|
||
index of the element to be assigned with <code>value</code>. In this form any
|
||
elements not explicitly mentioned that come before the largest index to
|
||
which a value is assigned are assigned an empty string. The indices may
|
||
be in any order. Note that this syntax is strict: <code>[</code> and <code>]=</code> must not
|
||
be quoted, and <code>key</code> may not consist of the unquoted string <code>]=</code>, but is
|
||
otherwise treated as a simple string. The enhanced forms of subscript
|
||
expression that may be used when directly subscripting a variable name,
|
||
described in the section Array Subscripts below, are not available.</p>
|
||
<p>The syntaxes with and without the explicit key may be mixed. An implicit
|
||
<code>key</code> is deduced by incrementing the index from the previously assigned
|
||
element. Note that it is not treated as an error if latter assignments
|
||
in this form overwrite earlier assignments.</p>
|
||
<p>For example, assuming the option <code>KSH_ARRAYS</code> is not set, the following:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">array=(one [3]=three four)
|
||
</code></pre>
|
||
</div>
|
||
<p>causes the array variable <code>array</code> to contain four elements <code>one</code>, an
|
||
empty string, <code>three</code> and <code>four</code>, in that order.</p>
|
||
<p>In the forms where only <code>value</code> is specified, full command line
|
||
expansion is performed.</p>
|
||
<p>In the <code>[``key``]=``value</code> form, both <code>key</code> and <code>value</code> undergo all
|
||
forms of expansion allowed for single word shell expansions (this does
|
||
not include filename generation); these are as performed by the
|
||
parameter expansion flag <code>(e)</code> as described in <a href="Expansion.html#Parameter-Expansion">Parameter
|
||
Expansion</a>. Nested parentheses may
|
||
surround <code>value</code> and are included as part of the value, which is joined
|
||
into a plain string; this differs from ksh which allows the values
|
||
themselves to be arrays. A future version of zsh may support that. To
|
||
cause the brackets to be interpreted as a character class for filename
|
||
generation, and therefore to treat the resulting list of files as a set
|
||
of values, quote the equal sign using any form of quoting. Example:</p>
|
||
<blockquote>
|
||
<p><code>name``=(``[a-z]’=’*)</code></p>
|
||
</blockquote>
|
||
<p>To append to an array without changing the existing values, use one of
|
||
the following:</p>
|
||
<blockquote>
|
||
<p><code>name``+=(``value</code> ...<code>)</code></p>
|
||
</blockquote>
|
||
<blockquote>
|
||
<p><code>name``+=(``[``key``]=``value</code> ...<code>)</code></p>
|
||
</blockquote>
|
||
<p>In the second form <code>key</code> may specify an existing index as well as an
|
||
index off the end of the old array; any existing value is overwritten by
|
||
<code>value</code>. Also, it is possible to use <code>[``key``]+=``value</code> to append to
|
||
the existing value at that index.</p>
|
||
<p>Within the parentheses on the right hand side of either form of the
|
||
assignment, newlines and semicolons are treated the same as white space,
|
||
separating individual <code>value</code>s. Any consecutive sequence of such
|
||
characters has the same effect.</p>
|
||
<p>Ordinary array parameters may also be explicitly declared with:
|
||
<span id="index-typeset_002c-use-of-1"></span></p>
|
||
<blockquote>
|
||
<p><code>typeset -a</code> <code>name</code></p>
|
||
</blockquote>
|
||
<p>Associative arrays <em>must</em> be declared before assignment, by using:</p>
|
||
<blockquote>
|
||
<p><code>typeset -A</code> <code>name</code></p>
|
||
</blockquote>
|
||
<p>When <code>name</code> refers to an associative array, the list in an assignment is
|
||
interpreted as alternating keys and values:</p>
|
||
<blockquote>
|
||
<p><code>set -A</code> <code>name</code> <code>key</code> <code>value</code> ...</p>
|
||
</blockquote>
|
||
<blockquote>
|
||
<p><code>name``=(``key</code> <code>value</code> ...<code>)</code></p>
|
||
</blockquote>
|
||
<blockquote>
|
||
<p><code>name``=(``[``key``]=``value</code> ...<code>)</code></p>
|
||
</blockquote>
|
||
<p>Note that only one of the two syntaxes above may be used in any given
|
||
assignment; the forms may not be mixed. This is unlike the case of
|
||
numerically indexed arrays.</p>
|
||
<p>Every <code>key</code> must have a <code>value</code> in this case. Note that this assigns to
|
||
the entire array, deleting any elements that do not appear in the list.
|
||
The append syntax may also be used with an associative array:</p>
|
||
<blockquote>
|
||
<p><code>name``+=(``key</code> <code>value</code> ...<code>)</code></p>
|
||
</blockquote>
|
||
<blockquote>
|
||
<p><code>name``+=(``[``key``]=``value</code> ...<code>)</code></p>
|
||
</blockquote>
|
||
<p>This adds a new key/value pair if the key is not already present, and
|
||
replaces the value for the existing key if it is. In the second form it
|
||
is also possible to use <code>[``key``]+=``value</code> to append to the existing
|
||
value at that key. Expansion is performed identically to the
|
||
corresponding forms for normal arrays, as described above.</p>
|
||
<p>To create an empty array (including associative arrays), use one of:</p>
|
||
<blockquote>
|
||
<p><code>set -A</code> <code>name</code></p>
|
||
</blockquote>
|
||
<blockquote>
|
||
<p><code>name``=()</code></p>
|
||
</blockquote>
|
||
<hr />
|
||
<p><span id="Array-Subscripts"></span></p>
|
||
<h3 id="1521-array-subscripts"><a class="header" href="#1521-array-subscripts">15.2.1 Array Subscripts</a></h3>
|
||
<p><span id="index-subscripts"></span></p>
|
||
<p>Individual elements of an array may be selected using a subscript. A
|
||
subscript of the form ‘<code>[``exp``]</code>’ selects the single element <code>exp</code>,
|
||
where <code>exp</code> is an arithmetic expression which will be subject to
|
||
arithmetic expansion as if it were surrounded by ‘<code>$((</code>...<code>))</code>’. The
|
||
elements are numbered beginning with 1, unless the <code>KSH_ARRAYS</code> option
|
||
is set in which case they are numbered from zero.
|
||
<span id="index-KSH_005fARRAYS_002c-use-of"></span></p>
|
||
<p>Subscripts may be used inside braces used to delimit a parameter name,
|
||
thus ‘<code>${foo[2]}</code>’ is equivalent to ‘<code>$foo[2]</code>’. If the <code>KSH_ARRAYS</code>
|
||
option is set, the braced form is the only one that works, as bracketed
|
||
expressions otherwise are not treated as subscripts.</p>
|
||
<p>If the <code>KSH_ARRAYS</code> option is not set, then by default accesses to an
|
||
array element with a subscript that evaluates to zero return an empty
|
||
string, while an attempt to write such an element is treated as an
|
||
error. For backward compatibility the <code>KSH_ZERO_SUBSCRIPT</code> option can be
|
||
set to cause subscript values 0 and 1 to be equivalent; see the
|
||
description of the option in <a href="Options.html#Description-of-Options">Description of
|
||
Options</a>.</p>
|
||
<p>The same subscripting syntax is used for associative arrays, except that
|
||
no arithmetic expansion is applied to <code>exp</code>. However, the parsing rules
|
||
for arithmetic expressions still apply, which affects the way that
|
||
certain special characters must be protected from interpretation. See
|
||
<em>Subscript Parsing</em> below for details.</p>
|
||
<p>A subscript of the form ‘<code>[*]</code>’ or ‘<code>[@]</code>’ evaluates to all elements of
|
||
an array; there is no difference between the two except when they appear
|
||
within double quotes. ‘<code>"$foo[*]"</code>’ evaluates to ‘<code>"$foo[1] $foo[2]
|
||
</code>...<code>"</code>’, whereas ‘<code>"$foo[@]"</code>’ evaluates to ‘<code>"$foo[1]" "$foo[2]"
|
||
</code>...’. For associative arrays, ‘<code>[*]</code>’ or ‘<code>[@]</code>’ evaluate to all the
|
||
values, in no particular order. Note that this does not substitute the
|
||
keys; see the documentation for the ‘<code>k</code>’ flag under <a href="Expansion.html#Parameter-Expansion">Parameter
|
||
Expansion</a> for complete details.
|
||
When an array parameter is referenced as ‘<code>$``name</code>’ (with no subscript)
|
||
it evaluates to ‘<code>$``name``[*]</code>’, unless the <code>KSH_ARRAYS</code> option is set
|
||
in which case it evaluates to ‘<code>${``name``[0]}</code>’ (for an associative
|
||
array, this means the value of the key ‘<code>0</code>’, which may not exist even
|
||
if there are values for other keys).</p>
|
||
<p>A subscript of the form ‘<code>[``exp1``,``exp2``]</code>’ selects all elements in
|
||
the range <code>exp1</code> to <code>exp2</code>, inclusive. (Associative arrays are
|
||
unordered, and so do not support ranges.) If one of the subscripts
|
||
evaluates to a negative number, say <code>-``n</code>, then the <code>n</code>th element from
|
||
the end of the array is used. Thus ‘<code>$foo[-3]</code>’ is the third element
|
||
from the end of the array <code>foo</code>, and ‘<code>$foo[1,-1]</code>’ is the same as
|
||
‘<code>$foo[*]</code>’.</p>
|
||
<p>Subscripting may also be performed on non-array values, in which case
|
||
the subscripts specify a substring to be extracted. For example, if
|
||
<code>FOO</code> is set to ‘<code>foobar</code>’, then ‘<code>echo $FOO[2,5]</code>’ prints ‘<code>ooba</code>’.
|
||
Note that some forms of subscripting described below perform pattern
|
||
matching, and in that case the substring extends from the start of the
|
||
match of the first subscript to the end of the match of the second
|
||
subscript. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">string="abcdefghijklm"
|
||
print ${string[(r)d?,(r)h?]}
|
||
</code></pre>
|
||
</div>
|
||
<p>prints ‘<code>defghi</code>’. This is an obvious generalisation of the rule for
|
||
single-character matches. For a single subscript, only a single
|
||
character is referenced (not the range of characters covered by the
|
||
match).</p>
|
||
<p>Note that in substring operations the second subscript is handled
|
||
differently by the <code>r</code> and <code>R</code> subscript flags: the former takes the
|
||
shortest match as the length and the latter the longest match. Hence in
|
||
the former case a <code>*</code> at the end is redundant while in the latter case
|
||
it matches the whole remainder of the string. This does not affect the
|
||
result of the single subscript case as here the length of the match is
|
||
irrelevant.</p>
|
||
<hr />
|
||
<p><span id="Array-Element-Assignment"></span></p>
|
||
<h3 id="1522-array-element-assignment"><a class="header" href="#1522-array-element-assignment">15.2.2 Array Element Assignment</a></h3>
|
||
<p>A subscript may be used on the left side of an assignment like so:</p>
|
||
<blockquote>
|
||
<p><code>name``[``exp``]=``value</code></p>
|
||
</blockquote>
|
||
<p>In this form of assignment the element or range specified by <code>exp</code> is
|
||
replaced by the expression on the right side. An array (but not an
|
||
associative array) may be created by assignment to a range or element.
|
||
Arrays do not nest, so assigning a parenthesized list of values to an
|
||
element or range changes the number of elements in the array, shifting
|
||
the other elements to accommodate the new values. (This is not supported
|
||
for associative arrays.)</p>
|
||
<p>This syntax also works as an argument to the <code>typeset</code> command:</p>
|
||
<blockquote>
|
||
<p><code>typeset</code> <code>"``name``[``exp``]"=``value</code></p>
|
||
</blockquote>
|
||
<p>The <code>value</code> may <em>not</em> be a parenthesized list in this case; only
|
||
single-element assignments may be made with <code>typeset</code>. Note that quotes
|
||
are necessary in this case to prevent the brackets from being
|
||
interpreted as filename generation operators. The <code>noglob</code> precommand
|
||
modifier could be used instead.</p>
|
||
<p>To delete an element of an ordinary array, assign ‘<code>()</code>’ to that
|
||
element. To delete an element of an associative array, use the <code>unset</code>
|
||
command:</p>
|
||
<blockquote>
|
||
<p><code>unset</code> <code>"``name``[``exp``]"</code></p>
|
||
</blockquote>
|
||
<hr />
|
||
<p><span id="Subscript-Flags"></span></p>
|
||
<h3 id="1523-subscript-flags"><a class="header" href="#1523-subscript-flags">15.2.3 Subscript Flags</a></h3>
|
||
<p><span id="index-subscript-flags"></span></p>
|
||
<p>If the opening bracket, or the comma in a range, in any subscript
|
||
expression is directly followed by an opening parenthesis, the string up
|
||
to the matching closing one is considered to be a list of flags, as in
|
||
‘<code>name``[(``flags``)``exp``]</code>’.</p>
|
||
<p>The flags <code>s</code>, <code>n</code> and <code>b</code> take an argument; the delimiter is shown
|
||
below as ‘<code>:</code>’, but any character, or the matching pairs ‘<code>(</code>...<code>)</code>’,
|
||
‘<code>{</code>...<code>}</code>’, ‘<code>[</code>...<code>]</code>’, or ‘<code><</code>...<code>></code>’, may be used, but note that
|
||
‘<code><</code>...<code>></code>’ can only be used if the subscript is inside a double
|
||
quoted expression or a parameter substitution enclosed in braces as
|
||
otherwise the expression is interpreted as a redirection.</p>
|
||
<p>The flags currently understood are:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>w</code><br />
|
||
If the parameter subscripted is a scalar then this flag makes
|
||
subscripting work on words instead of characters. The default word
|
||
separator is whitespace. When combined with the <code>i</code> or <code>I</code> flag, the
|
||
effect is to produce the index of the first character of the
|
||
first/last word which matches the given pattern; note that a failed
|
||
match in this case always yields 0.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>s:``string``:</code><br />
|
||
This gives the <code>string</code> that separates words (for use with the <code>w</code>
|
||
flag). The delimiter character <code>:</code> is arbitrary; see above.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>p</code><br />
|
||
Recognize the same escape sequences as the <code>print</code> builtin in the
|
||
string argument of a subsequent ‘<code>s</code>’ flag.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>f</code><br />
|
||
If the parameter subscripted is a scalar then this flag makes
|
||
subscripting work on lines instead of characters, i.e. with elements
|
||
separated by newlines. This is a shorthand for ‘<code>pws:\n:</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>r</code><br />
|
||
Reverse subscripting: if this flag is given, the <code>exp</code> is taken as a
|
||
pattern and the result is the first matching array element,
|
||
substring or word (if the parameter is an array, if it is a scalar,
|
||
or if it is a scalar and the ‘<code>w</code>’ flag is given, respectively). The
|
||
subscript used is the number of the matching element, so that pairs
|
||
of subscripts such as ‘<code>$foo[(r)??,3]</code>’ and ‘<code>$foo[(r)??,(r)f*]</code>’
|
||
are possible if the parameter is not an associative array. If the
|
||
parameter is an associative array, only the value part of each pair
|
||
is compared to the pattern, and the result is that value.</p>
|
||
<p>If a search through an ordinary array failed, the search sets the
|
||
subscript to one past the end of the array, and hence
|
||
<code>${array[(r)``pattern``]}</code> will substitute the empty string. Thus
|
||
the success of a search can be tested by using the <code>(i)</code> flag, for
|
||
example (assuming the option <code>KSH_ARRAYS</code> is not in effect):</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">[[ ${array[(i)pattern]} -le ${#array} ]]
|
||
</code></pre>
|
||
</div>
|
||
<p>If <code>KSH_ARRAYS</code> is in effect, the <code>-le</code> should be replaced by <code>-lt</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>R</code><br />
|
||
Like ‘<code>r</code>’, but gives the last match. For associative arrays, gives
|
||
all possible matches. May be used for assigning to ordinary array
|
||
elements, but not for assigning to associative arrays. On failure,
|
||
for normal arrays this has the effect of returning the element
|
||
corresponding to subscript 0; this is empty unless one of the
|
||
options <code>KSH_ARRAYS</code> or <code>KSH_ZERO_SUBSCRIPT</code> is in effect.</p>
|
||
<p>Note that in subscripts with both ‘<code>r</code>’ and ‘<code>R</code>’ pattern characters
|
||
are active even if they were substituted for a parameter (regardless
|
||
of the setting of <code>GLOB_SUBST</code> which controls this feature in normal
|
||
pattern matching). The flag ‘<code>e</code>’ can be added to inhibit pattern
|
||
matching. As this flag does not inhibit other forms of substitution,
|
||
care is still required; using a parameter to hold the key has the
|
||
desired effect:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">key2='original key'
|
||
print ${array[(Re)$key2]}
|
||
</code></pre>
|
||
</div>
|
||
</li>
|
||
<li>
|
||
<p><code>i</code><br />
|
||
Like ‘<code>r</code>’, but gives the index of the match instead; this may not
|
||
be combined with a second argument. On the left side of an
|
||
assignment, behaves like ‘<code>r</code>’. For associative arrays, the key part
|
||
of each pair is compared to the pattern, and the first matching key
|
||
found is the result. On failure substitutes the length of the array
|
||
plus one, as discussed under the description of ‘<code>r</code>’, or the empty
|
||
string for an associative array.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>I</code><br />
|
||
Like ‘<code>i</code>’, but gives the index of the last match, or all possible
|
||
matching keys in an associative array. On failure substitutes 0, or
|
||
the empty string for an associative array. This flag is best when
|
||
testing for values or keys that do not exist.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>k</code><br />
|
||
If used in a subscript on an associative array, this flag causes the
|
||
keys to be interpreted as patterns, and returns the value for the
|
||
first key found where <code>exp</code> is matched by the key. Note this could
|
||
be any such key as no ordering of associative arrays is defined.
|
||
This flag does not work on the left side of an assignment to an
|
||
associative array element. If used on another type of parameter,
|
||
this behaves like ‘<code>r</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>K</code><br />
|
||
On an associative array this is like ‘<code>k</code>’ but returns all values
|
||
where <code>exp</code> is matched by the keys. On other types of parameters
|
||
this has the same effect as ‘<code>R</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>n:``expr``:</code><br />
|
||
If combined with ‘<code>r</code>’, ‘<code>R</code>’, ‘<code>i</code>’ or ‘<code>I</code>’, makes them give the
|
||
<code>n</code>th or <code>n</code>th last match (if <code>expr</code> evaluates to <code>n</code>). This flag is
|
||
ignored when the array is associative. The delimiter character <code>:</code>
|
||
is arbitrary; see above.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>b:``expr``:</code><br />
|
||
If combined with ‘<code>r</code>’, ‘<code>R</code>’, ‘<code>i</code>’ or ‘<code>I</code>’, makes them begin at
|
||
the <code>n</code>th or <code>n</code>th last element, word, or character (if <code>expr</code>
|
||
evaluates to <code>n</code>). This flag is ignored when the array is
|
||
associative. The delimiter character <code>:</code> is arbitrary; see above.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>e</code><br />
|
||
This flag causes any pattern matching that would be performed on the
|
||
subscript to use plain string matching instead. Hence
|
||
‘<code>${array[(re)*]}</code>’ matches only the array element whose value is
|
||
<code>*</code>. Note that other forms of substitution such as parameter
|
||
substitution are not inhibited.</p>
|
||
<p>This flag can also be used to force <code>*</code> or <code>@</code> to be interpreted as
|
||
a single key rather than as a reference to all values. It may be
|
||
used for either purpose on the left side of an assignment.</p>
|
||
</li>
|
||
</ul>
|
||
<p>See <em>Parameter Expansion Flags</em> (<a href="Expansion.html#Parameter-Expansion">Parameter
|
||
Expansion</a>) for additional ways to
|
||
manipulate the results of array subscripting.</p>
|
||
<hr />
|
||
<p><span id="Subscript-Parsing"></span></p>
|
||
<h3 id="1524-subscript-parsing"><a class="header" href="#1524-subscript-parsing">15.2.4 Subscript Parsing</a></h3>
|
||
<p>This discussion applies mainly to associative array key strings and to
|
||
patterns used for reverse subscripting (the ‘<code>r</code>’, ‘<code>R</code>’, ‘<code>i</code>’, etc.
|
||
flags), but it may also affect parameter substitutions that appear as
|
||
part of an arithmetic expression in an ordinary subscript.</p>
|
||
<p>To avoid subscript parsing limitations in assignments to associative
|
||
array elements, use the append syntax:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">aa+=('key with "*strange*" characters' 'value string')
|
||
</code></pre>
|
||
</div>
|
||
<p>The basic rule to remember when writing a subscript expression is that
|
||
all text between the opening ‘<code>[</code>’ and the closing ‘<code>]</code>’ is interpreted
|
||
<em>as if</em> it were in double quotes
|
||
(<a href="Shell-Grammar.html#Quoting">Quoting</a>). However, unlike double quotes
|
||
which normally cannot nest, subscript expressions may appear inside
|
||
double-quoted strings or inside other subscript expressions (or both!),
|
||
so the rules have two important differences.</p>
|
||
<p>The first difference is that brackets (‘<code>[</code>’ and ‘<code>]</code>’) must appear as
|
||
balanced pairs in a subscript expression unless they are preceded by a
|
||
backslash (‘<code>\</code>’). Therefore, within a subscript expression (and unlike
|
||
true double-quoting) the sequence ‘<code>\[</code>’ becomes ‘<code>[</code>’, and similarly
|
||
‘<code>\]</code>’ becomes ‘<code>]</code>’. This applies even in cases where a backslash is
|
||
not normally required; for example, the pattern ‘<code>[^[]</code>’ (to match any
|
||
character other than an open bracket) should be written ‘<code>[^\[]</code>’ in a
|
||
reverse-subscript pattern. However, note that ‘<code>\[^\[\]</code>’ and even
|
||
‘<code>\[^[]</code>’ mean the <em>same</em> thing, because backslashes are always
|
||
stripped when they appear before brackets!</p>
|
||
<p>The same rule applies to parentheses (‘<code>(</code>’ and ‘<code>)</code>’) and braces (‘<code>{</code>’
|
||
and ‘<code>}</code>’): they must appear either in balanced pairs or preceded by a
|
||
backslash, and backslashes that protect parentheses or braces are
|
||
removed during parsing. This is because parameter expansions may be
|
||
surrounded by balanced braces, and subscript flags are introduced by
|
||
balanced parentheses.</p>
|
||
<p>The second difference is that a double-quote (‘<code>"</code>’) may appear as part
|
||
of a subscript expression without being preceded by a backslash, and
|
||
therefore that the two characters ‘<code>\"</code>’ remain as two characters in the
|
||
subscript (in true double-quoting, ‘<code>\"</code>’ becomes ‘<code>"</code>’). However,
|
||
because of the standard shell quoting rules, any double-quotes that
|
||
appear must occur in balanced pairs unless preceded by a backslash. This
|
||
makes it more difficult to write a subscript expression that contains an
|
||
odd number of double-quote characters, but the reason for this
|
||
difference is so that when a subscript expression appears inside true
|
||
double-quotes, one can still write ‘<code>\"</code>’ (rather than ‘<code>\\\"</code>’) for
|
||
‘<code>"</code>’.</p>
|
||
<p>To use an odd number of double quotes as a key in an assignment, use the
|
||
<code>typeset</code> builtin and an enclosing pair of double quotes; to refer to
|
||
the value of that key, again use double quotes:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">typeset -A aa
|
||
typeset "aa[one\"two\"three\"quotes]"=QQQ
|
||
print "$aa[one\"two\"three\"quotes]"
|
||
</code></pre>
|
||
</div>
|
||
<p>It is important to note that the quoting rules do not change when a
|
||
parameter expansion with a subscript is nested inside another subscript
|
||
expression. That is, it is not necessary to use additional backslashes
|
||
within the inner subscript expression; they are removed only once, from
|
||
the innermost subscript outwards. Parameters are also expanded from the
|
||
innermost subscript first, as each expansion is encountered left to
|
||
right in the outer expression.</p>
|
||
<p>A further complication arises from a way in which subscript parsing is
|
||
<em>not</em> different from double quote parsing. As in true double-quoting,
|
||
the sequences ‘<code>\*</code>’, and ‘<code>\@</code>’ remain as two characters when they
|
||
appear in a subscript expression. To use a literal ‘<code>*</code>’ or ‘<code>@</code>’ as an
|
||
associative array key, the ‘<code>e</code>’ flag must be used:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">typeset -A aa
|
||
aa[(e)*]=star
|
||
print $aa[(e)*]
|
||
</code></pre>
|
||
</div>
|
||
<p>A last detail must be considered when reverse subscripting is performed.
|
||
Parameters appearing in the subscript expression are first expanded and
|
||
then the complete expression is interpreted as a pattern. This has two
|
||
effects: first, parameters behave as if <code>GLOB_SUBST</code> were on (and it
|
||
cannot be turned off); second, backslashes are interpreted twice, once
|
||
when parsing the array subscript and again when parsing the pattern. In
|
||
a reverse subscript, it’s necessary to use <em>four</em> backslashes to cause a
|
||
single backslash to match literally in the pattern. For complex
|
||
patterns, it is often easiest to assign the desired pattern to a
|
||
parameter and then refer to that parameter in the subscript, because
|
||
then the backslashes, brackets, parentheses, etc., are seen only when
|
||
the complete expression is converted to a pattern. To match the value of
|
||
a parameter literally in a reverse subscript, rather than as a pattern,
|
||
use ‘<code>${(q``)``name``}</code>’ (<a href="Expansion.html#Parameter-Expansion">Parameter
|
||
Expansion</a>) to quote the expanded
|
||
value.</p>
|
||
<p>Note that the ‘<code>k</code>’ and ‘<code>K</code>’ flags are reverse subscripting for an
|
||
ordinary array, but are <em>not</em> reverse subscripting for an associative
|
||
array! (For an associative array, the keys in the array itself are
|
||
interpreted as patterns by those flags; the subscript is a plain string
|
||
in that case.)</p>
|
||
<p>One final note, not directly related to subscripting: the numeric names
|
||
of positional parameters (<a href="Parameters.html#Positional-Parameters">Positional
|
||
Parameters</a>) are parsed specially, so for
|
||
example ‘<code>$2foo</code>’ is equivalent to ‘<code>${2}foo</code>’. Therefore, to use
|
||
subscript syntax to extract a substring from a positional parameter, the
|
||
expansion must be surrounded by braces; for example, ‘<code>${2[3,5]}</code>’
|
||
evaluates to the third through fifth characters of the second positional
|
||
parameter, but ‘<code>$2[3,5]</code>’ is the entire second parameter concatenated
|
||
with the filename generation pattern ‘<code>[3,5]</code>’.</p>
|
||
<hr />
|
||
<p><span id="Positional-Parameters"></span>
|
||
<span id="Positional-Parameters-1"></span></p>
|
||
<h2 id="153-positional-parameters"><a class="header" href="#153-positional-parameters">15.3 Positional Parameters</a></h2>
|
||
<p>The positional parameters provide access to the command-line arguments
|
||
of a shell function, shell script, or the shell itself; see
|
||
<a href="Invocation.html#Invocation">Invocation</a>, and also
|
||
<a href="Functions.html#Functions">Functions</a>. The parameter <code>n</code>, where <code>n</code> is a
|
||
number, is the <code>n</code>th positional parameter. The parameter ‘<code>$0</code>’ is a
|
||
special case, see <a href="Parameters.html#Parameters-Set-By-The-Shell">Parameters Set By The
|
||
Shell</a>.</p>
|
||
<p>The parameters <code>*</code>, <code>@</code> and <code>argv</code> are arrays containing all the
|
||
positional parameters; thus ‘<code>$argv[``n``]</code>’, etc., is equivalent to
|
||
simply ‘<code>$``n</code>’. Note that the options <code>KSH_ARRAYS</code> or
|
||
<code>KSH_ZERO_SUBSCRIPT</code> apply to these arrays as well, so with either of
|
||
those options set, ‘<code>${argv[0]}</code>’ is equivalent to ‘<code>$1</code>’ and so on.</p>
|
||
<p>Positional parameters may be changed after the shell or function starts
|
||
by using the <code>set</code> builtin, by assigning to the <code>argv</code> array, or by
|
||
direct assignment of the form ‘<code>n``=``value</code>’ where <code>n</code> is the number of
|
||
the positional parameter to be changed. This also creates (with empty
|
||
values) any of the positions from 1 to <code>n</code> that do not already have
|
||
values. Note that, because the positional parameters form an array, an
|
||
array assignment of the form ‘<code>n``=(``value</code> ...<code>)</code>’ is allowed, and has
|
||
the effect of shifting all the values at positions greater than <code>n</code> by
|
||
as many positions as necessary to accommodate the new values.</p>
|
||
<hr />
|
||
<p><span id="Local-Parameters"></span>
|
||
<span id="Local-Parameters-1"></span></p>
|
||
<h2 id="154-local-parameters"><a class="header" href="#154-local-parameters">15.4 Local Parameters</a></h2>
|
||
<p>Shell function executions delimit scopes for shell parameters.
|
||
(Parameters are dynamically scoped.) The <code>typeset</code> builtin, and its
|
||
alternative forms <code>declare</code>, <code>integer</code>, <code>local</code> and <code>readonly</code> (but not
|
||
<code>export</code>), can be used to declare a parameter as being local to the
|
||
innermost scope.</p>
|
||
<p>When a parameter is read or assigned to, the innermost existing
|
||
parameter of that name is used. (That is, the local parameter hides any
|
||
less-local parameter.) However, assigning to a non-existent parameter,
|
||
or declaring a new parameter with <code>export</code>, causes it to be created in
|
||
the <em>outer</em>most scope.</p>
|
||
<p>Local parameters disappear when their scope ends. <code>unset</code> can be used to
|
||
delete a parameter while it is still in scope; any outer parameter of
|
||
the same name remains hidden.</p>
|
||
<p>Special parameters may also be made local; they retain their special
|
||
attributes unless either the existing or the newly-created parameter has
|
||
the <code>-h</code> (hide) attribute. This may have unexpected effects: there is no
|
||
default value, so if there is no assignment at the point the variable is
|
||
made local, it will be set to an empty value (or zero in the case of
|
||
integers). The following:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">typeset PATH=/new/directory:$PATH
|
||
</code></pre>
|
||
</div>
|
||
<p>is valid for temporarily allowing the shell or programmes called from it
|
||
to find the programs in <code>/new/directory</code> inside a function.</p>
|
||
<p>Note that the restriction in older versions of zsh that local parameters
|
||
were never exported has been removed.</p>
|
||
<hr />
|
||
<p><span id="Parameters-Set-By-The-Shell"></span>
|
||
<span id="Parameters-Set-By-The-Shell-1"></span></p>
|
||
<h2 id="155-parameters-set-by-the-shell"><a class="header" href="#155-parameters-set-by-the-shell">15.5 Parameters Set By The Shell</a></h2>
|
||
<p>In the parameter lists that follow, the mark ‘<S>’ indicates that the
|
||
parameter is special. ‘<Z>’ indicates that the parameter does not
|
||
exist when the shell initializes in <code>sh</code> or <code>ksh</code> emulation mode.</p>
|
||
<p>The following parameters are automatically set by the shell:</p>
|
||
<p><span id="index-_0021"></span></p>
|
||
<p><code>!</code> <S></p>
|
||
<p>The process ID of the last command started in the background with <code>&</code>,
|
||
put into the background with the <code>bg</code> builtin, or spawned with <code>coproc</code>.</p>
|
||
<p><span id="index-_0023"></span></p>
|
||
<p><code>#</code> <S></p>
|
||
<p>The number of positional parameters in decimal. Note that some confusion
|
||
may occur with the syntax <code>$#``param</code> which substitutes the length of
|
||
<code>param</code>. Use <code>${#}</code> to resolve ambiguities. In particular, the sequence
|
||
‘<code>$#-``...</code>’ in an arithmetic expression is interpreted as the length
|
||
of the parameter <code>-</code>, q.v.</p>
|
||
<p><span id="index-ARGC"></span></p>
|
||
<p><code>ARGC</code> <S> <Z></p>
|
||
<p>Same as <code>#</code>.</p>
|
||
<p><span id="index-_0024"></span></p>
|
||
<p><code>$</code> <S></p>
|
||
<p>The process ID of this shell. Note that this indicates the original
|
||
shell started by invoking <code>zsh</code>; all processes forked from the shells
|
||
without executing a new program, such as subshells started by
|
||
<code>(``...``)</code>, substitute the same value.</p>
|
||
<p><span id="index-_002d-1"></span></p>
|
||
<p><code>-</code> <S></p>
|
||
<p>Flags supplied to the shell on invocation or by the <code>set</code> or <code>setopt</code>
|
||
commands.</p>
|
||
<p><span id="index-_002a"></span></p>
|
||
<p><code>*</code> <S></p>
|
||
<p>An array containing the positional parameters.</p>
|
||
<p><span id="index-argv"></span></p>
|
||
<p><code>argv</code> <S> <Z></p>
|
||
<p>Same as <code>*</code>. Assigning to <code>argv</code> changes the local positional
|
||
parameters, but <code>argv</code> is <em>not</em> itself a local parameter. Deleting
|
||
<code>argv</code> with <code>unset</code> in any function deletes it everywhere, although only
|
||
the innermost positional parameter array is deleted (so <code>*</code> and <code>@</code> in
|
||
other scopes are not affected).</p>
|
||
<p><span id="index-_0040"></span></p>
|
||
<p><code>@</code> <S></p>
|
||
<p>Same as <code>argv[@]</code>, even when <code>argv</code> is not set.</p>
|
||
<p><span id="index-_003f"></span></p>
|
||
<p><code>?</code> <S></p>
|
||
<p>The exit status returned by the last command.</p>
|
||
<p><span id="index-0"></span></p>
|
||
<p><code>0</code> <S></p>
|
||
<p>The name used to invoke the current shell, or as set by the <code>-c</code> command
|
||
line option upon invocation. If the <code>FUNCTION_ARGZERO</code> option is set,
|
||
<code>$0</code> is set upon entry to a shell function to the name of the function,
|
||
and upon entry to a sourced script to the name of the script, and reset
|
||
to its previous value when the function or script returns.</p>
|
||
<p><span id="index-status"></span></p>
|
||
<p><code>status</code> <S> <Z></p>
|
||
<p>Same as <code>?</code>.</p>
|
||
<p><span id="index-pipestatus"></span></p>
|
||
<p><code>pipestatus</code> <S> <Z></p>
|
||
<p>An array containing the exit statuses returned by all commands in the
|
||
last pipeline.</p>
|
||
<p><span id="index-_005f"></span></p>
|
||
<p><code>_</code> <S></p>
|
||
<p>The last argument of the previous command. Also, this parameter is set
|
||
in the environment of every command executed to the full pathname of the
|
||
command.</p>
|
||
<p><span id="index-CPUTYPE"></span></p>
|
||
<p><code>CPUTYPE</code></p>
|
||
<p>The machine type (microprocessor class or machine model), as determined
|
||
at run time.</p>
|
||
<p><span id="index-EGID"></span></p>
|
||
<p><code>EGID</code> <S></p>
|
||
<p>The effective group ID of the shell process. If you have sufficient
|
||
privileges, you may change the effective group ID of the shell process
|
||
by assigning to this parameter. Also (assuming sufficient privileges),
|
||
you may start a single command with a different effective group ID by
|
||
‘<code>(EGID=``gid``; command)</code>’</p>
|
||
<p>If this is made local, it is not implicitly set to 0, but may be
|
||
explicitly set locally.</p>
|
||
<p><span id="index-EUID"></span></p>
|
||
<p><code>EUID</code> <S></p>
|
||
<p>The effective user ID of the shell process. If you have sufficient
|
||
privileges, you may change the effective user ID of the shell process by
|
||
assigning to this parameter. Also (assuming sufficient privileges), you
|
||
may start a single command with a different effective user ID by
|
||
‘<code>(EUID=``uid``; command)</code>’</p>
|
||
<p>If this is made local, it is not implicitly set to 0, but may be
|
||
explicitly set locally.</p>
|
||
<p><span id="index-ERRNO"></span></p>
|
||
<p><code>ERRNO</code> <S></p>
|
||
<p>The value of errno (see man page errno(3)) as set by the most recently
|
||
failed system call. This value is system dependent and is intended for
|
||
debugging purposes. It is also useful with the <code>zsh/system</code> module which
|
||
allows the number to be turned into a name or message.</p>
|
||
<p><span id="index-FUNCNEST"></span></p>
|
||
<p><code>FUNCNEST</code> <S></p>
|
||
<p>Integer. If greater than or equal to zero, the maximum nesting depth of
|
||
shell functions. When it is exceeded, an error is raised at the point
|
||
where a function is called. The default value is determined when the
|
||
shell is configured, but is typically 500. Increasing the value
|
||
increases the danger of a runaway function recursion causing the shell
|
||
to crash. Setting a negative value turns off the check.</p>
|
||
<p><span id="index-GID"></span></p>
|
||
<p><code>GID</code> <S></p>
|
||
<p>The real group ID of the shell process. If you have sufficient
|
||
privileges, you may change the group ID of the shell process by
|
||
assigning to this parameter. Also (assuming sufficient privileges), you
|
||
may start a single command under a different group ID by ‘<code>(GID=``gid``; command)</code>’</p>
|
||
<p>If this is made local, it is not implicitly set to 0, but may be
|
||
explicitly set locally.</p>
|
||
<p><span id="index-HISTCMD"></span></p>
|
||
<p><code>HISTCMD</code></p>
|
||
<p>The current history event number in an interactive shell, in other words
|
||
the event number for the command that caused <code>$HISTCMD</code> to be read. If
|
||
the current history event modifies the history, <code>HISTCMD</code> changes to the
|
||
new maximum history event number.</p>
|
||
<p><span id="index-HOST"></span></p>
|
||
<p><code>HOST</code></p>
|
||
<p>The current hostname.</p>
|
||
<p><span id="index-LINENO"></span></p>
|
||
<p><code>LINENO</code> <S></p>
|
||
<p>The line number of the current line within the current script, sourced
|
||
file, or shell function being executed, whichever was started most
|
||
recently. Note that in the case of shell functions the line number
|
||
refers to the function as it appeared in the original definition, not
|
||
necessarily as displayed by the <code>functions</code> builtin.</p>
|
||
<p><span id="index-LOGNAME"></span></p>
|
||
<p><code>LOGNAME</code></p>
|
||
<p>If the corresponding variable is not set in the environment of the
|
||
shell, it is initialized to the login name corresponding to the current
|
||
login session. This parameter is exported by default but this can be
|
||
disabled using the <code>typeset</code> builtin. The value is set to the string
|
||
returned by the man page getlogin(3) system call if that is available.</p>
|
||
<p><span id="index-MACHTYPE"></span></p>
|
||
<p><code>MACHTYPE</code></p>
|
||
<p>The machine type (microprocessor class or machine model), as determined
|
||
at compile time.</p>
|
||
<p><span id="index-OLDPWD"></span></p>
|
||
<p><code>OLDPWD</code></p>
|
||
<p>The previous working directory. This is set when the shell initializes
|
||
and whenever the directory changes.</p>
|
||
<p><span id="index-OPTARG"></span></p>
|
||
<p><code>OPTARG</code> <S></p>
|
||
<p>The value of the last option argument processed by the <code>getopts</code>
|
||
command.</p>
|
||
<p><span id="index-OPTIND"></span></p>
|
||
<p><code>OPTIND</code> <S></p>
|
||
<p>The index of the last option argument processed by the <code>getopts</code>
|
||
command.</p>
|
||
<p><span id="index-OSTYPE"></span></p>
|
||
<p><code>OSTYPE</code></p>
|
||
<p>The operating system, as determined at compile time.</p>
|
||
<p><span id="index-PPID"></span></p>
|
||
<p><code>PPID</code> <S></p>
|
||
<p>The process ID of the parent of the shell. As for <code>$$</code>, the value
|
||
indicates the parent of the original shell and does not change in
|
||
subshells.</p>
|
||
<p><span id="index-PWD"></span></p>
|
||
<p><code>PWD</code></p>
|
||
<p>The present working directory. This is set when the shell initializes
|
||
and whenever the directory changes.</p>
|
||
<p><span id="index-RANDOM"></span></p>
|
||
<p><code>RANDOM</code> <S></p>
|
||
<p>A pseudo-random integer from 0 to 32767, newly generated each time this
|
||
parameter is referenced. The random number generator can be seeded by
|
||
assigning a numeric value to <code>RANDOM</code>.</p>
|
||
<p>sequence; subshells that reference <code>RANDOM</code> will result in identical
|
||
pseudo-random values unless the value of <code>RANDOM</code> is referenced or
|
||
seeded in the parent shell in between subshell invocations.</p>
|
||
<p><span id="index-SECONDS"></span></p>
|
||
<p><code>SECONDS</code> <S></p>
|
||
<p>The number of seconds since shell invocation. If this parameter is
|
||
assigned a value, then the value returned upon reference will be the
|
||
value that was assigned plus the number of seconds since the assignment.</p>
|
||
<p>Unlike other special parameters, the type of the <code>SECONDS</code> parameter can
|
||
be changed using the <code>typeset</code> command. Only integer and one of the
|
||
floating point types are allowed. For example, ‘<code>typeset -F SECONDS</code>’
|
||
causes the value to be reported as a floating point number. The value is
|
||
available to microsecond accuracy, although the shell may show more or
|
||
fewer digits depending on the use of <code>typeset</code>. See the documentation
|
||
for the builtin <code>typeset</code> in <a href="Shell-Builtin-Commands.html#Shell-Builtin-Commands">Shell Builtin
|
||
Commands</a> for more
|
||
details.</p>
|
||
<p><span id="index-SHLVL"></span></p>
|
||
<p><code>SHLVL</code> <S></p>
|
||
<p>Incremented by one each time a new shell is started.</p>
|
||
<p><span id="index-signals"></span></p>
|
||
<p><code>signals</code></p>
|
||
<p>An array containing the names of the signals. Note that with the
|
||
standard zsh numbering of array indices, where the first element has
|
||
index 1, the signals are offset by 1 from the signal number used by the
|
||
operating system. For example, on typical Unix-like systems <code>HUP</code> is
|
||
signal number 1, but is referred to as <code>$signals[2]</code>. This is because of
|
||
<code>EXIT</code> at position 1 in the array, which is used internally by zsh but
|
||
is not known to the operating system.</p>
|
||
<p><span id="index-TRY_005fBLOCK_005fERROR"></span></p>
|
||
<p><code>TRY_BLOCK_ERROR</code> <S></p>
|
||
<p>In an <code>always</code> block, indicates whether the preceding list of code
|
||
caused an error. The value is 1 to indicate an error, 0 otherwise. It
|
||
may be reset, clearing the error condition. See <a href="Shell-Grammar.html#Complex-Commands">Complex
|
||
Commands</a></p>
|
||
<p><span id="index-TRY_005fBLOCK_005fINTERRUPT"></span></p>
|
||
<p><code>TRY_BLOCK_INTERRUPT</code> <S></p>
|
||
<p>This variable works in a similar way to <code>TRY_BLOCK_ERROR</code>, but
|
||
represents the status of an interrupt from the signal SIGINT, which
|
||
typically comes from the keyboard when the user types <code>^C</code>. If set to 0,
|
||
any such interrupt will be reset; otherwise, the interrupt is propagated
|
||
after the <code>always</code> block.</p>
|
||
<p>Note that it is possible that an interrupt arrives during the execution
|
||
of the <code>always</code> block; this interrupt is also propagated.</p>
|
||
<p><span id="index-TTY"></span></p>
|
||
<p><code>TTY</code></p>
|
||
<p>The name of the tty associated with the shell, if any.</p>
|
||
<p><span id="index-TTYIDLE"></span></p>
|
||
<p><code>TTYIDLE</code> <S></p>
|
||
<p>The idle time of the tty associated with the shell in seconds or -1 if
|
||
there is no such tty.</p>
|
||
<p><span id="index-UID"></span></p>
|
||
<p><code>UID</code> <S></p>
|
||
<p>The real user ID of the shell process. If you have sufficient
|
||
privileges, you may change the user ID of the shell by assigning to this
|
||
parameter. Also (assuming sufficient privileges), you may start a single
|
||
command under a different user ID by ‘<code>(UID=``uid``; command)</code>’</p>
|
||
<p>If this is made local, it is not implicitly set to 0, but may be
|
||
explicitly set locally.</p>
|
||
<p><span id="index-USERNAME"></span></p>
|
||
<p><code>USERNAME</code> <S></p>
|
||
<p>The username corresponding to the real user ID of the shell process. If
|
||
you have sufficient privileges, you may change the username (and also
|
||
the user ID and group ID) of the shell by assigning to this parameter.
|
||
Also (assuming sufficient privileges), you may start a single command
|
||
under a different username (and user ID and group ID) by
|
||
‘<code>(USERNAME=``username``; command)</code>’</p>
|
||
<p><span id="index-VENDOR"></span></p>
|
||
<p><code>VENDOR</code></p>
|
||
<p>The vendor, as determined at compile time.</p>
|
||
<p><span id="index-zsh_005feval_005fcontext"></span>
|
||
<span id="index-ZSH_005fEVAL_005fCONTEXT"></span></p>
|
||
<p><code>zsh_eval_context</code> <S> <Z> (<code>ZSH_EVAL_CONTEXT</code> <S>)</p>
|
||
<p>An array (colon-separated list) indicating the context of shell code
|
||
that is being run. Each time a piece of shell code that is stored within
|
||
the shell is executed a string is temporarily appended to the array to
|
||
indicate the type of operation that is being performed. Read in order
|
||
the array gives an indication of the stack of operations being performed
|
||
with the most immediate context last.</p>
|
||
<p>Note that the variable does not give information on syntactic context
|
||
such as pipelines or subshells. Use <code>$ZSH_SUBSHELL</code> to detect subshells.</p>
|
||
<p>The context is one of the following:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>cmdarg</code><br />
|
||
Code specified by the <code>-c</code> option to the command line that invoked
|
||
the shell.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>cmdsubst</code><br />
|
||
Command substitution using the <code>‘``...``‘</code> or <code>$(``...``)</code>
|
||
construct.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>equalsubst</code><br />
|
||
File substitution using the <code>=(``...``)</code> construct.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>eval</code><br />
|
||
Code executed by the <code>eval</code> builtin.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>evalautofunc</code><br />
|
||
Code executed with the <code>KSH_AUTOLOAD</code> mechanism in order to define
|
||
an autoloaded function.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>fc</code><br />
|
||
Code from the shell history executed by the <code>-e</code> option to the <code>fc</code>
|
||
builtin.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>file</code><br />
|
||
Lines of code being read directly from a file, for example by the
|
||
<code>source</code> builtin.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>filecode</code><br />
|
||
Lines of code being read from a <code>.zwc</code> file instead of directly from
|
||
the source file.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>globqual</code><br />
|
||
Code executed by the <code>e</code> or <code>+</code> glob qualifier.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>globsort</code><br />
|
||
Code executed to order files by the <code>o</code> glob qualifier.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>insubst</code><br />
|
||
File substitution using the <code><(``...``)</code> construct.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>loadautofunc</code><br />
|
||
Code read directly from a file to define an autoloaded function.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>outsubst</code><br />
|
||
File substitution using the <code>>(``...``)</code> construct.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>sched</code><br />
|
||
Code executed by the <code>sched</code> builtin.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>shfunc</code><br />
|
||
A shell function.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>stty</code><br />
|
||
Code passed to <code>stty</code> by the <code>STTY</code> environment variable. Normally
|
||
this is passed directly to the system’s <code>stty</code> command, so this
|
||
value is unlikely to be seen in practice.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>style</code><br />
|
||
Code executed as part of a style retrieved by the <code>zstyle</code> builtin
|
||
from the <code>zsh/zutil</code> module.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>toplevel</code><br />
|
||
The highest execution level of a script or interactive shell.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>trap</code><br />
|
||
Code executed as a trap defined by the <code>trap</code> builtin. Traps defined
|
||
as functions have the context <code>shfunc</code>. As traps are asynchronous
|
||
they may have a different hierarchy from other code.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zpty</code><br />
|
||
Code executed by the <code>zpty</code> builtin from the <code>zsh/zpty</code> module.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zregexparse-guard</code><br />
|
||
Code executed as a guard by the <code>zregexparse</code> command from the
|
||
<code>zsh/zutil</code> module.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zregexparse-action</code><br />
|
||
Code executed as an action by the <code>zregexparse</code> command from the
|
||
<code>zsh/zutil</code> module.</p>
|
||
</li>
|
||
</ul>
|
||
<p><span id="index-ZSH_005fARGZERO"></span></p>
|
||
<p><code>ZSH_ARGZERO</code></p>
|
||
<p>If zsh was invoked to run a script, this is the name of the script.
|
||
Otherwise, it is the name used to invoke the current shell. This is the
|
||
same as the value of <code>$0</code> when the <code>POSIX_ARGZERO</code> option is set, but is
|
||
always available.</p>
|
||
<p><span id="index-ZSH_005fEXECUTION_005fSTRING"></span></p>
|
||
<p><code>ZSH_EXECUTION_STRING</code></p>
|
||
<p>If the shell was started with the option <code>-c</code>, this contains the
|
||
argument passed to the option. Otherwise it is not set.</p>
|
||
<p><span id="index-ZSH_005fNAME"></span></p>
|
||
<p><code>ZSH_NAME</code></p>
|
||
<p>Expands to the basename of the command used to invoke this instance of
|
||
zsh.</p>
|
||
<p><span id="index-ZSH_005fPATCHLEVEL"></span></p>
|
||
<p><code>ZSH_PATCHLEVEL</code></p>
|
||
<p>The output of ‘<code>git describe –tags –long</code>’ for the zsh repository used
|
||
to build the shell. This is most useful in order to keep track of
|
||
versions of the shell during development between releases; hence most
|
||
users should not use it and should instead rely on <code>$ZSH_VERSION</code>.</p>
|
||
<p><code>zsh_scheduled_events</code></p>
|
||
<p>See <a href="Zsh-Modules.html#The-zsh_002fsched-Module">The zsh/sched Module</a>.</p>
|
||
<p><span id="index-ZSH_005fSCRIPT"></span></p>
|
||
<p><code>ZSH_SCRIPT</code></p>
|
||
<p>If zsh was invoked to run a script, this is the name of the script,
|
||
otherwise it is unset.</p>
|
||
<p><span id="index-ZSH_005fSUBSHELL-_003cS_003e"></span></p>
|
||
<p><code>ZSH_SUBSHELL</code></p>
|
||
<p>Readonly integer. Initially zero, incremented each time the shell forks
|
||
to create a subshell for executing code. Hence ‘<code>(print $ZSH_SUBSHELL)</code>’
|
||
and ‘<code>print $(print $ZSH_SUBSHELL)</code>’ output 1, while ‘<code>( (print $ZSH_SUBSHELL) )</code>’ outputs 2.</p>
|
||
<p><span id="index-ZSH_005fVERSION"></span></p>
|
||
<p><code>ZSH_VERSION</code></p>
|
||
<p>The version number of the release of zsh.</p>
|
||
<hr />
|
||
<p><span id="Parameters-Used-By-The-Shell"></span>
|
||
<span id="Parameters-Used-By-The-Shell-1"></span></p>
|
||
<h2 id="156-parameters-used-by-the-shell"><a class="header" href="#156-parameters-used-by-the-shell">15.6 Parameters Used By The Shell</a></h2>
|
||
<p>The following parameters are used by the shell. Again, ‘<S>’ indicates
|
||
that the parameter is special and ‘<Z>’ indicates that the parameter
|
||
does not exist when the shell initializes in <code>sh</code> or <code>ksh</code> emulation
|
||
mode.</p>
|
||
<p>In cases where there are two parameters with an upper- and lowercase
|
||
form of the same name, such as <code>path</code> and <code>PATH</code>, the lowercase form is
|
||
an array and the uppercase form is a scalar with the elements of the
|
||
array joined together by colons. These are similar to tied parameters
|
||
created via ‘<code>typeset -T</code>’. The normal use for the colon-separated form
|
||
is for exporting to the environment, while the array form is easier to
|
||
manipulate within the shell. Note that unsetting either of the pair will
|
||
unset the other; they retain their special properties when recreated,
|
||
and recreating one of the pair will recreate the other.</p>
|
||
<p><span id="index-ARGV0"></span></p>
|
||
<p><code>ARGV0</code></p>
|
||
<p>If exported, its value is used as the <code>argv[0]</code> of external commands.
|
||
Usually used in constructs like ‘<code>ARGV0=emacs nethack</code>’.</p>
|
||
<p><span id="index-editing-over-slow-connection"></span>
|
||
<span id="index-slow-connection_002c-editing-over"></span>
|
||
<span id="index-BAUD"></span></p>
|
||
<p><code>BAUD</code></p>
|
||
<p>The rate in bits per second at which data reaches the terminal. The line
|
||
editor will use this value in order to compensate for a slow terminal by
|
||
delaying updates to the display until necessary. If the parameter is
|
||
unset or the value is zero the compensation mechanism is turned off. The
|
||
parameter is not set by default.</p>
|
||
<p>This parameter may be profitably set in some circumstances, e.g. for
|
||
slow modems dialing into a communications server, or on a slow wide area
|
||
network. It should be set to the baud rate of the slowest part of the
|
||
link for best performance.</p>
|
||
<p><span id="index-cdpath"></span> <span id="index-CDPATH"></span></p>
|
||
<p><code>cdpath</code> <S> <Z> (<code>CDPATH</code> <S>)</p>
|
||
<p>An array (colon-separated list) of directories specifying the search
|
||
path for the <code>cd</code> command.</p>
|
||
<p><span id="index-COLUMNS"></span></p>
|
||
<p><code>COLUMNS</code> <S></p>
|
||
<p>The number of columns for this terminal session. Used for printing
|
||
select lists and for the line editor.</p>
|
||
<p><span id="index-CORRECT_005fIGNORE"></span></p>
|
||
<p><code>CORRECT_IGNORE</code></p>
|
||
<p>If set, is treated as a pattern during spelling correction. Any
|
||
potential correction that matches the pattern is ignored. For example,
|
||
if the value is ‘<code>_*</code>’ then completion functions (which, by convention,
|
||
have names beginning with ‘<code>_</code>’) will never be offered as spelling
|
||
corrections. The pattern does not apply to the correction of file names,
|
||
as applied by the <code>CORRECT_ALL</code> option (so with the example just given
|
||
files beginning with ‘<code>_</code>’ in the current directory would still be
|
||
completed).</p>
|
||
<p><span id="index-CORRECT_005fIGNORE_005fFILE"></span></p>
|
||
<p><code>CORRECT_IGNORE_FILE</code></p>
|
||
<p>If set, is treated as a pattern during spelling correction of file
|
||
names. Any file name that matches the pattern is never offered as a
|
||
correction. For example, if the value is ‘<code>.*</code>’ then dot file names will
|
||
never be offered as spelling corrections. This is useful with the
|
||
<code>CORRECT_ALL</code> option.</p>
|
||
<p><span id="index-DIRSTACKSIZE"></span></p>
|
||
<p><code>DIRSTACKSIZE</code></p>
|
||
<p>The maximum size of the directory stack, by default there is no limit.
|
||
If the stack gets larger than this, it will be truncated automatically.
|
||
This is useful with the <code>AUTO_PUSHD</code> option.
|
||
<span id="index-AUTO_005fPUSHD_002c-use-of"></span></p>
|
||
<p><span id="index-ENV"></span></p>
|
||
<p><code>ENV</code></p>
|
||
<p>If the <code>ENV</code> environment variable is set when zsh is invoked as <code>sh</code> or
|
||
<code>ksh</code>, <code>$ENV</code> is sourced after the profile scripts. The value of <code>ENV</code>
|
||
is subjected to parameter expansion, command substitution, and
|
||
arithmetic expansion before being interpreted as a pathname. Note that
|
||
<code>ENV</code> is <em>not</em> used unless the shell is interactive and zsh is emulating
|
||
sh or ksh.</p>
|
||
<p><span id="index-FCEDIT"></span></p>
|
||
<p><code>FCEDIT</code></p>
|
||
<p>The default editor for the <code>fc</code> builtin. If <code>FCEDIT</code> is not set, the
|
||
parameter <code>EDITOR</code> is used; if that is not set either, a builtin
|
||
default, usually <code>vi</code>, is used.</p>
|
||
<p><span id="index-fignore"></span> <span id="index-FIGNORE"></span></p>
|
||
<p><code>fignore</code> <S> <Z> (<code>FIGNORE</code> <S>)</p>
|
||
<p>An array (colon separated list) containing the suffixes of files to be
|
||
ignored during filename completion. However, if completion only
|
||
generates files with suffixes in this list, then these files are
|
||
completed anyway.</p>
|
||
<p><span id="index-fpath"></span> <span id="index-FPATH"></span></p>
|
||
<p><code>fpath</code> <S> <Z> (<code>FPATH</code> <S>)</p>
|
||
<p>An array (colon separated list) of directories specifying the search
|
||
path for function definitions. This path is searched when a function
|
||
file is found, then it is read and executed in the current environment.</p>
|
||
<p><span id="index-histchars"></span></p>
|
||
<p><code>histchars</code> <S></p>
|
||
<p>Three characters used by the shell’s history and lexical analysis
|
||
mechanism. The first character signals the start of a history expansion
|
||
(default ‘<code>!</code>’). The second character signals the start of a quick
|
||
history substitution (default ‘<code>^</code>’). The third character is the comment
|
||
character (default ‘<code>#</code>’).</p>
|
||
<p>The characters must be in the ASCII character set; any attempt to set
|
||
<code>histchars</code> to characters with a locale-dependent meaning will be
|
||
rejected with an error message.</p>
|
||
<p><span id="index-HISTCHARS"></span></p>
|
||
<p><code>HISTCHARS</code> <S> <Z></p>
|
||
<p>Same as <code>histchars</code>. (Deprecated.)</p>
|
||
<p><span id="index-HISTFILE"></span></p>
|
||
<p><code>HISTFILE</code></p>
|
||
<p>The file to save the history in when an interactive shell exits. If
|
||
unset, the history is not saved.</p>
|
||
<p><span id="index-HISTORY_005fIGNORE"></span></p>
|
||
<p><code>HISTORY_IGNORE</code></p>
|
||
<p>If set, is treated as a pattern at the time history files are written.
|
||
Any potential history entry that matches the pattern is skipped. For
|
||
example, if the value is ‘<code>fc *</code>’ then commands that invoke the
|
||
interactive history editor are never written to the history file.</p>
|
||
<p>Note that <code>HISTORY_IGNORE</code> defines a single pattern: to specify
|
||
alternatives use the ‘<code>(``first``|``second``|``...``)</code>’ syntax.</p>
|
||
<p>Compare the <code>HIST_NO_STORE</code> option or the <code>zshaddhistory</code> hook, either
|
||
of which would prevent such commands from being added to the interactive
|
||
history at all. If you wish to use <code>HISTORY_IGNORE</code> to stop history
|
||
being added in the first place, you can define the following hook:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zshaddhistory() {
|
||
emulate -L zsh
|
||
## uncomment if HISTORY_IGNORE
|
||
## should use EXTENDED_GLOB syntax
|
||
# setopt extendedglob
|
||
[[ $1 != ${~HISTORY_IGNORE} ]]
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-HISTSIZE"></span></p>
|
||
<p><code>HISTSIZE</code> <S></p>
|
||
<p>The maximum number of events stored in the internal history list. If you
|
||
use the <code>HIST_EXPIRE_DUPS_FIRST</code> option, setting this value larger than
|
||
the <code>SAVEHIST</code> size will give you the difference as a cushion for saving
|
||
duplicated history events.</p>
|
||
<p>If this is made local, it is not implicitly set to 0, but may be
|
||
explicitly set locally.</p>
|
||
<p><span id="index-HOME"></span></p>
|
||
<p><code>HOME</code> <S></p>
|
||
<p>The default argument for the <code>cd</code> command. This is not set automatically
|
||
by the shell in <code>sh</code>, <code>ksh</code> or <code>csh</code> emulation, but it is typically
|
||
present in the environment anyway, and if it becomes set it has its
|
||
usual special behaviour.</p>
|
||
<p><span id="index-IFS"></span></p>
|
||
<p><code>IFS</code> <S></p>
|
||
<p>Internal field separators (by default space, tab, newline and NUL), that
|
||
are used to separate words which result from command or parameter
|
||
expansion and words read by the <code>read</code> builtin. Any characters from the
|
||
set space, tab and newline that appear in the IFS are called <em>IFS white
|
||
space</em>. One or more IFS white space characters or one non-IFS white
|
||
space character together with any adjacent IFS white space character
|
||
delimit a field. If an IFS white space character appears twice
|
||
consecutively in the IFS, this character is treated as if it were not an
|
||
IFS white space character.</p>
|
||
<p>If the parameter is unset, the default is used. Note this has a
|
||
different effect from setting the parameter to an empty string.</p>
|
||
<p><span id="index-KEYBOARD_005fHACK"></span></p>
|
||
<p><code>KEYBOARD_HACK</code></p>
|
||
<p>This variable defines a character to be removed from the end of the
|
||
command line before interpreting it (interactive shells only). It is
|
||
intended to fix the problem with keys placed annoyingly close to return
|
||
and replaces the <code>SUNKEYBOARDHACK</code> option which did this for backquotes
|
||
only. Should the chosen character be one of singlequote, doublequote or
|
||
backquote, there must also be an odd number of them on the command line
|
||
for the last one to be removed.</p>
|
||
<p>For backward compatibility, if the <code>SUNKEYBOARDHACK</code> option is
|
||
explicitly set, the value of <code>KEYBOARD_HACK</code> reverts to backquote. If
|
||
the option is explicitly unset, this variable is set to empty.</p>
|
||
<p><span id="index-KEYTIMEOUT"></span></p>
|
||
<p><code>KEYTIMEOUT</code></p>
|
||
<p>The time the shell waits, in hundredths of seconds, for another key to
|
||
be pressed when reading bound multi-character sequences.</p>
|
||
<p><span id="index-LANG"></span></p>
|
||
<p><code>LANG</code> <S></p>
|
||
<p>This variable determines the locale category for any category not
|
||
specifically selected via a variable starting with ‘<code>LC_</code>’.</p>
|
||
<p><span id="index-LC_005fALL"></span></p>
|
||
<p><code>LC_ALL</code> <S></p>
|
||
<p>This variable overrides the value of the ‘<code>LANG</code>’ variable and the value
|
||
of any of the other variables starting with ‘<code>LC_</code>’.</p>
|
||
<p><span id="index-LC_005fCOLLATE"></span></p>
|
||
<p><code>LC_COLLATE</code> <S></p>
|
||
<p>This variable determines the locale category for character collation
|
||
information within ranges in glob brackets and for sorting.</p>
|
||
<p><span id="index-LC_005fCTYPE"></span></p>
|
||
<p><code>LC_CTYPE</code> <S></p>
|
||
<p>This variable determines the locale category for character handling
|
||
functions. If the <code>MULTIBYTE</code> option is in effect this variable or
|
||
<code>LANG</code> should contain a value that reflects the character set in use,
|
||
even if it is a single-byte character set, unless only the 7-bit subset
|
||
(ASCII) is used. For example, if the character set Linux distributions)
|
||
or <code>en_US.ISO8859-1</code> (MacOS).</p>
|
||
<p><span id="index-LC_005fMESSAGES"></span></p>
|
||
<p><code>LC_MESSAGES</code> <S></p>
|
||
<p>This variable determines the language in which messages should be
|
||
written. Note that zsh does not use message catalogs.</p>
|
||
<p><span id="index-LC_005fNUMERIC"></span></p>
|
||
<p><code>LC_NUMERIC</code> <S></p>
|
||
<p>This variable affects the decimal point character and thousands
|
||
separator character for the formatted input/output functions and string
|
||
conversion functions. Note that zsh ignores this setting when parsing
|
||
floating point mathematical expressions.</p>
|
||
<p><span id="index-LC_005fTIME"></span></p>
|
||
<p><code>LC_TIME</code> <S></p>
|
||
<p>This variable determines the locale category for date and time
|
||
formatting in prompt escape sequences.</p>
|
||
<p><span id="index-LINES"></span></p>
|
||
<p><code>LINES</code> <S></p>
|
||
<p>The number of lines for this terminal session. Used for printing select
|
||
lists and for the line editor.</p>
|
||
<p><span id="index-LISTMAX"></span></p>
|
||
<p><code>LISTMAX</code></p>
|
||
<p>In the line editor, the number of matches to list without asking most as
|
||
many lines as given by the absolute value. If set to zero, the shell
|
||
asks only if the top of the listing would scroll off the screen.</p>
|
||
<p><span id="index-LOGCHECK"></span></p>
|
||
<p><code>LOGCHECK</code></p>
|
||
<p>The interval in seconds between checks for login/logout activity using
|
||
the <code>watch</code> parameter.</p>
|
||
<p><span id="index-MAIL"></span></p>
|
||
<p><code>MAIL</code></p>
|
||
<p>If this parameter is set and <code>mailpath</code> is not set, the shell looks for
|
||
mail in the specified file.</p>
|
||
<p><span id="index-MAILCHECK"></span></p>
|
||
<p><code>MAILCHECK</code></p>
|
||
<p>The interval in seconds between checks for new mail.</p>
|
||
<p><span id="index-mailpath"></span> <span id="index-MAILPATH"></span></p>
|
||
<p><code>mailpath</code> <S> <Z> (<code>MAILPATH</code> <S>)</p>
|
||
<p>An array (colon-separated list) of filenames to check for new mail. Each
|
||
filename can be followed by a ‘<code>?</code>’ and a message that will be printed.
|
||
The message will undergo parameter expansion, command substitution and
|
||
arithmetic expansion with the variable <code>$_</code> defined as the name of the
|
||
file that has changed. The default message is ‘<code>You have new mail</code>’. If
|
||
an element is a directory instead of a file the shell will recursively
|
||
check every file in every subdirectory of the element.</p>
|
||
<p><span id="index-manpath"></span> <span id="index-MANPATH"></span></p>
|
||
<p><code>manpath</code> <S> <Z> (<code>MANPATH</code> <S> <Z>)</p>
|
||
<p>An array (colon-separated list) whose value is not used by the shell.
|
||
The <code>manpath</code> array can be useful, however, since setting it also sets
|
||
<code>MANPATH</code>, and vice versa.</p>
|
||
<p><code>match</code></p>
|
||
<p><code>mbegin</code></p>
|
||
<p><code>mend</code></p>
|
||
<p>Arrays set by the shell when the <code>b</code> globbing flag is used in pattern
|
||
matches. See the subsection <em>Globbing flags</em> in <a href="Expansion.html#Filename-Generation">Filename
|
||
Generation</a>.</p>
|
||
<p><code>MATCH</code></p>
|
||
<p><code>MBEGIN</code></p>
|
||
<p><code>MEND</code></p>
|
||
<p>Set by the shell when the <code>m</code> globbing flag is used in pattern matches.
|
||
See the subsection <em>Globbing flags</em> in <a href="Expansion.html#Filename-Generation">Filename
|
||
Generation</a>.</p>
|
||
<p><span id="index-module_005fpath"></span>
|
||
<span id="index-MODULE_005fPATH"></span></p>
|
||
<p><code>module_path</code> <S> <Z> (<code>MODULE_PATH</code> <S>)</p>
|
||
<p>An array (colon-separated list) of directories that <code>zmodload</code> searches
|
||
for dynamically loadable modules. This is initialized to a standard
|
||
pathname, usually ‘<code>/usr/local/lib/zsh/$ZSH_VERSION</code>’. (The
|
||
‘<code>/usr/local/lib</code>’ part varies from installation to installation.) For
|
||
security reasons, any value set in the environment when the shell is
|
||
started will be ignored.</p>
|
||
<p>These parameters only exist if the installation supports dynamic module
|
||
loading.</p>
|
||
<p><span id="index-NULLCMD"></span>
|
||
<span id="index-null-command-style"></span>
|
||
<span id="index-csh_002c-null-command-style"></span>
|
||
<span id="index-ksh_002c-null-command-style"></span></p>
|
||
<p><code>NULLCMD</code> <S></p>
|
||
<p>The command name to assume if a redirection is specified with no
|
||
command. Defaults to <code>cat</code>. For sh/ksh behavior, change this to <code>:</code>. For
|
||
csh-like behavior, unset this parameter; the shell will print an error
|
||
message if null commands are entered.</p>
|
||
<p><span id="index-path"></span> <span id="index-PATH"></span></p>
|
||
<p><code>path</code> <S> <Z> (<code>PATH</code> <S>)</p>
|
||
<p>An array (colon-separated list) of directories to search for commands.
|
||
When this parameter is set, each directory is scanned</p>
|
||
<p><span id="index-POSTEDIT"></span></p>
|
||
<p><code>POSTEDIT</code> <S></p>
|
||
<p>This string is output whenever the line editor exits. It usually
|
||
contains termcap strings to reset the terminal.</p>
|
||
<p><span id="index-PROMPT"></span></p>
|
||
<p><code>PROMPT</code> <S> <Z></p>
|
||
<p><span id="index-PROMPT2"></span></p>
|
||
<p><code>PROMPT2</code> <S> <Z></p>
|
||
<p><span id="index-PROMPT3"></span></p>
|
||
<p><code>PROMPT3</code> <S> <Z></p>
|
||
<p><span id="index-PROMPT4"></span></p>
|
||
<p><code>PROMPT4</code> <S> <Z></p>
|
||
<p>Same as <code>PS1</code>, <code>PS2</code>, <code>PS3</code> and <code>PS4</code>, respectively.</p>
|
||
<p><span id="index-prompt"></span></p>
|
||
<p><code>prompt</code> <S> <Z></p>
|
||
<p>Same as <code>PS1</code>.</p>
|
||
<p><span id="index-PROMPT_005fEOL_005fMARK"></span></p>
|
||
<p><code>PROMPT_EOL_MARK</code></p>
|
||
<p>When the <code>PROMPT_CR</code> and <code>PROMPT_SP</code> options are set, the
|
||
<code>PROMPT_EOL_MARK</code> parameter can be used to customize how the end of
|
||
partial lines are shown. This parameter undergoes prompt expansion, with
|
||
the <code>PROMPT_PERCENT</code> option set. If not set, the default behavior is
|
||
equivalent to the value ‘<code>%B%S%#%s%b</code>’.</p>
|
||
<p><span id="index-PS1"></span></p>
|
||
<p><code>PS1</code> <S></p>
|
||
<p>The primary prompt string, printed before a command is read. It
|
||
undergoes a special form of expansion before being displayed; see
|
||
<a href="Prompt-Expansion.html#Prompt-Expansion">Prompt Expansion</a>. The default
|
||
is ‘<code>%m%# </code>’.</p>
|
||
<p><span id="index-PS2"></span></p>
|
||
<p><code>PS2</code> <S></p>
|
||
<p>The secondary prompt, printed when the shell needs more information to
|
||
complete a command. It is expanded in the same way as <code>PS1</code>. The default
|
||
is ‘<code>%_> </code>’, which displays any shell constructs or quotation marks
|
||
which are currently being processed.</p>
|
||
<p><span id="index-PS3"></span></p>
|
||
<p><code>PS3</code> <S></p>
|
||
<p>Selection prompt used within a <code>select</code> loop. It is expanded in the same
|
||
way as <code>PS1</code>. The default is ‘<code>?# </code>’.</p>
|
||
<p><span id="index-PS4"></span></p>
|
||
<p><code>PS4</code> <S></p>
|
||
<p>The execution trace prompt. Default is ‘<code>+%N:%i> </code>’, which displays
|
||
the name of the current shell structure and the line number within it.
|
||
In sh or ksh emulation, the default is ‘<code>+ </code>’.</p>
|
||
<p><span id="index-psvar"></span> <span id="index-PSVAR"></span></p>
|
||
<p><code>psvar</code> <S> <Z> (<code>PSVAR</code> <S>)</p>
|
||
<p>An array (colon-separated list) whose elements can be used in <code>PROMPT</code>
|
||
strings. Setting <code>psvar</code> also sets <code>PSVAR</code>, and vice versa.</p>
|
||
<p><span id="index-READNULLCMD"></span></p>
|
||
<p><code>READNULLCMD</code> <S></p>
|
||
<p>The command name to assume if a single input redirection is specified
|
||
with no command. Defaults to <code>more</code>.</p>
|
||
<p><span id="index-REPORTMEMORY"></span></p>
|
||
<p><code>REPORTMEMORY</code></p>
|
||
<p>If nonnegative, commands whose maximum resident set size (roughly
|
||
speaking, main memory usage) in kilobytes is greater than this value
|
||
have timing statistics reported. The format used to output statistics is
|
||
the value of the <code>TIMEFMT</code> parameter, which is the same as for the
|
||
<code>REPORTTIME</code> variable and the <code>time</code> builtin; note that by default this
|
||
does not output memory usage. Appending <code>" max RSS %M"</code> to the value of
|
||
<code>TIMEFMT</code> causes it to output the value that triggered the report. If
|
||
<code>REPORTTIME</code> is also in use, at most a single report is printed for both
|
||
triggers. This feature requires the <code>getrusage()</code> system call, commonly
|
||
supported by modern Unix-like systems.</p>
|
||
<p><span id="index-REPORTTIME"></span></p>
|
||
<p><code>REPORTTIME</code></p>
|
||
<p>If nonnegative, commands whose combined user and system execution times
|
||
(measured in seconds) are greater than this value have timing statistics
|
||
printed for them. Output is suppressed for commands executed within the
|
||
line editor, including completion; commands explicitly marked with the
|
||
<code>time</code> keyword still cause the summary to be printed in this case.</p>
|
||
<p><span id="index-REPLY"></span></p>
|
||
<p><code>REPLY</code></p>
|
||
<p>This parameter is reserved by convention to pass string values between
|
||
shell scripts and shell builtins in situations where a function call or
|
||
redirection are impossible or undesirable. The <code>read</code> builtin and the
|
||
<code>select</code> complex command may set <code>REPLY</code>, and filename generation both
|
||
sets and examines its value when evaluating certain expressions. Some
|
||
modules also employ <code>REPLY</code> for similar purposes.</p>
|
||
<p><span id="index-reply"></span></p>
|
||
<p><code>reply</code></p>
|
||
<p>As <code>REPLY</code>, but for array values rather than strings.</p>
|
||
<p><span id="index-RPROMPT"></span></p>
|
||
<p><code>RPROMPT</code> <S></p>
|
||
<p><span id="index-RPS1"></span></p>
|
||
<p><code>RPS1</code> <S></p>
|
||
<p>This prompt is displayed on the right-hand side of the screen when the
|
||
primary prompt is being displayed on the left. This does not work if the
|
||
<code>SINGLE_LINE_ZLE</code> option is set. It is expanded in the same way as
|
||
<code>PS1</code>.</p>
|
||
<p><span id="index-RPROMPT2"></span></p>
|
||
<p><code>RPROMPT2</code> <S></p>
|
||
<p><span id="index-RPS2"></span></p>
|
||
<p><code>RPS2</code> <S></p>
|
||
<p>This prompt is displayed on the right-hand side of the screen when the
|
||
secondary prompt is being displayed on the left. This does not work if
|
||
the <code>SINGLE_LINE_ZLE</code> option is set. It is expanded in the same way as
|
||
<code>PS2</code>.</p>
|
||
<p><span id="index-SAVEHIST"></span></p>
|
||
<p><code>SAVEHIST</code></p>
|
||
<p>The maximum number of history events to save in the history file.</p>
|
||
<p>If this is made local, it is not implicitly set to 0, but may be
|
||
explicitly set locally.</p>
|
||
<p><span id="index-SPROMPT"></span></p>
|
||
<p><code>SPROMPT</code> <S></p>
|
||
<p>The prompt used for spelling correction. The sequence ‘<code>%R</code>’ expands to
|
||
the string which presumably needs spelling correction, and ‘<code>%r</code>’
|
||
expands to the proposed correction. All other prompt escapes are also
|
||
allowed.</p>
|
||
<p>The actions available at the prompt are <code>[nyae]</code>:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>n</code> (‘no’) (default)<br />
|
||
Discard the correction and run the command.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>y</code> (‘yes’)<br />
|
||
Make the correction and run the command.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>a</code> (‘abort’)<br />
|
||
Discard the entire command line without running it.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>e</code> (‘edit’)<br />
|
||
Resume editing the command line.</p>
|
||
</li>
|
||
</ul>
|
||
<p><span id="index-STTY"></span></p>
|
||
<p><code>STTY</code></p>
|
||
<p>If this parameter is set in a command’s environment, the shell runs the
|
||
<code>stty</code> command with the value of this parameter as arguments in order to
|
||
set up the terminal before executing the command. The modes apply only
|
||
to the command, and are reset when it finishes or is suspended. If the
|
||
command is suspended and continued later with the <code>fg</code> or <code>wait</code>
|
||
builtins it will see the modes specified by <code>STTY</code>, as if it were not
|
||
suspended. This (intentionally) does not apply if the command is
|
||
continued via ‘<code>kill -CONT</code>’. <code>STTY</code> is ignored if the command is run in
|
||
the background, or if it is in the environment of the shell but not
|
||
explicitly assigned to in the input line. This avoids running stty at
|
||
every external command by accidentally exporting it. Also note that
|
||
<code>STTY</code> should not be used for window size specifications; these will not
|
||
be local to the command.</p>
|
||
<p><span id="index-TERM"></span></p>
|
||
<p><code>TERM</code> <S></p>
|
||
<p>The type of terminal in use. This is used when looking up termcap
|
||
sequences. An assignment to <code>TERM</code> causes zsh to re-initialize the
|
||
terminal, even if the value does not change (e.g., ‘<code>TERM=$TERM</code>’). It
|
||
is necessary to make such an assignment upon any change to the terminal
|
||
definition database or terminal type in order for the new settings to
|
||
take effect.</p>
|
||
<p><span id="index-TERMINFO"></span></p>
|
||
<p><code>TERMINFO</code> <S></p>
|
||
<p>A reference to your terminfo database, used by the ‘terminfo’ library
|
||
when the system has it; see man page terminfo(5). If set, this causes
|
||
the shell to reinitialise the terminal, making the workaround
|
||
‘<code>TERM=$TERM</code>’ unnecessary.</p>
|
||
<p><span id="index-TERMINFO_005fDIRS"></span></p>
|
||
<p><code>TERMINFO_DIRS</code> <S></p>
|
||
<p>A colon-seprarated list of terminfo databases, used by the ‘terminfo’
|
||
library when the system has it; see man page terminfo(5). This variable
|
||
is only used by certain terminal libraries, in particular ncurses; see
|
||
man page terminfo(5) to check support on your system. If set, this
|
||
causes the shell to reinitialise the terminal, making the workaround
|
||
‘<code>TERM=$TERM</code>’ unnecessary. Note that unlike other colon-separated
|
||
arrays this is not tied to a zsh array.</p>
|
||
<p><span id="index-TIMEFMT"></span></p>
|
||
<p><code>TIMEFMT</code></p>
|
||
<p>The format of process time reports with the <code>time</code> keyword. The default
|
||
is ‘<code>%J %U user %S system %P cpu %*E total</code>’. Recognizes the following
|
||
escape sequences, although not all may be available on all systems, and
|
||
some that are available may not be useful:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>%%</code><br />
|
||
A ‘<code>%</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%U</code><br />
|
||
CPU seconds spent in user mode.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%S</code><br />
|
||
CPU seconds spent in kernel mode.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%E</code><br />
|
||
Elapsed time in seconds.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%P</code><br />
|
||
The CPU percentage, computed as 100*(<code>%U</code>+<code>%S</code>)/<code>%E</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%W</code><br />
|
||
Number of times the process was swapped.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%X</code><br />
|
||
The average amount in (shared) text space used in kilobytes.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%D</code><br />
|
||
The average amount in (unshared) data/stack space used in kilobytes.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%K</code><br />
|
||
The total space used (<code>%X</code>+<code>%D</code>) in kilobytes.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%M</code><br />
|
||
The maximum memory the process had in use at any time in kilobytes.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%F</code><br />
|
||
The number of major page faults (page needed to be brought from
|
||
disk).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%R</code><br />
|
||
The number of minor page faults.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%I</code><br />
|
||
The number of input operations.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%O</code><br />
|
||
The number of output operations.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%r</code><br />
|
||
The number of socket messages received.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%s</code><br />
|
||
The number of socket messages sent.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%k</code><br />
|
||
The number of signals received.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%w</code><br />
|
||
Number of voluntary context switches (waits).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%c</code><br />
|
||
Number of involuntary context switches.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%J</code><br />
|
||
The name of this job.</p>
|
||
</li>
|
||
</ul>
|
||
<p>A star may be inserted between the percent sign and flags printing time
|
||
(e.g., ‘<code>%*E</code>’); this causes the time to be printed in
|
||
‘<code>hh``:``mm``:``ss``.``ttt</code>’ format (hours and minutes are only
|
||
printed if they are not zero). Alternatively, ‘<code>m</code>’ or ‘<code>u</code>’ may be used
|
||
(e.g., ‘<code>%mE</code>’) to produce time output in milliseconds or microseconds,
|
||
respectively.</p>
|
||
<p><span id="index-TMOUT"></span></p>
|
||
<p><code>TMOUT</code></p>
|
||
<p>If this parameter is nonzero, the shell will receive an <code>ALRM</code> signal if
|
||
a command is not entered within the specified number of seconds after
|
||
issuing a prompt. If there is a trap on <code>SIGALRM</code>, it will be executed
|
||
and a new alarm is scheduled using the value of the <code>TMOUT</code> parameter
|
||
after executing the trap. If no trap is set, and the idle time of the
|
||
terminal is not less than the value of the <code>TMOUT</code> parameter, zsh
|
||
terminates. Otherwise a new alarm is scheduled to <code>TMOUT</code> seconds after
|
||
the last keypress.</p>
|
||
<p><span id="index-TMPPREFIX"></span></p>
|
||
<p><code>TMPPREFIX</code></p>
|
||
<p>A pathname prefix which the shell will use for all temporary files. Note
|
||
that this should include an initial part for the file name as well as
|
||
any directory names. The default is ‘<code>/tmp/zsh</code>’.</p>
|
||
<p><span id="index-TMPSUFFIX"></span></p>
|
||
<p><code>TMPSUFFIX</code></p>
|
||
<p>A filename suffix which the shell will use for temporary files created
|
||
by process substitutions (e.g., ‘<code>=(list)</code>’). Note that the value should
|
||
include a leading dot ‘<code>.</code>’ if intended to be interpreted as a file
|
||
extension. The default is not to append any suffix, thus this parameter
|
||
should be assigned only when needed and then unset again.</p>
|
||
<p><span id="index-watch"></span> <span id="index-WATCH"></span></p>
|
||
<p><code>watch</code> <S> <Z> (<code>WATCH</code> <S>)</p>
|
||
<p>An array (colon-separated list) of login/logout events to report.</p>
|
||
<p>If it contains the single word ‘<code>all</code>’, then all login/logout events are
|
||
reported. If it contains the single word ‘<code>notme</code>’, then all events are
|
||
reported as with ‘<code>all</code>’ except <code>$USERNAME</code>.</p>
|
||
<p>An entry in this list may consist of a username, an ‘<code>@</code>’ followed by a
|
||
remote hostname, and a ‘<code>%</code>’ followed by a line (tty). Any of these may
|
||
be a pattern (be sure to quote this during the assignment to <code>watch</code> so
|
||
that it does not immediately perform file generation); the setting of
|
||
the <code>EXTENDED_GLOB</code> option is respected. Any or all of these components
|
||
may be present in an entry; if a login/logout event matches all of them,
|
||
it is reported.</p>
|
||
<p>For example, with the <code>EXTENDED_GLOB</code> option set, the following:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">watch=('^(pws|barts)')
|
||
</code></pre>
|
||
</div>
|
||
<p>causes reports for activity associated with any user other than <code>pws</code> or
|
||
<code>barts</code>.</p>
|
||
<p><span id="index-WATCHFMT"></span></p>
|
||
<p><code>WATCHFMT</code></p>
|
||
<p>The format of login/logout reports if the <code>watch</code> parameter is set.
|
||
Default is ‘<code>%n has %a %l from %m</code>’. Recognizes the following escape
|
||
sequences:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>%n</code><br />
|
||
The name of the user that logged in/out.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%a</code><br />
|
||
The observed action, i.e. "logged on" or "logged off".</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%l</code><br />
|
||
The line (tty) the user is logged in on.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%M</code><br />
|
||
The full hostname of the remote host.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%m</code><br />
|
||
The hostname up to the first ‘<code>.</code>’. If only the IP address is
|
||
available or the utmp field contains the name of an X-windows
|
||
display, the whole name is printed.</p>
|
||
<p><em>NOTE:</em> The ‘<code>%m</code>’ and ‘<code>%M</code>’ escapes will work only if there is a
|
||
host name field in the utmp on your machine. Otherwise they are
|
||
treated as ordinary strings.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%S</code> (<code>%s</code>)<br />
|
||
Start (stop) standout mode.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%U</code> (<code>%u</code>)<br />
|
||
Start (stop) underline mode.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%B</code> (<code>%b</code>)<br />
|
||
Start (stop) boldface mode.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%t</code><br />
|
||
<code>%@</code><br />
|
||
The time, in 12-hour, am/pm format.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%T</code><br />
|
||
The time, in 24-hour format.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%w</code><br />
|
||
The date in ‘<code>day``-``dd</code>’ format.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%W</code><br />
|
||
The date in ‘<code>mm``/``dd``/``yy</code>’ format.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%D</code><br />
|
||
The date in ‘<code>yy``-``mm``-``dd</code>’ format.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%D{``string``}</code><br />
|
||
The date formatted as <code>string</code> using the <code>strftime</code> function, with
|
||
zsh extensions as described by <a href="Prompt-Expansion.html#Prompt-Expansion">Prompt
|
||
Expansion</a>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%(``x``:``true-text``:``false-text``)</code><br />
|
||
Specifies a ternary expression. The character following the <code>x</code> is
|
||
arbitrary; the same character is used to separate the text for the
|
||
"true" result from that for the "false" result. Both the separator
|
||
and the right parenthesis may be escaped with a backslash. Ternary
|
||
expressions may be nested.</p>
|
||
<p>The test character <code>x</code> may be any one of ‘<code>l</code>’, ‘<code>n</code>’, ‘<code>m</code>’ or
|
||
‘<code>M</code>’, which indicate a ‘true’ result if the corresponding
|
||
escape sequence would return a non-empty value; or it may be ‘<code>a</code>’,
|
||
which indicates a ‘true’ result if the watched user has logged in,
|
||
or ‘false’ if he has logged out. Other characters evaluate to
|
||
neither true nor false; the entire expression is omitted in this
|
||
case.</p>
|
||
<p>If the result is ‘true’, then the <code>true-text</code> is formatted according
|
||
to the rules above and printed, and the <code>false-text</code> is skipped. If
|
||
‘false’, the <code>true-text</code> is skipped and the <code>false-text</code> is
|
||
formatted and printed. Either or both of the branches may be empty,
|
||
but both separators must be present in any case.</p>
|
||
</li>
|
||
</ul>
|
||
<p><span id="index-WORDCHARS"></span></p>
|
||
<p><code>WORDCHARS</code> <S></p>
|
||
<p>A list of non-alphanumeric characters considered part of a word by the
|
||
line editor.</p>
|
||
<p><span id="index-ZBEEP"></span></p>
|
||
<p><code>ZBEEP</code></p>
|
||
<p>If set, this gives a string of characters, which can use all the same
|
||
codes as the <code>bindkey</code> command as described in <a href="Zsh-Modules.html#The-zsh_002fzle-Module">The zsh/zle
|
||
Module</a>, that will be output to
|
||
the terminal instead of beeping. This may have a visible instead of an
|
||
audible effect; for example, the string ‘<code>\e[?5h\e[?5l</code>’ on a vt100 or
|
||
xterm will have the effect of flashing reverse video on and off (if you
|
||
usually use reverse video, you should use the string ‘<code>\e[?5l\e[?5h</code>’
|
||
instead). This takes precedence over the <code>NOBEEP</code> option.</p>
|
||
<p><span id="index-ZDOTDIR"></span></p>
|
||
<p><code>ZDOTDIR</code></p>
|
||
<p>The directory to search for shell startup files (.zshrc, etc), if not
|
||
<code>$HOME</code>.</p>
|
||
<p><span id="index-zle_005fbracketed_005fpaste"></span>
|
||
<span id="index-bracketed-paste"></span>
|
||
<span id="index-enabling-bracketed-paste"></span></p>
|
||
<p><code>zle_bracketed_paste</code></p>
|
||
<p>Many terminal emulators have a feature that allows applications to
|
||
identify when text is pasted into the terminal rather than being typed
|
||
normally. For ZLE, this means that special characters such as tabs and
|
||
newlines can be inserted instead of invoking editor commands.
|
||
Furthermore, pasted text forms a single undo event and if the region is
|
||
active, pasted text will replace the region.</p>
|
||
<p>This two-element array contains the terminal escape sequences for
|
||
enabling and disabling the feature. These escape sequences are used to
|
||
enable bracketed paste when ZLE is active and disable it at other times.
|
||
Unsetting the parameter has the effect of ensuring that bracketed paste
|
||
remains disabled.</p>
|
||
<p><span id="index-zle_005fhighlight"></span></p>
|
||
<p><code>zle_highlight</code></p>
|
||
<p>An array describing contexts in which ZLE should highlight the input
|
||
text. See <a href="Zsh-Line-Editor.html#Character-Highlighting">Character
|
||
Highlighting</a>.</p>
|
||
<p><span id="index-ZLE_005fLINE_005fABORTED"></span></p>
|
||
<p><code>ZLE_LINE_ABORTED</code></p>
|
||
<p>This parameter is set by the line editor when an error occurs. It
|
||
contains the line that was being edited at the point of the error.
|
||
‘<code>print -zr – $ZLE_LINE_ABORTED</code>’ can be used to recover the line.
|
||
Only the most recent line of this kind is remembered.</p>
|
||
<p><span id="index-ZLE_005fREMOVE_005fSUFFIX_005fCHARS"></span>
|
||
<span id="index-ZLE_005fSPACE_005fSUFFIX_005fCHARS"></span></p>
|
||
<p><code>ZLE_REMOVE_SUFFIX_CHARS</code></p>
|
||
<p><code>ZLE_SPACE_SUFFIX_CHARS</code></p>
|
||
<p>These parameters are used by the line editor. In certain circumstances
|
||
suffixes (typically space or slash) added by the completion system will
|
||
be removed automatically, either because the next editing command as
|
||
requiring the suffix to be removed.</p>
|
||
<p>These variables can contain the sets of characters that will cause the
|
||
suffix to be removed. If <code>ZLE_REMOVE_SUFFIX_CHARS</code> is set, those
|
||
characters will cause the suffix to be removed; if
|
||
<code>ZLE_SPACE_SUFFIX_CHARS</code> is set, those characters will cause the suffix
|
||
to be removed and replaced by a space.</p>
|
||
<p>If <code>ZLE_REMOVE_SUFFIX_CHARS</code> is not set, the default behaviour is
|
||
equivalent to:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">ZLE_REMOVE_SUFFIX_CHARS=$' \t\n;&|'
|
||
</code></pre>
|
||
</div>
|
||
<p>If <code>ZLE_REMOVE_SUFFIX_CHARS</code> is set but is empty, no characters have
|
||
this behaviour. <code>ZLE_SPACE_SUFFIX_CHARS</code> takes precedence, so that the
|
||
following:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">ZLE_SPACE_SUFFIX_CHARS=$'&|'
|
||
</code></pre>
|
||
</div>
|
||
<p>causes the characters ‘<code>&</code>’ and ‘<code>|</code>’ to remove the suffix but to
|
||
replace it with a space.</p>
|
||
<p>To illustrate the difference, suppose that the option
|
||
<code>AUTO_REMOVE_SLASH</code> is in effect and the directory <code>DIR</code> has just been
|
||
completed, with an appended <code>/</code>, following which the user types ‘<code>&</code>’.
|
||
The default result is ‘<code>DIR&</code>’. With <code>ZLE_REMOVE_SUFFIX_CHARS</code> set but
|
||
without including ‘<code>&</code>’ the result is ‘<code>DIR/&</code>’. With
|
||
<code>ZLE_SPACE_SUFFIX_CHARS</code> set to include ‘<code>&</code>’ the result is ‘<code>DIR &</code>’.</p>
|
||
<p>Note that certain completions may provide their own suffix removal or
|
||
replacement behaviour which overrides the values described here. See the
|
||
completion system documentation in <a href="Completion-System.html#Completion-System">Completion
|
||
System</a>.</p>
|
||
<p><span id="index-ZLE_005fRPROMPT_005fINDENT"></span></p>
|
||
<p><code>ZLE_RPROMPT_INDENT</code> <S></p>
|
||
<p>If set, used to give the indentation between the right hand side of the
|
||
right prompt in the line editor as given by <code>RPS1</code> or <code>RPROMPT</code> and the
|
||
right hand side of the screen. If not set, the value 1 is used.</p>
|
||
<p>Typically this will be used to set the value to 0 so that the prompt
|
||
appears flush with the right hand side of the screen. This is not the
|
||
default as many terminals do not handle this correctly, in particular
|
||
when the prompt appears at the extreme bottom right of the screen.
|
||
Recent virtual terminals are more likely to handle this case correctly.
|
||
Some experimentation is necessary.</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>
|
||
<!-- 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="Options.html#16-options">16 Options</a>
|
||
<ul>
|
||
<li><a href="Options.html#161-specifying-options">16.1 Specifying Options</a></li>
|
||
<li><a href="Options.html#162-description-of-options">16.2 Description of Options</a>
|
||
<ul>
|
||
<li><a href="Options.html#1621-changing-directories">16.2.1 Changing Directories</a></li>
|
||
<li><a href="Options.html#1622-completion">16.2.2 Completion</a></li>
|
||
<li><a href="Options.html#1623-expansion-and-globbing">16.2.3 Expansion and Globbing</a></li>
|
||
<li><a href="Options.html#1624-history">16.2.4 History</a></li>
|
||
<li><a href="Options.html#1625-initialisation">16.2.5 Initialisation</a></li>
|
||
<li><a href="Options.html#1626-inputoutput">16.2.6 Input/Output</a></li>
|
||
<li><a href="Options.html#1627-job-control">16.2.7 Job Control</a></li>
|
||
<li><a href="Options.html#1628-prompting">16.2.8 Prompting</a></li>
|
||
<li><a href="Options.html#1629-scripts-and-functions">16.2.9 Scripts and Functions</a></li>
|
||
<li><a href="Options.html#16210-shell-emulation">16.2.10 Shell Emulation</a></li>
|
||
<li><a href="Options.html#16211-shell-state">16.2.11 Shell State</a></li>
|
||
<li><a href="Options.html#16212-zle">16.2.12 Zle</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Options.html#163-option-aliases">16.3 Option Aliases</a></li>
|
||
<li><a href="Options.html#164-single-letter-options">16.4 Single Letter Options</a>
|
||
<ul>
|
||
<li><a href="Options.html#1641-default-set">16.4.1 Default set</a></li>
|
||
<li><a href="Options.html#1642-shksh-emulation-set">16.4.2 sh/ksh emulation set</a></li>
|
||
<li><a href="Options.html#1643-also-note">16.4.3 Also note</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Options"></span> <span id="Options-1"></span></p>
|
||
<h1 id="16-options"><a class="header" href="#16-options">16 Options</a></h1>
|
||
<p><span id="index-options"></span></p>
|
||
<hr />
|
||
<p><span id="Specifying-Options"></span>
|
||
<span id="Specifying-Options-1"></span></p>
|
||
<h2 id="161-specifying-options"><a class="header" href="#161-specifying-options">16.1 Specifying Options</a></h2>
|
||
<p><span id="index-options_002c-specifying"></span></p>
|
||
<p>Options are primarily referred to by name. These names are case
|
||
insensitive and underscores are ignored. For example, ‘<code>allexport</code>’ is
|
||
equivalent to ‘<code>A__lleXP_ort</code>’.</p>
|
||
<p>The sense of an option name may be inverted by preceding it with ‘<code>no</code>’,
|
||
so ‘<code>setopt No_Beep</code>’ is equivalent to ‘<code>unsetopt beep</code>’. This inversion
|
||
can only be done once, so ‘<code>nonobeep</code>’ is <em>not</em> a synonym for ‘<code>beep</code>’.
|
||
Similarly, ‘<code>tify</code>’ is not a synonym for ‘<code>nonotify</code>’ (the inversion of
|
||
‘<code>notify</code>’).</p>
|
||
<p>Some options also have one or more single letter names. There are two
|
||
sets of single letter options: one used by default, and another used to
|
||
emulate sh/ksh (used when the <code>SH_OPTION_LETTERS</code> option is set). The
|
||
single letter options can be used on the shell command line, or with the
|
||
<code>set</code>, <code>setopt</code> and <code>unsetopt</code> builtins, as normal Unix options preceded
|
||
by ‘<code>-</code>’.</p>
|
||
<p>The sense of the single letter options may be inverted by using ‘<code>+</code>’
|
||
instead of ‘<code>-</code>’. Some of the single letter option names refer to an
|
||
option being off, in which case the inversion of that name refers to the
|
||
option being on. For example, ‘<code>+n</code>’ is the short name of ‘<code>exec</code>’, and
|
||
‘<code>-n</code>’ is the short name of its inversion, ‘<code>noexec</code>’.</p>
|
||
<p>In strings of single letter options supplied to the shell at startup,
|
||
trailing whitespace will be ignored; for example the string ‘<code>-f </code>’
|
||
will be treated just as ‘<code>-f</code>’, but the string ‘<code>-f i</code>’ is an error.
|
||
This is because many systems which implement the ‘<code>#!</code>’ mechanism for
|
||
calling scripts do not strip trailing whitespace.</p>
|
||
<hr />
|
||
<p><span id="Description-of-Options"></span>
|
||
<span id="Description-of-Options-1"></span></p>
|
||
<h2 id="162-description-of-options"><a class="header" href="#162-description-of-options">16.2 Description of Options</a></h2>
|
||
<p><span id="index-options_002c-description"></span></p>
|
||
<p>In the following list, options set by default in all emulations are
|
||
marked <D>; those set by default only in csh, ksh, sh, or zsh
|
||
emulations are marked <C>, <K>, <S>, <Z> as appropriate. When
|
||
listing options (by ‘<code>setopt</code>’, ‘<code>unsetopt</code>’, ‘<code>set -o</code>’ or ‘<code>set +o</code>’),
|
||
those turned on by default appear in the list prefixed with ‘<code>no</code>’.
|
||
Hence (unless <code>KSH_OPTION_PRINT</code> is set), ‘<code>setopt</code>’ shows all options
|
||
whose settings are changed from the default.</p>
|
||
<hr />
|
||
<p><span id="Changing-Directories"></span></p>
|
||
<h3 id="1621-changing-directories"><a class="header" href="#1621-changing-directories">16.2.1 Changing Directories</a></h3>
|
||
<p><span id="index-AUTO_005fCD"></span>
|
||
<span id="index-NO_005fAUTO_005fCD"></span>
|
||
<span id="index-AUTOCD"></span> <span id="index-NOAUTOCD"></span>
|
||
<span id="index-cd_002c-automatic"></span></p>
|
||
<p><code>AUTO_CD</code> (<code>-J</code>)</p>
|
||
<p>If a command is issued that can’t be executed as a normal command, and
|
||
the command is the name of a directory, perform the <code>cd</code> command to that
|
||
directory. This option is only applicable if the option <code>SHIN_STDIN</code> is
|
||
set, i.e. if commands are being read from standard input. The option is
|
||
designed for interactive use; it is recommended that <code>cd</code> be used
|
||
explicitly in scripts to avoid ambiguity.</p>
|
||
<p><span id="index-AUTO_005fPUSHD"></span>
|
||
<span id="index-NO_005fAUTO_005fPUSHD"></span>
|
||
<span id="index-AUTOPUSHD"></span> <span id="index-NOAUTOPUSHD"></span>
|
||
<span id="index-cd_002c-behaving-like-pushd"></span>
|
||
<span id="index-pushd_002c-making-cd-behave-like"></span></p>
|
||
<p><code>AUTO_PUSHD</code> (<code>-N</code>)</p>
|
||
<p>Make <code>cd</code> push the old directory onto the directory stack.</p>
|
||
<p><span id="index-CDABLE_005fVARS"></span>
|
||
<span id="index-NO_005fCDABLE_005fVARS"></span>
|
||
<span id="index-CDABLEVARS"></span>
|
||
<span id="index-NOCDABLEVARS"></span>
|
||
<span id="index-cd_002c-to-parameter"></span></p>
|
||
<p><code>CDABLE_VARS</code> (<code>-T</code>)</p>
|
||
<p>If the argument to a <code>cd</code> command (or an implied <code>cd</code> with the <code>AUTO_CD</code>
|
||
option set) is not a directory, and does not begin with a slash, try to
|
||
expand the expression as if it were preceded by a ‘<code>~</code>’ (see <a href="Expansion.html#Filename-Expansion">Filename
|
||
Expansion</a>).</p>
|
||
<p><span id="index-CD_005fSILENT"></span>
|
||
<span id="index-NO_005fCD_005fSILENT"></span>
|
||
<span id="index-CDSILENT"></span> <span id="index-NOCDSILENT"></span>
|
||
<span id="index-cd_002c-silencing"></span>
|
||
<span id="index-autocd_002c-silencing"></span></p>
|
||
<p><code>CD_SILENT</code></p>
|
||
<p>Never print the working directory after a <code>cd</code> (whether explicit or
|
||
implied with the <code>AUTO_CD</code> option set). <code>cd</code> normally prints the working
|
||
directory when the argument given to it was <code>-</code>, a stack entry, or the
|
||
name of a directory found under <code>CDPATH</code>. Note that this is distinct
|
||
from <code>pushd</code>’s stack-printing behaviour, which is controlled by
|
||
<code>PUSHD_SILENT</code>. This option overrides the printing-related effects of
|
||
<code>POSIX_CD</code>.</p>
|
||
<p><span id="index-CHASE_005fDOTS"></span>
|
||
<span id="index-NO_005fCHASE_005fDOTS"></span>
|
||
<span id="index-CHASEDOTS"></span> <span id="index-NOCHASEDOTS"></span>
|
||
<span id="index-cd_002c-with-_002e_002e-in-argument"></span></p>
|
||
<p><code>CHASE_DOTS</code></p>
|
||
<p>When changing to a directory containing a path segment ‘<code>..</code>’ which
|
||
would otherwise be treated as canceling the previous segment in the path
|
||
(in other words, ‘<code>foo/..</code>’ would be removed from the path, or if ‘<code>..</code>’
|
||
is the first part of the path, the last part of the current working
|
||
directory would be removed), instead resolve the path to the physical
|
||
directory. This option is overridden by <code>CHASE_LINKS</code>.</p>
|
||
<p>For example, suppose <code>/foo/bar</code> is a link to the directory <code>/alt/rod</code>.
|
||
Without this option set, ‘<code>cd /foo/bar/..</code>’ changes to <code>/foo</code>; with it
|
||
set, it changes to <code>/alt</code>. The same applies if the current directory is
|
||
<code>/foo/bar</code> and ‘<code>cd ..</code>’ is used. Note that all other symbolic links in
|
||
the path will also be resolved.</p>
|
||
<p><span id="index-CHASE_005fLINKS"></span>
|
||
<span id="index-NO_005fCHASE_005fLINKS"></span>
|
||
<span id="index-CHASELINKS"></span>
|
||
<span id="index-NOCHASELINKS"></span>
|
||
<span id="index-links_002c-symbolic"></span>
|
||
<span id="index-symbolic-links"></span></p>
|
||
<p><code>CHASE_LINKS</code> (<code>-w</code>)</p>
|
||
<p>Resolve symbolic links to their true values when changing directory.
|
||
This also has the effect of <code>CHASE_DOTS</code>, i.e. a ‘<code>..</code>’ path segment
|
||
will be treated as referring to the physical parent, even if the
|
||
preceding path segment is a symbolic link.</p>
|
||
<p><span id="index-POSIX_005fCD"></span> <span id="index-POSIXCD"></span>
|
||
<span id="index-NO_005fPOSIX_005fCD"></span>
|
||
<span id="index-NOPOSIXCD"></span>
|
||
<span id="index-CDPATH_002c-order-of-checking"></span></p>
|
||
<p><code>POSIX_CD</code> <K> <S></p>
|
||
<p>Modifies the behaviour of <code>cd</code>, <code>chdir</code> and <code>pushd</code> commands to make
|
||
them more compatible with the POSIX standard. The behaviour with the
|
||
option unset is described in the documentation for the <code>cd</code> builtin in
|
||
<a href="Shell-Builtin-Commands.html#Shell-Builtin-Commands">Shell Builtin
|
||
Commands</a>. If the
|
||
option is set, the shell does not test for directories beneath the local
|
||
directory (‘<code>.</code>’) until after all directories in <code>cdpath</code> have been
|
||
tested, and the <code>cd</code> and <code>chdir</code> commands do not recognise arguments of
|
||
the form ‘{<code>+</code>|<code>-</code>}<code>n</code>’ as directory stack entries.</p>
|
||
<p>Also, if the option is set, the conditions under which the shell prints
|
||
the new directory after changing to it are modified. It is no longer
|
||
restricted to interactive shells (although printing of the directory
|
||
stack with <code>pushd</code> is still limited to interactive shells); and any use
|
||
of a component of <code>CDPATH</code>, including a ‘<code>.</code>’ but excluding an empty
|
||
component that is otherwise treated as ‘<code>.</code>’, causes the directory to be
|
||
printed.</p>
|
||
<p><span id="index-PUSHD_005fIGNORE_005fDUPS"></span>
|
||
<span id="index-NO_005fPUSHD_005fIGNORE_005fDUPS"></span>
|
||
<span id="index-PUSHDIGNOREDUPS"></span>
|
||
<span id="index-NOPUSHDIGNOREDUPS"></span>
|
||
<span id="index-directory-stack_002c-ignoring-duplicates"></span></p>
|
||
<p><code>PUSHD_IGNORE_DUPS</code></p>
|
||
<p>Don’t push multiple copies of the same directory onto the directory
|
||
stack.</p>
|
||
<p><span id="index-PUSHD_005fMINUS"></span>
|
||
<span id="index-NO_005fPUSHD_005fMINUS"></span>
|
||
<span id="index-PUSHDMINUS"></span>
|
||
<span id="index-NOPUSHDMINUS"></span>
|
||
<span id="index-directory-stack_002c-controlling-syntax"></span></p>
|
||
<p><code>PUSHD_MINUS</code></p>
|
||
<p>Exchanges the meanings of ‘<code>+</code>’ and ‘<code>-</code>’ when used with a number to
|
||
specify a directory in the stack.</p>
|
||
<p><span id="index-PUSHD_005fSILENT"></span>
|
||
<span id="index-NO_005fPUSHD_005fSILENT"></span>
|
||
<span id="index-PUSHDSILENT"></span>
|
||
<span id="index-NOPUSHDSILENT"></span>
|
||
<span id="index-directory-stack_002c-silencing"></span></p>
|
||
<p><code>PUSHD_SILENT</code> (<code>-E</code>)</p>
|
||
<p>Do not print the directory stack after <code>pushd</code> or <code>popd</code>.</p>
|
||
<p><span id="index-PUSHD_005fTO_005fHOME"></span>
|
||
<span id="index-NO_005fPUSHD_005fTO_005fHOME"></span>
|
||
<span id="index-PUSHDTOHOME"></span>
|
||
<span id="index-NOPUSHDTOHOME"></span>
|
||
<span id="index-pushd_002c-to-home"></span></p>
|
||
<p><code>PUSHD_TO_HOME</code> (<code>-D</code>)</p>
|
||
<p>Have <code>pushd</code> with no arguments act like ‘<code>pushd $HOME</code>’.</p>
|
||
<hr />
|
||
<p><span id="Completion-4"></span></p>
|
||
<h3 id="1622-completion"><a class="header" href="#1622-completion">16.2.2 Completion</a></h3>
|
||
<p><span id="index-ALWAYS_005fLAST_005fPROMPT"></span>
|
||
<span id="index-NO_005fALWAYS_005fLAST_005fPROMPT"></span>
|
||
<span id="index-ALWAYSLASTPROMPT"></span>
|
||
<span id="index-NOALWAYSLASTPROMPT"></span></p>
|
||
<p><code>ALWAYS_LAST_PROMPT</code> <D></p>
|
||
<p>If unset, key functions that list completions try to return to the last
|
||
prompt if given a numeric argument. If set these functions try to return
|
||
to the last prompt if given <em>no</em> numeric argument.</p>
|
||
<p><span id="index-ALWAYS_005fTO_005fEND"></span>
|
||
<span id="index-NO_005fALWAYS_005fTO_005fEND"></span>
|
||
<span id="index-ALWAYSTOEND"></span>
|
||
<span id="index-NOALWAYSTOEND"></span></p>
|
||
<p><code>ALWAYS_TO_END</code></p>
|
||
<p>If a completion is performed with the cursor within a word, and a full
|
||
completion is inserted, the cursor is moved to the end of the word. That
|
||
is, the cursor is moved to the end of the word if either a single match
|
||
is inserted or menu completion is performed.</p>
|
||
<p><span id="index-AUTO_005fLIST"></span>
|
||
<span id="index-NO_005fAUTO_005fLIST"></span>
|
||
<span id="index-AUTOLIST"></span> <span id="index-NOAUTOLIST"></span>
|
||
<span id="index-completion_002c-listing-choices"></span></p>
|
||
<p><code>AUTO_LIST</code> (<code>-9</code>) <D></p>
|
||
<p>Automatically list choices on an ambiguous completion.</p>
|
||
<p><span id="index-AUTO_005fMENU"></span>
|
||
<span id="index-NO_005fAUTO_005fMENU"></span>
|
||
<span id="index-AUTOMENU"></span> <span id="index-NOAUTOMENU"></span>
|
||
<span id="index-completion_002c-menu"></span></p>
|
||
<p><code>AUTO_MENU</code> <D></p>
|
||
<p>Automatically use menu completion after the second consecutive request
|
||
for completion, for example by pressing the tab key repeatedly. This
|
||
option is overridden by <code>MENU_COMPLETE</code>.</p>
|
||
<p><span id="index-AUTO_005fNAME_005fDIRS"></span>
|
||
<span id="index-NO_005fAUTO_005fNAME_005fDIRS"></span>
|
||
<span id="index-AUTONAMEDIRS"></span>
|
||
<span id="index-NOAUTONAMEDIRS"></span>
|
||
<span id="index-directories_002c-named"></span></p>
|
||
<p><code>AUTO_NAME_DIRS</code></p>
|
||
<p>Any parameter that is set to the absolute name of a directory
|
||
immediately becomes a name for that directory, that will be used by the
|
||
‘<code>%~</code>’ and related prompt sequences, and will be available when
|
||
completion is performed on a word starting with ‘<code>~</code>’. (Otherwise, the
|
||
parameter must be used in the form ‘<code>~``param</code>’ first.)</p>
|
||
<p><span id="index-AUTO_005fPARAM_005fKEYS"></span>
|
||
<span id="index-NO_005fAUTO_005fPARAM_005fKEYS"></span>
|
||
<span id="index-AUTOPARAMKEYS"></span>
|
||
<span id="index-NOAUTOPARAMKEYS"></span></p>
|
||
<p><code>AUTO_PARAM_KEYS</code> <D></p>
|
||
<p>If a parameter name was completed and a following character (normally a
|
||
space) automatically inserted, and the next character typed is one of
|
||
those that have to come directly after the name (like ‘<code>}</code>’, ‘<code>:</code>’,
|
||
etc.), the automatically added character is deleted, so that the
|
||
character typed comes immediately after the parameter name. Completion
|
||
in a brace expansion is affected similarly: the added character is a
|
||
‘<code>,</code>’, which will be removed if ‘<code>}</code>’ is typed next.</p>
|
||
<p><span id="index-AUTO_005fPARAM_005fSLASH"></span>
|
||
<span id="index-NO_005fAUTO_005fPARAM_005fSLASH"></span>
|
||
<span id="index-AUTOPARAMSLASH"></span>
|
||
<span id="index-NOAUTOPARAMSLASH"></span></p>
|
||
<p><code>AUTO_PARAM_SLASH</code> <D></p>
|
||
<p>If a parameter is completed whose content is the name of a directory,
|
||
then add a trailing slash instead of a space.</p>
|
||
<p><span id="index-AUTO_005fREMOVE_005fSLASH"></span>
|
||
<span id="index-NO_005fAUTO_005fREMOVE_005fSLASH"></span>
|
||
<span id="index-AUTOREMOVESLASH"></span>
|
||
<span id="index-NOAUTOREMOVESLASH"></span>
|
||
<span id="index-slash_002c-removing-trailing"></span></p>
|
||
<p><code>AUTO_REMOVE_SLASH</code> <D></p>
|
||
<p>When the last character resulting from a completion is a slash and the
|
||
next character typed is a word delimiter, a slash, or a character that
|
||
ends a command (such as a semicolon or an ampersand), remove the slash.</p>
|
||
<p><span id="index-BASH_005fAUTO_005fLIST"></span>
|
||
<span id="index-NO_005fBASH_005fAUTO_005fLIST"></span>
|
||
<span id="index-BASHAUTOLIST"></span>
|
||
<span id="index-NOBASHAUTOLIST"></span>
|
||
<span id="index-completion_002c-listing-choices_002c-bash-style"></span></p>
|
||
<p><code>BASH_AUTO_LIST</code></p>
|
||
<p>On an ambiguous completion, automatically list choices when the
|
||
completion function is called twice in succession. This takes precedence
|
||
over <code>AUTO_LIST</code>. The setting of <code>LIST_AMBIGUOUS</code> is respected. If
|
||
<code>AUTO_MENU</code> is set, the menu behaviour will then start with the third
|
||
press. Note that this will not work with <code>MENU_COMPLETE</code>, since repeated
|
||
completion calls immediately cycle through the list in that case.</p>
|
||
<p><span id="index-COMPLETE_005fALIASES"></span>
|
||
<span id="index-NO_005fCOMPLETE_005fALIASES"></span>
|
||
<span id="index-COMPLETEALIASES"></span>
|
||
<span id="index-NOCOMPLETEALIASES"></span>
|
||
<span id="index-aliases_002c-completion-of"></span></p>
|
||
<p><code>COMPLETE_ALIASES</code></p>
|
||
<p>Prevents aliases on the command line from being internally substituted
|
||
before completion is attempted. The effect is to make the alias a
|
||
distinct command for completion purposes.</p>
|
||
<p><span id="index-COMPLETE_005fIN_005fWORD"></span>
|
||
<span id="index-NO_005fCOMPLETE_005fIN_005fWORD"></span>
|
||
<span id="index-COMPLETEINWORD"></span>
|
||
<span id="index-NOCOMPLETEINWORD"></span></p>
|
||
<p><code>COMPLETE_IN_WORD</code></p>
|
||
<p>If unset, the cursor is set to the end of the word if completion is
|
||
started. Otherwise it stays there and completion is done from both ends.</p>
|
||
<p><span id="index-GLOB_005fCOMPLETE"></span>
|
||
<span id="index-NO_005fGLOB_005fCOMPLETE"></span>
|
||
<span id="index-GLOBCOMPLETE"></span>
|
||
<span id="index-NOGLOBCOMPLETE"></span></p>
|
||
<p><code>GLOB_COMPLETE</code></p>
|
||
<p>When the current word has a glob pattern, do not insert all the words
|
||
resulting from the expansion but generate matches as for completion and
|
||
cycle through them like <code>MENU_COMPLETE</code>. The matches are generated as if
|
||
a ‘<code>*</code>’ was added to the end of the word, or inserted at the cursor when
|
||
<code>COMPLETE_IN_WORD</code> is set. This actually uses pattern matching, not
|
||
globbing, so it works not only for files but for any completion, such as
|
||
options, user names, etc.</p>
|
||
<p>Note that when the pattern matcher is used, matching control (for
|
||
example, case-insensitive or anchored matching) cannot be used. This
|
||
limitation only applies when the current word contains a pattern; simply
|
||
turning on the <code>GLOB_COMPLETE</code> option does not have this effect.</p>
|
||
<p><span id="index-HASH_005fLIST_005fALL"></span>
|
||
<span id="index-NO_005fHASH_005fLIST_005fALL"></span>
|
||
<span id="index-HASHLISTALL"></span>
|
||
<span id="index-NOHASHLISTALL"></span></p>
|
||
<p><code>HASH_LIST_ALL</code> <D></p>
|
||
<p>Whenever a command completion or spelling correction is attempted, make
|
||
sure the entire command path is hashed first. This makes the first
|
||
completion slower but avoids false reports of spelling errors.</p>
|
||
<p><span id="index-LIST_005fAMBIGUOUS"></span>
|
||
<span id="index-NO_005fLIST_005fAMBIGUOUS"></span>
|
||
<span id="index-LISTAMBIGUOUS"></span>
|
||
<span id="index-NOLISTAMBIGUOUS"></span>
|
||
<span id="index-ambiguous-completion"></span>
|
||
<span id="index-completion_002c-ambiguous"></span></p>
|
||
<p><code>LIST_AMBIGUOUS</code> <D></p>
|
||
<p>This option works when <code>AUTO_LIST</code> or <code>BASH_AUTO_LIST</code> is also set. If
|
||
there is an unambiguous prefix to insert on the command line, that is
|
||
done without a completion list being displayed; in other words,
|
||
auto-listing behaviour only takes place when nothing would be inserted.
|
||
In the case of <code>BASH_AUTO_LIST</code>, this means that the list will be
|
||
delayed to the third call of the function.</p>
|
||
<p><span id="index-LIST_005fBEEP"></span>
|
||
<span id="index-NO_005fLIST_005fBEEP"></span>
|
||
<span id="index-LISTBEEP"></span> <span id="index-NOLISTBEEP"></span>
|
||
<span id="index-beep_002c-ambiguous-completion"></span>
|
||
<span id="index-completion_002c-beep-on-ambiguous"></span></p>
|
||
<p><code>LIST_BEEP</code> <D></p>
|
||
<p>Beep on an ambiguous completion. More accurately, this forces the
|
||
completion widgets to return status 1 on an ambiguous completion, which
|
||
causes the shell to beep if the option <code>BEEP</code> is also set; this may be
|
||
modified if completion is called from a user-defined widget.</p>
|
||
<p><span id="index-LIST_005fPACKED"></span>
|
||
<span id="index-NO_005fLIST_005fPACKED"></span>
|
||
<span id="index-LISTPACKED"></span>
|
||
<span id="index-NOLISTPACKED"></span>
|
||
<span id="index-completion_002c-listing"></span></p>
|
||
<p><code>LIST_PACKED</code></p>
|
||
<p>Try to make the completion list smaller (occupying less lines) by
|
||
printing the matches in columns with different widths.</p>
|
||
<p><span id="index-LIST_005fROWS_005fFIRST"></span>
|
||
<span id="index-NO_005fLIST_005fROWS_005fFIRST"></span>
|
||
<span id="index-LISTROWSFIRST"></span>
|
||
<span id="index-NOLISTROWSFIRST"></span>
|
||
<span id="index-completion_002c-listing-order"></span></p>
|
||
<p><code>LIST_ROWS_FIRST</code></p>
|
||
<p>Lay out the matches in completion lists sorted horizontally, that is,
|
||
the second match is to the right of the first one, not under it as
|
||
usual.</p>
|
||
<p><span id="index-LIST_005fTYPES"></span>
|
||
<span id="index-NO_005fLIST_005fTYPES"></span>
|
||
<span id="index-LISTTYPES"></span> <span id="index-NOLISTTYPES"></span>
|
||
<span id="index-marking-file-types"></span>
|
||
<span id="index-files_002c-marking-type-of"></span></p>
|
||
<p><code>LIST_TYPES</code> (<code>-X</code>) <D></p>
|
||
<p>When listing files that are possible completions, show the type of each
|
||
file with a trailing identifying mark.</p>
|
||
<p><span id="index-MENU_005fCOMPLETE"></span>
|
||
<span id="index-NO_005fMENU_005fCOMPLETE"></span>
|
||
<span id="index-MENUCOMPLETE"></span>
|
||
<span id="index-NOMENUCOMPLETE"></span>
|
||
<span id="index-completion_002c-menu-1"></span></p>
|
||
<p><code>MENU_COMPLETE</code> (<code>-Y</code>)</p>
|
||
<p>On an ambiguous completion, instead of listing possibilities or beeping,
|
||
insert the first match immediately. Then when completion is requested
|
||
again, remove the first match and insert the second match, etc. When
|
||
there are no more matches, go back to the first one again.
|
||
<code>reverse-menu-complete</code> may be used to loop through the list in the
|
||
other direction. This option overrides <code>AUTO_MENU</code>.</p>
|
||
<p><span id="index-REC_005fEXACT"></span>
|
||
<span id="index-NO_005fREC_005fEXACT"></span>
|
||
<span id="index-RECEXACT"></span> <span id="index-NORECEXACT"></span>
|
||
<span id="index-completion_002c-exact-matches"></span></p>
|
||
<p><code>REC_EXACT</code> (<code>-S</code>)</p>
|
||
<p>If the string on the command line exactly matches one of the possible
|
||
completions, it is accepted, even if there is another completion (i.e.
|
||
that string with something else added) that also matches.</p>
|
||
<hr />
|
||
<p><span id="Expansion-and-Globbing"></span></p>
|
||
<h3 id="1623-expansion-and-globbing"><a class="header" href="#1623-expansion-and-globbing">16.2.3 Expansion and Globbing</a></h3>
|
||
<p><span id="index-BAD_005fPATTERN"></span>
|
||
<span id="index-NO_005fBAD_005fPATTERN"></span>
|
||
<span id="index-BADPATTERN"></span>
|
||
<span id="index-NOBADPATTERN"></span>
|
||
<span id="index-globbing_002c-bad-pattern"></span>
|
||
<span id="index-filename-generation_002c-bad-pattern"></span></p>
|
||
<p><code>BAD_PATTERN</code> (<code>+2</code>) <C> <Z></p>
|
||
<p>If a pattern for filename generation is badly formed, print an error
|
||
message. (If this option is unset, the pattern will be left unchanged.)</p>
|
||
<p><span id="index-BARE_005fGLOB_005fQUAL"></span>
|
||
<span id="index-NO_005fBARE_005fGLOB_005fQUAL"></span>
|
||
<span id="index-BAREGLOBQUAL"></span>
|
||
<span id="index-NOBAREGLOBQUAL"></span>
|
||
<span id="index-globbing-qualifiers_002c-enable"></span>
|
||
<span id="index-enable-globbing-qualifiers"></span></p>
|
||
<p><code>BARE_GLOB_QUAL</code> <Z></p>
|
||
<p>In a glob pattern, treat a trailing set of parentheses as a qualifier
|
||
list, if it contains no ‘<code>|</code>’, ‘<code>(</code>’ or (if special) ‘<code>~</code>’ characters.
|
||
See <a href="Expansion.html#Filename-Generation">Filename Generation</a>.</p>
|
||
<p><span id="index-BRACE_005fCCL"></span>
|
||
<span id="index-NO_005fBRACE_005fCCL"></span>
|
||
<span id="index-BRACECCL"></span> <span id="index-NOBRACECCL"></span>
|
||
<span id="index-brace-expansion_002c-extending"></span>
|
||
<span id="index-expansion_002c-brace_002c-extending"></span></p>
|
||
<p><code>BRACE_CCL</code></p>
|
||
<p>Expand expressions in braces which would not otherwise undergo brace
|
||
expansion to a lexically ordered list of all the characters. See <a href="Expansion.html#Brace-Expansion">Brace
|
||
Expansion</a>.</p>
|
||
<p><span id="index-CASE_005fGLOB"></span>
|
||
<span id="index-NO_005fCASE_005fGLOB"></span>
|
||
<span id="index-CASEGLOB"></span> <span id="index-NOCASEGLOB"></span>
|
||
<span id="index-case_002dinsensitive-globbing_002c-option"></span></p>
|
||
<p><code>CASE_GLOB</code> <D></p>
|
||
<p>Make globbing (filename generation) sensitive to case. Note that other
|
||
uses of patterns are always sensitive to case. If the option is unset,
|
||
the presence of any character which is special to filename generation
|
||
will cause case-insensitive matching. For example, <code>cvs(/)</code> can match
|
||
the directory <code>CVS</code> owing to the presence of the globbing flag (unless
|
||
the option <code>BARE_GLOB_QUAL</code> is unset).</p>
|
||
<p><span id="index-CASE_005fMATCH"></span>
|
||
<span id="index-NO_005fCASE_005fMATCH"></span>
|
||
<span id="index-CASEMATCH"></span> <span id="index-NOCASEMATCH"></span>
|
||
<span id="index-case_002dinsensitive-regular-expression-matches_002c-option"></span>
|
||
<span id="index-regular-expressions_002c-case_002dinsensitive-matching_002c-option"></span></p>
|
||
<p><code>CASE_MATCH</code> <D></p>
|
||
<p>Make regular expressions using the <code>zsh/regex</code> module (including matches
|
||
with <code>=~</code>) sensitive to case.</p>
|
||
<p><span id="index-CSH_005fNULL_005fGLOB"></span>
|
||
<span id="index-NO_005fCSH_005fNULL_005fGLOB"></span>
|
||
<span id="index-CSHNULLGLOB"></span>
|
||
<span id="index-NOCSHNULLGLOB"></span>
|
||
<span id="index-csh_002c-null-globbing-style"></span>
|
||
<span id="index-null-globbing-style_002c-csh"></span>
|
||
<span id="index-globbing_002c-null_002c-style_002c-csh"></span></p>
|
||
<p><code>CSH_NULL_GLOB</code> <C></p>
|
||
<p>If a pattern for filename generation has no matches, delete the pattern
|
||
from the argument list; do not report an error unless all the patterns
|
||
in a command have no matches. Overrides <code>NOMATCH</code>.</p>
|
||
<p><span id="index-EQUALS"></span> <span id="index-NO_005fEQUALS"></span>
|
||
<span id="index-NOEQUALS"></span>
|
||
<span id="index-filename-expansion_002c-_003d"></span></p>
|
||
<p><code>EQUALS</code> <Z></p>
|
||
<p>Perform <code>=</code> filename expansion. (See <a href="Expansion.html#Filename-Expansion">Filename
|
||
Expansion</a>.)</p>
|
||
<p><span id="index-EXTENDED_005fGLOB"></span>
|
||
<span id="index-NO_005fEXTENDED_005fGLOB"></span>
|
||
<span id="index-EXTENDEDGLOB"></span>
|
||
<span id="index-NOEXTENDEDGLOB"></span>
|
||
<span id="index-globbing_002c-extended"></span></p>
|
||
<p><code>EXTENDED_GLOB</code></p>
|
||
<p>Treat the ‘<code>#</code>’, ‘<code>~</code>’ and ‘<code>^</code>’ characters as part of patterns for
|
||
filename generation, etc. (An initial unquoted ‘<code>~</code>’ always produces
|
||
named directory expansion.)</p>
|
||
<p><span id="index-FORCE_005fFLOAT"></span>
|
||
<span id="index-NO_005fFORCE_005fFLOAT"></span>
|
||
<span id="index-FORCEFLOAT"></span>
|
||
<span id="index-NOFORCEFLOAT"></span>
|
||
<span id="index-floating-point_002c-forcing-use-of"></span>
|
||
<span id="index-forcing-use-of-floating-point"></span></p>
|
||
<p><code>FORCE_FLOAT</code></p>
|
||
<p>Constants in arithmetic evaluation will be treated as floating point
|
||
even without the use of a decimal point; the values of integer variables
|
||
will be converted to floating point when used in arithmetic expressions.
|
||
Integers in any base will be converted.</p>
|
||
<p><span id="index-GLOB"></span> <span id="index-NO_005fGLOB"></span>
|
||
<span id="index-NOGLOB"></span>
|
||
<span id="index-globbing_002c-enabling"></span>
|
||
<span id="index-enabling-globbing"></span></p>
|
||
<p><code>GLOB</code> (<code>+F</code>, ksh: <code>+f</code>) <D></p>
|
||
<p>Perform filename generation (globbing). (See <a href="Expansion.html#Filename-Generation">Filename
|
||
Generation</a>.)</p>
|
||
<p><span id="index-GLOB_005fASSIGN"></span>
|
||
<span id="index-NO_005fGLOB_005fASSIGN"></span>
|
||
<span id="index-GLOBASSIGN"></span>
|
||
<span id="index-NOGLOBASSIGN"></span></p>
|
||
<p><code>GLOB_ASSIGN</code> <C></p>
|
||
<p>If this option is set, filename generation (globbing) is performed on
|
||
the right hand side of scalar parameter assignments of the form
|
||
‘<code>name``=``pattern</code> (e.g. ‘<code>foo=*</code>’). If the result has more than one
|
||
word the parameter will become an array with those words as arguments.
|
||
This option is provided for backwards compatibility only: globbing is
|
||
always performed on the right hand side of array assignments of the form
|
||
‘<code>name``=(``value``)</code>’ (e.g. ‘<code>foo=(*)</code>’) and this form is recommended
|
||
for clarity; with this option set, it is not possible to predict whether
|
||
the result will be an array or a scalar.</p>
|
||
<p><span id="index-GLOB_005fDOTS"></span>
|
||
<span id="index-NO_005fGLOB_005fDOTS"></span>
|
||
<span id="index-GLOBDOTS"></span> <span id="index-NOGLOBDOTS"></span>
|
||
<span id="index-globbing_002c-of-_002e-files"></span></p>
|
||
<p><code>GLOB_DOTS</code> (<code>-4</code>)</p>
|
||
<p>Do not require a leading ‘<code>.</code>’ in a filename to be matched explicitly.</p>
|
||
<p><span id="index-GLOB_005fSTAR_005fSHORT"></span>
|
||
<span id="index-NO_005fGLOB_005fSTAR_005fSHORT"></span>
|
||
<span id="index-GLOBSTARSHORT"></span>
|
||
<span id="index-NOGLOBSTARSHORT"></span>
|
||
<span id="index-globbing_002c-short-forms"></span>
|
||
<span id="index-globbing_002c-_002a_002a-special"></span></p>
|
||
<p><code>GLOB_STAR_SHORT</code></p>
|
||
<p>When this option is set and the default zsh-style globbing is in effect,
|
||
the pattern ‘<code>**/*</code>’ can be abbreviated to ‘<code>**</code>’ and the pattern
|
||
‘<code>***/*</code>’ can be abbreviated to <code>***</code>. Hence ‘<code>**.c</code>’ finds a file
|
||
ending in <code>.c</code> in any subdirectory, and ‘<code>***.c</code>’ does the same while
|
||
also following symbolic links. A <code>/</code> immediately after the ‘<code>**</code>’ or
|
||
‘<code>***</code>’ forces the pattern to be treated as the unabbreviated form.</p>
|
||
<p><span id="index-GLOB_005fSUBST"></span>
|
||
<span id="index-NO_005fGLOB_005fSUBST"></span>
|
||
<span id="index-GLOBSUBST"></span> <span id="index-NOGLOBSUBST"></span></p>
|
||
<p><code>GLOB_SUBST</code> <C> <K> <S></p>
|
||
<p>Treat any characters resulting from parameter expansion as being
|
||
eligible for filename expansion and filename generation, and any
|
||
characters resulting from command substitution as being eligible for
|
||
filename generation. Braces (and commas in between) do not become
|
||
eligible for expansion.</p>
|
||
<p><span id="index-HIST_005fSUBST_005fPATTERN"></span>
|
||
<span id="index-NO_005fHIST_005fSUBST_005fPATTERN"></span>
|
||
<span id="index-HISTSUBSTPATTERN"></span>
|
||
<span id="index-NOHISTSUBSTPATTERN"></span></p>
|
||
<p><code>HIST_SUBST_PATTERN</code></p>
|
||
<p>Substitutions using the <code>:s</code> and <code>:&</code> history modifiers are performed
|
||
with pattern matching instead of string matching. This occurs wherever
|
||
history modifiers are valid, including glob qualifiers and parameters.
|
||
See <a href="Expansion.html#Modifiers">Modifiers</a>.</p>
|
||
<p><span id="index-IGNORE_005fBRACES"></span>
|
||
<span id="index-NO_005fIGNORE_005fBRACES"></span>
|
||
<span id="index-IGNOREBRACES"></span>
|
||
<span id="index-NOIGNOREBRACES"></span>
|
||
<span id="index-disabling-brace-expansion"></span>
|
||
<span id="index-brace-expansion_002c-disabling"></span>
|
||
<span id="index-expansion_002c-brace_002c-disabling"></span></p>
|
||
<p><code>IGNORE_BRACES</code> (<code>-I</code>) <S></p>
|
||
<p>Do not perform brace expansion. For historical reasons this also
|
||
includes the effect of the <code>IGNORE_CLOSE_BRACES</code> option.</p>
|
||
<p><span id="index-IGNORE_005fCLOSE_005fBRACES"></span>
|
||
<span id="index-NO_005fIGNORE_005fCLOSE_005fBRACES"></span>
|
||
<span id="index-IGNORECLOSEBRACES"></span>
|
||
<span id="index-NOIGNORECLOSEBRACES"></span></p>
|
||
<p><code>IGNORE_CLOSE_BRACES</code></p>
|
||
<p>When neither this option nor <code>IGNORE_BRACES</code> is set, a sole close brace
|
||
character ‘<code>}</code>’ is syntactically significant at any point on a command
|
||
line. This has the effect that no semicolon or newline is necessary
|
||
before the brace terminating a function or current shell construct. When
|
||
either option is set, a closing brace is syntactically significant only
|
||
in command position. Unlike <code>IGNORE_BRACES</code>, this option does not
|
||
disable brace expansion.</p>
|
||
<p>For example, with both options unset a function may be defined in the
|
||
following fashion:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">args() { echo $# }
|
||
</code></pre>
|
||
</div>
|
||
<p>while if either option is set, this does not work and something
|
||
equivalent to the following is required:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">args() { echo $#; }
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-KSH_005fGLOB"></span>
|
||
<span id="index-NO_005fKSH_005fGLOB"></span>
|
||
<span id="index-KSHGLOB"></span> <span id="index-NOKSHGLOB"></span></p>
|
||
<p><code>KSH_GLOB</code> <K></p>
|
||
<p>In pattern matching, the interpretation of parentheses is affected by a
|
||
preceding ‘<code>@</code>’, ‘<code>*</code>’, ‘<code>+</code>’, ‘<code>?</code>’ or ‘<code>!</code>’. See <a href="Expansion.html#Filename-Generation">Filename
|
||
Generation</a>.</p>
|
||
<p><span id="index-MAGIC_005fEQUAL_005fSUBST"></span>
|
||
<span id="index-NO_005fMAGIC_005fEQUAL_005fSUBST"></span>
|
||
<span id="index-MAGICEQUALSUBST"></span>
|
||
<span id="index-NOMAGICEQUALSUBST"></span></p>
|
||
<p><code>MAGIC_EQUAL_SUBST</code></p>
|
||
<p>All unquoted arguments of the form ‘<code>anything``=``expression</code>’ appearing
|
||
after the command name have filename expansion (that is, where
|
||
<code>expression</code> has a leading ‘<code>~</code>’ or ‘<code>=</code>’) performed on <code>expression</code> as
|
||
if it were a parameter assignment. The argument is not otherwise treated
|
||
specially; it is passed to the command as a single argument, and not
|
||
used as an actual parameter assignment. For example, in <code>echo foo=~/bar:~/rod</code>, both occurrences of <code>~</code> would be replaced. Note that
|
||
this happens anyway with <code>typeset</code> and similar statements.</p>
|
||
<p>This option respects the setting of the <code>KSH_TYPESET</code> option. In other
|
||
words, if both options are in effect, arguments looking like assignments
|
||
will not undergo word splitting.</p>
|
||
<p><span id="index-MARK_005fDIRS"></span>
|
||
<span id="index-NO_005fMARK_005fDIRS"></span>
|
||
<span id="index-MARKDIRS"></span> <span id="index-NOMARKDIRS"></span>
|
||
<span id="index-directories_002c-marking"></span>
|
||
<span id="index-marking-directories"></span></p>
|
||
<p><code>MARK_DIRS</code> (<code>-8</code>, ksh: <code>-X</code>)</p>
|
||
<p>Append a trailing ‘<code>/</code>’ to all directory names resulting from filename
|
||
generation (globbing).</p>
|
||
<p><span id="index-MULTIBYTE"></span>
|
||
<span id="index-NO_005fMULTIBYTE"></span>
|
||
<span id="index-NOMULTIBYTE"></span>
|
||
<span id="index-characters_002c-multibyte_002c-in-expansion-and-globbing"></span>
|
||
<span id="index-multibyte-characters_002c-in-expansion-and-globbing"></span></p>
|
||
<p><code>MULTIBYTE</code> <D></p>
|
||
<p>Respect multibyte characters when found in strings. When this option is
|
||
set, strings are examined using the system library to determine how many
|
||
bytes form a character, depending on the current locale. This affects
|
||
the way characters are counted in pattern matching, parameter values and
|
||
various delimiters.</p>
|
||
<p>The option is on by default if the shell was compiled with
|
||
<code>MULTIBYTE_SUPPORT</code>; otherwise it is off by default and has no effect if
|
||
turned on.</p>
|
||
<p>If the option is off a single byte is always treated as a single
|
||
character. This setting is designed purely for examining strings known
|
||
to contain raw bytes or other values that may not be characters in the
|
||
current locale. It is not necessary to unset the option merely because
|
||
the character set for the current locale does not contain multibyte
|
||
characters.</p>
|
||
<p>The option does not affect the shell’s editor, which always uses the
|
||
locale to determine multibyte characters. This is because the character
|
||
set displayed by the terminal emulator is independent of shell settings.</p>
|
||
<p><span id="index-NOMATCH"></span> <span id="index-NO_005fNOMATCH"></span>
|
||
<span id="index-NONOMATCH"></span>
|
||
<span id="index-globbing_002c-no-matches"></span></p>
|
||
<p><code>NOMATCH</code> (<code>+3</code>) <C> <Z></p>
|
||
<p>If a pattern for filename generation has no matches, print an error,
|
||
instead of leaving it unchanged in the argument list. This also applies
|
||
to file expansion of an initial ‘<code>~</code>’ or ‘<code>=</code>’.</p>
|
||
<p><span id="index-NULL_005fGLOB"></span>
|
||
<span id="index-NO_005fNULL_005fGLOB"></span>
|
||
<span id="index-NULLGLOB"></span> <span id="index-NONULLGLOB"></span>
|
||
<span id="index-globbing_002c-no-matches-1"></span></p>
|
||
<p><code>NULL_GLOB</code> (<code>-G</code>)</p>
|
||
<p>If a pattern for filename generation has no matches, delete the pattern
|
||
from the argument list instead of reporting an error. Overrides
|
||
<code>NOMATCH</code>.</p>
|
||
<p><span id="index-NUMERIC_005fGLOB_005fSORT"></span>
|
||
<span id="index-NO_005fNUMERIC_005fGLOB_005fSORT"></span>
|
||
<span id="index-NUMERICGLOBSORT"></span>
|
||
<span id="index-NONUMERICGLOBSORT"></span>
|
||
<span id="index-globbing_002c-sorting-numerically"></span></p>
|
||
<p><code>NUMERIC_GLOB_SORT</code></p>
|
||
<p>If numeric filenames are matched by a filename generation pattern, sort
|
||
the filenames numerically rather than lexicographically.</p>
|
||
<p><span id="index-RC_005fEXPAND_005fPARAM"></span>
|
||
<span id="index-NO_005fRC_005fEXPAND_005fPARAM"></span>
|
||
<span id="index-RCEXPANDPARAM"></span>
|
||
<span id="index-NORCEXPANDPARAM"></span>
|
||
<span id="index-rc_002c-parameter-expansion-style"></span>
|
||
<span id="index-parameter-expansion-style_002c-rc"></span></p>
|
||
<p><code>RC_EXPAND_PARAM</code> (<code>-P</code>)</p>
|
||
<p>Array expansions of the form ‘<code>foo``${``xx``}``bar</code>’, where the
|
||
parameter <code>xx</code> is set to <code>(``a b c``)</code>, are substituted with ‘<code>fooabar foobbar foocbar</code>’ instead of the default ‘<code>fooa b cbar</code>’. Note that an
|
||
empty array will therefore cause all arguments to be removed.</p>
|
||
<p><span id="index-REMATCH_005fPCRE"></span>
|
||
<span id="index-NO_005fREMATCH_005fPCRE"></span>
|
||
<span id="index-REMATCHPCRE"></span>
|
||
<span id="index-NOREMATCHPCRE"></span>
|
||
<span id="index-regexp_002c-PCRE"></span>
|
||
<span id="index-PCRE_002c-regexp"></span></p>
|
||
<p><code>REMATCH_PCRE</code></p>
|
||
<p>If set, regular expression matching with the <code>=~</code> operator will use
|
||
Perl-Compatible Regular Expressions from the PCRE library. (The
|
||
<code>zsh/pcre</code> module must be available.) If not set, regular expressions
|
||
will use the extended regexp syntax provided by the system libraries.</p>
|
||
<p><span id="index-SH_005fGLOB"></span>
|
||
<span id="index-NO_005fSH_005fGLOB"></span>
|
||
<span id="index-SHGLOB"></span> <span id="index-NOSHGLOB"></span>
|
||
<span id="index-sh_002c-globbing-style"></span>
|
||
<span id="index-globbing-style_002c-sh"></span></p>
|
||
<p><code>SH_GLOB</code> <K> <S></p>
|
||
<p>Disables the special meaning of ‘<code>(</code>’, ‘<code>|</code>’, ‘<code>)</code>’ and ’<code><</code>’ for
|
||
globbing the result of parameter and command substitutions, and in some
|
||
other places where the shell accepts patterns. If <code>SH_GLOB</code> is set but
|
||
<code>KSH_GLOB</code> is not, the shell allows the interpretation of subshell
|
||
expressions enclosed in parentheses in some cases where there is no
|
||
space before the opening parenthesis, e.g. <code>!(true)</code> is interpreted as
|
||
if there were a space after the <code>!</code>. This option is set by default if
|
||
zsh is invoked as <code>sh</code> or <code>ksh</code>.</p>
|
||
<p><span id="index-UNSET"></span> <span id="index-NO_005fUNSET"></span>
|
||
<span id="index-NOUNSET"></span>
|
||
<span id="index-parameters_002c-substituting-unset"></span>
|
||
<span id="index-unset-parameters_002c-substituting"></span></p>
|
||
<p><code>UNSET</code> (<code>+u</code>, ksh: <code>+u</code>) <K> <S> <Z></p>
|
||
<p>Treat unset parameters as if they were empty when substituting, and as
|
||
if they were zero when reading their values in arithmetic expansion and
|
||
arithmetic commands. Otherwise they are treated as an error.</p>
|
||
<p><span id="index-WARN_005fCREATE_005fGLOBAL"></span>
|
||
<span id="index-NO_005fWARN_005fCREATE_005fGLOBAL"></span>
|
||
<span id="index-WARNCREATEGLOBAL"></span>
|
||
<span id="index-NOWARNCREATEGLOBAL"></span>
|
||
<span id="index-parameters_002c-warning-when-created-globally"></span></p>
|
||
<p><code>WARN_CREATE_GLOBAL</code></p>
|
||
<p>Print a warning message when a global parameter is created in a function
|
||
by an assignment or in math context. This often indicates that a
|
||
parameter has not been declared local when it should have been.
|
||
Parameters explicitly declared global from within a function using
|
||
<code>typeset -g</code> do not cause a warning. Note that there is no warning when
|
||
a local parameter is assigned to in a nested function, which may also
|
||
indicate an error.</p>
|
||
<p><span id="index-WARN_005fNESTED_005fVAR"></span>
|
||
<span id="index-NO_005fWARN_005fNESTED_005fVAR"></span>
|
||
<span id="index-WARNNESTEDVAR"></span>
|
||
<span id="index-NO_005fWARNNESTEDVAR"></span>
|
||
<span id="index-parameters_002c-warning-when-setting-in-enclosing-scope"></span></p>
|
||
<p><code>WARN_NESTED_VAR</code></p>
|
||
<p>Print a warning message when an existing parameter from an enclosing
|
||
function scope, or global, is set in a function by an assignment or in
|
||
math context. Assignment to shell special parameters does not cause a
|
||
warning. This is the companion to <code>WARN_CREATE_GLOBAL</code> as in this case
|
||
the warning is only printed when a parameter is <em>not</em> created. Where
|
||
possible, use of <code>typeset -g</code> to set the parameter suppresses the error,
|
||
but note that this needs to be used every time the parameter is set. To
|
||
restrict the effect of this option to a single function scope, use
|
||
‘<code>functions -W</code>’.</p>
|
||
<p>For example, the following code produces a warning for the assignment
|
||
inside the function <code>nested</code> as that overrides the value within
|
||
<code>toplevel</code></p>
|
||
<div class="example">
|
||
<pre><code class="language-example">toplevel() {
|
||
local foo="in fn"
|
||
nested
|
||
}
|
||
nested() {
|
||
foo="in nested"
|
||
}
|
||
setopt warn_nested_var
|
||
toplevel
|
||
</code></pre>
|
||
</div>
|
||
<hr />
|
||
<p><span id="History"></span></p>
|
||
<h3 id="1624-history"><a class="header" href="#1624-history">16.2.4 History</a></h3>
|
||
<p><span id="index-APPEND_005fHISTORY"></span>
|
||
<span id="index-NO_005fAPPEND_005fHISTORY"></span>
|
||
<span id="index-APPENDHISTORY"></span>
|
||
<span id="index-NOAPPENDHISTORY"></span>
|
||
<span id="index-history_002c-appending-to-a-file"></span></p>
|
||
<p><code>APPEND_HISTORY</code> <D></p>
|
||
<p>If this is set, zsh sessions will append their history list to the
|
||
history file, rather than replace it. Thus, multiple parallel zsh
|
||
sessions will all have the new entries from their history lists added to
|
||
the history file, in the order that they exit. The file will still be
|
||
periodically re-written to trim it when the number of lines grows 20%
|
||
beyond the value specified by <code>$SAVEHIST</code> (see also the
|
||
<code>HIST_SAVE_BY_COPY</code> option).</p>
|
||
<p><span id="index-BANG_005fHIST"></span>
|
||
<span id="index-NO_005fBANG_005fHIST"></span>
|
||
<span id="index-BANGHIST"></span> <span id="index-NOBANGHIST"></span>
|
||
<span id="index-history_002c-enable-substitution"></span>
|
||
<span id="index-enable-history-substitution"></span></p>
|
||
<p><code>BANG_HIST</code> (<code>+K</code>) <C> <Z></p>
|
||
<p>Perform textual history expansion, csh-style, treating the character
|
||
‘<code>!</code>’ specially.</p>
|
||
<p><span id="index-EXTENDED_005fHISTORY"></span>
|
||
<span id="index-NO_005fEXTENDED_005fHISTORY"></span>
|
||
<span id="index-EXTENDEDHISTORY"></span>
|
||
<span id="index-NOEXTENDEDHISTORY"></span>
|
||
<span id="index-history_002c-timestamping"></span></p>
|
||
<p><code>EXTENDED_HISTORY</code> <C></p>
|
||
<p>Save each command’s beginning timestamp (in seconds since the epoch) and
|
||
the duration (in seconds) to the history file. The format of this
|
||
prefixed data is:</p>
|
||
<p>‘<code> : ``<beginning time>``:``<elapsed seconds>``;``<command></code>’.</p>
|
||
<p><span id="index-HIST_005fALLOW_005fCLOBBER"></span>
|
||
<span id="index-NO_005fHIST_005fALLOW_005fCLOBBER"></span>
|
||
<span id="index-HISTALLOWCLOBBER"></span>
|
||
<span id="index-NOHISTALLOWCLOBBER"></span></p>
|
||
<p><code>HIST_ALLOW_CLOBBER</code></p>
|
||
<p>Add ‘<code>|</code>’ to output redirections in the history. This allows history
|
||
references to clobber files even when <code>CLOBBER</code> is unset.</p>
|
||
<p><span id="index-HIST_005fBEEP"></span>
|
||
<span id="index-NO_005fHIST_005fBEEP"></span>
|
||
<span id="index-HISTBEEP"></span> <span id="index-NOHISTBEEP"></span>
|
||
<span id="index-history-beeping"></span>
|
||
<span id="index-beep_002c-history"></span></p>
|
||
<p><code>HIST_BEEP</code> <D></p>
|
||
<p>Beep in ZLE when a widget attempts to access a history entry which isn’t
|
||
there.</p>
|
||
<p><span id="index-HIST_005fEXPIRE_005fDUPS_005fFIRST"></span>
|
||
<span id="index-NO_005fHIST_005fEXPIRE_005fDUPS_005fFIRST"></span>
|
||
<span id="index-HISTEXPIREDUPSFIRST"></span>
|
||
<span id="index-NOHISTEXPIREDUPSFIRST"></span>
|
||
<span id="index-history_002c-expiring-duplicates"></span></p>
|
||
<p><code>HIST_EXPIRE_DUPS_FIRST</code></p>
|
||
<p>If the internal history needs to be trimmed to add the current command
|
||
line, setting this option will cause the oldest history event that has a
|
||
duplicate to be lost before losing a unique event from the list. You
|
||
should be sure to set the value of <code>HISTSIZE</code> to a larger number than
|
||
<code>SAVEHIST</code> in order to give you some room for the duplicated events,
|
||
otherwise this option will behave just like <code>HIST_IGNORE_ALL_DUPS</code> once
|
||
the history fills up with unique events.</p>
|
||
<p><span id="index-HIST_005fFCNTL_005fLOCK"></span>
|
||
<span id="index-NO_005fHIST_005fFCNTL_005fLOCK"></span>
|
||
<span id="index-HISTFCNTLLOCK"></span>
|
||
<span id="index-NOHISTFCNTLLOCK"></span></p>
|
||
<p><code>HIST_FCNTL_LOCK</code></p>
|
||
<p>When writing out the history file, by default zsh uses ad-hoc file
|
||
locking to avoid known problems with locking on some operating systems.
|
||
With this option locking is done by means of the system’s <code>fcntl</code> call,
|
||
where this method is available. On recent operating systems this may
|
||
provide better performance, in particular avoiding history corruption
|
||
when files are stored on NFS.</p>
|
||
<p><span id="index-HIST_005fFIND_005fNO_005fDUPS"></span>
|
||
<span id="index-NO_005fHIST_005fFIND_005fNO_005fDUPS"></span>
|
||
<span id="index-HISTFINDNODUPS"></span>
|
||
<span id="index-NOHISTFINDNODUPS"></span>
|
||
<span id="index-history_002c-ignoring-duplicates-in-search"></span></p>
|
||
<p><code>HIST_FIND_NO_DUPS</code></p>
|
||
<p>When searching for history entries in the line editor, do not display
|
||
duplicates of a line previously found, even if the duplicates are not
|
||
contiguous.</p>
|
||
<p><span id="index-HIST_005fIGNORE_005fALL_005fDUPS"></span>
|
||
<span id="index-NO_005fHIST_005fIGNORE_005fALL_005fDUPS"></span>
|
||
<span id="index-HISTIGNOREALLDUPS"></span>
|
||
<span id="index-NOHISTIGNOREALLDUPS"></span>
|
||
<span id="index-history_002c-ignoring-all-duplicates"></span></p>
|
||
<p><code>HIST_IGNORE_ALL_DUPS</code></p>
|
||
<p>If a new command line being added to the history list duplicates an
|
||
older one, the older command is removed from the list (even if it is not
|
||
the previous event).</p>
|
||
<p><span id="index-HIST_005fIGNORE_005fDUPS"></span>
|
||
<span id="index-NO_005fHIST_005fIGNORE_005fDUPS"></span>
|
||
<span id="index-HISTIGNOREDUPS"></span>
|
||
<span id="index-NOHISTIGNOREDUPS"></span>
|
||
<span id="index-history_002c-ignoring-duplicates"></span></p>
|
||
<p><code>HIST_IGNORE_DUPS</code> (<code>-h</code>)</p>
|
||
<p>Do not enter command lines into the history list if they are duplicates
|
||
of the previous event.</p>
|
||
<p><span id="index-HIST_005fIGNORE_005fSPACE"></span>
|
||
<span id="index-NO_005fHIST_005fIGNORE_005fSPACE"></span>
|
||
<span id="index-HISTIGNORESPACE"></span>
|
||
<span id="index-NOHISTIGNORESPACE"></span>
|
||
<span id="index-history_002c-ignoring-spaces"></span></p>
|
||
<p><code>HIST_IGNORE_SPACE</code> (<code>-g</code>)</p>
|
||
<p>Remove command lines from the history list when the first character on
|
||
the line is a space, or when one of the expanded aliases contains a
|
||
leading space. Only normal aliases (not global or suffix aliases) have
|
||
this behaviour. Note that the command lingers in the internal history
|
||
until the next command is entered before it vanishes, allowing you to
|
||
briefly reuse or edit the line. If you want to make it vanish right away
|
||
without entering another command, type a space and press return.</p>
|
||
<p><span id="index-HIST_005fLEX_005fWORDS"></span>
|
||
<span id="index-NO_005fHIST_005fLEX_005fWORDS"></span>
|
||
<span id="index-HISTLEXWORDS"></span>
|
||
<span id="index-NOHISTLEXWORDS"></span></p>
|
||
<p><code>HIST_LEX_WORDS</code></p>
|
||
<p>By default, shell history that is read in from files is split into words
|
||
on all white space. This means that arguments with quoted whitespace are
|
||
not correctly handled, with the consequence that references to words in
|
||
history lines that have been read from a file may be inaccurate. When
|
||
this option is set, words read in from a history file are divided up in
|
||
a similar fashion to normal shell command line handling. Although this
|
||
produces more accurately delimited words, if the size of the history
|
||
file is large this can be slow. Trial and error is necessary to decide.</p>
|
||
<p><span id="index-HIST_005fNO_005fFUNCTIONS"></span>
|
||
<span id="index-NO_005fHIST_005fNO_005fFUNCTIONS"></span>
|
||
<span id="index-HISTNOFUNCTIONS"></span>
|
||
<span id="index-NOHISTNOFUNCTIONS"></span></p>
|
||
<p><code>HIST_NO_FUNCTIONS</code></p>
|
||
<p>Remove function definitions from the history list. Note that the
|
||
function lingers in the internal history until the next command is
|
||
entered before it vanishes, allowing you to briefly reuse or edit the
|
||
definition.</p>
|
||
<p><span id="index-HIST_005fNO_005fSTORE"></span>
|
||
<span id="index-NO_005fHIST_005fNO_005fSTORE"></span>
|
||
<span id="index-HISTNOSTORE"></span>
|
||
<span id="index-NOHISTNOSTORE"></span></p>
|
||
<p><code>HIST_NO_STORE</code></p>
|
||
<p>Remove the <code>history</code> (<code>fc -l</code>) command from the history list when
|
||
invoked. Note that the command lingers in the internal history until the
|
||
next command is entered before it vanishes, allowing you to briefly
|
||
reuse or edit the line.</p>
|
||
<p><span id="index-HIST_005fREDUCE_005fBLANKS"></span>
|
||
<span id="index-NO_005fHIST_005fREDUCE_005fBLANKS"></span>
|
||
<span id="index-HISTREDUCEBLANKS"></span>
|
||
<span id="index-NOHISTREDUCEBLANKS"></span></p>
|
||
<p><code>HIST_REDUCE_BLANKS</code></p>
|
||
<p>Remove superfluous blanks from each command line being added to the
|
||
history list.</p>
|
||
<p><span id="index-HIST_005fSAVE_005fBY_005fCOPY"></span>
|
||
<span id="index-NO_005fHIST_005fSAVE_005fBY_005fCOPY"></span>
|
||
<span id="index-HISTSAVEBYCOPY"></span>
|
||
<span id="index-NOHISTSAVEBYCOPY"></span></p>
|
||
<p><code>HIST_SAVE_BY_COPY</code> <D></p>
|
||
<p>When the history file is re-written, we normally write out a copy of the
|
||
file named <code>$HISTFILE.new</code> and then rename it over the old one. However,
|
||
if this option is unset, we instead truncate the old history file and
|
||
write out the new version in-place. If one of the history-appending
|
||
options is enabled, this option only has an effect when the enlarged
|
||
history file needs to be re-written to trim it down to size. Disable
|
||
this only if you have special needs, as doing so makes it possible to
|
||
lose history entries if zsh gets interrupted during the save.</p>
|
||
<p>When writing out a copy of the history file, zsh preserves the old
|
||
file’s permissions and group information, but will refuse to write out
|
||
a new file if it would change the history file’s owner.</p>
|
||
<p><span id="index-HIST_005fSAVE_005fNO_005fDUPS"></span>
|
||
<span id="index-NO_005fHIST_005fSAVE_005fNO_005fDUPS"></span>
|
||
<span id="index-HISTSAVENODUPS"></span>
|
||
<span id="index-NOHISTSAVENODUPS"></span></p>
|
||
<p><code>HIST_SAVE_NO_DUPS</code></p>
|
||
<p>When writing out the history file, older commands that duplicate newer
|
||
ones are omitted.</p>
|
||
<p><span id="index-HIST_005fVERIFY"></span>
|
||
<span id="index-NO_005fHIST_005fVERIFY"></span>
|
||
<span id="index-HISTVERIFY"></span>
|
||
<span id="index-NOHISTVERIFY"></span>
|
||
<span id="index-history_002c-verifying-substitution"></span></p>
|
||
<p><code>HIST_VERIFY</code></p>
|
||
<p>Whenever the user enters a line with history expansion, don’t execute
|
||
the line directly; instead, perform history expansion and reload the
|
||
line into the editing buffer.</p>
|
||
<p><span id="index-INC_005fAPPEND_005fHISTORY"></span>
|
||
<span id="index-NO_005fINC_005fAPPEND_005fHISTORY"></span>
|
||
<span id="index-INCAPPENDHISTORY"></span>
|
||
<span id="index-NOINCAPPENDHISTORY"></span>
|
||
<span id="index-history_002c-incremental-appending-to-a-file"></span></p>
|
||
<p><code>INC_APPEND_HISTORY</code></p>
|
||
<p>This option works like <code>APPEND_HISTORY</code> except that new history lines
|
||
are added to the <code>$HISTFILE</code> incrementally (as soon as they are
|
||
entered), rather than waiting until the shell exits. The file will still
|
||
be periodically re-written to trim it when the number of lines grows 20%
|
||
beyond the value specified by <code>$SAVEHIST</code> (see also the
|
||
<code>HIST_SAVE_BY_COPY</code> option).</p>
|
||
<p><span id="index-INC_005fAPPEND_005fHISTORY_005fTIME"></span>
|
||
<span id="index-NO_005fINC_005fAPPEND_005fHISTORY_005fTIME"></span>
|
||
<span id="index-INCAPPENDHISTORYTIME"></span>
|
||
<span id="index-NOINCAPPENDHISTORYTIME"></span>
|
||
<span id="index-history_002c-incremental-appending-to-a-file-with-time"></span></p>
|
||
<p><code>INC_APPEND_HISTORY_TIME</code></p>
|
||
<p>This option is a variant of <code>INC_APPEND_HISTORY</code> in which, where
|
||
possible, the history entry is written out to the file after the command
|
||
is finished, so that the time taken by the command is recorded correctly
|
||
in the history file in <code>EXTENDED_HISTORY</code> format. This means that the
|
||
history entry will not be available immediately from other instances of
|
||
the shell that are using the same history file.</p>
|
||
<p>This option is only useful if <code>INC_APPEND_HISTORY</code> and <code>SHARE_HISTORY</code>
|
||
are turned off. The three options should be considered mutually
|
||
exclusive.</p>
|
||
<p><span id="index-SHARE_005fHISTORY"></span>
|
||
<span id="index-NO_005fSHARE_005fHISTORY"></span>
|
||
<span id="index-SHAREHISTORY"></span>
|
||
<span id="index-NOSHAREHISTORY"></span>
|
||
<span id="index-share-history"></span>
|
||
<span id="index-history_002c-sharing"></span></p>
|
||
<p><code>SHARE_HISTORY</code> <K></p>
|
||
<p>This option both imports new commands from the history file, and also
|
||
causes your typed commands to be appended to the history file (the
|
||
latter is like specifying <code>INC_APPEND_HISTORY</code>, which should be turned
|
||
off if this option is in effect). The history lines are also output with
|
||
timestamps ala <code>EXTENDED_HISTORY</code> (which makes it easier to find the
|
||
spot where we left off reading the file after it gets re-written).</p>
|
||
<p>By default, history movement commands visit the imported lines as well
|
||
as the local lines, but you can toggle this on and off with the
|
||
set-local-history zle binding. It is also possible to create a zle
|
||
widget that will make some commands ignore imported commands, and some
|
||
include them.</p>
|
||
<p>If you find that you want more control over when commands get imported,
|
||
you may wish to turn <code>SHARE_HISTORY</code> off, <code>INC_APPEND_HISTORY</code> or
|
||
<code>INC_APPEND_HISTORY_TIME</code> (see above) on, and then manually import
|
||
commands whenever you need them using ‘<code>fc -RI</code>’.</p>
|
||
<hr />
|
||
<p><span id="Initialisation"></span></p>
|
||
<h3 id="1625-initialisation"><a class="header" href="#1625-initialisation">16.2.5 Initialisation</a></h3>
|
||
<p><span id="index-ALL_005fEXPORT"></span>
|
||
<span id="index-NO_005fALL_005fEXPORT"></span>
|
||
<span id="index-ALLEXPORT"></span> <span id="index-NOALLEXPORT"></span>
|
||
<span id="index-export_002c-automatic"></span></p>
|
||
<p><code>ALL_EXPORT</code> (<code>-a</code>, ksh: <code>-a</code>)</p>
|
||
<p>All parameters subsequently defined are automatically exported.</p>
|
||
<p><span id="index-GLOBAL_005fEXPORT"></span>
|
||
<span id="index-NO_005fGLOBAL_005fEXPORT"></span>
|
||
<span id="index-GLOBALEXPORT"></span>
|
||
<span id="index-NOGLOBALEXPORT"></span>
|
||
<span id="index-environment_002c-and-local-parameters"></span></p>
|
||
<p><code>GLOBAL_EXPORT</code> <Z></p>
|
||
<p>If this option is set, passing the <code>-x</code> flag to the builtins <code>declare</code>,
|
||
<code>float</code>, <code>integer</code>, <code>readonly</code> and <code>typeset</code> (but not <code>local</code>) will also
|
||
set the <code>-g</code> flag; hence parameters exported to the environment will not
|
||
be made local to the enclosing function, unless they were already or the
|
||
flag <code>+g</code> is given explicitly. If the option is unset, exported
|
||
parameters will be made local in just the same way as any other
|
||
parameter.</p>
|
||
<p>This option is set by default for backward compatibility; it is not
|
||
recommended that its behaviour be relied upon. Note that the builtin
|
||
<code>export</code> always sets both the <code>-x</code> and <code>-g</code> flags, and hence its effect
|
||
extends beyond the scope of the enclosing function; this is the</p>
|
||
<p><span id="index-exporting_002c-and-local-parameters"></span>
|
||
<span id="index-GLOBAL_005fRCS"></span>
|
||
<span id="index-NO_005fGLOBAL_005fRCS"></span>
|
||
<span id="index-GLOBALRCS"></span> <span id="index-NOGLOBALRCS"></span>
|
||
<span id="index-startup-files_002c-global_002c-inhibiting"></span>
|
||
<span id="index-files_002c-global-startup_002c-inhibiting"></span></p>
|
||
<p><code>GLOBAL_RCS</code> (<code>-d</code>) <D></p>
|
||
<p>If this option is unset, the startup files <code>/etc/zprofile</code>,
|
||
<code>/etc/zshrc</code>, <code>/etc/zlogin</code> and <code>/etc/zlogout</code> will not be run. It can
|
||
be disabled and re-enabled at any time, including inside local startup
|
||
files (<code>.zshrc</code>, etc.).</p>
|
||
<p><span id="index-RCS"></span> <span id="index-NO_005fRCS"></span>
|
||
<span id="index-NORCS"></span>
|
||
<span id="index-startup-files_002c-sourcing"></span></p>
|
||
<p><code>RCS</code> (<code>+f</code>) <D></p>
|
||
<p>After <code>/etc/zshenv</code> is sourced on startup, source the <code>.zshenv</code>,
|
||
<code>/etc/zprofile</code>, <code>.zprofile</code>, <code>/etc/zshrc</code>, <code>.zshrc</code>, <code>/etc/zlogin</code>,
|
||
<code>.zlogin</code>, and <code>.zlogout</code> files, as described in
|
||
<a href="Files.html#Files">Files</a>. If this option is unset, the <code>/etc/zshenv</code>
|
||
file is still sourced, but any of the others will not be; it can be set
|
||
at any time to prevent the remaining startup files after the currently
|
||
executing one from being sourced.</p>
|
||
<hr />
|
||
<p><span id="Input_002fOutput"></span></p>
|
||
<h3 id="1626-inputoutput"><a class="header" href="#1626-inputoutput">16.2.6 Input/Output</a></h3>
|
||
<p><span id="index-ALIASES"></span> <span id="index-NO_005fALIASES"></span>
|
||
<span id="index-NOALIASES"></span>
|
||
<span id="index-aliases_002c-expansion"></span></p>
|
||
<p><code>ALIASES</code> <D></p>
|
||
<p>Expand aliases.</p>
|
||
<p><span id="index-CLOBBER"></span> <span id="index-NO_005fCLOBBER"></span>
|
||
<span id="index-NOCLOBBER"></span>
|
||
<span id="index-clobbering_002c-of-files"></span>
|
||
<span id="index-file-clobbering_002c-allowing"></span></p>
|
||
<p><code>CLOBBER</code> (<code>+C</code>, ksh: <code>+C</code>) <D></p>
|
||
<p>Allows ‘<code>></code>’ redirection to truncate existing files. Otherwise ‘<code>>!</code>’ or
|
||
‘<code>>|</code>’ must be used to truncate a file.</p>
|
||
<p>If the option is not set, and the option <code>APPEND_CREATE</code> is also not
|
||
set, ‘<code>>>!</code>’ or ‘<code>>>|</code>’ must be used to create a file. If either option
|
||
is set, ‘<code>>></code>’ may be used.</p>
|
||
<p><span id="index-CORRECT"></span> <span id="index-NO_005fCORRECT"></span>
|
||
<span id="index-NOCORRECT"></span>
|
||
<span id="index-correction_002c-spelling"></span>
|
||
<span id="index-spelling-correction"></span></p>
|
||
<p><code>CORRECT</code> (<code>-0</code>)</p>
|
||
<p>Try to correct the spelling of commands. Note that, when the
|
||
<code>HASH_LIST_ALL</code> option is not set or when some directories in the path
|
||
are not readable, this may falsely report spelling errors the first time
|
||
some commands are used.</p>
|
||
<p>The shell variable <code>CORRECT_IGNORE</code> may be set to a pattern to match
|
||
words that will never be offered as corrections.</p>
|
||
<p><span id="index-CORRECT_005fALL"></span>
|
||
<span id="index-NO_005fCORRECT_005fALL"></span>
|
||
<span id="index-CORRECTALL"></span>
|
||
<span id="index-NOCORRECTALL"></span></p>
|
||
<p><code>CORRECT_ALL</code> (<code>-O</code>)</p>
|
||
<p>Try to correct the spelling of all arguments in a line.</p>
|
||
<p>The shell variable <code>CORRECT_IGNORE_FILE</code> may be set to a pattern to
|
||
match file names that will never be offered as corrections.</p>
|
||
<p><span id="index-DVORAK"></span> <span id="index-NO_005fDVORAK"></span>
|
||
<span id="index-NODVORAK"></span></p>
|
||
<p><code>DVORAK</code></p>
|
||
<p>Use the Dvorak keyboard instead of the standard qwerty keyboard as a
|
||
basis for examining spelling mistakes for the <code>CORRECT</code> and
|
||
<code>CORRECT_ALL</code> options and the <code>spell-word</code> editor command.</p>
|
||
<p><span id="index-FLOW_005fCONTROL"></span>
|
||
<span id="index-NO_005fFLOW_005fCONTROL"></span>
|
||
<span id="index-FLOWCONTROL"></span>
|
||
<span id="index-NOFLOWCONTROL"></span>
|
||
<span id="index-flow-control"></span></p>
|
||
<p><code>FLOW_CONTROL</code> <D></p>
|
||
<p>If this option is unset, output flow control via start/stop characters
|
||
(usually assigned to ^S/^Q) is disabled in the shell’s editor.</p>
|
||
<p><span id="index-IGNORE_005fEOF"></span>
|
||
<span id="index-NO_005fIGNORE_005fEOF"></span>
|
||
<span id="index-IGNOREEOF"></span> <span id="index-NOIGNOREEOF"></span>
|
||
<span id="index-EOF_002c-ignoring"></span></p>
|
||
<p><code>IGNORE_EOF</code> (<code>-7</code>)</p>
|
||
<p>Do not exit on end-of-file. Require the use of <code>exit</code> or <code>logout</code>
|
||
instead. However, ten consecutive EOFs will cause the shell to exit
|
||
anyway, to avoid the shell hanging if its tty goes away.</p>
|
||
<p>Also, if this option is set and the Zsh Line Editor is used, widgets
|
||
implemented by shell functions can be bound to EOF (normally Control-D)
|
||
without printing the normal warning message. This works only for normal
|
||
widgets, not for completion widgets.</p>
|
||
<p><span id="index-INTERACTIVE_005fCOMMENTS"></span>
|
||
<span id="index-NO_005fINTERACTIVE_005fCOMMENTS"></span>
|
||
<span id="index-INTERACTIVECOMMENTS"></span>
|
||
<span id="index-NOINTERACTIVECOMMENTS"></span>
|
||
<span id="index-comments_002c-in-interactive-shells"></span></p>
|
||
<p><code>INTERACTIVE_COMMENTS</code> (<code>-k</code>) <K> <S></p>
|
||
<p>Allow comments even in interactive shells.</p>
|
||
<p><span id="index-HASH_005fCMDS"></span>
|
||
<span id="index-NO_005fHASH_005fCMDS"></span>
|
||
<span id="index-HASHCMDS"></span> <span id="index-NOHASHCMDS"></span>
|
||
<span id="index-hashing_002c-of-commands"></span>
|
||
<span id="index-command-hashing"></span></p>
|
||
<p><code>HASH_CMDS</code> <D></p>
|
||
<p>Note the location of each command the first time it is executed.
|
||
Subsequent invocations of the same command will use the saved location,
|
||
avoiding a path search. If this option is unset, no path hashing is done
|
||
at all. However, when <code>CORRECT</code> is set, commands whose names do not
|
||
appear in reporting them as spelling errors.</p>
|
||
<p><span id="index-HASH_005fDIRS"></span>
|
||
<span id="index-NO_005fHASH_005fDIRS"></span>
|
||
<span id="index-HASHDIRS"></span> <span id="index-NOHASHDIRS"></span>
|
||
<span id="index-hashing_002c-of-directories"></span>
|
||
<span id="index-directories_002c-hashing"></span></p>
|
||
<p><code>HASH_DIRS</code> <D></p>
|
||
<p>Whenever a command name is hashed, hash the directory containing it, as
|
||
well as all directories that occur earlier in the path. Has no effect if
|
||
neither <code>HASH_CMDS</code> nor <code>CORRECT</code> is set.</p>
|
||
<p><span id="index-HASH_005fEXECUTABLES_005fONLY"></span>
|
||
<span id="index-NO_005fHASH_005fEXECUTABLES_005fONLY"></span>
|
||
<span id="index-HASHEXECUTABLESONLY"></span>
|
||
<span id="index-NOHASHEXECUTABLESONLY"></span></p>
|
||
<p><code>HASH_EXECUTABLES_ONLY</code></p>
|
||
<p>When hashing commands because of <code>HASH_CMDS</code>, check that the is unset by
|
||
default as if the path contains a large number of commands, or consists
|
||
of many remote files, the additional tests can take a long time. Trial
|
||
and error is needed to show if this option is beneficial.</p>
|
||
<p><span id="index-MAIL_005fWARNING"></span>
|
||
<span id="index-NO_005fMAIL_005fWARNING"></span>
|
||
<span id="index-MAILWARNING"></span>
|
||
<span id="index-NOMAILWARNING"></span>
|
||
<span id="index-mail_002c-warning-of-reading"></span></p>
|
||
<p><code>MAIL_WARNING</code> (<code>-U</code>)</p>
|
||
<p>Print a warning message if a mail file has been accessed since the shell
|
||
last checked.</p>
|
||
<p><span id="index-PATH_005fDIRS"></span>
|
||
<span id="index-NO_005fPATH_005fDIRS"></span>
|
||
<span id="index-PATHDIRS"></span> <span id="index-NOPATHDIRS"></span>
|
||
<span id="index-path-search_002c-extended"></span></p>
|
||
<p><code>PATH_DIRS</code> (<code>-Q</code>)</p>
|
||
<p>Perform a path search even on command names with slashes in them. Thus
|
||
if ‘<code>/usr/local/bin</code>’ is in the user’s path, and he or she types
|
||
‘<code>X11/xinit</code>’, the command ‘<code>/usr/local/bin/X11/xinit</code>’ will be
|
||
executed (assuming it exists). Commands explicitly beginning with ‘<code>/</code>’,
|
||
‘<code>./</code>’ or ‘<code>../</code>’ are not subject to the path search. This also applies
|
||
to the ‘<code>.</code>’ and <code>source</code> builtins.</p>
|
||
<p>Note that subdirectories of the current directory are always searched
|
||
for indicated by this option, and regardless of whether ‘<code>.</code>’ or the
|
||
current directory appear in the command search path.</p>
|
||
<p><span id="index-PATH_005fSCRIPT"></span>
|
||
<span id="index-NO_005fPATH_005fSCRIPT"></span>
|
||
<span id="index-PATHSCRIPT"></span>
|
||
<span id="index-NOPATHSCRIPT"></span>
|
||
<span id="index-path-search_002c-for-script-argument-to-shell"></span></p>
|
||
<p><code>PATH_SCRIPT</code> <K> <S></p>
|
||
<p>If this option is not set, a script passed as the first non-option
|
||
argument to the shell must contain the name of the file to open. If this
|
||
option is set, and the script does not specify a directory path, the
|
||
script is looked for first in the current directory, then in the command
|
||
path. See <a href="Invocation.html#Invocation">Invocation</a>.</p>
|
||
<p><span id="index-PRINT_005fEIGHT_005fBIT"></span>
|
||
<span id="index-NO_005fPRINT_005fEIGHT_005fBIT"></span>
|
||
<span id="index-PRINTEIGHTBIT"></span>
|
||
<span id="index-NOPRINTEIGHTBIT"></span>
|
||
<span id="index-eight-bit-characters_002c-printing"></span></p>
|
||
<p><code>PRINT_EIGHT_BIT</code></p>
|
||
<p>Print eight bit characters literally in completion lists, etc. This
|
||
option is not necessary if your system correctly returns the
|
||
printability of eight bit characters (see man page ctype(3)).</p>
|
||
<p><span id="index-PRINT_005fEXIT_005fVALUE"></span>
|
||
<span id="index-NO_005fPRINT_005fEXIT_005fVALUE"></span>
|
||
<span id="index-PRINTEXITVALUE"></span>
|
||
<span id="index-NOPRINTEXITVALUE"></span>
|
||
<span id="index-exit-status_002c-printing"></span></p>
|
||
<p><code>PRINT_EXIT_VALUE</code> (<code>-1</code>)</p>
|
||
<p>Print the exit value of programs with non-zero exit status. This is only
|
||
available at the command line in interactive shells.</p>
|
||
<p><span id="index-RC_005fQUOTES"></span>
|
||
<span id="index-NO_005fRC_005fQUOTES"></span>
|
||
<span id="index-RCQUOTES"></span> <span id="index-NORCQUOTES"></span>
|
||
<span id="index-rc_002c-quoting-style"></span>
|
||
<span id="index-quoting-style_002c-rc"></span></p>
|
||
<p><code>RC_QUOTES</code></p>
|
||
<p>Allow the character sequence ‘<code>’’</code>’ to signify a single quote within
|
||
singly quoted strings. Note this does not apply in quoted strings using
|
||
the format <code>$’``...``’</code>, where a backslashed single quote can be used.</p>
|
||
<p><span id="index-RM_005fSTAR_005fSILENT"></span>
|
||
<span id="index-NO_005fRM_005fSTAR_005fSILENT"></span>
|
||
<span id="index-RMSTARSILENT"></span>
|
||
<span id="index-NORMSTARSILENT"></span>
|
||
<span id="index-rm-_002a_002c-querying-before"></span>
|
||
<span id="index-querying-before-rm-_002a"></span></p>
|
||
<p><code>RM_STAR_SILENT</code> (<code>-H</code>) <K> <S></p>
|
||
<p>Do not query the user before executing ‘<code>rm *</code>’ or ‘<code>rm path/*</code>’.</p>
|
||
<p><span id="index-RM_005fSTAR_005fWAIT"></span>
|
||
<span id="index-NO_005fRM_005fSTAR_005fWAIT"></span>
|
||
<span id="index-RMSTARWAIT"></span>
|
||
<span id="index-NORMSTARWAIT"></span>
|
||
<span id="index-rm-_002a_002c-waiting-before"></span>
|
||
<span id="index-waiting-before-rm-_002a"></span></p>
|
||
<p><code>RM_STAR_WAIT</code></p>
|
||
<p>If querying the user before executing ‘<code>rm *</code>’ or ‘<code>rm path/*</code>’, first
|
||
wait ten seconds and ignore anything typed in that time. This avoids the
|
||
problem of reflexively answering ‘yes’ to the query when one didn’t
|
||
really mean it. The wait and query can always be avoided by expanding
|
||
the ‘<code>*</code>’ in ZLE (with tab).</p>
|
||
<p><span id="index-SHORT_005fLOOPS"></span>
|
||
<span id="index-NO_005fSHORT_005fLOOPS"></span>
|
||
<span id="index-SHORTLOOPS"></span>
|
||
<span id="index-NOSHORTLOOPS"></span></p>
|
||
<p><code>SHORT_LOOPS</code> <C> <Z></p>
|
||
<p>Allow the short forms of <code>for</code>, <code>repeat</code>, <code>select</code>, <code>if</code>, and <code>function</code>
|
||
constructs.</p>
|
||
<p><span id="index-SUN_005fKEYBOARD_005fHACK"></span>
|
||
<span id="index-NO_005fSUN_005fKEYBOARD_005fHACK"></span>
|
||
<span id="index-SUNKEYBOARDHACK"></span>
|
||
<span id="index-NOSUNKEYBOARDHACK"></span>
|
||
<span id="index-sun-keyboard_002c-annoying"></span>
|
||
<span id="index-annoying-keyboard_002c-sun"></span></p>
|
||
<p><code>SUN_KEYBOARD_HACK</code> (<code>-L</code>)</p>
|
||
<p>If a line ends with a backquote, and there are an odd number of
|
||
backquotes on the line, ignore the trailing backquote. This is useful on
|
||
some keyboards where the return key is too small, and the backquote key
|
||
lies annoyingly close to it. As an alternative the variable
|
||
<code>KEYBOARD_HACK</code> lets you choose the character to be removed.</p>
|
||
<hr />
|
||
<p><span id="Job-Control"></span></p>
|
||
<h3 id="1627-job-control"><a class="header" href="#1627-job-control">16.2.7 Job Control</a></h3>
|
||
<p><span id="index-AUTO_005fCONTINUE"></span>
|
||
<span id="index-NO_005fAUTO_005fCONTINUE"></span>
|
||
<span id="index-AUTOCONTINUE"></span>
|
||
<span id="index-NOAUTOCONTINUE"></span>
|
||
<span id="index-jobs_002c-continuing-automatically"></span>
|
||
<span id="index-continuing-jobs-automatically"></span></p>
|
||
<p><code>AUTO_CONTINUE</code></p>
|
||
<p>with the <code>disown</code> builtin command are automatically sent a <code>CONT</code> signal
|
||
to make them running.</p>
|
||
<p><span id="index-AUTO_005fRESUME"></span>
|
||
<span id="index-NO_005fAUTO_005fRESUME"></span>
|
||
<span id="index-AUTORESUME"></span>
|
||
<span id="index-NOAUTORESUME"></span>
|
||
<span id="index-jobs_002c-resuming-automatically"></span>
|
||
<span id="index-resuming-jobs-automatically"></span></p>
|
||
<p><code>AUTO_RESUME</code> (<code>-W</code>)</p>
|
||
<p>Treat single word simple commands without redirection as candidates for
|
||
resumption of an existing job.</p>
|
||
<p><span id="index-BG_005fNICE"></span>
|
||
<span id="index-NO_005fBG_005fNICE"></span>
|
||
<span id="index-BGNICE"></span> <span id="index-NOBGNICE"></span>
|
||
<span id="index-jobs_002c-background-priority"></span>
|
||
<span id="index-background-jobs_002c-priority-of"></span>
|
||
<span id="index-priority-of-background-jobs"></span></p>
|
||
<p><code>BG_NICE</code> (<code>-6</code>) <C> <Z></p>
|
||
<p>Run all background jobs at a lower priority. This option is set by
|
||
default.</p>
|
||
<p><span id="index-CHECK_005fJOBS"></span>
|
||
<span id="index-NO_005fCHECK_005fJOBS"></span>
|
||
<span id="index-CHECKJOBS"></span> <span id="index-NOCHECKJOBS"></span>
|
||
<span id="index-exiting_002c-checking-jobs-when"></span>
|
||
<span id="index-logging-out_002c-checking-jobs-when"></span></p>
|
||
<p><code>CHECK_JOBS</code> <Z></p>
|
||
<p>Report the status of background and suspended jobs before exiting a
|
||
shell with job control; a second attempt to exit the shell will succeed.
|
||
<code>NO_CHECK_JOBS</code> is best used only in combination with <code>NO_HUP</code>, else
|
||
such jobs will be killed automatically.</p>
|
||
<p>The check is omitted if the commands run from the previous command line
|
||
included a ‘<code>jobs</code>’ command, since it is assumed the user is aware that
|
||
there are background or suspended jobs. A ‘<code>jobs</code>’ command run from one
|
||
of the hook functions defined in the section Special Functions in
|
||
<a href="Functions.html#Functions">Functions</a> is not counted for this purpose.</p>
|
||
<p><span id="index-CHECK_005fRUNNING_005fJOBS"></span>
|
||
<span id="index-NO_005fCHECK_005fRUNNING_005fJOBS"></span>
|
||
<span id="index-CHECKRUNNINGJOBS"></span>
|
||
<span id="index-NOCHECKRUNNINGJOBS"></span>
|
||
<span id="index-exiting_002c-checking-running-jobs-when"></span>
|
||
<span id="index-logging-out_002c-checking-running-jobs-when"></span></p>
|
||
<p><code>CHECK_RUNNING_JOBS</code> <Z></p>
|
||
<p>Check for both running and suspended jobs when <code>CHECK_JOBS</code> is enabled.
|
||
When this option is disabled, zsh checks only for suspended jobs, which
|
||
matches the default behavior of bash.</p>
|
||
<p>This option has no effect unless <code>CHECK_JOBS</code> is set.</p>
|
||
<p><span id="index-HUP"></span> <span id="index-NO_005fHUP"></span>
|
||
<span id="index-NOHUP"></span> <span id="index-jobs_002c-HUP"></span></p>
|
||
<p><code>HUP</code> <Z></p>
|
||
<p>Send the <code>HUP</code> signal to running jobs when the shell exits.</p>
|
||
<p><span id="index-LONG_005fLIST_005fJOBS"></span>
|
||
<span id="index-NO_005fLONG_005fLIST_005fJOBS"></span>
|
||
<span id="index-LONGLISTJOBS"></span>
|
||
<span id="index-NOLONGLISTJOBS"></span>
|
||
<span id="index-jobs_002c-list-format"></span></p>
|
||
<p><code>LONG_LIST_JOBS</code> (<code>-R</code>)</p>
|
||
<p>Print job notifications in the long format by default.</p>
|
||
<p><span id="index-MONITOR"></span> <span id="index-NO_005fMONITOR"></span>
|
||
<span id="index-NOMONITOR"></span>
|
||
<span id="index-job-control_002c-allowing"></span></p>
|
||
<p><code>MONITOR</code> (<code>-m</code>, ksh: <code>-m</code>)</p>
|
||
<p>Allow job control. Set by default in interactive shells.</p>
|
||
<p><span id="index-NOTIFY"></span> <span id="index-NO_005fNOTIFY"></span>
|
||
<span id="index-NONOTIFY"></span>
|
||
<span id="index-background-jobs_002c-notification"></span>
|
||
<span id="index-notification-of-background-jobs"></span></p>
|
||
<p><code>NOTIFY</code> (<code>-5</code>, ksh: <code>-b</code>) <Z></p>
|
||
<p>Report the status of background jobs immediately, rather than waiting
|
||
until just before printing a prompt.</p>
|
||
<p><span id="index-POSIX_005fJOBS"></span>
|
||
<span id="index-POSIXJOBS"></span>
|
||
<span id="index-NO_005fPOSIX_005fJOBS"></span>
|
||
<span id="index-NOPOSIXJOBS"></span>
|
||
<span id="index-bg_002c-output-in-POSIX-format"></span>
|
||
<span id="index-fg_002c-output-in-POSIX-format"></span>
|
||
<span id="index-job-control_002c-in-subshell"></span>
|
||
<span id="index-jobs_002c-output-in-subshell"></span></p>
|
||
<p><code>POSIX_JOBS</code> <K> <S></p>
|
||
<p>This option makes job control more compliant with the POSIX standard.</p>
|
||
<p>When the option is not set, the <code>MONITOR</code> option is unset on entry to
|
||
subshells, so that job control is no longer active. When the option is
|
||
set, the <code>MONITOR</code> option and job control remain active in the subshell,
|
||
but note that the subshell has no access to jobs in the parent shell.</p>
|
||
<p>When the option is not set, jobs put in the background or foreground
|
||
with <code>bg</code> or <code>fg</code> are displayed with the same information that would be
|
||
reported by <code>jobs</code>. When the option is set, only the text is printed.
|
||
The output from <code>jobs</code> itself is not affected by the option.</p>
|
||
<p>When the option is not set, job information from the parent shell is
|
||
saved for output within a subshell (for example, within a pipeline).
|
||
When the option is set, the output of <code>jobs</code> is empty until a job is
|
||
started within the subshell.</p>
|
||
<p>In previous versions of the shell, it was necessary to enable
|
||
<code>POSIX_JOBS</code> in order for the builtin command <code>wait</code> to return the
|
||
status of background jobs that had already exited. This is no longer the
|
||
case.</p>
|
||
<hr />
|
||
<p><span id="Prompting"></span></p>
|
||
<h3 id="1628-prompting"><a class="header" href="#1628-prompting">16.2.8 Prompting</a></h3>
|
||
<p><span id="index-PROMPT_005fBANG"></span>
|
||
<span id="index-NO_005fPROMPT_005fBANG"></span>
|
||
<span id="index-PROMPTBANG"></span>
|
||
<span id="index-NOPROMPTBANG"></span>
|
||
<span id="index-prompt_002c-_0021-expansion"></span></p>
|
||
<p><code>PROMPT_BANG</code> <K></p>
|
||
<p>If set, ‘<code>!</code>’ is treated specially in prompt expansion. See <a href="Prompt-Expansion.html#Prompt-Expansion">Prompt
|
||
Expansion</a>.</p>
|
||
<p><span id="index-PROMPT_005fCR"></span>
|
||
<span id="index-NO_005fPROMPT_005fCR"></span>
|
||
<span id="index-PROMPTCR"></span> <span id="index-NOPROMPTCR"></span>
|
||
<span id="index-prompt_002c-with-CR"></span></p>
|
||
<p><code>PROMPT_CR</code> (<code>+V</code>) <D></p>
|
||
<p>Print a carriage return just before printing a prompt in the line
|
||
editor. This is on by default as multi-line editing is only possible if
|
||
the editor knows where the start of the line appears.</p>
|
||
<p><span id="index-PROMPT_005fSP"></span>
|
||
<span id="index-NO_005fPROMPT_005fSP"></span>
|
||
<span id="index-PROMPTSP"></span> <span id="index-NOPROMPTSP"></span>
|
||
<span id="index-prompt_002c-save-partial-lines"></span></p>
|
||
<p><code>PROMPT_SP</code> <D></p>
|
||
<p>Attempt to preserve a partial line (i.e. a line that did not end with a
|
||
newline) that would otherwise be covered up by the command prompt due to
|
||
the <code>PROMPT_CR</code> option. This works by outputting some cursor-control
|
||
characters, including a series of spaces, that should make the terminal
|
||
wrap to the next line when a partial line is present (note that this is
|
||
only successful if your terminal has automatic margins, which is
|
||
typical).</p>
|
||
<p>When a partial line is preserved, by default you will see an
|
||
inverse+bold character at the end of the partial line: a ‘<code>%</code>’ for a
|
||
normal user or a ‘<code>#</code>’ for root. If set, the shell parameter
|
||
<code>PROMPT_EOL_MARK</code> can be used to customize how the end of partial lines
|
||
are shown.</p>
|
||
<p>NOTE: if the <code>PROMPT_CR</code> option is not set, enabling this option will
|
||
have no effect. This option is on by default.</p>
|
||
<p><span id="index-PROMPT_005fPERCENT"></span>
|
||
<span id="index-NO_005fPROMPT_005fPERCENT"></span>
|
||
<span id="index-PROMPTPERCENT"></span>
|
||
<span id="index-NOPROMPTPERCENT"></span>
|
||
<span id="index-prompt_002c-_0025-expansion"></span></p>
|
||
<p><code>PROMPT_PERCENT</code> <C> <Z></p>
|
||
<p>If set, ‘<code>%</code>’ is treated specially in prompt expansion. See <a href="Prompt-Expansion.html#Prompt-Expansion">Prompt
|
||
Expansion</a>.</p>
|
||
<p><span id="index-PROMPT_005fSUBST"></span>
|
||
<span id="index-NO_005fPROMPT_005fSUBST"></span>
|
||
<span id="index-PROMPTSUBST"></span>
|
||
<span id="index-NOPROMPTSUBST"></span>
|
||
<span id="index-prompt_002c-parameter-expansion"></span></p>
|
||
<p><code>PROMPT_SUBST</code> <K> <S></p>
|
||
<p>If set, <em>parameter expansion</em>, <em>command substitution</em> and <em>arithmetic
|
||
expansion</em> are performed in prompts. Substitutions within prompts do not
|
||
affect the command status.</p>
|
||
<p><span id="index-TRANSIENT_005fRPROMPT"></span>
|
||
<span id="index-NO_005fTRANSIENT_005fRPROMPT"></span>
|
||
<span id="index-TRANSIENTRPROMPT"></span>
|
||
<span id="index-NOTRANSIENTRPROMPT"></span></p>
|
||
<p><code>TRANSIENT_RPROMPT</code></p>
|
||
<p>Remove any right prompt from display when accepting a command line. This
|
||
may be useful with terminals with other cut/paste methods.</p>
|
||
<hr />
|
||
<p><span id="Scripts-and-Functions"></span></p>
|
||
<h3 id="1629-scripts-and-functions"><a class="header" href="#1629-scripts-and-functions">16.2.9 Scripts and Functions</a></h3>
|
||
<p><span id="index-ALIAS_005fFUNC_005fDEF"></span>
|
||
<span id="index-NO_005fALIAS_005fFUNC_005fDEF"></span>
|
||
<span id="index-ALIASFUNCDEF"></span>
|
||
<span id="index-NOALIASFUNCDEF"></span>
|
||
<span id="index-functions_002c-defining-with-expanded-aliases"></span>
|
||
<span id="index-aliases_002c-expanding-in-function-definition"></span></p>
|
||
<p><code>ALIAS_FUNC_DEF</code> <S></p>
|
||
<p>By default, zsh does not allow the definition of functions using the
|
||
‘<code>name</code> <code>()</code>’ syntax if <code>name</code> was expanded as an alias: this causes
|
||
an error. This is usually the desired behaviour, as otherwise the
|
||
combination of an alias and a function based on the same definition can
|
||
easily cause problems.</p>
|
||
<p>When this option is set, aliases can be used for defining functions.</p>
|
||
<p>For example, consider the following definitions as they might occur in a
|
||
startup file.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">alias foo=bar
|
||
foo() {
|
||
print This probably does not do what you expect.
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p>Here, <code>foo</code> is expanded as an alias to <code>bar</code> before the <code>()</code> is
|
||
encountered, so the function defined would be named <code>bar</code>. By default
|
||
this is instead an error in native mode. Note that quoting any part of
|
||
the function name, or using the keyword <code>function</code>, avoids the problem,
|
||
so is recommended when the function name can also be an alias.</p>
|
||
<p><span id="index-C_005fBASES"></span>
|
||
<span id="index-NO_005fC_005fBASES"></span>
|
||
<span id="index-CBASES"></span> <span id="index-NOCBASES"></span>
|
||
<span id="index-bases_002c-output-in-C-format"></span>
|
||
<span id="index-hexadecimal_002c-output-in-C-format"></span>
|
||
<span id="index-octal_002c-output-in-C-format"></span></p>
|
||
<p><code>C_BASES</code></p>
|
||
<p>Output hexadecimal numbers in the standard C format, for example
|
||
‘<code>0xFF</code>’ instead of the usual ‘<code>16#FF</code>’. If the option
|
||
<code>OCTAL_ZEROES</code> is also set (it is not by default), octal numbers will be
|
||
treated similarly and hence appear as ‘<code>077</code>’ instead of ‘<code>8#77</code>’. This
|
||
option has no effect on the choice of the output base, nor on the output
|
||
of bases other than hexadecimal and octal. Note that these formats will
|
||
be understood on input irrespective of the setting of <code>C_BASES</code>.</p>
|
||
<p><span id="index-C_005fPRECEDENCES"></span>
|
||
<span id="index-NO_005fC_005fPRECEDENCES"></span>
|
||
<span id="index-CPRECEDENCES"></span>
|
||
<span id="index-NOCPRECEDENCES"></span>
|
||
<span id="index-precedence_002c-operator"></span>
|
||
<span id="index-operator-precedence"></span></p>
|
||
<p><code>C_PRECEDENCES</code></p>
|
||
<p>This alters the precedence of arithmetic operators to be more like C and
|
||
other programming languages; <a href="Arithmetic-Evaluation.html#Arithmetic-Evaluation">Arithmetic
|
||
Evaluation</a> has an
|
||
explicit list.</p>
|
||
<p><span id="index-DEBUG_005fBEFORE_005fCMD"></span>
|
||
<span id="index-NO_005fDEBUG_005fBEFORE_005fCMD"></span>
|
||
<span id="index-DEBUGBEFORECMD"></span>
|
||
<span id="index-NODEBUGBEFORECMD"></span>
|
||
<span id="index-traps_002c-DEBUG_002c-before-or-after-command"></span>
|
||
<span id="index-DEBUG-trap_002c-before-or-after-command"></span></p>
|
||
<p><code>DEBUG_BEFORE_CMD</code> <D></p>
|
||
<p>Run the <code>DEBUG</code> trap before each command; otherwise it is run after each
|
||
command. Setting this option mimics the behaviour of ksh 93; with the
|
||
option unset the behaviour is that of ksh 88.</p>
|
||
<p><span id="index-ERR_005fEXIT"></span>
|
||
<span id="index-NO_005fERR_005fEXIT"></span>
|
||
<span id="index-ERREXIT"></span> <span id="index-NOERREXIT"></span>
|
||
<span id="index-exit-status_002c-trapping"></span></p>
|
||
<p><code>ERR_EXIT</code> (<code>-e</code>, ksh: <code>-e</code>)</p>
|
||
<p>If a command has a non-zero exit status, execute the <code>ZERR</code> trap, if
|
||
set, and exit. This is disabled while running initialization scripts.</p>
|
||
<p>The behaviour is also disabled inside <code>DEBUG</code> traps. In this case the
|
||
option is handled specially: it is unset on entry to the trap. If the
|
||
option <code>DEBUG_BEFORE_CMD</code> is set, as it is by default, and the option
|
||
<code>ERR_EXIT</code> is found to have been set on exit, then the command for which
|
||
the <code>DEBUG</code> trap is being executed is skipped. The option is restored
|
||
after the trap exits.</p>
|
||
<p>Non-zero status in a command list containing <code>&&</code> or <code>||</code> is ignored for
|
||
commands not at the end of the list. Hence</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">false && true
|
||
</code></pre>
|
||
</div>
|
||
<p>does not trigger exit.</p>
|
||
<p>Exiting due to <code>ERR_EXIT</code> has certain interactions with asynchronous
|
||
jobs noted in <a href="Jobs-_0026-Signals.html#Jobs-_0026-Signals">Jobs &
|
||
Signals</a>.</p>
|
||
<p><span id="index-ERR_005fRETURN"></span>
|
||
<span id="index-NO_005fERR_005fRETURN"></span>
|
||
<span id="index-ERRRETURN"></span> <span id="index-NOERRRETURN"></span>
|
||
<span id="index-function-return_002c-on-error"></span>
|
||
<span id="index-return-from-function_002c-on-error"></span></p>
|
||
<p><code>ERR_RETURN</code></p>
|
||
<p>If a command has a non-zero exit status, return immediately from the
|
||
enclosing function. The logic is similar to that for <code>ERR_EXIT</code>, except
|
||
that an implicit <code>return</code> statement is executed instead of an <code>exit</code>.
|
||
This will trigger an exit at the outermost level of a non-interactive
|
||
script.</p>
|
||
<p>Normally this option inherits the behaviour of <code>ERR_EXIT</code> that code
|
||
followed by ‘<code>&&</code>’ ‘<code>||</code>’ does not trigger a return. Hence in the
|
||
following:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">summit || true
|
||
</code></pre>
|
||
</div>
|
||
<p>no return is forced as the combined effect always has a zero return
|
||
status.</p>
|
||
<p>Note. however, that if <code>summit</code> in the above example is itself a
|
||
function, code inside it is considered separately: it may force a return
|
||
from <code>summit</code> (assuming the option remains set within <code>summit</code>), but not
|
||
from the enclosing context. This behaviour is different from <code>ERR_EXIT</code>
|
||
which is unaffected by function scope.</p>
|
||
<p><span id="index-EVAL_005fLINENO"></span>
|
||
<span id="index-NO_005fEVAL_005fLINENO"></span>
|
||
<span id="index-EVALLINENO"></span>
|
||
<span id="index-NOEVALLINENO"></span>
|
||
<span id="index-line-number_002c-in-evaluated-expression"></span></p>
|
||
<p><code>EVAL_LINENO</code> <Z></p>
|
||
<p>If set, line numbers of expressions evaluated using the builtin <code>eval</code>
|
||
are tracked separately of the enclosing environment. This applies both
|
||
to the parameter <code>LINENO</code> and the line number output by the prompt
|
||
escape <code>%i</code>. If the option is set, the prompt escape <code>%N</code> will output
|
||
the string ‘<code>(eval)</code>’ instead of the script or function name as an
|
||
indication. (The two prompt escapes are typically used in the parameter
|
||
<code>PS4</code> to be output when the option <code>XTRACE</code> is set.) If <code>EVAL_LINENO</code> is
|
||
unset, the line number of the surrounding script or function is retained
|
||
during the evaluation.</p>
|
||
<p><span id="index-EXEC"></span> <span id="index-NO_005fEXEC"></span>
|
||
<span id="index-NOEXEC"></span>
|
||
<span id="index-command-execution_002c-enabling"></span></p>
|
||
<p><code>EXEC</code> (<code>+n</code>, ksh: <code>+n</code>) <D></p>
|
||
<p>Do execute commands. Without this option, commands are read and checked
|
||
for syntax errors, but not executed. This option cannot be turned off in
|
||
an interactive shell, except when ‘<code>-n</code>’ is supplied to the shell at
|
||
startup.</p>
|
||
<p><span id="index-FUNCTION_005fARGZERO"></span>
|
||
<span id="index-NO_005fFUNCTION_005fARGZERO"></span>
|
||
<span id="index-FUNCTIONARGZERO"></span>
|
||
<span id="index-NOFUNCTIONARGZERO"></span>
|
||
<span id="index-_00240_002c-setting"></span></p>
|
||
<p><code>FUNCTION_ARGZERO</code> <C> <Z></p>
|
||
<p>When executing a shell function or sourcing a script, set <code>$0</code>
|
||
temporarily to the name of the function/script. Note that toggling
|
||
<code>FUNCTION_ARGZERO</code> from on to off (or off to on) does not change the
|
||
current value of <code>$0</code>. Only the state upon entry to the function or
|
||
script has an effect. Compare <code>POSIX_ARGZERO</code>.</p>
|
||
<p><span id="index-LOCAL_005fLOOPS"></span>
|
||
<span id="index-NO_005fLOCAL_005fLOOPS"></span>
|
||
<span id="index-LOCALLOOPS"></span>
|
||
<span id="index-NOLOCALLOOPS"></span>
|
||
<span id="index-break_002c-inside-function"></span>
|
||
<span id="index-continue_002c-inside-function"></span>
|
||
<span id="index-function_002c-scope-of-break-and-continue"></span></p>
|
||
<p><code>LOCAL_LOOPS</code></p>
|
||
<p>When this option is not set, the effect of <code>break</code> and <code>continue</code>
|
||
commands may propagate outside function scope, affecting loops in
|
||
calling functions. When the option is set in a calling function, a
|
||
<code>break</code> or a <code>continue</code> that is not caught within a called function
|
||
(regardless of the setting of the option within that function) produces
|
||
a warning and the effect is cancelled.</p>
|
||
<p><span id="index-LOCAL_005fOPTIONS"></span>
|
||
<span id="index-NO_005fLOCAL_005fOPTIONS"></span>
|
||
<span id="index-LOCALOPTIONS"></span>
|
||
<span id="index-NOLOCALOPTIONS"></span></p>
|
||
<p><code>LOCAL_OPTIONS</code> <K></p>
|
||
<p>If this option is set at the point of return from a shell function, most
|
||
options (including this one) which were in force upon entry to the
|
||
function are restored; options that are not restored are <code>PRIVILEGED</code>
|
||
and <code>RESTRICTED</code>. Otherwise, only this option, and the <code>LOCAL_LOOPS</code>,
|
||
<code>XTRACE</code> and <code>PRINT_EXIT_VALUE</code> options are restored. Hence if this is
|
||
explicitly unset by a shell function the other options in force at the
|
||
point of return will remain so. A shell function can also guarantee
|
||
itself a known shell configuration with a formulation like ‘<code>emulate -L zsh</code>’; the <code>-L</code> activates <code>LOCAL_OPTIONS</code>.</p>
|
||
<p><span id="index-LOCAL_005fPATTERNS"></span>
|
||
<span id="index-NO_005fLOCAL_005fPATTERNS"></span>
|
||
<span id="index-LOCALPATTERNS"></span>
|
||
<span id="index-NOLOCALPATTERNS"></span></p>
|
||
<p><code>LOCAL_PATTERNS</code></p>
|
||
<p>If this option is set at the point of return from a shell function, the
|
||
state of pattern disables, as set with the builtin command ‘<code>disable -p</code>’, is restored to what it was when the function was entered. The
|
||
behaviour of this option is similar to the effect of <code>LOCAL_OPTIONS</code> on
|
||
options; hence ‘<code>emulate -L sh</code>’ (or indeed any other emulation with the
|
||
<code>-L</code> option) activates <code>LOCAL_PATTERNS</code>.</p>
|
||
<p><span id="index-LOCAL_005fTRAPS"></span>
|
||
<span id="index-NO_005fLOCAL_005fTRAPS"></span>
|
||
<span id="index-LOCALTRAPS"></span>
|
||
<span id="index-NOLOCALTRAPS"></span></p>
|
||
<p><code>LOCAL_TRAPS</code> <K></p>
|
||
<p>If this option is set when a signal trap is set inside a function, then
|
||
the previous status of the trap for that signal will be restored when
|
||
the function exits. Note that this option must be set <em>prior</em> to
|
||
altering the trap behaviour in a function; unlike <code>LOCAL_OPTIONS</code>, the
|
||
value on exit from the function is irrelevant. However, it does not need
|
||
to be set before any global trap for that to be correctly restored by a
|
||
function. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">unsetopt localtraps
|
||
trap - INT
|
||
fn() { setopt localtraps; trap '' INT; sleep 3; }
|
||
</code></pre>
|
||
</div>
|
||
<p>will restore normal handling of <code>SIGINT</code> after the function exits.</p>
|
||
<p><span id="index-MULTI_005fFUNC_005fDEF"></span>
|
||
<span id="index-NO_005fMULTI_005fFUNC_005fDEF"></span>
|
||
<span id="index-MULTIFUNCDEF"></span>
|
||
<span id="index-NOMULTIFUNCDEF"></span></p>
|
||
<p><code>MULTI_FUNC_DEF</code> <Z></p>
|
||
<p>Allow definitions of multiple functions at once in the form ‘<code>fn1 fn2``...``()</code>’; if the option is not set, this causes a parse error.
|
||
Definition of multiple functions with the <code>function</code> keyword is always
|
||
allowed. Multiple function definitions are not often used and can cause
|
||
obscure errors.</p>
|
||
<p><span id="index-MULTIOS"></span> <span id="index-NO_005fMULTIOS"></span>
|
||
<span id="index-NOMULTIOS"></span></p>
|
||
<p><code>MULTIOS</code> <Z></p>
|
||
<p>Perform implicit tees or cats when multiple redirections are attempted
|
||
(see <a href="Redirection.html#Redirection">Redirection</a>).</p>
|
||
<p><span id="index-OCTAL_005fZEROES"></span>
|
||
<span id="index-NO_005fOCTAL_005fZEROES"></span>
|
||
<span id="index-OCTALZEROES"></span>
|
||
<span id="index-NOOCTALZEROES"></span>
|
||
<span id="index-octal_002c-arithmetic-expressions"></span></p>
|
||
<p><code>OCTAL_ZEROES</code> <S></p>
|
||
<p>Interpret any integer constant beginning with a 0 as octal, per IEEE Std
|
||
1003.2-1992 (ISO 9945-2:1993). This is not enabled by default as it
|
||
causes problems with parsing of, for example, date and time strings with
|
||
leading zeroes.</p>
|
||
<p>Sequences of digits indicating a numeric base such as the ‘<code>08</code>’
|
||
component in ‘<code>08#77</code>’ are always interpreted as decimal, regardless of
|
||
leading zeroes.</p>
|
||
<p><span id="index-PIPE_005fFAIL"></span>
|
||
<span id="index-NO_005fPIPE_005fFAIL"></span>
|
||
<span id="index-PIPEFAIL"></span> <span id="index-NOPIPEFAIL"></span>
|
||
<span id="index-exit-status-from-pipeline"></span>
|
||
<span id="index-status_002c-on-exit-from-pipeline"></span>
|
||
<span id="index-pipeline_002c-exit-status-from"></span></p>
|
||
<p><code>PIPE_FAIL</code></p>
|
||
<p>By default, when a pipeline exits the exit status recorded by the shell
|
||
and returned by the shell variable <code>$?</code> reflects that of the rightmost
|
||
element of a pipeline. If this option is set, the exit status instead
|
||
reflects the status of the rightmost element of the pipeline that was
|
||
non-zero, or zero if all elements exited with zero status.</p>
|
||
<p><span id="index-SOURCE_005fTRACE"></span>
|
||
<span id="index-NO_005fSOURCE_005fTRACE"></span>
|
||
<span id="index-SOURCETRACE"></span>
|
||
<span id="index-NOSOURCETRACE"></span></p>
|
||
<p><code>SOURCE_TRACE</code></p>
|
||
<p>If set, zsh will print an informational message announcing the name of
|
||
each file it loads. The format of the output is similar to that for the
|
||
<code>XTRACE</code> option, with the message <code><sourcetrace></code>. A file may be loaded
|
||
by the shell itself when it starts up and shuts down (<code>Startup/Shutdown Files</code>) or by the use of the ‘<code>source</code>’ and ‘<code>dot</code>’ builtin commands.</p>
|
||
<p><span id="index-TYPESET_005fSILENT"></span>
|
||
<span id="index-NO_005fTYPESET_005fSILENT"></span>
|
||
<span id="index-TYPESETSILENT"></span>
|
||
<span id="index-NOTYPESETSILENT"></span></p>
|
||
<p><code>TYPESET_SILENT</code></p>
|
||
<p>If this is unset, executing any of the ‘<code>typeset</code>’ family of commands
|
||
with no options and a list of parameters that have no values to be
|
||
assigned but already exist will display the value of the parameter. If
|
||
the option is set, they will only be shown when parameters are selected
|
||
with the ‘<code>-m</code>’ option. The option ‘<code>-p</code>’ is available whether or not
|
||
the option is set.</p>
|
||
<p><span id="index-VERBOSE"></span> <span id="index-NO_005fVERBOSE"></span>
|
||
<span id="index-NOVERBOSE"></span>
|
||
<span id="index-tracing_002c-of-input-lines"></span>
|
||
<span id="index-input_002c-tracing"></span></p>
|
||
<p><code>VERBOSE</code> (<code>-v</code>, ksh: <code>-v</code>)</p>
|
||
<p>Print shell input lines as they are read.</p>
|
||
<p><span id="index-XTRACE"></span> <span id="index-NO_005fXTRACE"></span>
|
||
<span id="index-NOXTRACE"></span>
|
||
<span id="index-tracing_002c-of-commands"></span>
|
||
<span id="index-commands_002c-tracing"></span></p>
|
||
<p><code>XTRACE</code> (<code>-x</code>, ksh: <code>-x</code>)</p>
|
||
<p>Print commands and their arguments as they are executed. The output is
|
||
preceded by the value of <code>$PS4</code>, formatted as described in <a href="Prompt-Expansion.html#Prompt-Expansion">Prompt
|
||
Expansion</a>.</p>
|
||
<hr />
|
||
<p><span id="Shell-Emulation"></span></p>
|
||
<h3 id="16210-shell-emulation"><a class="header" href="#16210-shell-emulation">16.2.10 Shell Emulation</a></h3>
|
||
<p><span id="index-APPEND_005fCREATE"></span>
|
||
<span id="index-NO_005fAPPEND_005fCREATE"></span>
|
||
<span id="index-APPENDCREATE"></span>
|
||
<span id="index-NOAPPENDCREATE"></span>
|
||
<span id="index-clobbering_002c-POSIX-compatibility"></span>
|
||
<span id="index-file-clobbering_002c-POSIX-compatibility"></span>
|
||
<span id="index-no-clobber_002c-POSIX-compatible"></span></p>
|
||
<p><code>APPEND_CREATE</code> <K> <S></p>
|
||
<p>This option only applies when <code>NO_CLOBBER</code> (-<code>C</code>) is in effect.</p>
|
||
<p>If this option is not set, the shell will report an error when a append
|
||
redirection (<code>>></code>) is used on a file that does not already exists (the
|
||
traditional zsh behaviour of <code>NO_CLOBBER</code>). If the option is set, no
|
||
error is reported (POSIX behaviour).</p>
|
||
<p><span id="index-BASH_005fREMATCH"></span>
|
||
<span id="index-NO_005fBASH_005fREMATCH"></span>
|
||
<span id="index-BASHREMATCH"></span>
|
||
<span id="index-NOBASHREMATCH"></span>
|
||
<span id="index-bash_002c-BASH_005fREMATCH-variable"></span>
|
||
<span id="index-regexp_002c-bash-BASH_005fREMATCH-variable"></span></p>
|
||
<p><code>BASH_REMATCH</code></p>
|
||
<p>When set, matches performed with the <code>=~</code> operator will set the
|
||
<code>BASH_REMATCH</code> array variable, instead of the default <code>MATCH</code> and
|
||
<code>match</code> variables. The first element of the <code>BASH_REMATCH</code> array will
|
||
contain the entire matched text and subsequent elements will contain
|
||
extracted substrings. This option makes more sense when <code>KSH_ARRAYS</code> is
|
||
also set, so that the entire matched portion is stored at index 0 and
|
||
the first substring is at index 1. Without this option, the <code>MATCH</code>
|
||
variable contains the entire matched text and the <code>match</code> array variable
|
||
contains substrings.</p>
|
||
<p><span id="index-BSD_005fECHO"></span>
|
||
<span id="index-NO_005fBSD_005fECHO"></span>
|
||
<span id="index-BSDECHO"></span> <span id="index-NOBSDECHO"></span>
|
||
<span id="index-echo_002c-BSD-compatible"></span></p>
|
||
<p><code>BSD_ECHO</code> <S></p>
|
||
<p>Make the <code>echo</code> builtin compatible with the BSD man page echo(1)
|
||
command. This disables backslashed escape sequences in echo strings
|
||
unless the <code>-e</code> option is specified.</p>
|
||
<p><span id="index-CONTINUE_005fON_005fERROR"></span>
|
||
<span id="index-NO_005fCONTINUE_005fON_005fERROR"></span>
|
||
<span id="index-CONTINUEONERROR"></span>
|
||
<span id="index-NOCONTINUEONERROR"></span>
|
||
<span id="index-error_002c-option-to-continue-script-on"></span></p>
|
||
<p><code>CONTINUE_ON_ERROR</code></p>
|
||
<p>If a fatal error is encountered (see
|
||
<a href="Shell-Grammar.html#Errors">Errors</a>), and the code is running in a
|
||
script, the shell will resume execution at the next statement in the
|
||
script at the top level, in other words outside all functions or shell
|
||
constructs such as loops and conditions. This mimics the behaviour of
|
||
interactive shells, where the shell returns to the line editor to read a
|
||
new command; it was the normal behaviour in versions of zsh before
|
||
5.0.1.</p>
|
||
<p><span id="index-CSH_005fJUNKIE_005fHISTORY"></span>
|
||
<span id="index-NO_005fCSH_005fJUNKIE_005fHISTORY"></span>
|
||
<span id="index-CSHJUNKIEHISTORY"></span>
|
||
<span id="index-NOCSHJUNKIEHISTORY"></span>
|
||
<span id="index-csh_002c-history-style"></span>
|
||
<span id="index-history-style_002c-csh"></span></p>
|
||
<p><code>CSH_JUNKIE_HISTORY</code> <C></p>
|
||
<p>A history reference without an event specifier will always refer to the
|
||
previous command. Without this option, such a history reference refers
|
||
to the same event as the previous history reference on the current
|
||
command line, defaulting to the previous command.</p>
|
||
<p><span id="index-CSH_005fJUNKIE_005fLOOPS"></span>
|
||
<span id="index-NO_005fCSH_005fJUNKIE_005fLOOPS"></span>
|
||
<span id="index-CSHJUNKIELOOPS"></span>
|
||
<span id="index-NOCSHJUNKIELOOPS"></span>
|
||
<span id="index-csh_002c-loop-style"></span>
|
||
<span id="index-loop-style_002c-csh"></span></p>
|
||
<p><code>CSH_JUNKIE_LOOPS</code> <C></p>
|
||
<p>Allow loop bodies to take the form ‘<code>list``; end</code>’ instead of ‘<code> do ``list``; done</code>’.</p>
|
||
<p><span id="index-CSH_005fJUNKIE_005fQUOTES"></span>
|
||
<span id="index-NO_005fCSH_005fJUNKIE_005fQUOTES"></span>
|
||
<span id="index-CSHJUNKIEQUOTES"></span>
|
||
<span id="index-NOCSHJUNKIEQUOTES"></span>
|
||
<span id="index-csh_002c-quoting-style"></span>
|
||
<span id="index-quoting-style_002c-csh"></span></p>
|
||
<p><code>CSH_JUNKIE_QUOTES</code> <C></p>
|
||
<p>Changes the rules for single- and double-quoted text to match that of
|
||
csh. These require that embedded newlines be preceded by a backslash;
|
||
unescaped newlines will cause an error message. In double-quoted
|
||
strings, it is made impossible to escape ‘<code>$</code>’, ‘<code>‘</code>’ or ‘<code>"</code>’ (and
|
||
‘<code>\</code>’ itself no longer needs escaping). Command substitutions are
|
||
only expanded once, and cannot be nested.</p>
|
||
<p><span id="index-CSH_005fNULLCMD"></span>
|
||
<span id="index-NO_005fCSH_005fNULLCMD"></span>
|
||
<span id="index-CSHNULLCMD"></span>
|
||
<span id="index-NOCSHNULLCMD"></span>
|
||
<span id="index-NULLCMD_002c-ignoring"></span>
|
||
<span id="index-READNULLCMD_002c-ignoring"></span>
|
||
<span id="index-redirections-with-no-command_002c-csh"></span>
|
||
<span id="index-csh_002c-redirections-with-no-command"></span></p>
|
||
<p><code>CSH_NULLCMD</code> <C></p>
|
||
<p>Do not use the values of <code>NULLCMD</code> and <code>READNULLCMD</code> when running
|
||
redirections with no command. This make such redirections fail (see
|
||
<a href="Redirection.html#Redirection">Redirection</a>).</p>
|
||
<p><span id="index-KSH_005fARRAYS"></span>
|
||
<span id="index-NO_005fKSH_005fARRAYS"></span>
|
||
<span id="index-KSHARRAYS"></span> <span id="index-NOKSHARRAYS"></span>
|
||
<span id="index-arrays_002c-ksh-style"></span>
|
||
<span id="index-array-style_002c-ksh"></span>
|
||
<span id="index-ksh_002c-array-style"></span></p>
|
||
<p><code>KSH_ARRAYS</code> <K> <S></p>
|
||
<p>Emulate ksh array handling as closely as possible. If this option is
|
||
set, array elements are numbered from zero, an array parameter without
|
||
subscript refers to the first element instead of the whole array, and
|
||
braces are required to delimit a subscript (‘<code>${path[2]}</code>’ rather than
|
||
just ‘<code>$path[2]</code>’) or to apply modifiers to any parameter (‘<code>${PWD:h}</code>’
|
||
rather than ‘<code>$PWD:h</code>’).</p>
|
||
<p><span id="index-KSH_005fAUTOLOAD"></span>
|
||
<span id="index-NO_005fKSH_005fAUTOLOAD"></span>
|
||
<span id="index-KSHAUTOLOAD"></span>
|
||
<span id="index-NOKSHAUTOLOAD"></span></p>
|
||
<p><code>KSH_AUTOLOAD</code> <K> <S></p>
|
||
<p>Emulate ksh function autoloading. This means that when a function is
|
||
autoloaded, the corresponding file is merely executed, and must define
|
||
the function itself. (By default, the function is defined to the
|
||
contents of the file. However, the most common ksh-style case - of the
|
||
file containing only a simple definition of the function - is always
|
||
handled in the ksh-compatible manner.)</p>
|
||
<p><span id="index-KSH_005fOPTION_005fPRINT"></span>
|
||
<span id="index-NO_005fKSH_005fOPTION_005fPRINT"></span>
|
||
<span id="index-KSHOPTIONPRINT"></span>
|
||
<span id="index-NOKSHOPTIONPRINT"></span>
|
||
<span id="index-option-printing_002c-ksh-style"></span>
|
||
<span id="index-option-printing-style_002c-ksh"></span>
|
||
<span id="index-ksh_002c-option-printing-style"></span></p>
|
||
<p><code>KSH_OPTION_PRINT</code> <K></p>
|
||
<p>Alters the way options settings are printed: instead of separate lists
|
||
of set and unset options, all options are shown, marked ‘on’ if they are
|
||
in the non-default state, ‘off’ otherwise.</p>
|
||
<p><span id="index-KSH_005fTYPESET"></span>
|
||
<span id="index-NO_005fKSH_005fTYPESET"></span>
|
||
<span id="index-KSHTYPESET"></span>
|
||
<span id="index-NOKSHTYPESET"></span>
|
||
<span id="index-argument-splitting_002c-in-typeset-etc_002e"></span>
|
||
<span id="index-ksh_002c-argument-splitting-in-typeset"></span></p>
|
||
<p><code>KSH_TYPESET</code></p>
|
||
<p>This option is now obsolete: a better appropximation to the behaviour of
|
||
other shells is obtained with the reserved word interface to <code>declare</code>,
|
||
<code>export</code>, <code>float</code>, <code>integer</code>, <code>local</code>, <code>readonly</code> and <code>typeset</code>. Note
|
||
that the option is only applied when the reserved word interface is
|
||
<em>not</em> in use.</p>
|
||
<p>Alters the way arguments to the <code>typeset</code> family of commands, including
|
||
<code>declare</code>, <code>export</code>, <code>float</code>, <code>integer</code>, <code>local</code> and <code>readonly</code>, are
|
||
processed. Without this option, zsh will perform normal word splitting
|
||
after command and parameter expansion in arguments of an assignment;
|
||
with it, word splitting does not take place in those cases.</p>
|
||
<p><span id="index-KSH_005fZERO_005fSUBSCRIPT"></span>
|
||
<span id="index-NO_005fKSH_005fZERO_005fSUBSCRIPT"></span>
|
||
<span id="index-KSHZEROSUBSCRIPT"></span>
|
||
<span id="index-NOKSHZEROSUBSCRIPT"></span>
|
||
<span id="index-arrays_002c-behaviour-of-index-zero"></span></p>
|
||
<p><code>KSH_ZERO_SUBSCRIPT</code></p>
|
||
<p>Treat use of a subscript of value zero in array or string expressions as
|
||
a reference to the first element, i.e. the element that usually has the
|
||
subscript 1. Ignored if <code>KSH_ARRAYS</code> is also set.</p>
|
||
<p>If neither this option nor <code>KSH_ARRAYS</code> is set, accesses to an element
|
||
of an array or string with subscript zero return an empty element or
|
||
string, while attempts to set element zero of an array or string are
|
||
treated as an error. However, attempts to set an otherwise valid
|
||
subscript range that includes zero will succeed. For example, if
|
||
<code>KSH_ZERO_SUBSCRIPT</code> is not set,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">array[0]=(element)
|
||
</code></pre>
|
||
</div>
|
||
<p>is an error, while</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">array[0,1]=(element)
|
||
</code></pre>
|
||
</div>
|
||
<p>is not and will replace the first element of the array.</p>
|
||
<p>This option is for compatibility with older versions of the shell and is
|
||
not recommended in new code.</p>
|
||
<p><span id="index-POSIX_005fALIASES"></span>
|
||
<span id="index-NO_005fPOSIX_005fALIASES"></span>
|
||
<span id="index-POSIXALIASES"></span>
|
||
<span id="index-NOPOSIXALIASES"></span></p>
|
||
<p><code>POSIX_ALIASES</code> <K> <S></p>
|
||
<p>When this option is set, reserved words are not candidates for alias
|
||
expansion: it is still possible to declare any of them as an alias, but
|
||
the alias will never be expanded. Reserved words are described in
|
||
<a href="Shell-Grammar.html#Reserved-Words">Reserved Words</a>.</p>
|
||
<p>Alias expansion takes place while text is being read; hence when this
|
||
option is set it does not take effect until the end of any function or
|
||
other piece of shell code parsed as one unit. Note this may cause
|
||
differences from other shells even when the option is in effect. For
|
||
example, when running a command with ‘<code>zsh -c</code>’, or even ‘<code>zsh -o posixaliases -c</code>’, the entire command argument is parsed as one unit, so
|
||
aliases defined within the argument are not available even in later
|
||
lines. If in doubt, avoid use of aliases in non-interactive code.</p>
|
||
<p><span id="index-POSIX_005fARGZERO"></span>
|
||
<span id="index-NO_005fPOSIX_005fARGZERO"></span>
|
||
<span id="index-POSIXARGZERO"></span>
|
||
<span id="index-NOPOSIXARGZERO"></span>
|
||
<span id="index-_00240_002c-using"></span></p>
|
||
<p><code>POSIX_ARGZERO</code></p>
|
||
<p>This option may be used to temporarily disable <code>FUNCTION_ARGZERO</code> and
|
||
thereby restore the value of <code>$0</code> to the name used to invoke the shell
|
||
(or as set by the <code>-c</code> command line option). For compatibility with
|
||
previous versions of the shell, emulations use <code>NO_FUNCTION_ARGZERO</code>
|
||
instead of <code>POSIX_ARGZERO</code>, which may result in unexpected scoping of
|
||
<code>$0</code> if the emulation mode is changed inside a function or script. To
|
||
avoid this, explicitly enable <code>POSIX_ARGZERO</code> in the <code>emulate</code> command:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">emulate sh -o POSIX_ARGZERO
|
||
</code></pre>
|
||
</div>
|
||
<p>Note that <code>NO_POSIX_ARGZERO</code> has no effect unless <code>FUNCTION_ARGZERO</code> was
|
||
already enabled upon entry to the function or script.</p>
|
||
<p><span id="index-POSIX_005fBUILTINS"></span>
|
||
<span id="index-NO_005fPOSIX_005fBUILTINS"></span>
|
||
<span id="index-POSIXBUILTINS"></span>
|
||
<span id="index-NOPOSIXBUILTINS"></span></p>
|
||
<p><code>POSIX_BUILTINS</code> <K> <S></p>
|
||
<p>When this option is set the <code>command</code> builtin can be used to execute
|
||
shell builtin commands. Parameter assignments specified before shell
|
||
functions and special builtins are kept after the command completes
|
||
unless the special builtin is prefixed with the <code>command</code> builtin.
|
||
Special builtins are <code>.</code>, <code>:</code>, <code>break</code>, <code>continue</code>, <code>declare</code>, <code>eval</code>,
|
||
<code>exit</code>, <code>export</code>, <code>integer</code>, <code>local</code>, <code>readonly</code>, <code>return</code>, <code>set</code>,
|
||
<code>shift</code>, <code>source</code>, <code>times</code>, <code>trap</code> and <code>unset</code>.</p>
|
||
<p>In addition, various error conditions associated with the above builtins
|
||
or <code>exec</code> cause a non-interactive shell to exit and an interactive shell
|
||
to return to its top-level processing.</p>
|
||
<p>Furthermore, functions and shell builtins are not executed after an
|
||
<code>exec</code> prefix; the command to be executed must be an external command
|
||
found in the path.</p>
|
||
<p>Furthermore, the <code>getopts</code> builtin behaves in a POSIX-compatible fashion
|
||
in that the associated variable <code>OPTIND</code> is not made local to functions.</p>
|
||
<p>Moreover, the warning and special exit code from <code>[[ -o ``non_existent_option`` ]]</code> are suppressed.</p>
|
||
<p><span id="index-POSIX_005fIDENTIFIERS"></span>
|
||
<span id="index-NO_005fPOSIX_005fIDENTIFIERS"></span>
|
||
<span id="index-POSIXIDENTIFIERS"></span>
|
||
<span id="index-NOPOSIXIDENTIFIERS"></span></p>
|
||
<p><code>POSIX_IDENTIFIERS</code> <K> <S></p>
|
||
<p>When this option is set, only the ASCII characters <code>a</code> to <code>z</code>, <code>A</code> to
|
||
<code>Z</code>, <code>0</code> to <code>9</code> and <code>_</code> may be used in identifiers (names of shell
|
||
parameters and modules).</p>
|
||
<p>In addition, setting this option limits the effect of parameter
|
||
substitution with no braces, so that the expression <code>$#</code> is treated as
|
||
the parameter <code>$#</code> even if followed by a valid parameter name. When it
|
||
is unset, zsh allows expressions of the form <code>$#``name</code> to refer to the
|
||
length of <code>$``name</code>, even for special variables, for example in
|
||
expressions such as <code>$#-</code> and <code>$#*</code>.</p>
|
||
<p>Another difference is that with the option set assignment to an unset
|
||
variable in arithmetic context causes the variable to be created as a
|
||
scalar rather than a numeric type. So after ‘<code>unset t; (( t = 3 ))</code>’.
|
||
without <code>POSIX_IDENTIFIERS</code> set <code>t</code> has integer type, while with it set
|
||
it has scalar type.</p>
|
||
<p>When the option is unset and multibyte character support is enabled
|
||
(i.e. it is compiled in and the option <code>MULTIBYTE</code> is set), then
|
||
additionally any alphanumeric characters in the local character set may
|
||
be used in identifiers. Note that scripts and functions written with
|
||
this feature are or function is parsed; setting them during execution is
|
||
not sufficient as the syntax <code>variable``=``value</code> has already been
|
||
parsed as a command rather than an assignment.</p>
|
||
<p>If multibyte character support is not compiled into the shell this
|
||
option is ignored; all octets with the top bit set may be used in
|
||
identifiers. This is non-standard but is the traditional zsh behaviour.</p>
|
||
<p><span id="index-POSIX_005fSTRINGS"></span>
|
||
<span id="index-NO_005fPOSIX_005fSTRINGS"></span>
|
||
<span id="index-POSIXSTRINGS"></span>
|
||
<span id="index-NOPOSIXSTRINGS"></span>
|
||
<span id="index-discarding-embedded-nulls-in-_0024_0027_002e_002e_002e_0027"></span>
|
||
<span id="index-embedded-nulls_002c-in-_0024_0027_002e_002e_002e_0027"></span>
|
||
<span id="index-nulls_002c-embedded-in-_0024_0027_002e_002e_002e_0027"></span></p>
|
||
<p><code>POSIX_STRINGS</code> <K> <S></p>
|
||
<p>This option affects processing of quoted strings. Currently it only
|
||
affects the behaviour of null characters, i.e. character 0 in the</p>
|
||
<p>When this option is not set, null characters embedded within strings of
|
||
the form <code>$’``...``’</code> are treated as ordinary characters. The entire
|
||
string is maintained within the shell and output to files where
|
||
necessary, although owing to restrictions of the library interface the
|
||
string is truncated at the null character in file names, environment
|
||
variables, or in arguments to external programs.</p>
|
||
<p>When this option is set, the <code>$’``...``’</code> expression is truncated at the
|
||
null character. Note that remaining parts of the same string beyond the
|
||
termination of the quotes are not truncated.</p>
|
||
<p>For example, the command line argument <code>a$’b\0c’d</code> is treated with the
|
||
option off as the characters <code>a</code>, <code>b</code>, null, <code>c</code>, <code>d</code>, and with the
|
||
option on as the characters <code>a</code>, <code>b</code>, <code>d</code>.</p>
|
||
<p><span id="index-POSIX_005fTRAPS"></span>
|
||
<span id="index-NO_005fPOSIX_005fTRAPS"></span>
|
||
<span id="index-POSIXTRAPS"></span>
|
||
<span id="index-NOPOSIXTRAPS"></span>
|
||
<span id="index-traps_002c-on-function-exit"></span>
|
||
<span id="index-traps_002c-POSIX-compatibility"></span></p>
|
||
<p><code>POSIX_TRAPS</code> <K> <S></p>
|
||
<p>When this option is set, the usual zsh behaviour of executing traps for
|
||
<code>EXIT</code> on exit from shell functions is suppressed. In that case,
|
||
manipulating <code>EXIT</code> traps always alters the global trap for exiting the
|
||
shell; the <code>LOCAL_TRAPS</code> option is ignored for the <code>EXIT</code> trap.
|
||
Furthermore, a <code>return</code> statement executed in a trap with no argument
|
||
passes back from the function the value from the surrounding context,
|
||
not from code executed within the trap.</p>
|
||
<p><span id="index-SH_005fFILE_005fEXPANSION"></span>
|
||
<span id="index-NO_005fSH_005fFILE_005fEXPANSION"></span>
|
||
<span id="index-SHFILEEXPANSION"></span>
|
||
<span id="index-NOSHFILEEXPANSION"></span>
|
||
<span id="index-sh_002c-expansion-style"></span>
|
||
<span id="index-expansion-style_002c-sh"></span></p>
|
||
<p><code>SH_FILE_EXPANSION</code> <K> <S></p>
|
||
<p>Perform filename expansion (e.g., <code>~</code> expansion) <em>before</em> parameter
|
||
expansion, command substitution, arithmetic expansion and brace
|
||
expansion. If this option is unset, it is performed <em>after</em> brace
|
||
expansion, so things like ‘<code>~$USERNAME</code>’ and ‘<code>~{pfalstad,rc}</code>’ will
|
||
work.</p>
|
||
<p><span id="index-SH_005fNULLCMD"></span>
|
||
<span id="index-NO_005fSH_005fNULLCMD"></span>
|
||
<span id="index-SHNULLCMD"></span> <span id="index-NOSHNULLCMD"></span>
|
||
<span id="index-NULLCMD_002c-ignoring-1"></span>
|
||
<span id="index-READNULLCMD_002c-ignoring-1"></span>
|
||
<span id="index-sh_002c-redirections-with-no-command"></span>
|
||
<span id="index-ksh_002c-redirections-with-no-command"></span>
|
||
<span id="index-redirections-with-no-command_002c-sh"></span>
|
||
<span id="index-redirections-with-no-command_002c-ksh"></span></p>
|
||
<p><code>SH_NULLCMD</code> <K> <S></p>
|
||
<p>Do not use the values of <code>NULLCMD</code> and <code>READNULLCMD</code> when doing
|
||
redirections, use ‘<code>:</code>’ instead (see
|
||
<a href="Redirection.html#Redirection">Redirection</a>).</p>
|
||
<p><span id="index-SH_005fOPTION_005fLETTERS"></span>
|
||
<span id="index-NO_005fSH_005fOPTION_005fLETTERS"></span>
|
||
<span id="index-SHOPTIONLETTERS"></span>
|
||
<span id="index-NOSHOPTIONLETTERS"></span>
|
||
<span id="index-sh_002c-single-letter-options-style"></span>
|
||
<span id="index-ksh_002c-single-letter-options-style"></span>
|
||
<span id="index-single-letter-options_002c-ksh-style"></span>
|
||
<span id="index-options_002c-single-letter_002c-ksh-style"></span></p>
|
||
<p><code>SH_OPTION_LETTERS</code> <K> <S></p>
|
||
<p>If this option is set the shell tries to interpret single letter options
|
||
(which are used with <code>set</code> and <code>setopt</code>) like ksh does. This also
|
||
affects the value of the <code>-</code> special parameter.</p>
|
||
<p><span id="index-SH_005fWORD_005fSPLIT"></span>
|
||
<span id="index-NO_005fSH_005fWORD_005fSPLIT"></span>
|
||
<span id="index-SHWORDSPLIT"></span>
|
||
<span id="index-NOSHWORDSPLIT"></span>
|
||
<span id="index-field-splitting_002c-sh-style"></span>
|
||
<span id="index-sh_002c-field-splitting-style"></span></p>
|
||
<p><code>SH_WORD_SPLIT</code> (<code>-y</code>) <K> <S></p>
|
||
<p>Causes field splitting to be performed on unquoted parameter expansions.
|
||
Note that this option has nothing to do with word splitting. (See
|
||
<a href="Expansion.html#Parameter-Expansion">Parameter Expansion</a>.)</p>
|
||
<p><span id="index-TRAPS_005fASYNC"></span>
|
||
<span id="index-NO_005fTRAPS_005fASYNC"></span>
|
||
<span id="index-TRAPSASYNC"></span>
|
||
<span id="index-NOTRAPSASYNC"></span>
|
||
<span id="index-traps_002c-asynchronous"></span></p>
|
||
<p><code>TRAPS_ASYNC</code></p>
|
||
<p>While waiting for a program to exit, handle signals and run traps
|
||
immediately. Otherwise the trap is run after a child process has exited.
|
||
Note this does not affect the point at which traps are run for any case
|
||
other than when the shell is waiting for a child process.</p>
|
||
<hr />
|
||
<p><span id="Shell-State"></span></p>
|
||
<h3 id="16211-shell-state"><a class="header" href="#16211-shell-state">16.2.11 Shell State</a></h3>
|
||
<p><span id="index-INTERACTIVE"></span>
|
||
<span id="index-NO_005fINTERACTIVE"></span>
|
||
<span id="index-NOINTERACTIVE"></span></p>
|
||
<p><code>INTERACTIVE</code> (<code>-i</code>, ksh: <code>-i</code>)</p>
|
||
<p>This is an interactive shell. This option is set upon initialisation if
|
||
the standard input is a tty and commands are being read from standard
|
||
input. (See the discussion of <code>SHIN_STDIN</code>.) This heuristic may be
|
||
overridden by specifying a state for this option on the command line.
|
||
The value of this option can only be changed via flags supplied at
|
||
invocation of the shell. It cannot be changed once zsh is running.</p>
|
||
<p><span id="index-LOGIN"></span> <span id="index-NO_005fLOGIN"></span>
|
||
<span id="index-NOLOGIN"></span></p>
|
||
<p><code>LOGIN</code> (<code>-l</code>, ksh: <code>-l</code>)</p>
|
||
<p>This is a login shell. If this option is not explicitly set, the shell
|
||
becomes a login shell if the first character of the <code>argv[0]</code> passed to
|
||
the shell is a ‘<code>-</code>’.</p>
|
||
<p><span id="index-PRIVILEGED"></span>
|
||
<span id="index-NO_005fPRIVILEGED"></span>
|
||
<span id="index-NOPRIVILEGED"></span>
|
||
<span id="index-privileged-mode"></span>
|
||
<span id="index-mode_002c-privileged"></span></p>
|
||
<p><code>PRIVILEGED</code> (<code>-p</code>, ksh: <code>-p</code>)</p>
|
||
<p>Turn on privileged mode. Typically this is used when script is to be run
|
||
with elevated privileges. This should be done as follows directly with
|
||
the <code>-p</code> option to zsh so that it takes effect during startup.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">#!/bin/zsh -p
|
||
</code></pre>
|
||
</div>
|
||
<p>The option is enabled automatically on startup if the effective user
|
||
(group) ID is not equal to the real user (group) ID. In this case,
|
||
turning the option off causes the effective user and group IDs to be set
|
||
to the real user and group IDs. Be aware that if that fails the shell
|
||
may be running with different IDs than was intended so a script should
|
||
check for failure and act accordingly, for example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">unsetopt privileged || exit
|
||
</code></pre>
|
||
</div>
|
||
<p>The <code>PRIVILEGED</code> option disables sourcing user startup files. If zsh is
|
||
invoked as ‘<code>sh</code>’ or ‘<code>ksh</code>’ with this option set, <code>/etc/suid_profile</code>
|
||
is sourced (after <code>/etc/profile</code> on interactive shells). Sourcing
|
||
<code>~/.profile</code> is disabled and the contents of the <code>ENV</code> variable is
|
||
ignored. This option cannot be changed using the <code>-m</code> option of <code>setopt</code>
|
||
and <code>unsetopt</code>, and changing it inside a function always changes it
|
||
globally regardless of the <code>LOCAL_OPTIONS</code> option.</p>
|
||
<p><span id="index-RESTRICTED-1"></span>
|
||
<span id="index-NO_005fRESTRICTED"></span>
|
||
<span id="index-NORESTRICTED"></span>
|
||
<span id="index-restricted-shell-1"></span></p>
|
||
<p><code>RESTRICTED</code> (<code>-r</code>)</p>
|
||
<p>Enables restricted mode. This option cannot be changed using <code>unsetopt</code>,
|
||
and setting it inside a function always changes it globally regardless
|
||
of the <code>LOCAL_OPTIONS</code> option. See <a href="Invocation.html#Restricted-Shell">Restricted
|
||
Shell</a>.</p>
|
||
<p><span id="index-SHIN_005fSTDIN"></span>
|
||
<span id="index-NO_005fSHIN_005fSTDIN"></span>
|
||
<span id="index-SHINSTDIN"></span> <span id="index-NOSHINSTDIN"></span></p>
|
||
<p><code>SHIN_STDIN</code> (<code>-s</code>, ksh: <code>-s</code>)</p>
|
||
<p>Commands are being read from the standard input. Commands are read from
|
||
standard input if no command is specified with <code>-c</code> and no file of
|
||
commands is specified. If <code>SHIN_STDIN</code> is set explicitly on the command
|
||
line, any argument that would otherwise have been taken as a file to run
|
||
will instead be treated as a normal positional parameter. Note that
|
||
setting or unsetting this option on the command line does not
|
||
necessarily affect the state the option will have while the shell is
|
||
running - that is purely an indicator of whether or not commands are
|
||
<em>actually</em> being read from standard input. The value of this option can
|
||
only be changed via flags supplied at invocation of the shell. It cannot
|
||
be changed once zsh is running.</p>
|
||
<p><span id="index-SINGLE_005fCOMMAND"></span>
|
||
<span id="index-NO_005fSINGLE_005fCOMMAND"></span>
|
||
<span id="index-SINGLECOMMAND"></span>
|
||
<span id="index-NOSINGLECOMMAND"></span>
|
||
<span id="index-single-command"></span>
|
||
<span id="index-INTERACTIVE_002c-use-of"></span></p>
|
||
<p><code>SINGLE_COMMAND</code> (<code>-t</code>, ksh: <code>-t</code>)</p>
|
||
<p>If the shell is reading from standard input, it exits after a single
|
||
command has been executed. This also makes the shell non-interactive,
|
||
unless the <code>INTERACTIVE</code> option is explicitly set on the command line.
|
||
The value of this option can only be changed via flags supplied at
|
||
invocation of the shell. It cannot be changed once zsh is running.</p>
|
||
<hr />
|
||
<p><span id="Zle"></span></p>
|
||
<h3 id="16212-zle"><a class="header" href="#16212-zle">16.2.12 Zle</a></h3>
|
||
<p><span id="index-BEEP"></span> <span id="index-NO_005fBEEP"></span>
|
||
<span id="index-NOBEEP"></span>
|
||
<span id="index-beep_002c-enabling"></span>
|
||
<span id="index-enabling-the-beep"></span></p>
|
||
<p><code>BEEP</code> (<code>+B</code>) <D></p>
|
||
<p>Beep on error in ZLE.</p>
|
||
<p><span id="index-COMBINING_005fCHARS"></span>
|
||
<span id="index-NO_005fCOMBINING_005fCHARS"></span>
|
||
<span id="index-COMBININGCHARS"></span>
|
||
<span id="index-NOCOMBININGCHARS"></span>
|
||
<span id="index-characters_002c-_0028Unicode_0029-combining"></span>
|
||
<span id="index-combining-characters-_0028Unicode_0029"></span>
|
||
<span id="index-Unicode-combining-characters"></span></p>
|
||
<p><code>COMBINING_CHARS</code></p>
|
||
<p>Assume that the terminal displays combining characters correctly.
|
||
Specifically, if a base alphanumeric character is followed by one or
|
||
more zero-width punctuation characters, assume that the zero-width
|
||
characters will be displayed as modifications to the base character
|
||
within the same width. Not all terminals handle this. If this option is
|
||
not set, zero-width characters are displayed separately with special
|
||
mark-up.</p>
|
||
<p>If this option is set, the pattern test <code>[[:WORD:]]</code> matches a
|
||
zero-width punctuation character on the assumption that it will be used
|
||
as part of a word in combination with a word character. Otherwise the
|
||
base shell does not handle combining characters specially.</p>
|
||
<p><span id="index-EMACS"></span> <span id="index-NO_005fEMACS"></span>
|
||
<span id="index-NOEMACS"></span></p>
|
||
<p><code>EMACS</code></p>
|
||
<p>If ZLE is loaded, turning on this option has the equivalent effect of
|
||
‘<code>bindkey -e</code>’. In addition, the VI option is unset. Turning it off
|
||
has no effect. The option setting is not guaranteed to reflect the
|
||
current keymap. This option is provided for compatibility; <code>bindkey</code> is
|
||
the recommended interface.</p>
|
||
<p><span id="index-OVERSTRIKE"></span>
|
||
<span id="index-NO_005fOVERSTRIKE"></span>
|
||
<span id="index-NOOVERSTRIKE"></span>
|
||
<span id="index-editor_002c-overstrike-mode"></span>
|
||
<span id="index-overstrike-mode_002c-of-editor"></span></p>
|
||
<p><code>OVERSTRIKE</code></p>
|
||
<p>Start up the line editor in overstrike mode.</p>
|
||
<p><span id="index-SINGLE_005fLINE_005fZLE"></span>
|
||
<span id="index-NO_005fSINGLE_005fLINE_005fZLE"></span>
|
||
<span id="index-SINGLELINEZLE"></span>
|
||
<span id="index-NOSINGLELINEZLE"></span>
|
||
<span id="index-editor_002c-single-line-mode"></span></p>
|
||
<p><code>SINGLE_LINE_ZLE</code> (<code>-M</code>) <K></p>
|
||
<p>Use single-line command line editing instead of multi-line.</p>
|
||
<p>Note that although this is on by default in ksh emulation it only
|
||
provides superficial compatibility with the ksh line editor and reduces
|
||
the effectiveness of the zsh line editor. As it has no effect on shell
|
||
syntax, many users may wish to disable this option when using ksh
|
||
emulation interactively.</p>
|
||
<p><span id="index-VI"></span> <span id="index-NO_005fVI"></span>
|
||
<span id="index-NOVI"></span></p>
|
||
<p><code>VI</code></p>
|
||
<p>If ZLE is loaded, turning on this option has the equivalent effect of
|
||
‘<code>bindkey -v</code>’. In addition, the EMACS option is unset. Turning it off
|
||
has no effect. The option setting is not guaranteed to reflect the
|
||
current keymap. This option is provided for compatibility; <code>bindkey</code> is
|
||
the recommended interface.</p>
|
||
<p><span id="index-ZLE"></span> <span id="index-NO_005fZLE"></span>
|
||
<span id="index-NOZLE"></span>
|
||
<span id="index-editor_002c-enabling"></span>
|
||
<span id="index-enabling-the-editor"></span></p>
|
||
<p><code>ZLE</code> (<code>-Z</code>)</p>
|
||
<p>Use the zsh line editor. Set by default in interactive shells connected
|
||
to a terminal.</p>
|
||
<hr />
|
||
<p><span id="Option-Aliases"></span> <span id="Option-Aliases-1"></span></p>
|
||
<h2 id="163-option-aliases"><a class="header" href="#163-option-aliases">16.3 Option Aliases</a></h2>
|
||
<p><span id="index-options_002c-aliases"></span></p>
|
||
<p>Some options have alternative names. These aliases are never used for
|
||
output, but can be used just like normal option names when specifying
|
||
options to the shell.</p>
|
||
<p><span id="index-BRACE_005fEXPAND"></span>
|
||
<span id="index-NO_005fBRACE_005fEXPAND"></span>
|
||
<span id="index-BRACEEXPAND"></span>
|
||
<span id="index-NOBRACEEXPAND"></span></p>
|
||
<p><code>BRACE_EXPAND</code></p>
|
||
<p><em>NO_</em><code>IGNORE_BRACES</code> (ksh and bash compatibility)</p>
|
||
<p><span id="index-DOT_005fGLOB"></span>
|
||
<span id="index-NO_005fDOT_005fGLOB"></span>
|
||
<span id="index-DOTGLOB"></span> <span id="index-NODOTGLOB"></span></p>
|
||
<p><code>DOT_GLOB</code></p>
|
||
<p><code>GLOB_DOTS</code> (bash compatibility)</p>
|
||
<p><span id="index-HASH_005fALL"></span>
|
||
<span id="index-NO_005fHASH_005fALL"></span>
|
||
<span id="index-HASHALL"></span> <span id="index-NOHASHALL"></span></p>
|
||
<p><code>HASH_ALL</code></p>
|
||
<p><code>HASH_CMDS</code> (bash compatibility)</p>
|
||
<p><span id="index-HIST_005fAPPEND"></span>
|
||
<span id="index-NO_005fHIST_005fAPPEND"></span>
|
||
<span id="index-HISTAPPEND"></span>
|
||
<span id="index-NOHISTAPPEND"></span></p>
|
||
<p><code>HIST_APPEND</code></p>
|
||
<p><code>APPEND_HISTORY</code> (bash compatibility)</p>
|
||
<p><span id="index-HIST_005fEXPAND"></span>
|
||
<span id="index-NO_005fHIST_005fEXPAND"></span>
|
||
<span id="index-HISTEXPAND"></span>
|
||
<span id="index-NOHISTEXPAND"></span></p>
|
||
<p><code>HIST_EXPAND</code></p>
|
||
<p><code>BANG_HIST</code> (bash compatibility)</p>
|
||
<p><span id="index-LOG"></span> <span id="index-NO_005fLOG"></span>
|
||
<span id="index-NOLOG"></span></p>
|
||
<p><code>LOG</code></p>
|
||
<p><em>NO_</em><code>HIST_NO_FUNCTIONS</code> (ksh compatibility)</p>
|
||
<p><span id="index-MAIL_005fWARN"></span>
|
||
<span id="index-NO_005fMAIL_005fWARN"></span>
|
||
<span id="index-MAILWARN"></span> <span id="index-NOMAILWARN"></span></p>
|
||
<p><code>MAIL_WARN</code></p>
|
||
<p><code>MAIL_WARNING</code> (bash compatibility)</p>
|
||
<p><span id="index-ONE_005fCMD"></span>
|
||
<span id="index-NO_005fONE_005fCMD"></span>
|
||
<span id="index-ONECMD"></span> <span id="index-NOONECMD"></span></p>
|
||
<p><code>ONE_CMD</code></p>
|
||
<p><code>SINGLE_COMMAND</code> (bash compatibility)</p>
|
||
<p><span id="index-PHYSICAL"></span>
|
||
<span id="index-NO_005fPHYSICAL"></span>
|
||
<span id="index-NOPHYSICAL"></span></p>
|
||
<p><code>PHYSICAL</code></p>
|
||
<p><code>CHASE_LINKS</code> (ksh and bash compatibility)</p>
|
||
<p><span id="index-PROMPT_005fVARS"></span>
|
||
<span id="index-NO_005fPROMPT_005fVARS"></span>
|
||
<span id="index-PROMPTVARS"></span>
|
||
<span id="index-NOPROMPTVARS"></span></p>
|
||
<p><code>PROMPT_VARS</code></p>
|
||
<p><code>PROMPT_SUBST</code> (bash compatibility)</p>
|
||
<p><span id="index-STDIN"></span> <span id="index-NO_005fSTDIN"></span>
|
||
<span id="index-NOSTDIN"></span></p>
|
||
<p><code>STDIN</code></p>
|
||
<p><code>SHIN_STDIN</code> (ksh compatibility)</p>
|
||
<p><span id="index-TRACK_005fALL"></span>
|
||
<span id="index-NO_005fTRACK_005fALL"></span>
|
||
<span id="index-TRACKALL"></span> <span id="index-NOTRACKALL"></span></p>
|
||
<p><code>TRACK_ALL</code></p>
|
||
<p><code>HASH_CMDS</code> (ksh compatibility)</p>
|
||
<hr />
|
||
<p><span id="Single-Letter-Options"></span>
|
||
<span id="Single-Letter-Options-1"></span></p>
|
||
<h2 id="164-single-letter-options"><a class="header" href="#164-single-letter-options">16.4 Single Letter Options</a></h2>
|
||
<p><span id="index-options_002c-single-letter"></span>
|
||
<span id="index-single-letter-options"></span></p>
|
||
<hr />
|
||
<p><span id="Default-set"></span></p>
|
||
<h3 id="1641-default-set"><a class="header" href="#1641-default-set">16.4.1 Default set</a></h3>
|
||
<ul>
|
||
<li>
|
||
<p><code>-0</code><br />
|
||
CORRECT</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-1</code><br />
|
||
PRINT_EXIT_VALUE</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-2</code><br />
|
||
*NO_*BAD_PATTERN</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-3</code><br />
|
||
*NO_*NOMATCH</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-4</code><br />
|
||
GLOB_DOTS</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-5</code><br />
|
||
NOTIFY</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-6</code><br />
|
||
BG_NICE</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-7</code><br />
|
||
IGNORE_EOF</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-8</code><br />
|
||
MARK_DIRS</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-9</code><br />
|
||
AUTO_LIST</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-B</code><br />
|
||
*NO_*BEEP</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-C</code><br />
|
||
*NO_*CLOBBER</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-D</code><br />
|
||
PUSHD_TO_HOME</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-E</code><br />
|
||
PUSHD_SILENT</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-F</code><br />
|
||
*NO_*GLOB</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-G</code><br />
|
||
NULL_GLOB</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-H</code><br />
|
||
RM_STAR_SILENT</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-I</code><br />
|
||
IGNORE_BRACES</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-J</code><br />
|
||
AUTO_CD</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-K</code><br />
|
||
*NO_*BANG_HIST</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-L</code><br />
|
||
SUN_KEYBOARD_HACK</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-M</code><br />
|
||
SINGLE_LINE_ZLE</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-N</code><br />
|
||
AUTO_PUSHD</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-O</code><br />
|
||
CORRECT_ALL</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-P</code><br />
|
||
RC_EXPAND_PARAM</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-Q</code><br />
|
||
PATH_DIRS</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-R</code><br />
|
||
LONG_LIST_JOBS</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-S</code><br />
|
||
REC_EXACT</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-T</code><br />
|
||
CDABLE_VARS</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-U</code><br />
|
||
MAIL_WARNING</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-V</code><br />
|
||
*NO_*PROMPT_CR</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-W</code><br />
|
||
AUTO_RESUME</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-X</code><br />
|
||
LIST_TYPES</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-Y</code><br />
|
||
MENU_COMPLETE</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-Z</code><br />
|
||
ZLE</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-a</code><br />
|
||
ALL_EXPORT</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-e</code><br />
|
||
ERR_EXIT</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-f</code><br />
|
||
*NO_*RCS</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-g</code><br />
|
||
HIST_IGNORE_SPACE</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-h</code><br />
|
||
HIST_IGNORE_DUPS</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-i</code><br />
|
||
INTERACTIVE</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-k</code><br />
|
||
INTERACTIVE_COMMENTS</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-l</code><br />
|
||
LOGIN</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-m</code><br />
|
||
MONITOR</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-n</code><br />
|
||
*NO_*EXEC</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-p</code><br />
|
||
PRIVILEGED</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-r</code><br />
|
||
RESTRICTED</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-s</code><br />
|
||
SHIN_STDIN</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-t</code><br />
|
||
SINGLE_COMMAND</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-u</code><br />
|
||
*NO_*UNSET</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-v</code><br />
|
||
VERBOSE</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-w</code><br />
|
||
CHASE_LINKS</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-x</code><br />
|
||
XTRACE</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-y</code><br />
|
||
SH_WORD_SPLIT</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="sh_002fksh-emulation-set"></span></p>
|
||
<h3 id="1642-shksh-emulation-set"><a class="header" href="#1642-shksh-emulation-set">16.4.2 sh/ksh emulation set</a></h3>
|
||
<ul>
|
||
<li>
|
||
<p><code>-C</code><br />
|
||
*NO_*CLOBBER</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-T</code><br />
|
||
TRAPS_ASYNC</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-X</code><br />
|
||
MARK_DIRS</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-a</code><br />
|
||
ALL_EXPORT</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-b</code><br />
|
||
NOTIFY</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-e</code><br />
|
||
ERR_EXIT</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-f</code><br />
|
||
*NO_*GLOB</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-i</code><br />
|
||
INTERACTIVE</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-l</code><br />
|
||
LOGIN</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-m</code><br />
|
||
MONITOR</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-n</code><br />
|
||
*NO_*EXEC</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-p</code><br />
|
||
PRIVILEGED</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-r</code><br />
|
||
RESTRICTED</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-s</code><br />
|
||
SHIN_STDIN</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-t</code><br />
|
||
SINGLE_COMMAND</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-u</code><br />
|
||
*NO_*UNSET</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-v</code><br />
|
||
VERBOSE</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-x</code><br />
|
||
XTRACE</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Also-note"></span></p>
|
||
<h3 id="1643-also-note"><a class="header" href="#1643-also-note">16.4.3 Also note</a></h3>
|
||
<ul>
|
||
<li>
|
||
<p><code>-A</code><br />
|
||
Used by <code>set</code> for setting arrays</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-b</code><br />
|
||
Used on the command line to specify end of option processing</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-c</code><br />
|
||
Used on the command line to specify a single command</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-m</code><br />
|
||
Used by <code>setopt</code> for pattern-matching option setting</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-o</code><br />
|
||
Used in all places to allow use of long option names</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-s</code><br />
|
||
Used by <code>set</code> to sort positional parameters</p>
|
||
</li>
|
||
</ul>
|
||
<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>
|
||
<!-- 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="Shell-Builtin-Commands.html#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>
|
||
<!-- 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="Zsh-Line-Editor.html#18-zsh-line-editor">18 Zsh Line Editor</a>
|
||
<ul>
|
||
<li><a href="Zsh-Line-Editor.html#181-description">18.1 Description</a></li>
|
||
<li><a href="Zsh-Line-Editor.html#182-keymaps">18.2 Keymaps</a>
|
||
<ul>
|
||
<li><a href="Zsh-Line-Editor.html#1821-reading-commands">18.2.1 Reading Commands</a></li>
|
||
<li><a href="Zsh-Line-Editor.html#1822-local-keymaps">18.2.2 Local Keymaps</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Zsh-Line-Editor.html#183-zle-builtins">18.3 Zle Builtins</a></li>
|
||
<li><a href="Zsh-Line-Editor.html#184-widgets">18.4 Widgets</a></li>
|
||
<li><a href="Zsh-Line-Editor.html#185-user-defined-widgets">18.5 User-Defined Widgets</a>
|
||
<ul>
|
||
<li><a href="Zsh-Line-Editor.html#1851-special-widgets">18.5.1 Special Widgets</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Zsh-Line-Editor.html#186-standard-widgets">18.6 Standard Widgets</a>
|
||
<ul>
|
||
<li><a href="Zsh-Line-Editor.html#1861-movement">18.6.1 Movement</a></li>
|
||
<li><a href="Zsh-Line-Editor.html#1862-history-control">18.6.2 History Control</a></li>
|
||
<li><a href="Zsh-Line-Editor.html#1863-modifying-text">18.6.3 Modifying Text</a></li>
|
||
<li><a href="Zsh-Line-Editor.html#1864-arguments">18.6.4 Arguments</a></li>
|
||
<li><a href="Zsh-Line-Editor.html#1865-completion">18.6.5 Completion</a></li>
|
||
<li><a href="Zsh-Line-Editor.html#1866-miscellaneous">18.6.6 Miscellaneous</a></li>
|
||
<li><a href="Zsh-Line-Editor.html#1867-text-objects">18.6.7 Text Objects</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Zsh-Line-Editor.html#187-character-highlighting">18.7 Character Highlighting</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Zsh-Line-Editor"></span> <span id="Zsh-Line-Editor-1"></span></p>
|
||
<h1 id="18-zsh-line-editor"><a class="header" href="#18-zsh-line-editor">18 Zsh Line Editor</a></h1>
|
||
<p><span id="index-line-editor"></span>
|
||
<span id="index-editor_002c-line"></span> <span id="index-ZLE-1"></span></p>
|
||
<hr />
|
||
<p><span id="Description-9"></span></p>
|
||
<h2 id="181-description"><a class="header" href="#181-description">18.1 Description</a></h2>
|
||
<p><span id="index-ZLE_002c-use-of"></span></p>
|
||
<p>If the <code>ZLE</code> option is set (which it is by default in interactive
|
||
shells) and the shell input is attached to the terminal, the user is
|
||
able to edit command lines.</p>
|
||
<p>There are two display modes. The first, multiline mode, is the default.
|
||
It only works if the <code>TERM</code> parameter is set to a valid terminal type
|
||
that can move the cursor up. The second, single line mode, is used if
|
||
<code>TERM</code> is invalid or incapable of moving the cursor up, or if the
|
||
<code>SINGLE_LINE_ZLE</code> option is set.
|
||
<span id="index-SINGLE_005fLINE_005fZLE_002c-use-of"></span>
|
||
<span id="index-ksh_002c-editor-mode"></span>
|
||
<span id="index-editor-ksh-style"></span> This mode is similar to ksh,
|
||
and uses no termcap sequences. If <code>TERM</code> is "emacs", the <code>ZLE</code> option
|
||
will be unset by default.</p>
|
||
<p><span id="index-BAUD_002c-use-of"></span>
|
||
<span id="index-COLUMNS_002c-use-of"></span>
|
||
<span id="index-LINES_002c-use-of"></span></p>
|
||
<p>The parameters <code>BAUD</code>, <code>COLUMNS</code>, and <code>LINES</code> are also used by the line
|
||
editor. See <a href="Parameters.html#Parameters-Used-By-The-Shell">Parameters Used By The
|
||
Shell</a>.</p>
|
||
<p><span id="index-zle_005fhighlight_002c-use-of"></span></p>
|
||
<p>The parameter <code>zle_highlight</code> is also used by the line editor; see
|
||
<a href="Zsh-Line-Editor.html#Character-Highlighting">Character Highlighting</a>. Highlighting of
|
||
special characters and the region between the cursor and the mark (as
|
||
set with <code>set-mark-command</code> in Emacs mode, or by <code>visual-mode</code> in Vi
|
||
mode) is enabled by default; consult this reference for more
|
||
information. Irascible conservatives will wish to know that all
|
||
highlighting may be disabled by the following setting:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle_highlight=(none)
|
||
</code></pre>
|
||
</div>
|
||
<p>In many places, references are made to the <code>numeric argument</code>. This can
|
||
by default be entered in emacs mode by holding the alt key and typing a
|
||
number, or pressing escape before each digit, and in vi command mode by
|
||
typing the number before entering a command. Generally the numeric
|
||
argument causes the next command entered to be repeated the specified
|
||
number of times, unless otherwise noted below; this is implemented by
|
||
the <code>digit-argument</code> widget. See also <a href="Zsh-Line-Editor.html#Arguments">Arguments</a> for some
|
||
other ways the numeric argument can be modified.</p>
|
||
<hr />
|
||
<p><span id="Keymaps"></span> <span id="Keymaps-1"></span></p>
|
||
<h2 id="182-keymaps"><a class="header" href="#182-keymaps">18.2 Keymaps</a></h2>
|
||
<p><span id="index-keymaps"></span> <span id="index-key-bindings"></span>
|
||
<span id="index-bindings_002c-key"></span></p>
|
||
<p>A keymap in ZLE contains a set of bindings between key sequences and ZLE
|
||
commands. The empty key sequence cannot be bound.</p>
|
||
<p>There can be any number of keymaps at any time, and each keymap has one
|
||
or more names. If all of a keymap’s names are deleted, it disappears.
|
||
<span id="index-bindkey_002c-use-of"></span> <code>bindkey</code> can be used to
|
||
manipulate keymap names.</p>
|
||
<p>Initially, there are eight keymaps:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>emacs</code><br />
|
||
EMACS emulation</p>
|
||
</li>
|
||
<li>
|
||
<p><code>viins</code><br />
|
||
vi emulation - insert mode</p>
|
||
</li>
|
||
<li>
|
||
<p><code>vicmd</code><br />
|
||
vi emulation - command mode</p>
|
||
</li>
|
||
<li>
|
||
<p><code>viopp</code><br />
|
||
vi emulation - operator pending</p>
|
||
</li>
|
||
<li>
|
||
<p><code>visual</code><br />
|
||
vi emulation - selection active</p>
|
||
</li>
|
||
<li>
|
||
<p><code>isearch</code><br />
|
||
incremental search mode</p>
|
||
</li>
|
||
<li>
|
||
<p><code>command</code><br />
|
||
read a command name</p>
|
||
</li>
|
||
<li>
|
||
<p><code>.safe</code><br />
|
||
fallback keymap</p>
|
||
</li>
|
||
</ul>
|
||
<p>The ‘<code>.safe</code>’ keymap is special. It can never be altered, and the name
|
||
can never be removed. However, it can be linked to other names, which
|
||
can be removed. In the future other special keymaps may be added; users
|
||
should avoid using names beginning with ‘<code>.</code>’ for their own keymaps.</p>
|
||
<p><span id="index-VISUAL"></span> <span id="index-EDITOR"></span></p>
|
||
<p>In addition to these names, either ‘<code>emacs</code>’ or ‘<code>viins</code>’ is also linked
|
||
to the name ‘<code>main</code>’. If one of the <code>VISUAL</code> or <code>EDITOR</code> environment
|
||
variables contain the string ‘<code>vi</code>’ when the shell starts up then it
|
||
will be ‘<code>viins</code>’, otherwise it will be ‘<code>emacs</code>’. <code>bindkey</code>’s <code>-e</code> and
|
||
<code>-v</code> options provide a convenient way to override this default choice.</p>
|
||
<p>When the editor starts up, it will select the ‘<code>main</code>’ keymap. If that
|
||
keymap doesn’t exist, it will use ‘<code>.safe</code>’ instead.</p>
|
||
<p>In the ‘<code>.safe</code>’ keymap, each single key is bound to <code>self-insert</code>,
|
||
except for ^J (line feed) and ^M (return) which are bound to
|
||
<code>accept-line</code>. This is deliberately not pleasant to use; if you are
|
||
using it, it means you deleted the main keymap, and you should put it
|
||
back.</p>
|
||
<hr />
|
||
<p><span id="Reading-Commands"></span></p>
|
||
<h3 id="1821-reading-commands"><a class="header" href="#1821-reading-commands">18.2.1 Reading Commands</a></h3>
|
||
<p>When ZLE is reading a command from the terminal, it may read a sequence
|
||
that is bound to some command and is also a prefix of a longer bound
|
||
string. In this case ZLE will wait a certain time to see if more
|
||
characters are typed, and if not (or they don’t match any longer string)
|
||
it will execute the binding. This timeout is defined by the <code>KEYTIMEOUT</code>
|
||
parameter; its default is 0.4 sec. There is no timeout if the prefix
|
||
string is not itself bound to a command.</p>
|
||
<p>The key timeout is also applied when ZLE is reading the bytes from a
|
||
multibyte character string when it is in the appropriate mode. (This
|
||
requires that the shell was compiled with multibyte mode enabled;
|
||
typically also the locale has characters with the UTF-8 encoding,
|
||
although any multibyte encoding known to the operating system is
|
||
supported.) If the second or a subsequent byte is not read within the
|
||
timeout period, the shell acts as if <code>?</code> were typed and resets the input
|
||
state.</p>
|
||
<p>As well as ZLE commands, key sequences can be bound to other strings, by
|
||
using ‘<code>bindkey -s</code>’. When such a sequence is read, the replacement
|
||
string is pushed back as input, and the command reading process starts
|
||
again using these fake keystrokes. This input can itself invoke further
|
||
replacement strings, but in order to detect loops the process will be
|
||
stopped if there are twenty such replacements without a real command
|
||
being read.</p>
|
||
<p>A key sequence typed by the user can be turned into a command name for
|
||
use in user-defined widgets with the <code>read-command</code> widget, described in
|
||
<a href="Zsh-Line-Editor.html#Miscellaneous">Miscellaneous</a> below.</p>
|
||
<hr />
|
||
<p><span id="Local-Keymaps"></span></p>
|
||
<h3 id="1822-local-keymaps"><a class="header" href="#1822-local-keymaps">18.2.2 Local Keymaps</a></h3>
|
||
<p><span id="index-local-keymaps"></span></p>
|
||
<p>While for normal editing a single keymap is used exclusively, in many
|
||
modes a local keymap allows for some keys to be customised. For example,
|
||
in an incremental search mode, a binding in the <code>isearch</code> keymap will
|
||
override a binding in the <code>main</code> keymap but all keys that are not
|
||
overridden can still be used.</p>
|
||
<p>If a key sequence is defined in a local keymap, it will hide a key
|
||
sequence in the global keymap that is a prefix of that sequence. An
|
||
example of this occurs with the binding of <code>iw</code> in <code>viopp</code> as this hides
|
||
the binding of <code>i</code> in <code>vicmd</code>. However, a longer sequence in the global
|
||
keymap that shares the same prefix can still apply so for example the
|
||
binding of <code>^Xa</code> in the global keymap will be unaffected by the binding
|
||
of <code>^Xb</code> in the local keymap.</p>
|
||
<hr />
|
||
<p><span id="Zle-Builtins"></span> <span id="Zle-Builtins-1"></span></p>
|
||
<h2 id="183-zle-builtins"><a class="header" href="#183-zle-builtins">18.3 Zle Builtins</a></h2>
|
||
<p><span id="index-zle_002c-builtin-commands"></span></p>
|
||
<p>The ZLE module contains three related builtin commands. The <code>bindkey</code>
|
||
command manipulates keymaps and key bindings; the <code>vared</code> command
|
||
invokes ZLE on the value of a shell parameter; and the <code>zle</code> command
|
||
manipulates editing widgets and allows command line access to ZLE
|
||
commands from within shell functions.</p>
|
||
<p><span id="index-bindkey"></span>
|
||
<span id="index-keys_002c-rebinding"></span>
|
||
<span id="index-rebinding-keys"></span>
|
||
<span id="index-keys_002c-binding"></span>
|
||
<span id="index-binding-keys"></span> <span id="index-keymaps-1"></span></p>
|
||
<p><code>bindkey</code> [ <code>options</code> ] <code>-l</code> [ <code>-L</code> ] [ <code>keymap</code> ... ]</p>
|
||
<p><code>bindkey</code> [ <code>options</code> ] <code>-d</code></p>
|
||
<p><code>bindkey</code> [ <code>options</code> ] <code>-D</code> <code>keymap</code> ...</p>
|
||
<p><code>bindkey</code> [ <code>options</code> ] <code>-A</code> <code>old-keymap new-keymap</code></p>
|
||
<p><code>bindkey</code> [ <code>options</code> ] <code>-N</code> <code>new-keymap</code> [ <code>old-keymap</code> ]</p>
|
||
<p><code>bindkey</code> [ <code>options</code> ] <code>-m</code></p>
|
||
<p><code>bindkey</code> [ <code>options</code> ] <code>-r</code> <code>in-string</code> ...</p>
|
||
<p><code>bindkey</code> [ <code>options</code> ] <code>-s</code> <code>in-string out-string</code> ...</p>
|
||
<p><code>bindkey</code> [ <code>options</code> ] <code>in-string command</code> ...</p>
|
||
<p><code>bindkey</code> [ <code>options</code> ] [ <code>in-string</code> ]</p>
|
||
<p><code>bindkey</code>’s options can be divided into three categories: keymap
|
||
selection for the current command, operation selection, and others. The
|
||
keymap selection options are:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-e</code><br />
|
||
Selects keymap ‘<code>emacs</code>’ for any operations by the current command,
|
||
and also links ‘<code>emacs</code>’ to ‘<code>main</code>’ so that it is selected by
|
||
default the next time the editor starts.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-v</code><br />
|
||
Selects keymap ‘<code>viins</code>’ for any operations by the current command,
|
||
and also links ‘<code>viins</code>’ to ‘<code>main</code>’ so that it is selected by
|
||
default the next time the editor starts.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-a</code><br />
|
||
Selects keymap ‘<code>vicmd</code>’ for any operations by the current command.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-M</code> <code>keymap</code><br />
|
||
The <code>keymap</code> specifies a keymap name that is selected for any
|
||
operations by the current command.</p>
|
||
</li>
|
||
</ul>
|
||
<p>If a keymap selection is required and none of the options above are
|
||
used, the ‘<code>main</code>’ keymap is used. Some operations do not permit a
|
||
keymap to be selected, namely:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-l</code><br />
|
||
List all existing keymap names; if any arguments are given, list
|
||
just those keymaps.</p>
|
||
<p>If the <code>-L</code> option is also used, list in the form of <code>bindkey</code>
|
||
commands to create or link the keymaps. ‘<code>bindkey -lL main</code>’ shows
|
||
which keymap is linked to ‘<code>main</code>’, if any, and hence if the
|
||
standard emacs or vi emulation is in effect. This option does not
|
||
show the <code>.safe</code> keymap because it cannot be created in that
|
||
fashion; however, neither is ‘<code>bindkey -lL .safe</code>’ reported as an
|
||
error, it simply outputs nothing.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-d</code><br />
|
||
Delete all existing keymaps and reset to the default state.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-D</code> <code>keymap</code> ...<br />
|
||
Delete the named <code>keymap</code>s.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-A</code> <code>old-keymap new-keymap</code><br />
|
||
Make the <code>new-keymap</code> name an alias for <code>old-keymap</code>, so that both
|
||
names refer to the same keymap. The names have equal standing; if
|
||
either is deleted, the other remains. If there is already a keymap
|
||
with the <code>new-keymap</code> name, it is deleted.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-N</code> <code>new-keymap</code> [ <code>old-keymap</code> ]<br />
|
||
Create a new keymap, named <code>new-keymap</code>. If a keymap already has
|
||
that name, it is deleted. If an <code>old-keymap</code> name is given, the new
|
||
keymap is initialized to be a duplicate of it, otherwise the new
|
||
keymap will be empty.</p>
|
||
</li>
|
||
</ul>
|
||
<p>To use a newly created keymap, it should be linked to <code>main</code>. Hence the
|
||
sequence of commands to create and use a new keymap ‘<code>mymap</code>’
|
||
initialized from the <code>emacs</code> keymap (which remains unchanged) is:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">bindkey -N mymap emacs
|
||
bindkey -A mymap main
|
||
</code></pre>
|
||
</div>
|
||
<p>Note that while ‘<code>bindkey -A</code> <code>newmap</code> <code>main</code>’ will work when <code>newmap</code>
|
||
is <code>emacs</code> or <code>viins</code>, it will not work for <code>vicmd</code>, as switching from
|
||
vi insert to command mode becomes impossible.</p>
|
||
<p>The following operations act on the ‘<code>main</code>’ keymap if no keymap
|
||
selection option was given:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-m</code><br />
|
||
Add the built-in set of meta-key bindings to the selected keymap.
|
||
Only keys that are unbound or bound to <code>self-insert</code> are affected.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-r</code> <code>in-string</code> ...<br />
|
||
Unbind the specified <code>in-string</code>s in the selected keymap. This is
|
||
exactly equivalent to binding the strings to <code>undefined-key</code>.</p>
|
||
<p>When <code>-R</code> is also used, interpret the <code>in-string</code>s as ranges.</p>
|
||
<p>When <code>-p</code> is also used, the <code>in-string</code>s specify prefixes. Any
|
||
binding that has the given <code>in-string</code> as a prefix, not including
|
||
the binding for the <code>in-string</code> itself, if any, will be removed. For
|
||
example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">bindkey -rpM viins '^['
|
||
</code></pre>
|
||
</div>
|
||
<p>will remove all bindings in the vi-insert keymap beginning with an
|
||
escape character (probably cursor keys), but leave the binding for
|
||
the escape character itself (probably <code>vi-cmd-mode</code>). This is
|
||
incompatible with the option <code>-R</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-s</code> <code>in-string out-string</code> ...<br />
|
||
Bind each <code>in-string</code> to each <code>out-string</code>. When <code>in-string</code> is
|
||
typed, <code>out-string</code> will be pushed back and treated as input to the
|
||
line editor. When <code>-R</code> is also used, interpret the <code>in-string</code>s as
|
||
ranges.</p>
|
||
<p>Note that both <code>in-string</code> and <code>out-string</code> are subject to the same
|
||
form of interpretation, as described below.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>in-string command</code> ...<br />
|
||
Bind each <code>in-string</code> to each <code>command</code>. When <code>-R</code> is used,
|
||
interpret the <code>in-string</code>s as ranges.</p>
|
||
</li>
|
||
<li>
|
||
<p>[ <code>in-string</code> ]<br />
|
||
List key bindings. If an <code>in-string</code> is specified, the binding of
|
||
that string in the selected keymap is displayed. Otherwise, all key
|
||
bindings in the selected keymap are displayed. (As a special case,
|
||
if the <code>-e</code> or <code>-v</code> option is used alone, the keymap is <em>not</em>
|
||
displayed - the implicit linking of keymaps is the only thing that
|
||
happens.)</p>
|
||
<p>When the option <code>-p</code> is used, the <code>in-string</code> must be present. The
|
||
listing shows all bindings which have the given key sequence as a
|
||
prefix, not including any bindings for the key sequence itself.</p>
|
||
<p>When the <code>-L</code> option is used, the list is in the form of <code>bindkey</code>
|
||
commands to create the key bindings.</p>
|
||
</li>
|
||
</ul>
|
||
<p>When the <code>-R</code> option is used as noted above, a valid range consists of
|
||
two characters, with an optional ‘<code>-</code>’ between them. All characters
|
||
between the two specified, inclusive, are bound as specified.</p>
|
||
<p>For either <code>in-string</code> or <code>out-string</code>, the following escape sequences
|
||
are recognised:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>\a</code><br />
|
||
bell character</p>
|
||
</li>
|
||
<li>
|
||
<p><code>\b</code><br />
|
||
backspace</p>
|
||
</li>
|
||
<li>
|
||
<p><code>\e</code>, <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>\``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>
|
||
<li>
|
||
<p><code>\M</code>[<code>-</code>]<code>X</code><br />
|
||
character with meta bit set</p>
|
||
</li>
|
||
<li>
|
||
<p><code>\C</code>[<code>-</code>]<code>X</code><br />
|
||
control character</p>
|
||
</li>
|
||
<li>
|
||
<p><code>^``X</code><br />
|
||
control character</p>
|
||
</li>
|
||
</ul>
|
||
<p>In all other cases, ‘<code>\</code>’ escapes the following character. Delete is
|
||
written as ‘<code>^?</code>’. Note that ‘<code>\M^?</code>’ and ‘<code>^\M?</code>’ are not the same, and
|
||
that (unlike emacs), the bindings ‘<code>\M-``X</code>’ and ‘<code>\e``X</code>’ are entirely
|
||
distinct, although they are initialized to the same bindings by
|
||
‘<code>bindkey -m</code>’.</p>
|
||
<p><span id="index-vared"></span>
|
||
<span id="index-parameters_002c-editing"></span>
|
||
<span id="index-editing-parameters"></span></p>
|
||
<p><code>vared </code>[ <code>-Aacghe</code> ] [ <code>-p</code> <code>prompt</code> ] [ <code>-r</code> <code>rprompt</code> ]</p>
|
||
<p><code> </code>[ <code>-M</code> <code>main-keymap</code> ] [ <code>-m</code> <code>vicmd-keymap</code> ]</p>
|
||
<p><code> </code>[ <code>-i</code> <code>init-widget</code> ] [ <code>-f</code> <code>finish-widget</code> ]</p>
|
||
<p><code> </code>[ <code>-t</code> <code>tty</code> ] <code>name</code></p>
|
||
<p>The value of the parameter <code>name</code> is loaded into the edit buffer, and
|
||
the line editor is invoked. When the editor exits, <code>name</code> is set to the
|
||
string value returned by the editor. When the <code>-c</code> flag is given, the
|
||
parameter is created if it doesn’t already exist. The <code>-a</code> flag may be
|
||
given with <code>-c</code> to create an array parameter, or the <code>-A</code> flag to create
|
||
an associative array. If the type of an existing parameter does not
|
||
match the type to be created, the parameter is unset and recreated. The
|
||
<code>-g</code> flag may be given to suppress warnings from the
|
||
<code>WARN_CREATE_GLOBAL</code> and <code>WARN_NESTED_VAR</code> options.</p>
|
||
<p>If an array or array slice is being edited, separator characters as
|
||
defined in <code>$IFS</code> will be shown quoted with a backslash, as will
|
||
backslashes themselves. Conversely, when the edited text is split into
|
||
an array, a backslash quotes an immediately following separator
|
||
character or backslash; no other special handling of backslashes, or any
|
||
handling of quotes, is performed.</p>
|
||
<p>Individual elements of existing array or associative array parameters
|
||
may be edited by using subscript syntax on <code>name</code>. New elements are
|
||
created automatically, even without <code>-c</code>.</p>
|
||
<p>If the <code>-p</code> flag is given, the following string will be taken as the
|
||
prompt to display at the left. If the <code>-r</code> flag is given, the following
|
||
string gives the prompt to display at the right. If the <code>-h</code> flag is
|
||
specified, the history can be accessed from ZLE. If the <code>-e</code> flag is
|
||
given, typing <code>^D</code> (Control-D) on an empty line causes <code>vared</code> to exit
|
||
immediately with a non-zero return value.</p>
|
||
<p>The <code>-M</code> option gives a keymap to link to the <code>main</code> keymap during
|
||
editing, and the <code>-m</code> option gives a keymap to link to the <code>vicmd</code>
|
||
keymap during editing. For vi-style editing, this allows a pair of
|
||
keymaps to override <code>viins</code> and <code>vicmd</code>. For emacs-style editing, only
|
||
<code>-M</code> is normally needed but the <code>-m</code> option may still be used. On exit,
|
||
the previous keymaps will be restored.</p>
|
||
<p><code>Vared</code> calls the usual ‘<code>zle-line-init</code>’ and ‘<code>zle-line-finish</code>’ hooks
|
||
before and after it takes control. Using the <code>-i</code> and <code>-f</code> options, it
|
||
is possible to replace these with other custom widgets.</p>
|
||
<p>If ‘<code>-t</code> <code>tty</code>’ is given, <code>tty</code> is the name of a terminal device to be
|
||
used instead of the default <code>/dev/tty</code>. If <code>tty</code> does not refer to a
|
||
terminal an error is reported.</p>
|
||
<p><span id="index-zle"></span>
|
||
<span id="index-widgets_002c-rebinding"></span>
|
||
<span id="index-rebinding-widgets"></span>
|
||
<span id="index-widgets_002c-binding"></span>
|
||
<span id="index-binding-widgets"></span>
|
||
<span id="index-widgets_002c-invoking"></span>
|
||
<span id="index-invoking-widgets"></span>
|
||
<span id="index-widgets_002c-calling"></span>
|
||
<span id="index-calling-widgets"></span>
|
||
<span id="index-widgets_002c-defining"></span>
|
||
<span id="index-defining-widgets"></span></p>
|
||
<p><code>zle</code></p>
|
||
<p><code>zle</code> <code>-l</code> [ <code>-L</code> | <code>-a</code> ] [ <code>string</code> ... ]</p>
|
||
<p><code>zle</code> <code>-D</code> <code>widget</code> ...</p>
|
||
<p><code>zle</code> <code>-A</code> <code>old-widget</code> <code>new-widget</code></p>
|
||
<p><code>zle</code> <code>-N</code> <code>widget</code> [ <code>function</code> ]</p>
|
||
<p><code>zle</code> <code>-f</code> <code>flag</code> [ <code>flag</code>... ]</p>
|
||
<p><code>zle</code> <code>-C</code> <code>widget</code> <code>completion-widget</code> <code>function</code></p>
|
||
<p><code>zle</code> <code>-R</code> [ <code>-c</code> ] [ <code>display-string</code> ] [ <code>string</code> ... ]</p>
|
||
<p><code>zle</code> <code>-M</code> <code>string</code></p>
|
||
<p><code>zle</code> <code>-U</code> <code>string</code></p>
|
||
<p><code>zle</code> <code>-K</code> <code>keymap</code></p>
|
||
<p><code>zle</code> <code>-F</code> [ <code>-L</code> | <code>-w</code> ] [ <code>fd</code> [ <code>handler</code> ] ]</p>
|
||
<p><code>zle</code> <code>-I</code></p>
|
||
<p><code>zle</code> <code>-T</code> [ <code>tc</code> <code>function</code> | <code>-r</code> <code>tc</code> | <code>-L</code> ]</p>
|
||
<p><code>zle</code> <code>widget</code> [ <code>-n</code> <code>num</code> ] [ <code>-Nw</code> ] [ <code>-K</code> <code>keymap</code> ] <code>args</code>
|
||
...</p>
|
||
<p>The <code>zle</code> builtin performs a number of different actions concerning ZLE.</p>
|
||
<p>With no options and no arguments, only the return status will be set. It
|
||
is zero if ZLE is currently active and widgets could be invoked using
|
||
this builtin command and non-zero otherwise. Note that even if non-zero
|
||
status is returned, zle may still be active as part of the completion
|
||
system; this does not allow direct calls to ZLE widgets.</p>
|
||
<p>Otherwise, which operation it performs depends on its options:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-l</code> [ <code>-L</code> | <code>-a</code> ] [ <code>string</code> ]<br />
|
||
List all existing user-defined widgets. If the <code>-L</code> option is used,
|
||
list in the form of <code>zle</code> commands to create the widgets.</p>
|
||
<p>When combined with the <code>-a</code> option, all widget names are listed,
|
||
including the builtin ones. In this case the <code>-L</code> option is ignored.</p>
|
||
<p>If at least one <code>string</code> is given, and <code>-a</code> is present or <code>-L</code> is
|
||
not used, nothing will be printed. The return status will be zero if
|
||
all <code>string</code>s are names of existing widgets and non-zero if at least
|
||
one <code>string</code> is not a name of a defined widget. If <code>-a</code> is also
|
||
present, all widget names are used for the comparison including
|
||
builtin widgets, else only user-defined widgets are used.</p>
|
||
<p>If at least one <code>string</code> is present and the <code>-L</code> option is used,
|
||
user-defined widgets matching any <code>string</code> are listed in the form of
|
||
<code>zle</code> commands to create the widgets.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-D</code> <code>widget</code> ...<br />
|
||
Delete the named <code>widget</code>s.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-A</code> <code>old-widget</code> <code>new-widget</code><br />
|
||
Make the <code>new-widget</code> name an alias for <code>old-widget</code>, so that both
|
||
names refer to the same widget. The names have equal standing; if
|
||
either is deleted, the other remains. If there is already a widget
|
||
with the <code>new-widget</code> name, it is deleted.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-N</code> <code>widget</code> [ <code>function</code> ]<br />
|
||
Create a user-defined widget. If there is already a widget with the
|
||
specified name, it is overwritten. When the new widget is invoked
|
||
from within the editor, the specified shell <code>function</code> is called. If
|
||
no function name is specified, it defaults to the same name as the
|
||
widget. For further information, see <a href="Zsh-Line-Editor.html#Zle-Widgets">Widgets</a>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-f</code> <code>flag</code> [ <code>flag</code>... ]<br />
|
||
Set various flags on the running widget. Possible values for <code>flag</code>
|
||
are:</p>
|
||
<p><code>yank</code> for indicating that the widget has yanked text into the
|
||
buffer. If the widget is wrapping an existing internal widget, no
|
||
further action is necessary, but if it has inserted the text
|
||
manually, then it should also take care to set <code>YANK_START</code> and
|
||
<code>YANK_END</code> correctly. <code>yankbefore</code> does the same but is used when
|
||
the yanked text appears after the cursor.</p>
|
||
<p><code>kill</code> for indicating that text has been killed into the cutbuffer.
|
||
When repeatedly invoking a kill widget, text is appended to the
|
||
cutbuffer instead of replacing it, but when wrapping such widgets,
|
||
it is necessary to call ‘<code>zle -f kill</code>’ to retain this effect.</p>
|
||
<p><code>vichange</code> for indicating that the widget represents a vi change
|
||
that can be repeated as a whole with ‘<code>vi-repeat-change</code>’. The flag
|
||
should be set early in the function before inspecting the value of
|
||
<code>NUMERIC</code> or invoking other widgets. This has no effect for a widget
|
||
invoked from insert mode. If insert mode is active when the widget
|
||
finishes, the change extends until next returning to command mode.</p>
|
||
<p><span id="index-completion-widgets_002c-creating"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>-C</code> <code>widget</code> <code>completion-widget</code> <code>function</code><br />
|
||
Create a user-defined completion widget named <code>widget</code>. The
|
||
completion widget will behave like the built-in completion-widget
|
||
whose name is given as <code>completion-widget</code>. To generate the
|
||
completions, the shell function <code>function</code> will be called. For
|
||
further information, see <a href="Completion-Widgets.html#Completion-Widgets">Completion
|
||
Widgets</a>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-R</code> [ <code>-c</code> ] [ <code>display-string</code> ] [ <code>string</code> ... ]<br />
|
||
Redisplay the command line; this is to be called from within a
|
||
user-defined widget to allow changes to become visible. If a
|
||
<code>display-string</code> is given and not empty, this is shown in the status
|
||
line (immediately below the line being edited).</p>
|
||
<p>If the optional <code>string</code>s are given they are listed below the prompt
|
||
in the same way as completion lists are printed. If no <code>string</code>s are
|
||
given but the <code>-c</code> option is used such a list is cleared.</p>
|
||
<p>Note that this option is only useful for widgets that do not exit
|
||
immediately after using it because the strings displayed will be
|
||
erased immediately after return from the widget.</p>
|
||
<p>This command can safely be called outside user defined widgets; if
|
||
zle is active, the display will be refreshed, while if zle is not
|
||
active, the command has no effect. In this case there will usually
|
||
be no other arguments.</p>
|
||
<p>The status is zero if zle was active, else one.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-M</code> <code>string</code><br />
|
||
As with the <code>-R</code> option, the <code>string</code> will be displayed below the
|
||
command line; unlike the <code>-R</code> option, the string will not be put
|
||
into the status line but will instead be printed normally below the
|
||
prompt. This means that the <code>string</code> will still be displayed after
|
||
the widget returns (until it is overwritten by subsequent commands).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-U</code> <code>string</code><br />
|
||
This pushes the characters in the <code>string</code> onto the input stack of
|
||
ZLE. After the widget currently executed finishes ZLE will behave as
|
||
if the characters in the <code>string</code> were typed by the user.</p>
|
||
<p>As ZLE uses a stack, if this option is used repeatedly the last
|
||
string pushed onto the stack will be processed first. However, the
|
||
characters in each <code>string</code> will be processed in the order in which
|
||
they appear in the string.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-K</code> <code>keymap</code><br />
|
||
Selects the keymap named <code>keymap</code>. An error message will be
|
||
displayed if there is no such keymap.</p>
|
||
<p>This keymap selection affects the interpretation of following
|
||
keystrokes within this invocation of ZLE. Any following invocation
|
||
(e.g., the next command line) will start as usual with the ‘<code>main</code>’
|
||
keymap selected.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-F</code> [ <code>-L</code> | <code>-w</code> ] [ <code>fd</code> [ <code>handler</code> ] ]<br />
|
||
Only available if your system supports one of the ‘poll’ or ‘select’
|
||
system calls; most modern systems do.</p>
|
||
<p>Installs <code>handler</code> (the name of a shell function) to handle input
|
||
from file descriptor <code>fd</code>. Installing a handler for an <code>fd</code> which is
|
||
already handled causes the existing handler to be replaced. Any
|
||
number of handlers for any number of readable file descriptors may
|
||
be installed. Note that zle makes no attempt to check whether this
|
||
<code>fd</code> is actually readable when installing the handler. The user must
|
||
make their own arrangements for handling the file descriptor when
|
||
zle is not active.</p>
|
||
<p>When zle is attempting to read data, it will examine both the
|
||
terminal and the list of handled <code>fd</code>’s. If data becomes available
|
||
on a handled <code>fd</code>, zle calls <code>handler</code> with the fd which is ready
|
||
for reading as the first argument. Under normal circumstances this
|
||
is the only argument, but if an error was detected, a second
|
||
argument provides details: ‘<code>hup</code>’ for a disconnect, ‘<code>nval</code>’ for a
|
||
closed or otherwise invalid descriptor, or ‘<code>err</code>’ for any other
|
||
condition. Systems that support only the ‘select’ system call always
|
||
use ‘<code>err</code>’.</p>
|
||
<p>If the option <code>-w</code> is also given, the <code>handler</code> is instead a line
|
||
editor widget, typically a shell function made into a widget using
|
||
‘<code>zle -N</code>’. In that case <code>handler</code> can use all the facilities of
|
||
zle to update the current editing line. Note, however, that as
|
||
handling <code>fd</code> takes place at a low level changes to the display will
|
||
not automatically appear; the widget should call ‘<code>zle -R</code>’ to force
|
||
redisplay. As of this writing, widget handlers only support a single
|
||
argument and thus are never passed a string for error state, so
|
||
widgets must be prepared to test the descriptor themselves.</p>
|
||
<p>If either type of handler produces output to the terminal, it should
|
||
call ‘<code>zle -I</code>’ before doing so (see below). Handlers should not
|
||
attempt to read from the terminal.</p>
|
||
<p>If no <code>handler</code> is given, but an <code>fd</code> is present, any handler for
|
||
that <code>fd</code> is removed. If there is none, an error message is printed
|
||
and status 1 is returned.</p>
|
||
<p>If no arguments are given, or the <code>-L</code> option is supplied, a list of
|
||
handlers is printed in a form which can be stored for later
|
||
execution.</p>
|
||
<p>An <code>fd</code> (but not a <code>handler</code>) may optionally be given with the <code>-L</code>
|
||
option; in this case, the function will list the handler if any,
|
||
else silently return status 1.</p>
|
||
<p>Note that this feature should be used with care. Activity on one of
|
||
the <code>fd</code>’s which is not properly handled can cause the terminal to
|
||
become unusable. Removing an <code>fd</code> handler from within a signal trap
|
||
may cause</p>
|
||
<p>Here is a simple example of using this feature. A connection to a
|
||
remote TCP port is created using the ztcp command; see <a href="Zsh-Modules.html#The-zsh_002fnet_002ftcp-Module">The
|
||
zsh/net/tcp
|
||
Module</a>. Then a
|
||
handler is installed which simply prints out any data which arrives
|
||
on this connection. Note that ‘select’ will indicate that the file
|
||
descriptor needs handling if the remote side has closed the
|
||
connection; we handle that by testing for a failed read.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">if ztcp pwspc 2811; then
|
||
tcpfd=$REPLY
|
||
handler() {
|
||
zle -I
|
||
local line
|
||
if ! read -r line <&$1; then
|
||
# select marks this fd if we reach EOF,
|
||
# so handle this specially.
|
||
print "[Read on fd $1 failed, removing.]" >&2
|
||
zle -F $1
|
||
return 1
|
||
fi
|
||
print -r - $line
|
||
}
|
||
zle -F $tcpfd handler
|
||
fi
|
||
</code></pre>
|
||
</div>
|
||
</li>
|
||
<li>
|
||
<p><code>-I</code><br />
|
||
Unusually, this option is most useful outside ordinary widget
|
||
functions, though it may be used within if normal output to the
|
||
terminal is required. It invalidates the current zle display in
|
||
preparation for output; typically this will be from a trap function.
|
||
It has no effect if zle is not active. When a trap exits, the shell
|
||
checks to see if the display needs restoring, hence the following
|
||
will print output in such a way as not to disturb the line being
|
||
edited:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">TRAPUSR1() {
|
||
# Invalidate zle display
|
||
[[ -o zle ]] && zle -I
|
||
# Show output
|
||
print Hello
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p>In general, the trap function may need to test whether zle is active
|
||
before using this method (as shown in the example), since the
|
||
<code>zsh/zle</code> module may not even be loaded; if it is not, the command
|
||
can be skipped.</p>
|
||
<p>It is possible to call ‘<code>zle -I</code>’ several times before control is
|
||
returned to the editor; the display will only be invalidated the
|
||
first time to minimise disruption.</p>
|
||
<p>Note that there are normally better ways of manipulating the display
|
||
from within zle widgets; see, for example, ‘<code>zle -R</code>’ above.</p>
|
||
<p>The returned status is zero if zle was invalidated, even though this
|
||
may have been by a previous call to ‘<code>zle -I</code>’ or by a system
|
||
notification. To test if a zle widget may be called at this point,
|
||
execute <code>zle</code> with no arguments and examine the return status.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-T</code><br />
|
||
This is used to add, list or remove internal transformations on the
|
||
processing performed by the line editor. It is typically used only
|
||
for debugging or testing and is therefore of little interest to the
|
||
general user.</p>
|
||
<p>‘<code>zle -T</code> <code>transformation</code> <code>func</code>’ specifies that the given
|
||
<code>transformation</code> (see below) is effected by shell function <code>func</code>.</p>
|
||
<p>‘<code>zle -Tr</code> <code>transformation</code>’ removes the given <code>transformation</code> if
|
||
it was present (it is not an error if none was).</p>
|
||
<p>‘<code>zle -TL</code>’ can be used to list all transformations currently in
|
||
operation.</p>
|
||
<p>Currently the only transformation is <code>tc</code>. This is used instead of
|
||
outputting termcap codes to the terminal. When the transformation is
|
||
in operation the shell function is passed the termcap code that
|
||
would be output as its first argument; if the operation required a
|
||
numeric argument, that is passed as a second argument. The function
|
||
should set the shell variable <code>REPLY</code> to the transformed termcap
|
||
code. Typically this is used to produce some simply formatted
|
||
version of the code and optional argument for debugging or testing.
|
||
Note that this transformation is not applied to other non-printing
|
||
characters such as carriage returns and newlines.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>widget</code> [ <code>-n</code> <code>num</code> ] [ <code>-Nw</code> ] [ <code>-K</code> <code>keymap</code> ] <code>args</code>
|
||
...<br />
|
||
Invoke the specified <code>widget</code>. This can only be done when ZLE is
|
||
active; normally this will be within a user-defined widget.</p>
|
||
<p>With the options <code>-n</code> and <code>-N</code>, the current numeric argument will be
|
||
saved and then restored after the call to <code>widget</code>; ‘<code>-n</code> <code>num</code>’
|
||
sets the numeric argument temporarily to <code>num</code>, while ‘<code>-N</code>’ sets it
|
||
to the default, i.e. as if there were none.</p>
|
||
<p>With the option <code>-K</code>, <code>keymap</code> will be used as the current keymap
|
||
during the execution of the widget. The previous keymap will be
|
||
restored when the widget exits.</p>
|
||
<p>Normally, calling a widget in this way does not set the special
|
||
parameter <code>WIDGET</code> and related parameters, so that the environment
|
||
appears as if the top-level widget called by the user were still
|
||
active. With the option <code>-w</code>, <code>WIDGET</code> and related parameters are
|
||
set to reflect the widget being executed by the <code>zle</code> call.</p>
|
||
<p>Any further arguments will be passed to the widget; note that as
|
||
standard argument handling is performed, any general argument list
|
||
should be preceded by <code>-``-</code>. If it is a shell function, these are
|
||
passed down as positional parameters; for builtin widgets it is up
|
||
to the widget in question what it does with them. Currently
|
||
arguments are only handled by the incremental-search commands, the
|
||
<code>history-search-forward</code> and <code>-backward</code> and the corresponding
|
||
functions prefixed by <code>vi-</code>, and by <code>universal-argument</code>. No error
|
||
is flagged if the command does not use the arguments, or only uses
|
||
some of them.</p>
|
||
<p>The return status reflects the success or failure of the operation
|
||
carried out by the widget, or if it is a user-defined widget the
|
||
return status of the shell function.</p>
|
||
<p>A non-zero return status causes the shell to beep when the widget
|
||
exits, unless the <code>BEEP</code> options was unset or the widget was called
|
||
via the <code>zle</code> command. Thus if a user defined widget requires an
|
||
immediate beep, it should call the <code>beep</code> widget directly.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Zle-Widgets"></span> <span id="Widgets-1"></span></p>
|
||
<h2 id="184-widgets"><a class="header" href="#184-widgets">18.4 Widgets</a></h2>
|
||
<p><span id="index-widgets"></span></p>
|
||
<p>All actions in the editor are performed by ‘widgets’. A widget’s job is
|
||
simply to perform some small action. The ZLE commands that key sequences
|
||
in keymaps are bound to are in fact widgets. Widgets can be user-defined
|
||
or built in.</p>
|
||
<p>The standard widgets built into ZLE are listed in Standard Widgets
|
||
below. Other built-in widgets can be defined by other modules (see <a href="Zsh-Modules.html#Zsh-Modules">Zsh
|
||
Modules</a>). Each built-in widget has two
|
||
names: its normal canonical name, and the same name preceded by a ‘<code>.</code>’.
|
||
The ‘<code>.</code>’ name is special: it can’t be rebound to a different widget.
|
||
This makes the widget available even when its usual name has been
|
||
redefined.</p>
|
||
<p>User-defined widgets are defined using ‘<code>zle -N</code>’, and implemented as
|
||
shell functions. When the widget is executed, the corresponding shell
|
||
function is executed, and can perform editing (or other) actions. It is
|
||
recommended that user-defined widgets should not have names starting
|
||
with ‘<code>.</code>’.</p>
|
||
<hr />
|
||
<p><span id="User_002dDefined-Widgets"></span></p>
|
||
<h2 id="185-user-defined-widgets"><a class="header" href="#185-user-defined-widgets">18.5 User-Defined Widgets</a></h2>
|
||
<p><span id="index-widgets_002c-user_002ddefined"></span></p>
|
||
<p>User-defined widgets, being implemented as shell functions, can execute
|
||
any normal shell command. They can also run other widgets (whether
|
||
built-in or user-defined) using the <code>zle</code> builtin command. The standard
|
||
input of the function is redirected from /dev/null to prevent external
|
||
commands from unintentionally blocking ZLE by reading from the terminal,
|
||
but <code>read -k</code> or <code>read -q</code> can be used to read characters. Finally, they
|
||
can examine and edit the ZLE buffer being edited by reading and setting
|
||
the special parameters described below.</p>
|
||
<p><span id="index-parameters_002c-editor"></span>
|
||
<span id="index-parameters_002c-zle"></span></p>
|
||
<p>These special parameters are always available in widget functions, but
|
||
are not in any way special outside ZLE. If they have some normal value
|
||
outside ZLE, that value is temporarily inaccessible, but will return
|
||
when the widget function exits. These special parameters in fact have
|
||
local scope, like parameters created in a function using <code>local</code>.</p>
|
||
<p>Inside completion widgets and traps called while ZLE is active, these
|
||
parameters are available read-only.</p>
|
||
<p>Note that the parameters appear as local to any ZLE widget in which they
|
||
appear. Hence if it is desired to override them this needs to be done
|
||
within a nested function:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">widget-function() {
|
||
# $WIDGET here refers to the special variable
|
||
# that is local inside widget-function
|
||
() {
|
||
# This anonymous nested function allows WIDGET
|
||
# to be used as a local variable. The -h
|
||
# removes the special status of the variable.
|
||
local -h WIDGET
|
||
}
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-BUFFER"></span></p>
|
||
<p><code>BUFFER</code> (scalar)</p>
|
||
<p>The entire contents of the edit buffer. If it is written to, the cursor
|
||
remains at the same offset, unless that would put it outside the buffer.</p>
|
||
<p><span id="index-BUFFERLINES"></span></p>
|
||
<p><code>BUFFERLINES</code> (integer)</p>
|
||
<p>The number of screen lines needed for the edit buffer currently
|
||
displayed on screen (i.e. without any changes to the preceding
|
||
parameters done after the last redisplay); read-only.</p>
|
||
<p><span id="index-CONTEXT"></span></p>
|
||
<p><code>CONTEXT</code> (scalar)</p>
|
||
<p>The context in which zle was called to read a line; read-only. One of
|
||
the values:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>start</code><br />
|
||
The start of a command line (at prompt <code>PS1</code>).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>cont</code><br />
|
||
A continuation to a command line (at prompt <code>PS2</code>).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>select</code><br />
|
||
In a <code>select</code> loop (at prompt <code>PS3</code>).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>vared</code><br />
|
||
Editing a variable in <code>vared</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<p><span id="index-CURSOR"></span></p>
|
||
<p><code>CURSOR</code> (integer)</p>
|
||
<p>The offset of the cursor, within the edit buffer. This is in the range 0
|
||
to <code>$#BUFFER</code>, and is by definition equal to <code>$#LBUFFER</code>. Attempts to
|
||
move the cursor outside the buffer will result in the cursor being moved
|
||
to the appropriate end of the buffer.</p>
|
||
<p><span id="index-CUTBUFFER"></span></p>
|
||
<p><code>CUTBUFFER</code> (scalar)</p>
|
||
<p>The last item cut using one of the ‘<code>kill-</code>’ commands; the string which
|
||
the next yank would insert in the line. Later entries in the kill ring
|
||
are in the array <code>killring</code>. Note that the command ‘<code>zle copy-region-as-kill</code> <code>string</code>’ can be used to set the text of the cut
|
||
buffer from a shell function and cycle the kill ring in the same way as
|
||
interactively killing text.</p>
|
||
<p><span id="index-HISTNO"></span></p>
|
||
<p><code>HISTNO</code> (integer)</p>
|
||
<p>The current history number. Setting this has the same effect as moving
|
||
up or down in the history to the corresponding history line. An attempt
|
||
to set it is ignored if the line is not stored in the history. Note this
|
||
is not the same as the parameter <code>HISTCMD</code>, which always gives the
|
||
number of the history line being added to the main shell’s history.
|
||
<code>HISTNO</code> refers to the line being retrieved within zle.</p>
|
||
<p><span id="index-ISEARCHMATCH_005fACTIVE"></span>
|
||
<span id="index-ISEARCHMATCH_005fSTART"></span>
|
||
<span id="index-ISEARCHMATCH_005fEND"></span></p>
|
||
<p><code>ISEARCHMATCH_ACTIVE</code> (integer)</p>
|
||
<p><code>ISEARCHMATCH_START</code> (integer)</p>
|
||
<p><code>ISEARCHMATCH_END</code> (integer)</p>
|
||
<p><code>ISEARCHMATCH_ACTIVE</code> indicates whether a part of the <code>BUFFER</code> is
|
||
currently matched by an incremental search pattern. <code>ISEARCHMATCH_START</code>
|
||
and <code>ISEARCHMATCH_END</code> give the location of the matched part and are in
|
||
the same units as <code>CURSOR</code>. They are only valid for reading when
|
||
<code>ISEARCHMATCH_ACTIVE</code> is non-zero.</p>
|
||
<p>All parameters are read-only.</p>
|
||
<p><span id="index-KEYMAP"></span></p>
|
||
<p><code>KEYMAP</code> (scalar)</p>
|
||
<p>The name of the currently selected keymap; read-only.</p>
|
||
<p><span id="index-KEYS"></span></p>
|
||
<p><code>KEYS</code> (scalar)</p>
|
||
<p>The keys typed to invoke this widget, as a literal string; read-only.</p>
|
||
<p><span id="index-KEYS_005fQUEUED_005fCOUNT"></span></p>
|
||
<p><code>KEYS_QUEUED_COUNT</code> (integer)</p>
|
||
<p>The number of bytes pushed back to the input queue and therefore
|
||
available for reading immediately before any I/O is done; read-only. See
|
||
also <code>PENDING</code>; the two values are distinct.</p>
|
||
<p><span id="index-killring"></span></p>
|
||
<p><code>killring</code> (array)</p>
|
||
<p>The array of previously killed items, with the most recently killed
|
||
first. This gives the items that would be retrieved by a <code>yank-pop</code> in
|
||
the same order. Note, however, that the most recently killed item is in
|
||
<code>$CUTBUFFER</code>; <code>$killring</code> shows the array of previous entries.</p>
|
||
<p>The default size for the kill ring is eight, however the length may be
|
||
changed by normal array operations. Any empty string in the kill ring is
|
||
ignored by the <code>yank-pop</code> command, hence the size of the array
|
||
effectively sets the maximum length of the kill ring, while the number
|
||
of non-zero strings gives the current length, both as seen by the user
|
||
at the command line.</p>
|
||
<p><span id="index-LASTABORTEDSEARCH"></span></p>
|
||
<p><code>LASTABORTEDSEARCH</code> (scalar)</p>
|
||
<p>The last search string used by an interactive search that was aborted by
|
||
the user (status 3 returned by the search widget).</p>
|
||
<p><span id="index-LASTSEARCH"></span></p>
|
||
<p><code>LASTSEARCH</code> (scalar)</p>
|
||
<p>The last search string used by an interactive search; read-only. This is
|
||
set even if the search failed (status 0, 1 or 2 returned by the search
|
||
widget), but not if it was aborted by the user.</p>
|
||
<p><span id="index-LASTWIDGET"></span></p>
|
||
<p><code>LASTWIDGET</code> (scalar)</p>
|
||
<p>The name of the last widget that was executed; read-only.</p>
|
||
<p><span id="index-LBUFFER"></span></p>
|
||
<p><code>LBUFFER</code> (scalar)</p>
|
||
<p>The part of the buffer that lies to the left of the cursor position. If
|
||
it is assigned to, only that part of the buffer is replaced, and the
|
||
cursor remains between the new <code>$LBUFFER</code> and the old <code>$RBUFFER</code>.</p>
|
||
<p><span id="index-MARK"></span></p>
|
||
<p><code>MARK</code> (integer)</p>
|
||
<p>Like <code>CURSOR</code>, but for the mark. With vi-mode operators that wait for a
|
||
movement command to select a region of text, setting <code>MARK</code> allows the
|
||
selection to extend in both directions from the initial cursor position.</p>
|
||
<p><span id="index-NUMERIC"></span></p>
|
||
<p><code>NUMERIC</code> (integer)</p>
|
||
<p>The numeric argument. If no numeric argument was given, this parameter
|
||
is unset. When this is set inside a widget function, builtin widgets
|
||
called with the <code>zle</code> builtin command will use the value assigned. If it
|
||
is unset inside a widget function, builtin widgets called behave as if
|
||
no numeric argument was given.</p>
|
||
<p><span id="index-PENDING"></span></p>
|
||
<p><code>PENDING</code> (integer)</p>
|
||
<p>The number of bytes pending for input, i.e. the number of bytes which
|
||
have already been typed and can immediately be read. On systems where
|
||
the shell is not able to get this information, this parameter will
|
||
always have a value of zero. Read-only. See also <code>KEYS_QUEUED_COUNT</code>;
|
||
the two values are distinct.</p>
|
||
<p><span id="index-PREBUFFER"></span></p>
|
||
<p><code>PREBUFFER</code> (scalar)</p>
|
||
<p>In a multi-line input at the secondary prompt, this read-only parameter
|
||
contains the contents of the lines before the one the cursor is
|
||
currently in.</p>
|
||
<p><span id="index-PREDISPLAY"></span></p>
|
||
<p><code>PREDISPLAY</code> (scalar)</p>
|
||
<p>does not have to be a complete line; to display a complete line, a
|
||
newline must be appended explicitly. The text is reset on each new
|
||
invocation (but not recursive invocation) of zle.</p>
|
||
<p><span id="index-POSTDISPLAY"></span></p>
|
||
<p><code>POSTDISPLAY</code> (scalar)</p>
|
||
<p>does not have to be a complete line; to display a complete line, a
|
||
newline must be prepended explicitly. The text is reset on each new
|
||
invocation (but not recursive invocation) of zle.</p>
|
||
<p><span id="index-RBUFFER"></span></p>
|
||
<p><code>RBUFFER</code> (scalar)</p>
|
||
<p>The part of the buffer that lies to the right of the cursor position. If
|
||
it is assigned to, only that part of the buffer is replaced, and the
|
||
cursor remains between the old <code>$LBUFFER</code> and the new <code>$RBUFFER</code>.</p>
|
||
<p><span id="index-REGION_005fACTIVE"></span></p>
|
||
<p><code>REGION_ACTIVE</code> (integer)</p>
|
||
<p>Indicates if the region is currently active. It can be assigned 0 or 1
|
||
to deactivate and activate the region respectively. A value of 2
|
||
activates the region in line-wise mode with the highlighted text
|
||
extending for whole lines only; see <a href="Zsh-Line-Editor.html#Character-Highlighting">Character
|
||
Highlighting</a>.</p>
|
||
<p><span id="index-region_005fhighlight"></span></p>
|
||
<p><code>region_highlight</code> (array)</p>
|
||
<p>Each element of this array may be set to a string that describes
|
||
highlighting for an arbitrary region of the command line that will take
|
||
effect the next time the command line is redisplayed. Highlighting and
|
||
<code>POSTDISPLAY</code> are possible, but note that the <code>P</code> flag is needed for
|
||
character indexing to include <code>PREDISPLAY</code>.</p>
|
||
<p>Each string consists of the following parts:</p>
|
||
<ul>
|
||
<li>Optionally, a ‘<code>P</code>’ to signify that the start and end offset that
|
||
follow include any string set by the <code>PREDISPLAY</code> special parameter;
|
||
this is needed if the predisplay string itself is to be highlighted.
|
||
Whitespace may follow the ‘<code>P</code>’.</li>
|
||
<li>A start offset in the same units as <code>CURSOR</code>, terminated by
|
||
whitespace.</li>
|
||
<li>An end offset in the same units as <code>CURSOR</code>, terminated by
|
||
whitespace.</li>
|
||
<li>A highlight specification in the same format as used for contexts in
|
||
the parameter <code>zle_highlight</code>, see <a href="Zsh-Line-Editor.html#Character-Highlighting">Character
|
||
Highlighting</a>; for example, <code>standout</code> or
|
||
<code>fg=red,bold</code>.</li>
|
||
</ul>
|
||
<p>For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">region_highlight=("P0 20 bold")
|
||
</code></pre>
|
||
</div>
|
||
<p>specifies that the first twenty characters of the text including any
|
||
predisplay string should be highlighted in bold.</p>
|
||
<p>Note that the effect of <code>region_highlight</code> is not saved and disappears
|
||
as soon as the line is accepted.</p>
|
||
<p>The final highlighting on the command line depends on both
|
||
<code>region_highlight</code> and <code>zle_highlight</code>; see <a href="Zsh-Line-Editor.html#Character-Highlighting">Character
|
||
Highlighting</a> for details.</p>
|
||
<p><span id="index-registers"></span></p>
|
||
<p><code>registers</code> (associative array)</p>
|
||
<p>The contents of each of the vi register buffers. These are typically set
|
||
using <code>vi-set-buffer</code> followed by a delete, change or yank command.</p>
|
||
<p><span id="index-SUFFIX_005fACTIVE"></span>
|
||
<span id="index-SUFFIX_005fSTART"></span>
|
||
<span id="index-SUFFIX_005fEND"></span></p>
|
||
<p><code>SUFFIX_ACTIVE</code> (integer)</p>
|
||
<p><code>SUFFIX_START</code> (integer)</p>
|
||
<p><code>SUFFIX_END</code> (integer)</p>
|
||
<p><code>SUFFIX_ACTIVE</code> indicates whether an auto-removable completion suffix is
|
||
currently active. <code>SUFFIX_START</code> and <code>SUFFIX_END</code> give the location of
|
||
the suffix and are in the same units as <code>CURSOR</code>. They are only valid
|
||
for reading when <code>SUFFIX_ACTIVE</code> is non-zero.</p>
|
||
<p>All parameters are read-only.</p>
|
||
<p><span id="index-UNDO_005fCHANGE_005fNO"></span></p>
|
||
<p><code>UNDO_CHANGE_NO</code> (integer)</p>
|
||
<p>A number representing the state of the undo history. The only use of
|
||
this is passing as an argument to the <code>undo</code> widget in order to undo
|
||
back to the recorded point. Read-only.</p>
|
||
<p><span id="index-UNDO_005fLIMIT_005fNO"></span></p>
|
||
<p><code>UNDO_LIMIT_NO</code> (integer)</p>
|
||
<p>A number corresponding to an existing change in the undo history;
|
||
compare <code>UNDO_CHANGE_NO</code>. If this is set to a value greater than zero,
|
||
the <code>undo</code> command will not allow the line to be undone beyond the given
|
||
change number. It is still possible to use ‘<code>zle undo</code> <code>change</code>’ in a
|
||
widget to undo beyond that point; in that case, it will not be possible
|
||
to undo at all until <code>UNDO_LIMIT_NO</code> is reduced. Set to 0 to disable the
|
||
limit.</p>
|
||
<p>A typical use of this variable in a widget function is as follows (note
|
||
the additional function scope is required):</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">() {
|
||
local UNDO_LIMIT_NO=$UNDO_CHANGE_NO
|
||
# Perform some form of recursive edit.
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-WIDGET"></span></p>
|
||
<p><code>WIDGET</code> (scalar)</p>
|
||
<p>The name of the widget currently being executed; read-only.</p>
|
||
<p><span id="index-WIDGETFUNC"></span></p>
|
||
<p><code>WIDGETFUNC</code> (scalar)</p>
|
||
<p>The name of the shell function that implements a widget defined with
|
||
either <code>zle -N</code> or <code>zle -C</code>. In the former case, this is the second
|
||
argument to the <code>zle -N</code> command that defined the widget, or the first
|
||
argument if there was no second argument. In the latter case this is the
|
||
third argument to the <code>zle -C</code> command that defined the widget.
|
||
Read-only.</p>
|
||
<p><span id="index-WIDGETSTYLE"></span></p>
|
||
<p><code>WIDGETSTYLE</code> (scalar)</p>
|
||
<p>Describes the implementation behind the completion widget currently
|
||
being executed; the second argument that followed <code>zle -C</code> when the
|
||
widget was defined. This is the name of a builtin completion widget. For
|
||
widgets defined with <code>zle -N</code> this is set to the empty string.
|
||
Read-only.</p>
|
||
<p><span id="index-YANK_005fACTIVE"></span>
|
||
<span id="index-YANK_005fSTART"></span>
|
||
<span id="index-YANK_005fEND"></span></p>
|
||
<p><code>YANK_ACTIVE</code> (integer)</p>
|
||
<p><code>YANK_START</code> (integer)</p>
|
||
<p><code>YANK_END</code> (integer)</p>
|
||
<p><code>YANK_ACTIVE</code> indicates whether text has just been yanked (pasted) into
|
||
the buffer. <code>YANK_START</code> and <code>YANK_END</code> give the location of the pasted
|
||
text and are in the same units as <code>CURSOR</code>. They are only valid for
|
||
reading when <code>YANK_ACTIVE</code> is non-zero. They can also be assigned by
|
||
widgets that insert text in a yank-like fashion, for example wrappers of
|
||
<code>bracketed-paste</code>. See also <code>zle -f</code>.</p>
|
||
<p><code>YANK_ACTIVE</code> is read-only.</p>
|
||
<p><span id="index-ZLE_005fRECURSIVE"></span></p>
|
||
<p><code>ZLE_RECURSIVE</code> (integer)</p>
|
||
<p>Usually zero, but incremented inside any instance of <code>recursive-edit</code>.
|
||
Hence indicates the current recursion level.</p>
|
||
<p><code>ZLE_RECURSIVE</code> is read-only.</p>
|
||
<p><span id="index-ZLE_005fSTATE"></span></p>
|
||
<p><code>ZLE_STATE</code> (scalar)</p>
|
||
<p>Contains a set of space-separated words that describe the current <code>zle</code>
|
||
state.</p>
|
||
<p>Currently, the states shown are the insert mode as set by the
|
||
<code>overwrite-mode</code> or <code>vi-replace</code> widgets and whether history commands
|
||
will visit imported entries as controlled by the set-local-history
|
||
widget. The string contains ‘<code>insert</code>’ if characters to be inserted on
|
||
the command line move existing characters to the right or ‘<code>overwrite</code>’
|
||
if characters to be inserted overwrite existing characters. It contains
|
||
‘<code>localhistory</code>’ if only local history commands will be visited or
|
||
‘<code>globalhistory</code>’ if imported history commands will also be visited.</p>
|
||
<p>The substrings are sorted in alphabetical order so that if you want to
|
||
test for two specific substrings in a future-proof way, you can do match
|
||
by doing:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">if [[ $ZLE_STATE == *globalhistory*insert* ]]; then ...; fi
|
||
</code></pre>
|
||
</div>
|
||
<hr />
|
||
<p><span id="Special-Widgets"></span></p>
|
||
<h3 id="1851-special-widgets"><a class="header" href="#1851-special-widgets">18.5.1 Special Widgets</a></h3>
|
||
<p>There are a few user-defined widgets which are special to the shell. If
|
||
they do not exist, no special action is taken. The environment provided
|
||
is identical to that for any other editing widget.</p>
|
||
<p><span id="index-zle_002disearch_002dexit"></span></p>
|
||
<p><code>zle-isearch-exit</code></p>
|
||
<p>Executed at the end of incremental search at the point where the isearch
|
||
prompt is removed from the display. See <code>zle-isearch-update</code> for an
|
||
example.</p>
|
||
<p><span id="index-zle_002disearch_002dupdate"></span></p>
|
||
<p><code>zle-isearch-update</code></p>
|
||
<p>Executed within incremental search when the display is about to be
|
||
redrawn. Additional output below the incremental search prompt can be
|
||
generated by using ‘<code>zle -M</code>’ within the widget. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle-isearch-update() { zle -M "Line $HISTNO"; }
|
||
zle -N zle-isearch-update
|
||
</code></pre>
|
||
</div>
|
||
<p>Note the line output by ‘<code>zle -M</code>’ is not deleted on exit from
|
||
incremental search. This can be done from a <code>zle-isearch-exit</code> widget:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle-isearch-exit() { zle -M ""; }
|
||
zle -N zle-isearch-exit
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-zle_002dline_002dpre_002dredraw"></span></p>
|
||
<p><code>zle-line-pre-redraw</code></p>
|
||
<p>Executed whenever the input line is about to be redrawn, providing an
|
||
opportunity to update the region_highlight array.</p>
|
||
<p><span id="index-zle_002dline_002dinit"></span></p>
|
||
<p><code>zle-line-init</code></p>
|
||
<p>Executed every time the line editor is started to read a new line of
|
||
input. The following example puts the line editor into vi command mode
|
||
when it starts up.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle-line-init() { zle -K vicmd; }
|
||
zle -N zle-line-init
|
||
</code></pre>
|
||
</div>
|
||
<p>(The command inside the function sets the keymap directly; it is
|
||
equivalent to <code>zle vi-cmd-mode</code>.)</p>
|
||
<p><span id="index-zle_002dline_002dfinish"></span></p>
|
||
<p><code>zle-line-finish</code></p>
|
||
<p>This is similar to <code>zle-line-init</code> but is executed every time the line
|
||
editor has finished reading a line of input.</p>
|
||
<p><span id="index-zle_002dhistory_002dline_002dset"></span></p>
|
||
<p><code>zle-history-line-set</code></p>
|
||
<p>Executed when the history line changes.</p>
|
||
<p><span id="index-zle_002dkeymap_002dselect"></span></p>
|
||
<p><code>zle-keymap-select</code></p>
|
||
<p>Executed every time the keymap changes, i.e. the special parameter
|
||
<code>KEYMAP</code> is set to a different value, while the line editor is active.
|
||
Initialising the keymap when the line editor starts does not cause the
|
||
widget to be called.</p>
|
||
<p>The value <code>$KEYMAP</code> within the function reflects the new keymap. The old
|
||
keymap is passed as the sole argument.</p>
|
||
<p>This can be used for detecting switches between the vi command (<code>vicmd</code>)
|
||
and insert (usually <code>main</code>) keymaps.</p>
|
||
<hr />
|
||
<p><span id="Standard-Widgets"></span></p>
|
||
<h2 id="186-standard-widgets"><a class="header" href="#186-standard-widgets">18.6 Standard Widgets</a></h2>
|
||
<p><span id="index-widgets_002c-standard"></span></p>
|
||
<p>The following is a list of all the standard widgets, and their default
|
||
bindings in emacs mode, vi command mode and vi insert mode (the
|
||
‘<code>emacs</code>’, ‘<code>vicmd</code>’ and ‘<code>viins</code>’ keymaps, respectively).</p>
|
||
<p>Note that cursor keys are bound to movement keys in all three keymaps;
|
||
the shell assumes that the cursor keys send the key sequences reported
|
||
by the terminal-handling library (termcap or terminfo). The key
|
||
sequences shown in the list are those based on the VT100, common on many
|
||
modern terminals, but in fact these are not necessarily bound. In the
|
||
case of the <code>viins</code> keymap, the initial escape character of the
|
||
sequences serves also to return to the <code>vicmd</code> keymap: whether this
|
||
happens is determined by the <code>KEYTIMEOUT</code> parameter, see
|
||
<a href="Parameters.html#Parameters">Parameters</a>.</p>
|
||
<hr />
|
||
<p><span id="Movement"></span> <span id="Movement-1"></span></p>
|
||
<h3 id="1861-movement"><a class="header" href="#1861-movement">18.6.1 Movement</a></h3>
|
||
<p><span id="index-vi_002dbackward_002dblank_002dword"></span></p>
|
||
<p><code>vi-backward-blank-word</code> (unbound) (<code>B</code>) (unbound)</p>
|
||
<p>Move backward one word, where a word is defined as a series of non-blank
|
||
characters.</p>
|
||
<p><span id="index-vi_002dbackward_002dblank_002dword_002dend"></span></p>
|
||
<p><code>vi-backward-blank-word-end</code> (unbound) (<code>gE</code>) (unbound)</p>
|
||
<p>Move to the end of the previous word, where a word is defined as a
|
||
series of non-blank characters.</p>
|
||
<p><span id="index-backward_002dchar"></span></p>
|
||
<p><code>backward-char</code> (<code>^B ESC-[D</code>) (unbound) (unbound)</p>
|
||
<p>Move backward one character.</p>
|
||
<p><span id="index-vi_002dbackward_002dchar"></span></p>
|
||
<p><code>vi-backward-char</code> (unbound) (<code>^H h ^?</code>) (<code>ESC-[D</code>)</p>
|
||
<p>Move backward one character, without changing lines.</p>
|
||
<p><span id="index-backward_002dword"></span></p>
|
||
<p><code>backward-word</code> (<code>ESC-B ESC-b</code>) (unbound) (unbound)</p>
|
||
<p>Move to the beginning of the previous word.</p>
|
||
<p><span id="index-emacs_002dbackward_002dword"></span></p>
|
||
<p><code>emacs-backward-word</code></p>
|
||
<p>Move to the beginning of the previous word.</p>
|
||
<p><span id="index-vi_002dbackward_002dword"></span></p>
|
||
<p><code>vi-backward-word</code> (unbound) (<code>b</code>) (unbound)</p>
|
||
<p>Move to the beginning of the previous word, vi-style.</p>
|
||
<p><span id="index-vi_002dbackward_002dword_002dend"></span></p>
|
||
<p><code>vi-backward-word-end</code> (unbound) (<code>ge</code>) (unbound)</p>
|
||
<p>Move to the end of the previous word, vi-style.</p>
|
||
<p><span id="index-beginning_002dof_002dline"></span></p>
|
||
<p><code>beginning-of-line</code> (<code>^A</code>) (unbound) (unbound)</p>
|
||
<p>Move to the beginning of the line. If already at the beginning of the
|
||
line, move to the beginning of the previous line, if any.</p>
|
||
<p><span id="index-vi_002dbeginning_002dof_002dline"></span></p>
|
||
<p><code>vi-beginning-of-line</code></p>
|
||
<p>Move to the beginning of the line, without changing lines.</p>
|
||
<p><span id="index-down_002dline"></span></p>
|
||
<p><code>down-line</code> (unbound) (unbound) (unbound)</p>
|
||
<p>Move down a line in the buffer.</p>
|
||
<p><span id="index-end_002dof_002dline"></span></p>
|
||
<p><code>end-of-line</code> (<code>^E</code>) (unbound) (unbound)</p>
|
||
<p>Move to the end of the line. If already at the end of the line, move to
|
||
the end of the next line, if any.</p>
|
||
<p><span id="index-vi_002dend_002dof_002dline"></span></p>
|
||
<p><code>vi-end-of-line</code> (unbound) (<code>$</code>) (unbound)</p>
|
||
<p>Move to the end of the line. If an argument is given to this command,
|
||
the cursor will be moved to the end of the line (argument - 1) lines
|
||
down.</p>
|
||
<p><span id="index-vi_002dforward_002dblank_002dword"></span></p>
|
||
<p><code>vi-forward-blank-word</code> (unbound) (<code>W</code>) (unbound)</p>
|
||
<p>Move forward one word, where a word is defined as a series of non-blank
|
||
characters.</p>
|
||
<p><span id="index-vi_002dforward_002dblank_002dword_002dend"></span></p>
|
||
<p><code>vi-forward-blank-word-end</code> (unbound) (<code>E</code>) (unbound)</p>
|
||
<p>Move to the end of the current word, or, if at the end of the current
|
||
word, to the end of the next word, where a word is defined as a series
|
||
of non-blank characters.</p>
|
||
<p><span id="index-forward_002dchar"></span></p>
|
||
<p><code>forward-char</code> (<code>^F ESC-[C</code>) (unbound) (unbound)</p>
|
||
<p>Move forward one character.</p>
|
||
<p><span id="index-vi_002dforward_002dchar"></span></p>
|
||
<p><code>vi-forward-char</code> (unbound) (<code>space l</code>) (<code>ESC-[C</code>)</p>
|
||
<p>Move forward one character.</p>
|
||
<p><span id="index-vi_002dfind_002dnext_002dchar"></span></p>
|
||
<p><code>vi-find-next-char</code> (<code>^X^F</code>) (<code>f</code>) (unbound)</p>
|
||
<p>Read a character from the keyboard, and move to the next occurrence of
|
||
it in the line.</p>
|
||
<p><span id="index-vi_002dfind_002dnext_002dchar_002dskip"></span></p>
|
||
<p><code>vi-find-next-char-skip</code> (unbound) (<code>t</code>) (unbound)</p>
|
||
<p>Read a character from the keyboard, and move to the position just before
|
||
the next occurrence of it in the line.</p>
|
||
<p><span id="index-vi_002dfind_002dprev_002dchar"></span></p>
|
||
<p><code>vi-find-prev-char</code> (unbound) (<code>F</code>) (unbound)</p>
|
||
<p>Read a character from the keyboard, and move to the previous occurrence
|
||
of it in the line.</p>
|
||
<p><span id="index-vi_002dfind_002dprev_002dchar_002dskip"></span></p>
|
||
<p><code>vi-find-prev-char-skip</code> (unbound) (<code>T</code>) (unbound)</p>
|
||
<p>Read a character from the keyboard, and move to the position just after
|
||
the previous occurrence of it in the line.</p>
|
||
<p><span id="index-vi_002dfirst_002dnon_002dblank"></span></p>
|
||
<p><code>vi-first-non-blank</code> (unbound) (<code>^</code>) (unbound)</p>
|
||
<p>Move to the first non-blank character in the line.</p>
|
||
<p><span id="index-vi_002dforward_002dword"></span></p>
|
||
<p><code>vi-forward-word</code> (unbound) (<code>w</code>) (unbound)</p>
|
||
<p>Move forward one word, vi-style.</p>
|
||
<p><span id="index-forward_002dword"></span></p>
|
||
<p><code>forward-word</code> (<code>ESC-F ESC-f</code>) (unbound) (unbound)</p>
|
||
<p>Move to the beginning of the next word. The editor’s idea of a word is
|
||
specified with the <code>WORDCHARS</code> parameter.</p>
|
||
<p><span id="index-emacs_002dforward_002dword"></span></p>
|
||
<p><code>emacs-forward-word</code></p>
|
||
<p>Move to the end of the next word.</p>
|
||
<p><span id="index-vi_002dforward_002dword_002dend"></span></p>
|
||
<p><code>vi-forward-word-end</code> (unbound) (<code>e</code>) (unbound)</p>
|
||
<p>Move to the end of the next word.</p>
|
||
<p><span id="index-vi_002dgoto_002dcolumn"></span></p>
|
||
<p><code>vi-goto-column</code> (<code>ESC-|</code>) (<code>|</code>) (unbound)</p>
|
||
<p>Move to the column specified by the numeric argument.</p>
|
||
<p><span id="index-vi_002dgoto_002dmark"></span></p>
|
||
<p><code>vi-goto-mark</code> (unbound) (<code>‘</code>) (unbound)</p>
|
||
<p>Move to the specified mark.</p>
|
||
<p><span id="index-vi_002dgoto_002dmark_002dline"></span></p>
|
||
<p><code>vi-goto-mark-line</code> (unbound) (<code>’</code>) (unbound)</p>
|
||
<p>Move to beginning of the line containing the specified mark.</p>
|
||
<p><span id="index-vi_002drepeat_002dfind"></span></p>
|
||
<p><code>vi-repeat-find</code> (unbound) (<code>;</code>) (unbound)</p>
|
||
<p>Repeat the last <code>vi-find</code> command.</p>
|
||
<p><span id="index-vi_002drev_002drepeat_002dfind"></span></p>
|
||
<p><code>vi-rev-repeat-find</code> (unbound) (<code>,</code>) (unbound)</p>
|
||
<p>Repeat the last <code>vi-find</code> command in the opposite direction.</p>
|
||
<p><span id="index-up_002dline"></span></p>
|
||
<p><code>up-line</code> (unbound) (unbound) (unbound)</p>
|
||
<p>Move up a line in the buffer.</p>
|
||
<hr />
|
||
<p><span id="History-Control"></span> <span id="History-Control-1"></span></p>
|
||
<h3 id="1862-history-control"><a class="header" href="#1862-history-control">18.6.2 History Control</a></h3>
|
||
<p><span id="index-beginning_002dof_002dbuffer_002dor_002dhistory"></span></p>
|
||
<p><code>beginning-of-buffer-or-history</code> (<code>ESC-<</code>) (<code>gg</code>) (unbound)</p>
|
||
<p>Move to the beginning of the buffer, or if already there, move to the
|
||
first event in the history list.</p>
|
||
<p><span id="index-beginning_002dof_002dline_002dhist"></span></p>
|
||
<p><code>beginning-of-line-hist</code></p>
|
||
<p>Move to the beginning of the line. If already at the beginning of the
|
||
buffer, move to the previous history line.</p>
|
||
<p><span id="index-beginning_002dof_002dhistory"></span></p>
|
||
<p><code>beginning-of-history</code></p>
|
||
<p>Move to the first event in the history list.</p>
|
||
<p><span id="index-down_002dline_002dor_002dhistory"></span></p>
|
||
<p><code>down-line-or-history</code> (<code>^N ESC-[B</code>) (<code>j</code>) (<code>ESC-[B</code>)</p>
|
||
<p>Move down a line in the buffer, or if already at the bottom line, move
|
||
to the next event in the history list.</p>
|
||
<p><span id="index-vi_002ddown_002dline_002dor_002dhistory"></span></p>
|
||
<p><code>vi-down-line-or-history</code> (unbound) (<code>+</code>) (unbound)</p>
|
||
<p>Move down a line in the buffer, or if already at the bottom line, move
|
||
to the next event in the history list. Then move to the first non-blank
|
||
character on the line.</p>
|
||
<p><span id="index-down_002dline_002dor_002dsearch"></span></p>
|
||
<p><code>down-line-or-search</code></p>
|
||
<p>Move down a line in the buffer, or if already at the bottom line, search
|
||
forward in the history for a line beginning with the first word in the
|
||
buffer.</p>
|
||
<p>If called from a function by the <code>zle</code> command with arguments, the first
|
||
argument is taken as the string for which to search, rather than the
|
||
first word in the buffer.</p>
|
||
<p><span id="index-down_002dhistory"></span></p>
|
||
<p><code>down-history</code> (unbound) (<code>^N</code>) (unbound)</p>
|
||
<p>Move to the next event in the history list.</p>
|
||
<p><span id="index-history_002dbeginning_002dsearch_002dbackward"></span></p>
|
||
<p><code>history-beginning-search-backward</code></p>
|
||
<p>Search backward in the history for a line beginning with the current
|
||
line up to the cursor. This leaves the cursor in its original position.</p>
|
||
<p><span id="index-end_002dof_002dbuffer_002dor_002dhistory"></span></p>
|
||
<p><code>end-of-buffer-or-history</code> (<code>ESC-></code>) (unbound) (unbound)</p>
|
||
<p>Move to the end of the buffer, or if already there, move to the last
|
||
event in the history list.</p>
|
||
<p><span id="index-end_002dof_002dline_002dhist"></span></p>
|
||
<p><code>end-of-line-hist</code></p>
|
||
<p>Move to the end of the line. If already at the end of the buffer, move
|
||
to the next history line.</p>
|
||
<p><span id="index-end_002dof_002dhistory"></span></p>
|
||
<p><code>end-of-history</code></p>
|
||
<p>Move to the last event in the history list.</p>
|
||
<p><span id="index-vi_002dfetch_002dhistory"></span></p>
|
||
<p><code>vi-fetch-history</code> (unbound) (<code>G</code>) (unbound)</p>
|
||
<p>Fetch the history line specified by the numeric argument. This defaults
|
||
to the current history line (i.e. the one that isn’t history yet).</p>
|
||
<p><span id="index-history_002dincremental_002dsearch_002dbackward"></span></p>
|
||
<p><code>history-incremental-search-backward</code> (<code>^R ^Xr</code>) (unbound) (unbound)</p>
|
||
<p>Search backward incrementally for a specified string. The search is
|
||
case-insensitive if the search string does not have uppercase letters
|
||
and no numeric argument was given. The string may begin with ‘<code>^</code>’ to
|
||
anchor the search to the beginning of the line. When called from a
|
||
user-defined function returns the following statuses: 0, if the search
|
||
succeeded; 1, if the search failed; 2, if the search term was a bad
|
||
pattern; 3, if the search was aborted by the <code>send-break</code> command.</p>
|
||
<p>A restricted set of editing functions is available in the mini-buffer.
|
||
Keys are looked up in the special <code>isearch</code> keymap, and if not found
|
||
there in the main keymap (note that by default the <code>isearch</code> keymap is
|
||
empty). An interrupt signal, as defined by the stty setting, will stop
|
||
the search and go back to the original line. An undefined key will have
|
||
the same effect. Note that the following always perform the same task
|
||
within incremental searches and cannot be replaced by user defined
|
||
widgets, nor can the set of functions be extended. The supported
|
||
functions are:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>accept-and-hold</code><br />
|
||
<code>accept-and-infer-next-history</code><br />
|
||
<code>accept-line</code><br />
|
||
<code>accept-line-and-down-history</code><br />
|
||
Perform the usual function after exiting incremental search. The
|
||
command line displayed is executed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>backward-delete-char</code><br />
|
||
<code>vi-backward-delete-char</code><br />
|
||
Back up one place in the search history. If the search has been
|
||
repeated this does not immediately erase a character in the
|
||
minibuffer.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>accept-search</code><br />
|
||
Exit incremental search, retaining the command line but performing
|
||
no further action. Note that this function is not bound by default
|
||
and has no effect outside incremental search.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>backward-delete-word</code><br />
|
||
<code>backward-kill-word</code><br />
|
||
<code>vi-backward-kill-word</code><br />
|
||
Back up one character in the minibuffer; if multiple searches have
|
||
been performed since the character was inserted the search history
|
||
is rewound to the point just before the character was entered. Hence
|
||
this has the effect of repeating <code>backward-delete-char</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>clear-screen</code><br />
|
||
Clear the screen, remaining in incremental search mode.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>history-incremental-search-backward</code><br />
|
||
Find the next occurrence of the contents of the mini-buffer. If the
|
||
mini-buffer is empty, the most recent previously used search string
|
||
is reinstated.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>history-incremental-search-forward</code><br />
|
||
Invert the sense of the search.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>magic-space</code><br />
|
||
Inserts a non-magical space.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>quoted-insert</code><br />
|
||
<code>vi-quoted-insert</code><br />
|
||
Quote the character to insert into the minibuffer.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>redisplay</code><br />
|
||
Redisplay the command line, remaining in incremental search mode.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>vi-cmd-mode</code><br />
|
||
Select the ‘<code>vicmd</code>’ keymap; the ‘<code>main</code>’ keymap (insert mode) will
|
||
be selected initially.</p>
|
||
<p>In addition, the modifications that were made while in vi insert
|
||
mode are merged to form a single undo event.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>vi-repeat-search</code><br />
|
||
<code>vi-rev-repeat-search</code><br />
|
||
Repeat the search. The direction of the search is indicated in the
|
||
mini-buffer.</p>
|
||
</li>
|
||
</ul>
|
||
<p>Any character that is not bound to one of the above functions, or
|
||
<code>self-insert</code> or <code>self-insert-unmeta</code>, will cause the mode to be exited.
|
||
The character is then looked up and executed in the keymap in effect at
|
||
that point.</p>
|
||
<p>When called from a widget function by the <code>zle</code> command, the incremental
|
||
search commands can take a string argument. This will be treated as a
|
||
string of keys, as for arguments to the <code>bindkey</code> command, and used as
|
||
initial input for the command. Any characters in the string which are
|
||
unused by the incremental search will be silently ignored. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle history-incremental-search-backward forceps
|
||
</code></pre>
|
||
</div>
|
||
<p>will search backwards for <code>forceps</code>, leaving the minibuffer containing
|
||
the string ‘<code>forceps</code>’.</p>
|
||
<p><span id="index-history_002dincremental_002dsearch_002dforward"></span></p>
|
||
<p><code>history-incremental-search-forward</code> (<code>^S ^Xs</code>) (unbound) (unbound)</p>
|
||
<p>Search forward incrementally for a specified string. The search is
|
||
case-insensitive if the search string does not have uppercase letters
|
||
and no numeric argument was given. The string may begin with ‘<code>^</code>’ to
|
||
anchor the search to the beginning of the line. The functions available
|
||
in the mini-buffer are the same as for
|
||
<code>history-incremental-search-backward</code>.</p>
|
||
<p><span id="index-history_002dincremental_002dpattern_002dsearch_002dbackward"></span>
|
||
<span id="index-history_002dincremental_002dpattern_002dsearch_002dforward"></span></p>
|
||
<p><code>history-incremental-pattern-search-backward</code></p>
|
||
<p><code>history-incremental-pattern-search-forward</code></p>
|
||
<p>These widgets behave similarly to the corresponding widgets with no
|
||
<code>-pattern</code>, but the search string typed by the user is treated as a
|
||
pattern, respecting the current settings of the various options
|
||
affecting pattern matching. See <a href="Expansion.html#Filename-Generation">Filename
|
||
Generation</a> for a description of
|
||
patterns. If no numeric argument was given lowercase letters in the
|
||
search string may match uppercase letters in the history. The string may
|
||
begin with ‘<code>^</code>’ to anchor the search to the beginning of the line.</p>
|
||
<p>The prompt changes to indicate an invalid pattern; this may simply
|
||
indicate the pattern is not yet complete.</p>
|
||
<p>Note that only non-overlapping matches are reported, so an expression
|
||
with wildcards may return fewer matches on a line than are visible by
|
||
inspection.</p>
|
||
<p><span id="index-history_002dsearch_002dbackward"></span></p>
|
||
<p><code>history-search-backward</code> (<code>ESC-P ESC-p</code>) (unbound) (unbound)</p>
|
||
<p>Search backward in the history for a line beginning with the first word
|
||
in the buffer.</p>
|
||
<p>If called from a function by the <code>zle</code> command with arguments, the first
|
||
argument is taken as the string for which to search, rather than the
|
||
first word in the buffer.</p>
|
||
<p><span id="index-vi_002dhistory_002dsearch_002dbackward"></span></p>
|
||
<p><code>vi-history-search-backward</code> (unbound) (<code>/</code>) (unbound)</p>
|
||
<p>Search backward in the history for a specified string. The string may
|
||
begin with ‘<code>^</code>’ to anchor the search to the beginning of the line.</p>
|
||
<p>A restricted set of editing functions is available in the mini-buffer.
|
||
An interrupt signal, as defined by the stty setting, will stop the
|
||
search. The functions available in the mini-buffer are: <code>accept-line</code>,
|
||
<code>backward-delete-char</code>, <code>vi-backward-delete-char</code>, <code>backward-kill-word</code>,
|
||
<code>vi-backward-kill-word</code>, <code>clear-screen</code>, <code>redisplay</code>, <code>quoted-insert</code>
|
||
and <code>vi-quoted-insert</code>.</p>
|
||
<p><code>vi-cmd-mode</code> is treated the same as accept-line, and <code>magic-space</code> is
|
||
treated as a space. Any other character that is not bound to self-insert
|
||
or self-insert-unmeta will beep and be ignored. If the function is
|
||
called from vi command mode, the bindings of the current insert mode
|
||
will be used.</p>
|
||
<p>If called from a function by the <code>zle</code> command with arguments, the first
|
||
argument is taken as the string for which to search, rather than the
|
||
first word in the buffer.</p>
|
||
<p><span id="index-history_002dsearch_002dforward"></span></p>
|
||
<p><code>history-search-forward</code> (<code>ESC-N ESC-n</code>) (unbound) (unbound)</p>
|
||
<p>Search forward in the history for a line beginning with the first word
|
||
in the buffer.</p>
|
||
<p>If called from a function by the <code>zle</code> command with arguments, the first
|
||
argument is taken as the string for which to search, rather than the
|
||
first word in the buffer.</p>
|
||
<p><span id="index-vi_002dhistory_002dsearch_002dforward"></span></p>
|
||
<p><code>vi-history-search-forward</code> (unbound) (<code>?</code>) (unbound)</p>
|
||
<p>Search forward in the history for a specified string. The string may
|
||
begin with ‘<code>^</code>’ to anchor the search to the beginning of the line. The
|
||
functions available in the mini-buffer are the same as for
|
||
<code>vi-history-search-backward</code>. Argument handling is also the same as for
|
||
that command.</p>
|
||
<p><span id="index-infer_002dnext_002dhistory"></span></p>
|
||
<p><code>infer-next-history</code> (<code>^X^N</code>) (unbound) (unbound)</p>
|
||
<p>Search in the history list for a line matching the current one and fetch
|
||
the event following it.</p>
|
||
<p><span id="index-insert_002dlast_002dword"></span></p>
|
||
<p><code>insert-last-word</code> (<code>ESC-_ ESC-.</code>) (unbound) (unbound)</p>
|
||
<p>Insert the last word from the previous history event at the cursor
|
||
position. If a positive numeric argument is given, insert that word from
|
||
the end of the previous history event. If the argument is zero or
|
||
negative insert that word from the left (zero inserts the previous
|
||
command word). Repeating this command replaces the word just inserted
|
||
with the last word from the history event prior to the one just used;
|
||
numeric arguments can be used in the same way to pick a word from that
|
||
event.</p>
|
||
<p>When called from a shell function invoked from a user-defined widget,
|
||
the command can take one to three arguments. The first argument
|
||
specifies a history offset which applies to successive calls to this
|
||
widget: if it is -1, the default behaviour is used, while if it is 1,
|
||
successive calls will move forwards through the history. The value 0 can
|
||
be used to indicate that the history line examined by the previous
|
||
execution of the command will be reexamined. Note that negative numbers
|
||
should be preceded by a ‘<code>-``-</code>’ argument to avoid confusing them with
|
||
options.</p>
|
||
<p>If two arguments are given, the second specifies the word on the command
|
||
line in normal array index notation (as a more natural alternative to
|
||
the numeric argument). Hence 1 is the first word, and -1 (the default)
|
||
is the last word.</p>
|
||
<p>If a third argument is given, its value is ignored, but it is used to
|
||
signify that the history offset is relative to the current history line,
|
||
rather than the one remembered after the previous invocations of
|
||
<code>insert-last-word</code>.</p>
|
||
<p>For example, the default behaviour of the command corresponds to</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle insert-last-word -- -1 -1
|
||
</code></pre>
|
||
</div>
|
||
<p>while the command</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle insert-last-word -- -1 1 -
|
||
</code></pre>
|
||
</div>
|
||
<p>always copies the first word of the line in the history immediately
|
||
before the line being edited. This has the side effect that later
|
||
invocations of the widget will be relative to that line.</p>
|
||
<p><span id="index-vi_002drepeat_002dsearch"></span></p>
|
||
<p><code>vi-repeat-search</code> (unbound) (<code>n</code>) (unbound)</p>
|
||
<p>Repeat the last vi history search.</p>
|
||
<p><span id="index-vi_002drev_002drepeat_002dsearch"></span></p>
|
||
<p><code>vi-rev-repeat-search</code> (unbound) (<code>N</code>) (unbound)</p>
|
||
<p>Repeat the last vi history search, but in reverse.</p>
|
||
<p><span id="index-up_002dline_002dor_002dhistory"></span></p>
|
||
<p><code>up-line-or-history</code> (<code>^P ESC-[A</code>) (<code>k</code>) (<code>ESC-[A</code>)</p>
|
||
<p>Move up a line in the buffer, or if already at the top line, move to the
|
||
previous event in the history list.</p>
|
||
<p><span id="index-vi_002dup_002dline_002dor_002dhistory"></span></p>
|
||
<p><code>vi-up-line-or-history</code> (unbound) (<code>-</code>) (unbound)</p>
|
||
<p>Move up a line in the buffer, or if already at the top line, move to the
|
||
previous event in the history list. Then move to the first non-blank
|
||
character on the line.</p>
|
||
<p><span id="index-up_002dline_002dor_002dsearch"></span></p>
|
||
<p><code>up-line-or-search</code></p>
|
||
<p>Move up a line in the buffer, or if already at the top line, search
|
||
backward in the history for a line beginning with the first word in the
|
||
buffer.</p>
|
||
<p>If called from a function by the <code>zle</code> command with arguments, the first
|
||
argument is taken as the string for which to search, rather than the
|
||
first word in the buffer.</p>
|
||
<p><span id="index-up_002dhistory"></span></p>
|
||
<p><code>up-history</code> (unbound) (<code>^P</code>) (unbound)</p>
|
||
<p>Move to the previous event in the history list.</p>
|
||
<p><span id="index-history_002dbeginning_002dsearch_002dforward"></span></p>
|
||
<p><code>history-beginning-search-forward</code></p>
|
||
<p>Search forward in the history for a line beginning with the current line
|
||
up to the cursor. This leaves the cursor in its original position.</p>
|
||
<p><span id="index-set_002dlocal_002dhistory"></span></p>
|
||
<p><code>set-local-history</code></p>
|
||
<p>By default, history movement commands visit the imported lines as well
|
||
as the local lines. This widget lets you toggle this on and off, or set
|
||
it with the numeric argument. Zero for both local and imported lines and
|
||
nonzero for only local lines.</p>
|
||
<hr />
|
||
<p><span id="Modifying-Text"></span> <span id="Modifying-Text-1"></span></p>
|
||
<h3 id="1863-modifying-text"><a class="header" href="#1863-modifying-text">18.6.3 Modifying Text</a></h3>
|
||
<p><span id="index-vi_002dadd_002deol"></span></p>
|
||
<p><code>vi-add-eol</code> (unbound) (<code>A</code>) (unbound)</p>
|
||
<p>Move to the end of the line and enter insert mode.</p>
|
||
<p><span id="index-vi_002dadd_002dnext"></span></p>
|
||
<p><code>vi-add-next</code> (unbound) (<code>a</code>) (unbound)</p>
|
||
<p>Enter insert mode after the current cursor position, without changing
|
||
lines.</p>
|
||
<p><span id="index-backward_002ddelete_002dchar"></span></p>
|
||
<p><code>backward-delete-char</code> (<code>^H ^?</code>) (unbound) (unbound)</p>
|
||
<p>Delete the character behind the cursor.</p>
|
||
<p><span id="index-vi_002dbackward_002ddelete_002dchar"></span></p>
|
||
<p><code>vi-backward-delete-char</code> (unbound) (<code>X</code>) (<code>^H</code>)</p>
|
||
<p>Delete the character behind the cursor, without changing lines. If in
|
||
insert mode, this won’t delete past the point where insert mode was last
|
||
entered.</p>
|
||
<p><span id="index-backward_002ddelete_002dword"></span></p>
|
||
<p><code>backward-delete-word</code></p>
|
||
<p>Delete the word behind the cursor.</p>
|
||
<p><span id="index-backward_002dkill_002dline"></span></p>
|
||
<p><code>backward-kill-line</code></p>
|
||
<p>Kill from the beginning of the line to the cursor position.</p>
|
||
<p><span id="index-backward_002dkill_002dword"></span></p>
|
||
<p><code>backward-kill-word</code> (<code>^W ESC-^H ESC-^?</code>) (unbound) (unbound)</p>
|
||
<p>Kill the word behind the cursor.</p>
|
||
<p><span id="index-vi_002dbackward_002dkill_002dword"></span></p>
|
||
<p><code>vi-backward-kill-word</code> (unbound) (unbound) (<code>^W</code>)</p>
|
||
<p>Kill the word behind the cursor, without going past the point where
|
||
insert mode was last entered.</p>
|
||
<p><span id="index-capitalize_002dword"></span></p>
|
||
<p><code>capitalize-word</code> (<code>ESC-C ESC-c</code>) (unbound) (unbound)</p>
|
||
<p>Capitalize the current word and move past it.</p>
|
||
<p><span id="index-vi_002dchange"></span></p>
|
||
<p><code>vi-change</code> (unbound) (<code>c</code>) (unbound)</p>
|
||
<p>Read a movement command from the keyboard, and kill from the cursor
|
||
position to the endpoint of the movement. Then enter insert mode. If the
|
||
command is <code>vi-change</code>, change the current line.</p>
|
||
<p>For compatibility with vi, if the command is <code>vi-forward-word</code> or
|
||
<code>vi-forward-blank-word</code>, the whitespace after the word is not included.
|
||
If you prefer the more consistent behaviour with the whitespace included
|
||
use the following key binding:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">bindkey -a -s cw dwi
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-vi_002dchange_002deol"></span></p>
|
||
<p><code>vi-change-eol</code> (unbound) (<code>C</code>) (unbound)</p>
|
||
<p>Kill to the end of the line and enter insert mode.</p>
|
||
<p><span id="index-vi_002dchange_002dwhole_002dline"></span></p>
|
||
<p><code>vi-change-whole-line</code> (unbound) (<code>S</code>) (unbound)</p>
|
||
<p>Kill the current line and enter insert mode.</p>
|
||
<p><span id="index-copy_002dregion_002das_002dkill"></span></p>
|
||
<p><code>copy-region-as-kill</code> (<code>ESC-W ESC-w</code>) (unbound) (unbound)</p>
|
||
<p>Copy the area from the cursor to the mark to the kill buffer.</p>
|
||
<p>If called from a ZLE widget function in the form ‘<code>zle copy-region-as-kill</code> <code>string</code>’ then <code>string</code> will be taken as the text
|
||
to copy to the kill buffer. The cursor, the mark and the text on the
|
||
command line are not used in this case.</p>
|
||
<p><span id="index-copy_002dprev_002dword"></span></p>
|
||
<p><code>copy-prev-word</code> (<code>ESC-^_</code>) (unbound) (unbound)</p>
|
||
<p>Duplicate the word to the left of the cursor.</p>
|
||
<p><span id="index-copy_002dprev_002dshell_002dword"></span></p>
|
||
<p><code>copy-prev-shell-word</code></p>
|
||
<p>Like <code>copy-prev-word</code>, but the word is found by using shell parsing,
|
||
whereas <code>copy-prev-word</code> looks for blanks. This makes a difference when
|
||
the word is quoted and contains spaces.</p>
|
||
<p><span id="index-vi_002ddelete"></span></p>
|
||
<p><code>vi-delete</code> (unbound) (<code>d</code>) (unbound)</p>
|
||
<p>Read a movement command from the keyboard, and kill from the cursor
|
||
position to the endpoint of the movement. If the command is <code>vi-delete</code>,
|
||
kill the current line.</p>
|
||
<p><span id="index-delete_002dchar"></span></p>
|
||
<p><code>delete-char</code></p>
|
||
<p>Delete the character under the cursor.</p>
|
||
<p><span id="index-vi_002ddelete_002dchar"></span></p>
|
||
<p><code>vi-delete-char</code> (unbound) (<code>x</code>) (unbound)</p>
|
||
<p>Delete the character under the cursor, without going past the end of the
|
||
line.</p>
|
||
<p><span id="index-delete_002dword"></span></p>
|
||
<p><code>delete-word</code></p>
|
||
<p>Delete the current word.</p>
|
||
<p><span id="index-down_002dcase_002dword"></span></p>
|
||
<p><code>down-case-word</code> (<code>ESC-L ESC-l</code>) (unbound) (unbound)</p>
|
||
<p>Convert the current word to all lowercase and move past it.</p>
|
||
<p><span id="index-vi_002ddown_002dcase"></span></p>
|
||
<p><code>vi-down-case</code> (unbound) (<code>gu</code>) (unbound)</p>
|
||
<p>Read a movement command from the keyboard, and convert all characters
|
||
from the cursor position to the endpoint of the movement to lowercase.
|
||
If the movement command is <code>vi-down-case</code>, swap the case of all
|
||
characters on the current line.</p>
|
||
<p><span id="index-kill_002dword"></span></p>
|
||
<p><code>kill-word</code> (<code>ESC-D ESC-d</code>) (unbound) (unbound)</p>
|
||
<p>Kill the current word.</p>
|
||
<p><span id="index-gosmacs_002dtranspose_002dchars"></span></p>
|
||
<p><code>gosmacs-transpose-chars</code></p>
|
||
<p>Exchange the two characters behind the cursor.</p>
|
||
<p><span id="index-vi_002dindent"></span></p>
|
||
<p><code>vi-indent</code> (unbound) (<code>></code>) (unbound)</p>
|
||
<p>Indent a number of lines.</p>
|
||
<p><span id="index-vi_002dinsert"></span></p>
|
||
<p><code>vi-insert</code> (unbound) (<code>i</code>) (unbound)</p>
|
||
<p>Enter insert mode.</p>
|
||
<p><span id="index-vi_002dinsert_002dbol"></span></p>
|
||
<p><code>vi-insert-bol</code> (unbound) (<code>I</code>) (unbound)</p>
|
||
<p>Move to the first non-blank character on the line and enter insert mode.</p>
|
||
<p><span id="index-vi_002djoin"></span></p>
|
||
<p><code>vi-join</code> (<code>^X^J</code>) (<code>J</code>) (unbound)</p>
|
||
<p>Join the current line with the next one.</p>
|
||
<p><span id="index-kill_002dline"></span></p>
|
||
<p><code>kill-line</code> (<code>^K</code>) (unbound) (unbound)</p>
|
||
<p>Kill from the cursor to the end of the line. If already on the end of
|
||
the line, kill the newline character.</p>
|
||
<p><span id="index-vi_002dkill_002dline"></span></p>
|
||
<p><code>vi-kill-line</code> (unbound) (unbound) (<code>^U</code>)</p>
|
||
<p>Kill from the cursor back to wherever insert mode was last entered.</p>
|
||
<p><span id="index-vi_002dkill_002deol"></span></p>
|
||
<p><code>vi-kill-eol</code> (unbound) (<code>D</code>) (unbound)</p>
|
||
<p>Kill from the cursor to the end of the line.</p>
|
||
<p><span id="index-kill_002dregion"></span></p>
|
||
<p><code>kill-region</code></p>
|
||
<p>Kill from the cursor to the mark.</p>
|
||
<p><span id="index-kill_002dbuffer"></span></p>
|
||
<p><code>kill-buffer</code> (<code>^X^K</code>) (unbound) (unbound)</p>
|
||
<p>Kill the entire buffer.</p>
|
||
<p><span id="index-kill_002dwhole_002dline"></span></p>
|
||
<p><code>kill-whole-line</code> (<code>^U</code>) (unbound) (unbound)</p>
|
||
<p>Kill the current line.</p>
|
||
<p><span id="index-vi_002dmatch_002dbracket"></span></p>
|
||
<p><code>vi-match-bracket</code> (<code>^X^B</code>) (<code>%</code>) (unbound)</p>
|
||
<p>Move to the bracket character (one of <code>{}</code>, <code>()</code> or <code>[]</code>) that matches
|
||
the one under the cursor. If the cursor is not on a bracket character,
|
||
move forward without going past the end of the line to find one, and
|
||
then go to the matching bracket.</p>
|
||
<p><span id="index-vi_002dopen_002dline_002dabove"></span></p>
|
||
<p><code>vi-open-line-above</code> (unbound) (<code>O</code>) (unbound)</p>
|
||
<p>Open a line above the cursor and enter insert mode.</p>
|
||
<p><span id="index-vi_002dopen_002dline_002dbelow"></span></p>
|
||
<p><code>vi-open-line-below</code> (unbound) (<code>o</code>) (unbound)</p>
|
||
<p>Open a line below the cursor and enter insert mode.</p>
|
||
<p><span id="index-vi_002doper_002dswap_002dcase"></span></p>
|
||
<p><code>vi-oper-swap-case</code> (unbound) (<code>g~</code>) (unbound)</p>
|
||
<p>Read a movement command from the keyboard, and swap the case of all
|
||
characters from the cursor position to the endpoint of the movement. If
|
||
the movement command is <code>vi-oper-swap-case</code>, swap the case of all
|
||
characters on the current line.</p>
|
||
<p><span id="index-overwrite_002dmode"></span></p>
|
||
<p><code>overwrite-mode</code> (<code>^X^O</code>) (unbound) (unbound)</p>
|
||
<p>Toggle between overwrite mode and insert mode.</p>
|
||
<p><span id="index-vi_002dput_002dbefore"></span></p>
|
||
<p><code>vi-put-before</code> (unbound) (<code>P</code>) (unbound)</p>
|
||
<p>Insert the contents of the kill buffer before the cursor. If the kill
|
||
buffer contains a sequence of lines (as opposed to characters), paste it
|
||
above the current line.</p>
|
||
<p><span id="index-vi_002dput_002dafter"></span></p>
|
||
<p><code>vi-put-after</code> (unbound) (<code>p</code>) (unbound)</p>
|
||
<p>Insert the contents of the kill buffer after the cursor. If the kill
|
||
buffer contains a sequence of lines (as opposed to characters), paste it
|
||
below the current line.</p>
|
||
<p><span id="index-put_002dreplace_002dselection"></span></p>
|
||
<p><code>put-replace-selection</code> (unbound) (unbound) (unbound)</p>
|
||
<p>Replace the contents of the current region or selection with the
|
||
contents of the kill buffer. If the kill buffer contains a sequence of
|
||
lines (as opposed to characters), the current line will be split by the
|
||
pasted lines.</p>
|
||
<p><span id="index-quoted_002dinsert"></span></p>
|
||
<p><code>quoted-insert</code> (<code>^V</code>) (unbound) (unbound)</p>
|
||
<p>Insert the next character typed into the buffer literally. An interrupt
|
||
character will not be inserted.</p>
|
||
<p><span id="index-vi_002dquoted_002dinsert"></span></p>
|
||
<p><code>vi-quoted-insert</code> (unbound) (unbound) (<code>^Q ^V</code>)</p>
|
||
<p>Display a ‘<code>^</code>’ at the cursor position, and insert the next character
|
||
typed into the buffer literally. An interrupt character will not be
|
||
inserted.</p>
|
||
<p><span id="index-quote_002dline"></span></p>
|
||
<p><code>quote-line</code> (<code>ESC-’</code>) (unbound) (unbound)</p>
|
||
<p>Quote the current line; that is, put a ‘<code>’</code>’ character at the beginning
|
||
and the end, and convert all ‘<code>’</code>’ characters to ‘<code>’\’’</code>’.</p>
|
||
<p><span id="index-quote_002dregion"></span></p>
|
||
<p><code>quote-region</code> (<code>ESC-"</code>) (unbound) (unbound)</p>
|
||
<p>Quote the region from the cursor to the mark.</p>
|
||
<p><span id="index-vi_002dreplace"></span></p>
|
||
<p><code>vi-replace</code> (unbound) (<code>R</code>) (unbound)</p>
|
||
<p>Enter overwrite mode.</p>
|
||
<p><span id="index-vi_002drepeat_002dchange"></span></p>
|
||
<p><code>vi-repeat-change</code> (unbound) (<code>.</code>) (unbound)</p>
|
||
<p>Repeat the last vi mode text modification. If a count was used with the
|
||
modification, it is remembered. If a count is given to this command, it
|
||
overrides the remembered count, and is remembered for future uses of
|
||
this command. The cut buffer specification is similarly remembered.</p>
|
||
<p><span id="index-vi_002dreplace_002dchars"></span></p>
|
||
<p><code>vi-replace-chars</code> (unbound) (<code>r</code>) (unbound)</p>
|
||
<p>Replace the character under the cursor with a character read from the
|
||
keyboard.</p>
|
||
<p><span id="index-self_002dinsert"></span></p>
|
||
<p>Insert a character into the buffer at the cursor position.</p>
|
||
<p><span id="index-self_002dinsert_002dunmeta"></span></p>
|
||
<p><code>self-insert-unmeta</code> (<code>ESC-^I ESC-^J ESC-^M</code>) (unbound) (unbound)</p>
|
||
<p>Insert a character into the buffer after stripping the meta bit and
|
||
converting ^M to ^J.</p>
|
||
<p><span id="index-vi_002dsubstitute"></span></p>
|
||
<p><code>vi-substitute</code> (unbound) (<code>s</code>) (unbound)</p>
|
||
<p>Substitute the next character(s).</p>
|
||
<p><span id="index-vi_002dswap_002dcase"></span></p>
|
||
<p><code>vi-swap-case</code> (unbound) (<code>~</code>) (unbound)</p>
|
||
<p>Swap the case of the character under the cursor and move past it.</p>
|
||
<p><span id="index-transpose_002dchars"></span></p>
|
||
<p><code>transpose-chars</code> (<code>^T</code>) (unbound) (unbound)</p>
|
||
<p>Exchange the two characters to the left of the cursor if at end of line,
|
||
else exchange the character under the cursor with the character to the
|
||
left.</p>
|
||
<p><span id="index-transpose_002dwords"></span></p>
|
||
<p><code>transpose-words</code> (<code>ESC-T ESC-t</code>) (unbound) (unbound)</p>
|
||
<p>Exchange the current word with the one before it.</p>
|
||
<p>With a positive numeric argument <em>N</em>, the word around the cursor, or
|
||
following it if the cursor is between words, is transposed with the
|
||
preceding <em>N</em> words. The cursor is put at the end of the resulting group
|
||
of words.</p>
|
||
<p>With a negative numeric argument <em>-N</em>, the effect is the same as using a
|
||
positive argument <em>N</em> except that the original cursor position is
|
||
retained, regardless of how the words are rearranged.</p>
|
||
<p><span id="index-vi_002dunindent"></span></p>
|
||
<p><code>vi-unindent</code> (unbound) (<code><</code>) (unbound)</p>
|
||
<p>Unindent a number of lines.</p>
|
||
<p><span id="index-vi_002dup_002dcase"></span></p>
|
||
<p><code>vi-up-case</code> (unbound) (<code>gU</code>) (unbound)</p>
|
||
<p>Read a movement command from the keyboard, and convert all characters
|
||
from the cursor position to the endpoint of the movement to lowercase.
|
||
If the movement command is <code>vi-up-case</code>, swap the case of all characters
|
||
on the current line.</p>
|
||
<p><span id="index-up_002dcase_002dword"></span></p>
|
||
<p><code>up-case-word</code> (<code>ESC-U ESC-u</code>) (unbound) (unbound)</p>
|
||
<p>Convert the current word to all caps and move past it.</p>
|
||
<p><span id="index-yank"></span></p>
|
||
<p><code>yank</code> (<code>^Y</code>) (unbound) (unbound)</p>
|
||
<p>Insert the contents of the kill buffer at the cursor position.</p>
|
||
<p><span id="index-yank_002dpop"></span></p>
|
||
<p><code>yank-pop</code> (<code>ESC-y</code>) (unbound) (unbound)</p>
|
||
<p>Remove the text just yanked, rotate the kill-ring (the history of
|
||
previously killed text) and yank the new top. Only works following
|
||
<code>yank</code>, <code>vi-put-before</code>, <code>vi-put-after</code> or <code>yank-pop</code>.</p>
|
||
<p><span id="index-vi_002dyank"></span></p>
|
||
<p><code>vi-yank</code> (unbound) (<code>y</code>) (unbound)</p>
|
||
<p>Read a movement command from the keyboard, and copy the region from the
|
||
cursor position to the endpoint of the movement into the kill buffer. If
|
||
the command is <code>vi-yank</code>, copy the current line.</p>
|
||
<p><span id="index-vi_002dyank_002dwhole_002dline"></span></p>
|
||
<p><code>vi-yank-whole-line</code> (unbound) (<code>Y</code>) (unbound)</p>
|
||
<p>Copy the current line into the kill buffer.</p>
|
||
<p><span id="index-vi_002dyank_002deol"></span></p>
|
||
<p><code>vi-yank-eol</code></p>
|
||
<p>Copy the region from the cursor position to the end of the line into the
|
||
kill buffer. Arguably, this is what Y should do in vi, but it isn’t what
|
||
it actually does.</p>
|
||
<hr />
|
||
<p><span id="Arguments"></span> <span id="Arguments-1"></span></p>
|
||
<h3 id="1864-arguments"><a class="header" href="#1864-arguments">18.6.4 Arguments</a></h3>
|
||
<p><span id="index-digit_002dargument"></span></p>
|
||
<p><code>digit-argument</code> (<code>ESC-0</code>..<code>ESC-9</code>) (<code>1</code>-<code>9</code>) (unbound)</p>
|
||
<p>Start a new numeric argument, or add to the current one. See also
|
||
<code>vi-digit-or-beginning-of-line</code>. This only works if bound to a key
|
||
sequence ending in a decimal digit.</p>
|
||
<p>Inside a widget function, a call to this function treats the last key of
|
||
the key sequence which called the widget as the digit.</p>
|
||
<p><span id="index-neg_002dargument"></span></p>
|
||
<p><code>neg-argument</code> (<code>ESC-``-</code>) (unbound) (unbound)</p>
|
||
<p>Changes the sign of the following argument.</p>
|
||
<p><span id="index-universal_002dargument"></span></p>
|
||
<p><code>universal-argument</code></p>
|
||
<p>Multiply the argument of the next command by 4. Alternatively, if this
|
||
command is followed by an integer (positive or negative), use that as
|
||
the argument for the next command. Thus digits cannot be repeated using
|
||
this command. For example, if this command occurs twice, followed
|
||
immediately by <code>forward-char</code>, move forward sixteen spaces; if instead
|
||
it is followed by <code>-2</code>, then <code>forward-char</code>, move backward two spaces.</p>
|
||
<p>Inside a widget function, if passed an argument, i.e. ‘<code>zle universal-argument</code> <code>num</code>’, the numeric argument will be set to <code>num</code>;
|
||
this is equivalent to ‘<code>NUMERIC=``num</code>’.</p>
|
||
<p><span id="index-argument_002dbase"></span></p>
|
||
<p><code>argument-base</code></p>
|
||
<p>Use the existing numeric argument as a numeric base, which must be in
|
||
the range 2 to 36 inclusive. Subsequent use of <code>digit-argument</code> and
|
||
<code>universal-argument</code> will input a new numeric argument in the given
|
||
base. The usual hexadecimal convention is used: the letter <code>a</code> or <code>A</code>
|
||
corresponds to 10, and so on. Arguments in bases requiring digits from
|
||
10 upwards are more conveniently input with <code>universal-argument</code>, since
|
||
<code>ESC-a</code> etc. are not usually bound to <code>digit-argument</code>.</p>
|
||
<p>The function can be used with a command argument inside a user-defined
|
||
widget. The following code sets the base to 16 and lets the user input a
|
||
hexadecimal argument until a key out of the digit range is typed:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle argument-base 16
|
||
zle universal-argument
|
||
</code></pre>
|
||
</div>
|
||
<hr />
|
||
<p><span id="Completion"></span> <span id="Completion-2"></span></p>
|
||
<h3 id="1865-completion"><a class="header" href="#1865-completion">18.6.5 Completion</a></h3>
|
||
<p><span id="index-accept_002dand_002dmenu_002dcomplete"></span></p>
|
||
<p><code>accept-and-menu-complete</code></p>
|
||
<p>In a menu completion, insert the current completion into the buffer, and
|
||
advance to the next possible completion.</p>
|
||
<p><span id="index-complete_002dword"></span></p>
|
||
<p><code>complete-word</code></p>
|
||
<p>Attempt completion on the current word.</p>
|
||
<p><span id="index-delete_002dchar_002dor_002dlist"></span></p>
|
||
<p><code>delete-char-or-list</code> (<code>^D</code>) (unbound) (unbound)</p>
|
||
<p>Delete the character under the cursor. If the cursor is at the end of
|
||
the line, list possible completions for the current word.</p>
|
||
<p><span id="index-expand_002dcmd_002dpath"></span></p>
|
||
<p><code>expand-cmd-path</code></p>
|
||
<p>Expand the current command to its full pathname.</p>
|
||
<p><span id="index-expand_002dor_002dcomplete"></span></p>
|
||
<p><code>expand-or-complete</code> (<code>TAB</code>) (unbound) (<code>TAB</code>)</p>
|
||
<p>Attempt shell expansion on the current word. If that fails, attempt
|
||
completion.</p>
|
||
<p><span id="index-expand_002dor_002dcomplete_002dprefix"></span></p>
|
||
<p><code>expand-or-complete-prefix</code></p>
|
||
<p>Attempt shell expansion on the current word up to cursor.</p>
|
||
<p><span id="index-expand_002dhistory"></span></p>
|
||
<p><code>expand-history</code> (<code>ESC-space ESC-!</code>) (unbound) (unbound)</p>
|
||
<p>Perform history expansion on the edit buffer.</p>
|
||
<p><span id="index-expand_002dword"></span></p>
|
||
<p><code>expand-word</code> (<code>^X*</code>) (unbound) (unbound)</p>
|
||
<p>Attempt shell expansion on the current word.</p>
|
||
<p><span id="index-list_002dchoices"></span></p>
|
||
<p><code>list-choices</code> (<code>ESC-^D</code>) (<code>^D =</code>) (<code>^D</code>)</p>
|
||
<p>List possible completions for the current word.</p>
|
||
<p><span id="index-list_002dexpand"></span></p>
|
||
<p><code>list-expand</code> (<code>^Xg ^XG</code>) (<code>^G</code>) (<code>^G</code>)</p>
|
||
<p>List the expansion of the current word.</p>
|
||
<p><span id="index-magic_002dspace"></span></p>
|
||
<p><code>magic-space</code></p>
|
||
<p>Perform history expansion and insert a space into the buffer. This is
|
||
intended to be bound to space.</p>
|
||
<p><span id="index-menu_002dcomplete"></span>
|
||
<span id="index-MENU_005fCOMPLETE_002c-use-of"></span></p>
|
||
<p><code>menu-complete</code></p>
|
||
<p>Like <code>complete-word</code>, except that menu completion is used. See the
|
||
<code>MENU_COMPLETE</code> option.</p>
|
||
<p><span id="index-menu_002dexpand_002dor_002dcomplete"></span></p>
|
||
<p><code>menu-expand-or-complete</code></p>
|
||
<p>Like <code>expand-or-complete</code>, except that menu completion is used.</p>
|
||
<p><span id="index-reverse_002dmenu_002dcomplete"></span></p>
|
||
<p><code>reverse-menu-complete</code></p>
|
||
<p>Perform menu completion, like <code>menu-complete</code>, except that if a menu
|
||
completion is already in progress, move to the <em>previous</em> completion
|
||
rather than the next.</p>
|
||
<p><span id="index-end_002dof_002dlist"></span></p>
|
||
<p><code>end-of-list</code></p>
|
||
<p>When a previous completion displayed a list below the prompt, this
|
||
widget can be used to move the prompt below the list.</p>
|
||
<hr />
|
||
<p><span id="Miscellaneous"></span> <span id="Miscellaneous-1"></span></p>
|
||
<h3 id="1866-miscellaneous"><a class="header" href="#1866-miscellaneous">18.6.6 Miscellaneous</a></h3>
|
||
<p><span id="index-accept_002dand_002dhold"></span></p>
|
||
<p><code>accept-and-hold</code> (<code>ESC-A ESC-a</code>) (unbound) (unbound)</p>
|
||
<p>Push the contents of the buffer on the buffer stack and execute it.</p>
|
||
<p><span id="index-accept_002dand_002dinfer_002dnext_002dhistory"></span></p>
|
||
<p><code>accept-and-infer-next-history</code></p>
|
||
<p>Execute the contents of the buffer. Then search the history list for a
|
||
line matching the current one and push the event following onto the
|
||
buffer stack.</p>
|
||
<p><span id="index-accept_002dline"></span></p>
|
||
<p><code>accept-line</code> (<code>^J ^M</code>) (<code>^J ^M</code>) (<code>^J ^M</code>)</p>
|
||
<p>Finish editing the buffer. Normally this causes the buffer to be
|
||
executed as a shell command.</p>
|
||
<p><span id="index-accept_002dline_002dand_002ddown_002dhistory"></span></p>
|
||
<p><code>accept-line-and-down-history</code> (<code>^O</code>) (unbound) (unbound)</p>
|
||
<p>Execute the current line, and push the next history event on the buffer
|
||
stack.</p>
|
||
<p><span id="index-auto_002dsuffix_002dremove"></span></p>
|
||
<p><code>auto-suffix-remove</code></p>
|
||
<p>If the previous action added a suffix (space, slash, etc.) to the word
|
||
on the command line, remove it. Otherwise do nothing. Removing the
|
||
suffix ends any active menu completion or menu selection.</p>
|
||
<p>This widget is intended to be called from user-defined widgets to
|
||
enforce a desired suffix-removal behavior.</p>
|
||
<p><span id="index-auto_002dsuffix_002dretain"></span></p>
|
||
<p><code>auto-suffix-retain</code></p>
|
||
<p>If the previous action added a suffix (space, slash, etc.) to the word
|
||
on the command line, force it to be preserved. Otherwise do nothing.
|
||
Retaining the suffix ends any active menu completion or menu selection.</p>
|
||
<p>This widget is intended to be called from user-defined widgets to
|
||
enforce a desired suffix-preservation behavior.</p>
|
||
<p><span id="index-beep"></span></p>
|
||
<p><code>beep</code></p>
|
||
<p>Beep, unless the <code>BEEP</code> option is unset.</p>
|
||
<p><span id="index-bracketed_002dpaste"></span></p>
|
||
<p><code>bracketed-paste</code></p>
|
||
<p>This widget is invoked when text is pasted to the terminal emulator. It
|
||
is not intended to be bound to actual keys but instead to the special
|
||
sequence generated by the terminal emulator when text is pasted.</p>
|
||
<p>When invoked interactively, the pasted text is inserted to the buffer
|
||
and placed in the cutbuffer. If a numeric argument is given, shell
|
||
quoting will be applied to the pasted text before it is inserted.</p>
|
||
<p>When a named buffer is specified with <code>vi-set-buffer</code> (<code>"x</code>), the pasted
|
||
text is stored in that named buffer but not inserted.</p>
|
||
<p>When called from a widget function as ‘<code>bracketed-paste</code> <code>name</code>‘, the
|
||
pasted text is assigned to the variable <code>name</code> and no other processing
|
||
is done.</p>
|
||
<p>See also the <code>zle_bracketed_paste</code> parameter.</p>
|
||
<p><span id="index-vi_002dcmd_002dmode"></span></p>
|
||
<p><code>vi-cmd-mode</code> (<code>^X^V</code>) (unbound) (<code>^[</code>)</p>
|
||
<p>Enter command mode; that is, select the ‘<code>vicmd</code>’ keymap. Yes, this is
|
||
bound by default in emacs mode.</p>
|
||
<p><span id="index-vi_002dcaps_002dlock_002dpanic"></span></p>
|
||
<p><code>vi-caps-lock-panic</code></p>
|
||
<p>Hang until any lowercase key is pressed. This is for vi users without
|
||
the mental capacity to keep track of their caps lock key (like the
|
||
author).</p>
|
||
<p><span id="index-clear_002dscreen"></span></p>
|
||
<p><code>clear-screen</code> (<code>^L ESC-^L</code>) (<code>^L</code>) (<code>^L</code>)</p>
|
||
<p>Clear the screen and redraw the prompt.</p>
|
||
<p><span id="index-deactivate_002dregion"></span></p>
|
||
<p><code>deactivate-region</code></p>
|
||
<p>Make the current region inactive. This disables vim-style visual
|
||
selection mode if it is active.</p>
|
||
<p><span id="index-describe_002dkey_002dbriefly"></span></p>
|
||
<p><code>describe-key-briefly</code></p>
|
||
<p>Reads a key sequence, then prints the function bound to that sequence.</p>
|
||
<p><span id="index-exchange_002dpoint_002dand_002dmark"></span></p>
|
||
<p><code>exchange-point-and-mark</code> (<code>^X^X</code>) (unbound) (unbound)</p>
|
||
<p>Exchange the cursor position (point) with the position of the mark.
|
||
Unless a negative numeric argument is given, the region between point
|
||
and mark is activated so that it can be highlighted. If a zero numeric
|
||
argument is given, the region is activated but point and mark are not
|
||
swapped.</p>
|
||
<p><span id="index-execute_002dnamed_002dcmd"></span></p>
|
||
<p><code>execute-named-cmd</code> (<code>ESC-x</code>) (<code>:</code>) (unbound)</p>
|
||
<p>Read the name of an editor command and execute it. Aliasing this widget
|
||
with ‘<code>zle -A</code>’ or replacing it with ‘<code>zle -N</code>’ has no effect when
|
||
interpreting key bindings, but ‘<code>zle execute-named-cmd</code>’ will invoke
|
||
such an alias or replacement.</p>
|
||
<p>A restricted set of editing functions is available in the mini-buffer.
|
||
Keys are looked up in the special <code>command</code> keymap, and if not found
|
||
there in the main keymap. An interrupt signal, as defined by the stty
|
||
setting, will abort the function. Note that the following always perform
|
||
the same task within the <code>executed-named-cmd</code> environment and cannot be
|
||
replaced by user defined widgets, nor can the set of functions be
|
||
extended. The allowed functions are: <code>backward-delete-char</code>,
|
||
<code>vi-backward-delete-char</code>, <code>clear-screen</code>, <code>redisplay</code>, <code>quoted-insert</code>,
|
||
<code>vi-quoted-insert</code>, <code>backward-kill-word</code>, <code>vi-backward-kill-word</code>,
|
||
<code>kill-whole-line</code>, <code>vi-kill-line</code>, <code>backward-kill-line</code>, <code>list-choices</code>,
|
||
<code>delete-char-or-list</code>, <code>complete-word</code>, <code>accept-line</code>,
|
||
<code>expand-or-complete</code> and <code>expand-or-complete-prefix</code>.</p>
|
||
<p><code>kill-region</code> kills the last word, and vi-cmd-mode is treated the same
|
||
as accept-line. The space and tab characters, if not bound to one of
|
||
these functions, will complete the name and then list the possibilities
|
||
if the <code>AUTO_LIST</code> option is set. Any other character that is not bound
|
||
to <code>self-insert</code> or <code>self-insert-unmeta</code> will beep and be ignored. The
|
||
bindings of the current insert mode will be used.</p>
|
||
<p>Currently this command may not be redefined or called by name.</p>
|
||
<p><span id="index-execute_002dlast_002dnamed_002dcmd"></span></p>
|
||
<p><code>execute-last-named-cmd</code> (<code>ESC-z</code>) (unbound) (unbound)</p>
|
||
<p>Redo the last function executed with <code>execute-named-cmd</code>.</p>
|
||
<p>Like <code>execute-named-cmd</code>, this command may not be redefined, but it may
|
||
be called by name.</p>
|
||
<p><span id="index-get_002dline"></span></p>
|
||
<p><code>get-line</code> (<code>ESC-G ESC-g</code>) (unbound) (unbound)</p>
|
||
<p>Pop the top line off the buffer stack and insert it at the cursor
|
||
position.</p>
|
||
<p><span id="index-pound_002dinsert"></span></p>
|
||
<p><code>pound-insert</code> (unbound) (<code>#</code>) (unbound)</p>
|
||
<p>If there is no # character at the beginning of the buffer, add one to
|
||
the beginning of each line. If there is one, remove a # from each line
|
||
that has one. In either case, accept the current line. The
|
||
<code>INTERACTIVE_COMMENTS</code> option must be set for this to have any
|
||
usefulness.</p>
|
||
<p><span id="index-vi_002dpound_002dinsert"></span></p>
|
||
<p><code>vi-pound-insert</code></p>
|
||
<p>If there is no # character at the beginning of the current line, add
|
||
one. If there is one, remove it. The <code>INTERACTIVE_COMMENTS</code> option must
|
||
be set for this to have any usefulness.</p>
|
||
<p><span id="index-push_002dinput"></span></p>
|
||
<p><code>push-input</code></p>
|
||
<p>Push the entire current multiline construct onto the buffer stack and
|
||
return to the top-level (<code>PS1</code>) prompt. If the current parser construct
|
||
is only a single line, this is exactly like <code>push-line</code>. Next time the
|
||
editor starts up or is popped with <code>get-line</code>, the construct will be
|
||
popped off the top of the buffer stack and loaded into the editing
|
||
buffer.</p>
|
||
<p><span id="index-push_002dline"></span></p>
|
||
<p><code>push-line</code> (<code>^Q ESC-Q ESC-q</code>) (unbound) (unbound)</p>
|
||
<p>Push the current buffer onto the buffer stack and clear the buffer. Next
|
||
time the editor starts up, the buffer will be popped off the top of the
|
||
buffer stack and loaded into the editing buffer.</p>
|
||
<p><span id="index-push_002dline_002dor_002dedit"></span></p>
|
||
<p><code>push-line-or-edit</code></p>
|
||
<p>At the top-level (<code>PS1</code>) prompt, equivalent to <code>push-line</code>. At a
|
||
secondary (<code>PS2</code>) prompt, move the entire current multiline construct
|
||
into the editor buffer. The latter is equivalent to <code>push-input</code>
|
||
followed by <code>get-line</code>.</p>
|
||
<p><span id="index-read_002dcommand"></span></p>
|
||
<p><code>read-command</code></p>
|
||
<p>Only useful from a user-defined widget. A keystroke is read just as in
|
||
normal operation, but instead of the command being executed the name of
|
||
the command that would be executed is stored in the shell parameter
|
||
<code>REPLY</code>. This can be used as the argument of a future <code>zle</code> command. If
|
||
the key sequence is not bound, status 1 is returned; typically, however,
|
||
<code>REPLY</code> is set to <code>undefined-key</code> to indicate a useless key sequence.</p>
|
||
<p><span id="index-recursive_002dedit"></span></p>
|
||
<p><code>recursive-edit</code></p>
|
||
<p>Only useful from a user-defined widget. At this point in the function,
|
||
the editor regains control until one of the standard widgets which would
|
||
normally cause zle to exit (typically an <code>accept-line</code> caused by hitting
|
||
the return key) is executed. Instead, control returns to the
|
||
user-defined widget. The status returned is non-zero if the return was
|
||
caused by an error, but the function still continues executing and hence
|
||
may tidy up. This makes it safe for the user-defined widget to alter the
|
||
command line or key bindings temporarily.</p>
|
||
<p>The following widget, <code>caps-lock</code>, serves as an example.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">self-insert-ucase() {
|
||
LBUFFER+=${(U)KEYS[-1]}
|
||
}
|
||
|
||
integer stat
|
||
|
||
zle -N self-insert self-insert-ucase
|
||
zle -A caps-lock save-caps-lock
|
||
zle -A accept-line caps-lock
|
||
|
||
zle recursive-edit
|
||
stat=$?
|
||
|
||
zle -A .self-insert self-insert
|
||
zle -A save-caps-lock caps-lock
|
||
zle -D save-caps-lock
|
||
|
||
(( stat )) && zle send-break
|
||
|
||
return $stat
|
||
</code></pre>
|
||
</div>
|
||
<p>This causes typed letters to be inserted capitalised until either
|
||
<code>accept-line</code> (i.e. typically the return key) is typed or the
|
||
<code>caps-lock</code> widget is invoked again; the later is handled by saving the
|
||
old definition of <code>caps-lock</code> as <code>save-caps-lock</code> and then rebinding it
|
||
to invoke <code>accept-line</code>. Note that an error from the recursive edit is
|
||
detected as a non-zero return status and propagated by using the
|
||
<code>send-break</code> widget.</p>
|
||
<p><span id="index-redisplay"></span></p>
|
||
<p><code>redisplay</code> (unbound) (<code>^R</code>) (<code>^R</code>)</p>
|
||
<p>Redisplays the edit buffer.</p>
|
||
<p><span id="index-reset_002dprompt"></span></p>
|
||
<p><code>reset-prompt</code> (unbound) (unbound) (unbound)</p>
|
||
<p>Force the prompts on both the left and right of the screen to be
|
||
re-expanded, then redisplay the edit buffer. This reflects changes both
|
||
to the prompt variables themselves and changes in the expansion of the
|
||
values (for example, changes in time or directory, or changes to the
|
||
value of variables referred to by the prompt).</p>
|
||
<p>Otherwise, the prompt is only expanded each time zle starts, and when
|
||
the display has been interrupted by output from another part of the
|
||
shell (such as a job notification) which causes the command line to be
|
||
reprinted.</p>
|
||
<p><code>reset-prompt</code> doesn’t alter the special parameter <code>LASTWIDGET</code>.</p>
|
||
<p><span id="index-send_002dbreak"></span></p>
|
||
<p><code>send-break</code> (<code>^G ESC-^G</code>) (unbound) (unbound)</p>
|
||
<p>Abort the current editor function, e.g. <code>execute-named-command</code>, or the
|
||
editor itself, e.g. if you are in <code>vared</code>. Otherwise abort the parsing
|
||
of the current line; in this case the aborted line is available in the
|
||
shell variable <code>ZLE_LINE_ABORTED</code>. If the editor is aborted from within
|
||
<code>vared</code>, the variable <code>ZLE_VARED_ABORTED</code> is set.</p>
|
||
<p><span id="index-run_002dhelp"></span></p>
|
||
<p><code>run-help</code> (<code>ESC-H ESC-h</code>) (unbound) (unbound)</p>
|
||
<p>Push the buffer onto the buffer stack, and execute the command
|
||
‘<code>run-help</code> <code>cmd</code>’, where <code>cmd</code> is the current command. <code>run-help</code> is
|
||
normally aliased to <code>man</code>.</p>
|
||
<p><span id="index-vi_002dset_002dbuffer"></span></p>
|
||
<p><code>vi-set-buffer</code> (unbound) (<code>"</code>) (unbound)</p>
|
||
<p>Specify a buffer to be used in the following command. There are 37
|
||
buffers that can be specified: the 26 ‘named’ buffers <code>"a</code> to <code>"z</code>, the
|
||
‘yank’ buffer <code>"0</code>, the nine ‘queued’ buffers <code>"1</code> to <code>"9</code> and the
|
||
‘black hole’ buffer <code>"_</code>. The named buffers can also be specified as
|
||
<code>"A</code> to <code>"Z</code>.</p>
|
||
<p>When a buffer is specified for a cut, change or yank command, the text
|
||
concerned replaces the previous contents of the specified buffer. If a
|
||
named buffer is specified using a capital, the newly cut text is
|
||
appended to the buffer instead of overwriting it. When using the <code>"_</code>
|
||
buffer, nothing happens. This can be useful for deleting text without
|
||
affecting any buffers.</p>
|
||
<p>If no buffer is specified for a cut or change command, <code>"1</code> is used, and
|
||
the contents of <code>"1</code> to <code>"8</code> are each shifted along one buffer; the
|
||
contents of <code>"9</code> is lost. If no buffer is specified for a yank command,
|
||
<code>"0</code> is used. Finally, a paste command without a specified buffer will
|
||
paste the text from the most recent command regardless of any buffer
|
||
that might have been used with that command.</p>
|
||
<p>When called from a widget function by the <code>zle</code> command, the buffer can
|
||
optionally be specified with an argument. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle vi-set-buffer A
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-vi_002dset_002dmark"></span></p>
|
||
<p><code>vi-set-mark</code> (unbound) (<code>m</code>) (unbound)</p>
|
||
<p>Set the specified mark at the cursor position.</p>
|
||
<p><span id="index-set_002dmark_002dcommand"></span></p>
|
||
<p><code>set-mark-command</code> (<code>^@</code>) (unbound) (unbound)</p>
|
||
<p>Set the mark at the cursor position. If called with a negative numeric
|
||
argument, do not set the mark but deactivate the region so that it is no
|
||
longer highlighted (it is still usable for other purposes). Otherwise
|
||
the region is marked as active.</p>
|
||
<p><span id="index-spell_002dword"></span></p>
|
||
<p><code>spell-word</code> (<code>ESC-$ ESC-S ESC-s</code>) (unbound) (unbound)</p>
|
||
<p>Attempt spelling correction on the current word.</p>
|
||
<p><span id="index-split_002dundo"></span></p>
|
||
<p><code>split-undo</code></p>
|
||
<p>Breaks the undo sequence at the current change. This is useful in vi
|
||
mode as changes made in insert mode are coalesced on entering command
|
||
mode. Similarly, <code>undo</code> will normally revert as one all the changes made
|
||
by a user-defined widget.</p>
|
||
<p><span id="index-undefined_002dkey"></span></p>
|
||
<p><code>undefined-key</code></p>
|
||
<p>This command is executed when a key sequence that is not bound to any
|
||
command is typed. By default it beeps.</p>
|
||
<p><span id="index-undo"></span></p>
|
||
<p><code>undo</code> (<code>^_ ^Xu ^X^U</code>) (<code>u</code>) (unbound)</p>
|
||
<p>Incrementally undo the last text modification. When called from a
|
||
user-defined widget, takes an optional argument indicating a previous
|
||
state of the undo history as returned by the <code>UNDO_CHANGE_NO</code> variable;
|
||
modifications are undone until that state is reached, subject to any
|
||
limit imposed by the <code>UNDO_LIMIT_NO</code> variable.</p>
|
||
<p>Note that when invoked from vi command mode, the full prior change made
|
||
in insert mode is reverted, the changes having been merged when command
|
||
mode was selected.</p>
|
||
<p><span id="index-redo"></span></p>
|
||
<p><code>redo</code> (unbound) (<code>^R</code>) (unbound)</p>
|
||
<p>Incrementally redo undone text modifications.</p>
|
||
<p><span id="index-vi_002dundo_002dchange"></span></p>
|
||
<p><code>vi-undo-change</code> (unbound) (unbound) (unbound)</p>
|
||
<p>Undo the last text modification. If repeated, redo the modification.</p>
|
||
<p><span id="index-visual_002dmode"></span></p>
|
||
<p><code>visual-mode</code> (unbound) (<code>v</code>) (unbound)</p>
|
||
<p>Toggle vim-style visual selection mode. If line-wise visual mode is
|
||
currently enabled then it is changed to being character-wise. If used
|
||
following an operator, it forces the subsequent movement command to be
|
||
treated as a character-wise movement.</p>
|
||
<p><span id="index-visual_002dline_002dmode"></span></p>
|
||
<p><code>visual-line-mode</code> (unbound) (<code>V</code>) (unbound)</p>
|
||
<p>Toggle vim-style line-wise visual selection mode. If character-wise
|
||
visual mode is currently enabled then it is changed to being line-wise.
|
||
If used following an operator, it forces the subsequent movement command
|
||
to be treated as a line-wise movement.</p>
|
||
<p><span id="index-what_002dcursor_002dposition"></span></p>
|
||
<p><code>what-cursor-position</code> (<code>^X=</code>) (<code>ga</code>) (unbound)</p>
|
||
<p>Print the character under the cursor, its code as an octal, decimal and
|
||
hexadecimal number, the current cursor position within the buffer and
|
||
the column of the cursor in the current line.</p>
|
||
<p><span id="index-where_002dis"></span></p>
|
||
<p><code>where-is</code></p>
|
||
<p>Read the name of an editor command and print the listing of key
|
||
sequences that invoke the specified command. A restricted set of editing
|
||
functions is available in the mini-buffer. Keys are looked up in the
|
||
special <code>command</code> keymap, and if not found there in the main keymap.</p>
|
||
<p><span id="index-which_002dcommand"></span></p>
|
||
<p><code>which-command</code> (<code>ESC-?</code>) (unbound) (unbound)</p>
|
||
<p>Push the buffer onto the buffer stack, and execute the command
|
||
‘<code>which-command</code> <code>cmd</code>’. where <code>cmd</code> is the current command.
|
||
<code>which-command</code> is normally aliased to <code>whence</code>.</p>
|
||
<p><span id="index-vi_002ddigit_002dor_002dbeginning_002dof_002dline"></span></p>
|
||
<p><code>vi-digit-or-beginning-of-line</code> (unbound) (<code>0</code>) (unbound)</p>
|
||
<p>If the last command executed was a digit as part of an argument,
|
||
continue the argument. Otherwise, execute vi-beginning-of-line.</p>
|
||
<hr />
|
||
<p><span id="Text-Objects"></span> <span id="Text-Objects-1"></span></p>
|
||
<h3 id="1867-text-objects"><a class="header" href="#1867-text-objects">18.6.7 Text Objects</a></h3>
|
||
<p><span id="index-text-objects"></span></p>
|
||
<p>Text objects are commands that can be used to select a block of text
|
||
according to some criteria. They are a feature of the vim text editor
|
||
and so are primarily intended for use with vi operators or from visual
|
||
selection mode. However, they can also be used from vi-insert or emacs
|
||
mode. Key bindings listed below apply to the <code>viopp</code> and <code>visual</code>
|
||
keymaps.</p>
|
||
<p><span id="index-select_002da_002dblank_002dword"></span></p>
|
||
<p><code>select-a-blank-word</code> (<code>aW</code>)</p>
|
||
<p>Select a word including adjacent blanks, where a word is defined as a
|
||
series of non-blank characters. With a numeric argument, multiple words
|
||
will be selected.</p>
|
||
<p><span id="index-select_002da_002dshell_002dword"></span></p>
|
||
<p><code>select-a-shell-word</code> (<code>aa</code>)</p>
|
||
<p>Select the current command argument applying the normal rules for
|
||
quoting.</p>
|
||
<p><span id="index-select_002da_002dword"></span></p>
|
||
<p><code>select-a-word</code> (<code>aw</code>)</p>
|
||
<p>Select a word including adjacent blanks, using the normal vi-style word
|
||
definition. With a numeric argument, multiple words will be selected.</p>
|
||
<p><span id="index-select_002din_002dblank_002dword"></span></p>
|
||
<p><code>select-in-blank-word</code> (<code>iW</code>)</p>
|
||
<p>Select a word, where a word is defined as a series of non-blank
|
||
characters. With a numeric argument, multiple words will be selected.</p>
|
||
<p><span id="index-select_002din_002dshell_002dword"></span></p>
|
||
<p><code>select-in-shell-word</code> (<code>ia</code>)</p>
|
||
<p>Select the current command argument applying the normal rules for
|
||
quoting. If the argument begins and ends with matching quote characters,
|
||
these are not included in the selection.</p>
|
||
<p><span id="index-select_002din_002dword"></span></p>
|
||
<p><code>select-in-word</code> (<code>iw</code>)</p>
|
||
<p>Select a word, using the normal vi-style word definition. With a numeric
|
||
argument, multiple words will be selected.</p>
|
||
<hr />
|
||
<p><span id="Character-Highlighting"></span>
|
||
<span id="Character-Highlighting-1"></span></p>
|
||
<h2 id="187-character-highlighting"><a class="header" href="#187-character-highlighting">18.7 Character Highlighting</a></h2>
|
||
<p><span id="index-zle_005fhighlight_002c-setting"></span></p>
|
||
<p>The line editor has the ability to highlight characters or regions of
|
||
the line that have a particular significance. This is controlled by the
|
||
array parameter <code>zle_highlight</code>, if it has been set by the user.</p>
|
||
<p>If the parameter contains the single entry <code>none</code> all highlighting is
|
||
turned off. Note the parameter is still expected to be an array.</p>
|
||
<p>Otherwise each entry of the array should consist of a word indicating a
|
||
context for highlighting, then a colon, then a comma-separated list of
|
||
the types of highlighting to apply in that context.</p>
|
||
<p>The contexts available for highlighting are the following:</p>
|
||
<p><span id="index-region_002c-highlighting"></span>
|
||
<span id="index-highlighting_002c-region"></span></p>
|
||
<p><code>default</code></p>
|
||
<p>Any text within the command line not affected by any other highlighting.</p>
|
||
<p><code>isearch</code></p>
|
||
<p>When one of the incremental history search widgets is active, the area
|
||
of the command line matched by the search string or pattern.</p>
|
||
<p><code>region</code></p>
|
||
<p>The currently selected text. In emacs terminology, this is referred to
|
||
as the region and is bounded by the cursor (point) and the mark. The
|
||
region is only highlighted if it is active, which is the case after the
|
||
mark is modified with <code>set-mark-command</code> or <code>exchange-point-and-mark</code>.
|
||
Note that whether or not the region is active has no effect on its use
|
||
within emacs style widgets, it simply determines whether it is
|
||
highlighted. In vi mode, the region corresponds to selected text in
|
||
visual mode.</p>
|
||
<p><span id="index-special-characters_002c-highlighting"></span>
|
||
<span id="index-highlighting_002c-special-characters"></span></p>
|
||
<p><code>special</code></p>
|
||
<p>representation but are shown in a special manner by the line editor.
|
||
These characters are described below.</p>
|
||
<p><span id="index-completion-removable-suffix_002c-highlighting"></span>
|
||
<span id="index-suffix_002c-highlighting-removable_002c-in-completion"></span>
|
||
<span id="index-removable-suffix_002c-highlighting-in-completion"></span></p>
|
||
<p><code>suffix</code></p>
|
||
<p>This context is used in completion for characters that are marked as
|
||
suffixes that will be removed if the completion ends at that point, the
|
||
most obvious example being a slash (<code>/</code>) after a directory name. Note
|
||
that suffix removal is configurable; the circumstances under which the
|
||
suffix will be removed may differ for different completions.</p>
|
||
<p><code>paste</code></p>
|
||
<p>Following a command to paste text, the characters that were inserted.</p>
|
||
<p>When <code>region_highlight</code> is set, the contexts that describe a region —
|
||
<code>isearch</code>, <code>region</code>, <code>suffix</code>, and <code>paste</code> — are applied first, then
|
||
<code>region_highlight</code> is applied, then the remaining <code>zle_highlight</code>
|
||
contexts are applied. If a particular character is affected by multiple
|
||
specifications, the last specification wins.</p>
|
||
<p><code>zle_highlight</code> may contain additional fields for controlling how
|
||
terminal sequences to change colours are output. Each of the following
|
||
is followed by a colon and a string in the same form as for key
|
||
bindings. This will not be necessary for the vast majority of terminals
|
||
as the defaults shown in parentheses are widely used.</p>
|
||
<p><span id="index-escape-sequences_002c-terminal_002c-for-highlighting"></span>
|
||
<span id="index-terminal-escape-sequences-for-highlighting"></span></p>
|
||
<p><code>fg_start_code</code> (<code>\e[3</code>)</p>
|
||
<p>The start of the escape sequence for the foreground colour. This is
|
||
followed by one to three ASCII digits representing the colour. Only used
|
||
for palette colors, i.e. not 24-bit colors specified via a color
|
||
triplet.</p>
|
||
<p><code>fg_default_code</code> (<code>9</code>)</p>
|
||
<p>The number to use instead of the colour to reset the default foreground
|
||
colour.</p>
|
||
<p><code>fg_end_code</code> (<code>m</code>)</p>
|
||
<p>The end of the escape sequence for the foreground colour.</p>
|
||
<p><code>bg_start_code</code> (<code>\e[4</code>)</p>
|
||
<p>The start of the escape sequence for the background colour. See
|
||
<code>fg_start_code</code> above.</p>
|
||
<p><code>bg_default_code</code> (<code>9</code>)</p>
|
||
<p>The number to use instead of the colour to reset the default background
|
||
colour.</p>
|
||
<p><code>bg_end_code</code> (<code>m</code>)</p>
|
||
<p>The end of the escape sequence for the background colour.</p>
|
||
<p>The available types of highlighting are the following. Note that not all
|
||
types of highlighting are available on all terminals:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>none</code><br />
|
||
No highlighting is applied to the given context. It is not useful
|
||
for this to appear with other types of highlighting; it is used to
|
||
override a default.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>fg=``colour</code><br />
|
||
The foreground colour should be set to <code>colour</code>, a decimal integer,
|
||
the name of one of the eight most widely-supported colours or as a
|
||
‘<code>#</code>’ followed by an RGB triplet in hexadecimal format.</p>
|
||
<p>Not all terminals support this and, of those that do, not all
|
||
provide facilities to test the support, hence the user should decide
|
||
based on the terminal type. Most terminals support the colours
|
||
<code>black</code>, <code>red</code>, <code>green</code>, <code>yellow</code>, <code>blue</code>, <code>magenta</code>, <code>cyan</code> and
|
||
<code>white</code>, which can be set by name. In addition. <code>default</code> may be
|
||
used to set the terminal’s default foreground colour. Abbreviations
|
||
are allowed; <code>b</code> or <code>bl</code> selects black. Some terminals may generate
|
||
additional colours if the <code>bold</code> attribute is also present.</p>
|
||
<p>On recent terminals and on systems with an up-to-date terminal
|
||
database the number of colours supported may be tested by the
|
||
command ‘<code>echotc Co</code>’; if this succeeds, it indicates a limit on the
|
||
number of colours which will be enforced by the line editor. The
|
||
number of colours is in any case limited to 256 (i.e. the range 0 to
|
||
255).</p>
|
||
<p>Some modern terminal emulators have support for 24-bit true colour
|
||
(16 million colours). In this case, the hex triplet format can be
|
||
used. This consists of a ‘<code>#</code>’ followed by either a three or six
|
||
digit hexadecimal number describing the red, green and blue
|
||
components of the colour. Hex triplets can also be used with 88 and
|
||
256 colour terminals via the <code>zsh/nearcolor</code> module (see <a href="Zsh-Modules.html#The-zsh_002fnearcolor-Module">The
|
||
zsh/nearcolor
|
||
Module</a>).</p>
|
||
<p>Colour is also known as color.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>bg=``colour</code><br />
|
||
The background colour should be set to <code>colour</code>. This works
|
||
similarly to the foreground colour, except the background is not
|
||
usually affected by the bold attribute.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>bold</code><br />
|
||
The characters in the given context are shown in a bold font. Not
|
||
all terminals distinguish bold fonts.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>standout</code><br />
|
||
The characters in the given context are shown in the terminal’s
|
||
standout mode. The actual effect is specific to the terminal; on
|
||
many terminals it is inverse video. On some such terminals, where
|
||
the cursor does not blink it appears with standout mode negated,
|
||
making it less than clear where the cursor actually is. On such
|
||
terminals one of the other effects may be preferable for
|
||
highlighting the region and matched search string.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>underline</code><br />
|
||
The characters in the given context are shown underlined. Some
|
||
terminals show the foreground in a different colour instead; in this
|
||
case whitespace will not be highlighted.</p>
|
||
</li>
|
||
</ul>
|
||
<p>The characters described above as ‘special’ are as follows. The
|
||
formatting described here is used irrespective of whether the characters
|
||
are highlighted:</p>
|
||
<ul>
|
||
<li>
|
||
<p>ASCII control characters<br />
|
||
Control characters in the ASCII range are shown as ‘<code>^</code>’ followed by
|
||
the base character.</p>
|
||
<p>This item applies to control characters not in the ASCII range, plus
|
||
other characters as follows. If the <code>MULTIBYTE</code> option is in effect,
|
||
multibyte characters not in the ASCII character set that are
|
||
reported as having zero width are treated as combining characters
|
||
when the option <code>COMBINING_CHARS</code> is on. If the option is off, or if
|
||
a character appears where a combining character is not valid, the
|
||
character</p>
|
||
<p>angle brackets. The number is the code point of the character in the
|
||
wide character set; this may or may not be Unicode, depending on the
|
||
operating system.</p>
|
||
</li>
|
||
<li>
|
||
<p>Invalid multibyte characters<br />
|
||
If the <code>MULTIBYTE</code> option is in effect, any sequence of one or more
|
||
bytes that does not form a valid character in the current character
|
||
set is treated as a series of bytes each shown as a special
|
||
character. as the bytes are represented as two hexadecimal digits
|
||
between angle brackets, as distinct from the four or eight digits
|
||
that are used for character set.</p>
|
||
<p>Not all systems support this: for it to work, the system’s
|
||
representation of wide characters must be code values from the
|
||
Universal Character Set, as defined by IS0 10646 (also known as
|
||
Unicode).</p>
|
||
</li>
|
||
<li>
|
||
<p>Wrapped double-width characters<br />
|
||
When a double-width character appears in the final column of a line,
|
||
it is instead shown on the next line. The empty space left in the
|
||
original position is highlighted as a special character.</p>
|
||
</li>
|
||
</ul>
|
||
<p>If <code>zle_highlight</code> is not set or no value applies to a particular
|
||
context, the defaults applied are equivalent to</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle_highlight=(region:standout special:standout
|
||
suffix:bold isearch:underline paste:standout)
|
||
</code></pre>
|
||
</div>
|
||
<p>i.e. both the region and special characters are shown in standout mode.</p>
|
||
<p>Within widgets, arbitrary regions may be highlighted by setting the
|
||
special array parameter <code>region_highlight</code>; see <a href="Zsh-Line-Editor.html#Zle-Widgets">Widgets</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>
|
||
<!-- 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="Completion-Widgets.html#19-completion-widgets">19 Completion Widgets</a>
|
||
<ul>
|
||
<li><a href="Completion-Widgets.html#191-description">19.1 Description</a></li>
|
||
<li><a href="Completion-Widgets.html#192-completion-special-parameters">19.2 Completion Special Parameters</a></li>
|
||
<li><a href="Completion-Widgets.html#193-completion-builtin-commands">19.3 Completion Builtin Commands</a></li>
|
||
<li><a href="Completion-Widgets.html#194-completion-condition-codes">19.4 Completion Condition Codes</a></li>
|
||
<li><a href="Completion-Widgets.html#195-completion-matching-control">19.5 Completion Matching Control</a></li>
|
||
<li><a href="Completion-Widgets.html#196-completion-widget-example">19.6 Completion Widget Example</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Completion-Widgets"></span>
|
||
<span id="Completion-Widgets-1"></span></p>
|
||
<h1 id="19-completion-widgets"><a class="header" href="#19-completion-widgets">19 Completion Widgets</a></h1>
|
||
<p><span id="index-completion_002c-widgets"></span>
|
||
<span id="index-completion_002c-programmable"></span>
|
||
<span id="index-completion_002c-controlling"></span></p>
|
||
<hr />
|
||
<p><span id="Description-1"></span></p>
|
||
<h2 id="191-description"><a class="header" href="#191-description">19.1 Description</a></h2>
|
||
<p>The shell’s programmable completion mechanism can be manipulated in two
|
||
ways; here the low-level features supporting the newer, function-based
|
||
mechanism are defined. A complete set of shell functions based on these
|
||
features is described in the next chapter, <a href="Completion-System.html#Completion-System">Completion
|
||
System</a>, and users with no
|
||
interest in adding to that system (or, potentially, writing their own —
|
||
see dictionary entry for ‘hubris’) should skip the current section. The
|
||
older system based on the <code>compctl</code> builtin command is described in
|
||
<a href="Completion-Using-compctl.html#Completion-Using-compctl">Completion Using
|
||
compctl</a>.</p>
|
||
<p>Completion widgets are defined by the <code>-C</code> option to the <code>zle</code> builtin
|
||
command provided by the <code>zsh/zle</code> module (see <a href="Zsh-Modules.html#The-zsh_002fzle-Module">The zsh/zle
|
||
Module</a>). For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle -C complete expand-or-complete completer
|
||
</code></pre>
|
||
</div>
|
||
<p>defines a widget named ‘<code>complete</code>’. The second argument is the name of
|
||
any of the builtin widgets that handle completions: <code>complete-word</code>,
|
||
<code>expand-or-complete</code>, <code>expand-or-complete-prefix</code>, <code>menu-complete</code>,
|
||
<code>menu-expand-or-complete</code>, <code>reverse-menu-complete</code>, <code>list-choices</code>, or
|
||
<code>delete-char-or-list</code>. Note that this will still work even if the widget
|
||
in question has been re-bound.</p>
|
||
<p>When this newly defined widget is bound to a key using the <code>bindkey</code>
|
||
builtin command defined in the <code>zsh/zle</code> module (<a href="Zsh-Line-Editor.html#Zsh-Line-Editor">Zsh Line
|
||
Editor</a>), typing that key will
|
||
call the shell function ‘<code>completer</code>’. This function is responsible for
|
||
generating the possible matches using the builtins described below. As
|
||
with other ZLE widgets, the function is called with its standard input
|
||
closed.</p>
|
||
<p>Once the function returns, the completion code takes over control again
|
||
and treats the matches in the same manner as the specified builtin
|
||
widget, in this case <code>expand-or-complete</code>.</p>
|
||
<hr />
|
||
<p><span id="Completion-Special-Parameters"></span>
|
||
<span id="Completion-Special-Parameters-1"></span></p>
|
||
<h2 id="192-completion-special-parameters"><a class="header" href="#192-completion-special-parameters">19.2 Completion Special Parameters</a></h2>
|
||
<p>The parameters <code>ZLE_REMOVE_SUFFIX_CHARS</code> and <code>ZLE_SPACE_SUFFIX_CHARS</code>
|
||
are used by the completion mechanism, but are not special. See
|
||
<a href="Parameters.html#Parameters-Used-By-The-Shell">Parameters Used By The
|
||
Shell</a>.</p>
|
||
<p>Inside completion widgets, and any functions called from them, some
|
||
parameters have special meaning; outside these functions they are not
|
||
special to the shell in any way. These parameters are used to pass
|
||
information between the completion code and the completion widget. Some
|
||
of the builtin commands and the condition codes use or change the
|
||
current values of these parameters. Any existing values will be hidden
|
||
during execution of completion widgets; except for <code>compstate</code>, the
|
||
parameters are reset on each function exit (including nested function
|
||
calls from within the completion widget) to the values they had when the
|
||
function was entered.</p>
|
||
<p><span id="index-CURRENT"></span></p>
|
||
<p><code>CURRENT</code></p>
|
||
<p>This is the number of the current word, i.e. the word the cursor is
|
||
currently on in the <code>words</code> array. Note that this value is only correct
|
||
if the <code>ksharrays</code> option is not set.</p>
|
||
<p><span id="index-IPREFIX"></span></p>
|
||
<p><code>IPREFIX</code></p>
|
||
<p>Initially this will be set to the empty string. This parameter functions
|
||
like <code>PREFIX</code>; it contains a string which precedes the one in <code>PREFIX</code>
|
||
and is not considered part of the list of matches. Typically, a string
|
||
is transferred from the beginning of <code>PREFIX</code> to the end of <code>IPREFIX</code>,
|
||
for example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">IPREFIX=${PREFIX%%\=*}=
|
||
PREFIX=${PREFIX#*=}
|
||
</code></pre>
|
||
</div>
|
||
<p>causes the part of the prefix up to and including the first equal sign
|
||
not to be treated as part of a matched string. This can be done
|
||
automatically by the <code>compset</code> builtin, see below.</p>
|
||
<p><span id="index-ISUFFIX"></span></p>
|
||
<p><code>ISUFFIX</code></p>
|
||
<p>As <code>IPREFIX</code>, but for a suffix that should not be considered part of the
|
||
matches; note that the <code>ISUFFIX</code> string follows the <code>SUFFIX</code> string.</p>
|
||
<p><span id="index-PREFIX"></span></p>
|
||
<p><code>PREFIX</code></p>
|
||
<p>Initially this will be set to the part of the current word from the
|
||
beginning of the word up to the position of the cursor; it may be
|
||
altered to give a common prefix for all matches.</p>
|
||
<p><span id="index-QIPREFIX"></span></p>
|
||
<p><code>QIPREFIX</code></p>
|
||
<p>This parameter is read-only and contains the quoted string up to the
|
||
word being completed. E.g. when completing ‘<code>"foo</code>’, this parameter
|
||
contains the double quote. If the <code>-q</code> option of <code>compset</code> is used (see
|
||
below), and the original string was ‘<code>"foo bar</code>’ with the cursor on the
|
||
‘<code>bar</code>’, this parameter contains ‘<code>"foo </code>’.</p>
|
||
<p><span id="index-QISUFFIX"></span></p>
|
||
<p><code>QISUFFIX</code></p>
|
||
<p>Like <code>QIPREFIX</code>, but containing the suffix.</p>
|
||
<p><span id="index-SUFFIX"></span></p>
|
||
<p><code>SUFFIX</code></p>
|
||
<p>Initially this will be set to the part of the current word from the
|
||
cursor position to the end; it may be altered to give a common suffix
|
||
for all matches. It is most useful when the option <code>COMPLETE_IN_WORD</code> is
|
||
set, as otherwise the whole word on the command line is treated as a
|
||
prefix.</p>
|
||
<p><span id="index-compstate"></span>
|
||
<span id="index-completion-widgets_002c-examining-and-setting-state-in"></span></p>
|
||
<p><code>compstate</code></p>
|
||
<p>This is an associative array with various keys and values that the
|
||
completion code uses to exchange information with the completion widget.
|
||
The keys are:</p>
|
||
<p><span id="index-all_005fquotes_002c-compstate"></span></p>
|
||
<p><code>all_quotes</code></p>
|
||
<p>The <code>-q</code> option of the <code>compset</code> builtin command (see below) allows a
|
||
quoted string to be broken into separate words; if the cursor is on one
|
||
of those words, that word will be completed, possibly invoking ‘<code>compset -q</code>’ recursively. With this key it is possible to test the types of
|
||
quoted strings which are currently broken into parts in this fashion.
|
||
Its value contains one character for each quoting level. The characters
|
||
are a single quote or a double quote for strings quoted with these
|
||
characters, a dollars sign for strings quoted with <code>$’``...``’</code> and a
|
||
backslash for strings not starting with a quote character. The first
|
||
character in the value always corresponds to the innermost quoting
|
||
level.</p>
|
||
<p><span id="index-context_002c-compstate"></span></p>
|
||
<p><code>context</code></p>
|
||
<p>This will be set by the completion code to the overall context in which
|
||
completion is attempted. Possible values are:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>array_value</code><br />
|
||
when completing inside the value of an array parameter assignment;
|
||
in this case the <code>words</code> array contains the words inside the
|
||
parentheses.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>brace_parameter</code><br />
|
||
when completing the name of a parameter in a parameter expansion
|
||
beginning with <code>${</code>. This context will also be set when completing
|
||
parameter flags following <code>${(</code>; the full command line argument is
|
||
presented and the handler must test the value to be completed to
|
||
ascertain that this is the case.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>assign_parameter</code><br />
|
||
when completing the name of a parameter in a parameter assignment.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>command</code><br />
|
||
when completing for a normal command (either in command position or
|
||
for an argument of the command).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>condition</code><br />
|
||
when completing inside a ‘<code>[[</code>...<code>]]</code>’ conditional expression; in
|
||
this case the <code>words</code> array contains only the words inside the
|
||
conditional expression.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>math</code><br />
|
||
when completing in a mathematical environment such as a
|
||
‘<code>((</code>...<code>))</code>’ construct.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>parameter</code><br />
|
||
when completing the name of a parameter in a parameter expansion
|
||
beginning with <code>$</code> but not <code>${</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>redirect</code><br />
|
||
when completing after a redirection operator.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>subscript</code><br />
|
||
when completing inside a parameter subscript.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>value</code><br />
|
||
when completing the value of a parameter assignment.</p>
|
||
</li>
|
||
</ul>
|
||
<p><span id="index-exact_002c-compstate"></span></p>
|
||
<p><code>exact</code></p>
|
||
<p>Controls the behaviour when the <code>REC_EXACT</code> option is set. It will be
|
||
set to <code>accept</code> if an exact match would be accepted, and will be unset
|
||
otherwise.</p>
|
||
<p>If it was set when at least one match equal to the string on the line
|
||
was generated, the match is accepted.</p>
|
||
<p><span id="index-exact_005fstring_002c-compstate"></span></p>
|
||
<p><code>exact_string</code></p>
|
||
<p>The string of an exact match if one was found, otherwise unset.</p>
|
||
<p><span id="index-ignored_002c-compstate"></span></p>
|
||
<p><code>ignored</code></p>
|
||
<p>The number of words that were ignored because they matched one of the
|
||
patterns given with the <code>-F</code> option to the <code>compadd</code> builtin command.</p>
|
||
<p><span id="index-insert_002c-compstate"></span></p>
|
||
<p><code>insert</code></p>
|
||
<p>This controls the manner in which a match is inserted into the command
|
||
line. On entry to the widget function, if it is unset the command line
|
||
is not to be changed; if set to <code>unambiguous</code>, any prefix common to all
|
||
matches is to be inserted; if set to <code>automenu-unambiguous</code>, the common
|
||
prefix is to be inserted and the next invocation of the completion code
|
||
may start menu completion (due to the <code>AUTO_MENU</code> option being set); if
|
||
set to <code>menu</code> or <code>automenu</code> menu completion will be started for the
|
||
matches currently generated (in the latter case this will happen because
|
||
the <code>AUTO_MENU</code> is set). The value may also contain the string ‘<code>tab</code>’
|
||
when the completion code would normally not really do completion, but
|
||
only insert the TAB character.</p>
|
||
<p>On exit it may be set to any of the values above (where setting it to
|
||
the empty string is the same as unsetting it), or to a number, in which
|
||
case the match whose number is given will be inserted into the command
|
||
line. Negative numbers count backward from the last match (with ‘<code>-1</code>’
|
||
selecting the last match) and out-of-range values are wrapped around, so
|
||
that a value of zero selects the last match and a value one more than
|
||
the maximum selects the first. Unless the value of this key ends in a
|
||
space, the match is inserted as in a menu completion, i.e. without
|
||
automatically appending a space.</p>
|
||
<p>Both <code>menu</code> and <code>automenu</code> may also specify the number of the match to
|
||
insert, given after a colon. For example, ‘<code>menu:2</code>’ says to start menu
|
||
completion, beginning with the second match.</p>
|
||
<p>Note that a value containing the substring ‘<code>tab</code>’ makes the matches
|
||
generated be ignored and only the TAB be inserted.</p>
|
||
<p>Finally, it may also be set to <code>all</code>, which makes all matches generated
|
||
be inserted into the line.</p>
|
||
<p><span id="index-insert_005fpositions_002c-compstate"></span></p>
|
||
<p><code>insert_positions</code></p>
|
||
<p>When the completion system inserts an unambiguous string into the line,
|
||
there may be multiple places where characters are missing or where the
|
||
character inserted differs from at least one match. The value of this
|
||
key contains a colon separated list of all these positions, as indexes
|
||
into the command line.</p>
|
||
<p><span id="index-last_005fprompt_002c-compstate"></span></p>
|
||
<p><code>last_prompt</code></p>
|
||
<p>If this is set to a non-empty string for every match added, the
|
||
completion code will move the cursor back to the previous prompt after
|
||
the list of completions has been displayed. Initially this is set or
|
||
unset according to the <code>ALWAYS_LAST_PROMPT</code> option.</p>
|
||
<p><span id="index-list_002c-compstate"></span></p>
|
||
<p><code>list</code></p>
|
||
<p>This controls whether or how the list of matches will be displayed. If
|
||
it is unset or empty they will never be listed; if its value begins with
|
||
<code>list</code>, they will always be listed; if it begins with <code>autolist</code> or
|
||
<code>ambiguous</code>, they will be listed when the <code>AUTO_LIST</code> or
|
||
<code>LIST_AMBIGUOUS</code> options respectively would normally cause them to be.</p>
|
||
<p>If the substring <code>force</code> appears in the value, this makes the list be
|
||
shown even if there is only one match. Normally, the list would be shown
|
||
only if there are at least two matches.</p>
|
||
<p>The value contains the substring <code>packed</code> if the <code>LIST_PACKED</code> option is
|
||
set. If this substring is given for all matches added to a group, this
|
||
group will show the <code>LIST_PACKED</code> behavior. The same is done for the
|
||
<code>LIST_ROWS_FIRST</code> option with the substring <code>rows</code>.</p>
|
||
<p>Finally, if the value contains the string <code>explanations</code>, only the
|
||
explanation strings, if any, will be listed and if it contains
|
||
<code>messages</code>, only the messages (added with the <code>-x</code> option of <code>compadd</code>)
|
||
will be listed. If it contains both <code>explanations</code> and <code>messages</code> both
|
||
kinds of explanation strings will be listed. It will be set
|
||
appropriately on entry to a completion widget and may be changed there.</p>
|
||
<p><span id="index-list_005flines_002c-compstate"></span></p>
|
||
<p><code>list_lines</code></p>
|
||
<p>This gives the number of lines that are needed to display the full list
|
||
of completions. Note that to calculate the total number of lines to
|
||
display you need to add the number of lines needed for the command line
|
||
to this value, this is available as the value of the <code>BUFFERLINES</code>
|
||
special parameter.</p>
|
||
<p><span id="index-list_005fmax_002c-compstate"></span></p>
|
||
<p><code>list_max</code></p>
|
||
<p>Initially this is set to the value of the <code>LISTMAX</code> parameter. It may be
|
||
set to any other value; when the widget exits this value will be used in
|
||
the same way as the value of <code>LISTMAX</code>.</p>
|
||
<p><span id="index-nmatches_002c-compstate"></span></p>
|
||
<p><code>nmatches</code></p>
|
||
<p>The number of matches generated and accepted by the completion code so
|
||
far.</p>
|
||
<p><span id="index-old_005finsert_002c-compstate"></span></p>
|
||
<p><code>old_insert</code></p>
|
||
<p>On entry to the widget this will be set to the number of the match of an
|
||
old list of completions that is currently inserted into the command
|
||
line. If no match has been inserted, this is unset.</p>
|
||
<p>As with <code>old_list</code>, the value of this key will only be used if it is the
|
||
string <code>keep</code>. If it was set to this value by the widget and there was
|
||
an old match inserted into the command line, this match will be kept and
|
||
if the value of the <code>insert</code> key specifies that another match should be
|
||
inserted, this will be inserted after the old one.</p>
|
||
<p><span id="index-old_005flist_002c-compstate"></span></p>
|
||
<p><code>old_list</code></p>
|
||
<p>This is set to <code>yes</code> if there is still a valid list of completions from
|
||
a previous completion at the time the widget is invoked. This will
|
||
usually be the case if and only if the previous editing operation was a
|
||
completion widget or one of the builtin completion functions. If there
|
||
is a valid list and it is also currently shown on the screen, the value
|
||
of this key is <code>shown</code>.</p>
|
||
<p>After the widget has exited the value of this key is only used if it was
|
||
set to <code>keep</code>. In this case the completion code will continue to use
|
||
this old list. If the widget generated new matches, they will not be
|
||
used.</p>
|
||
<p><span id="index-parameter_002c-compstate"></span></p>
|
||
<p><code>parameter</code></p>
|
||
<p>The name of the parameter when completing in a subscript or in the value
|
||
of a parameter assignment.</p>
|
||
<p><span id="index-pattern_005finsert_002c-compstate"></span></p>
|
||
<p><code>pattern_insert</code></p>
|
||
<p>Normally this is set to <code>menu</code>, which specifies that menu completion
|
||
will be used whenever a set of matches was generated using pattern
|
||
matching. If it is set to any other non-empty string by the user and
|
||
menu completion is not selected by other option settings, the code will
|
||
instead insert any common prefix for the generated matches as with
|
||
normal completion.</p>
|
||
<p><span id="index-pattern_005fmatch_002c-compstate"></span></p>
|
||
<p><code>pattern_match</code></p>
|
||
<p>Locally controls the behaviour given by the <code>GLOB_COMPLETE</code> option.
|
||
Initially it is set to ‘<code>*</code>’ if and only if the option is set. The
|
||
completion widget may set it to this value, to an empty string (which
|
||
has the same effect as unsetting it), or to any other non-empty string.
|
||
If it is non-empty, unquoted metacharacters on the command line will be
|
||
treated as patterns; if it is ‘<code>*</code>’, then additionally a wildcard ‘<code>*</code>’
|
||
is assumed at the cursor position; if it is empty or unset,
|
||
metacharacters will be treated literally.</p>
|
||
<p>Note that the matcher specifications given to the <code>compadd</code> builtin
|
||
command are not used if this is set to a non-empty string.</p>
|
||
<p><span id="index-quote_002c-compstate"></span></p>
|
||
<p><code>quote</code></p>
|
||
<p>When completing inside quotes, this contains the quotation character
|
||
(i.e. either a single quote, a double quote, or a backtick). Otherwise
|
||
it is unset.</p>
|
||
<p><span id="index-quoting_002c-compstate"></span></p>
|
||
<p><code>quoting</code></p>
|
||
<p>When completing inside single quotes, this is set to the string
|
||
<code>single</code>; inside double quotes, the string <code>double</code>; inside backticks,
|
||
the string <code>backtick</code>. Otherwise it is unset.</p>
|
||
<p><span id="index-redirect_002c-compstate"></span></p>
|
||
<p><code>redirect</code></p>
|
||
<p>The redirection operator when completing in a redirection position, i.e.
|
||
one of <code><</code>, <code>></code>, etc.</p>
|
||
<p><span id="index-restore_002c-compstate"></span></p>
|
||
<p><code>restore</code></p>
|
||
<p>This is set to <code>auto</code> before a function is entered, which forces the
|
||
special parameters mentioned above (<code>words</code>, <code>CURRENT</code>, <code>PREFIX</code>,
|
||
<code>IPREFIX</code>, <code>SUFFIX</code>, and <code>ISUFFIX</code>) to be restored to their previous
|
||
values when the function exits. If a function unsets it or sets it to
|
||
any other string, they will not be restored.</p>
|
||
<p><span id="index-to_005fend_002c-compstate"></span></p>
|
||
<p><code>to_end</code></p>
|
||
<p>Specifies the occasions on which the cursor is moved to the end of a
|
||
string when a match is inserted. On entry to a widget function, it may
|
||
be <code>single</code> if this will happen when a single unambiguous match was
|
||
inserted or <code>match</code> if it will happen any time a match is inserted (for
|
||
example, by menu completion; this is likely to be the effect of the
|
||
<code>ALWAYS_TO_END</code> option).</p>
|
||
<p>On exit, it may be set to <code>single</code> as above. It may also be set to
|
||
<code>always</code>, or to the empty string or unset; in those cases the cursor
|
||
will be moved to the end of the string always or never respectively. Any
|
||
other string is treated as <code>match</code>.</p>
|
||
<p><span id="index-unambiguous_002c-compstate"></span></p>
|
||
<p><code>unambiguous</code></p>
|
||
<p>This key is read-only and will always be set to the common (unambiguous)
|
||
prefix the completion code has generated for all matches added so far.</p>
|
||
<p><span id="index-unambiguous_005fcursor_002c-compstate"></span></p>
|
||
<p><code>unambiguous_cursor</code></p>
|
||
<p>This gives the position the cursor would be placed at if the common
|
||
prefix in the <code>unambiguous</code> key were inserted, relative to the value of
|
||
that key. The cursor would be placed before the character whose index is
|
||
given by this key.</p>
|
||
<p><span id="index-unambiguous_005fpositions_002c-compstate"></span></p>
|
||
<p><code>unambiguous_positions</code></p>
|
||
<p>This contains all positions where characters in the unambiguous string
|
||
are missing or where the character inserted differs from at least one of
|
||
the matches. The positions are given as indexes into the string given by
|
||
the value of the <code>unambiguous</code> key.</p>
|
||
<p><span id="index-vared_002c-compstate"></span></p>
|
||
<p><code>vared</code></p>
|
||
<p>If completion is called while editing a line using the <code>vared</code> builtin,
|
||
the value of this key is set to the name of the parameter given as an
|
||
argument to <code>vared</code>. This key is only set while a <code>vared</code> command is
|
||
active.</p>
|
||
<p><span id="index-words"></span></p>
|
||
<p><code>words</code></p>
|
||
<p>This array contains the words present on the command line currently
|
||
being edited.</p>
|
||
<hr />
|
||
<p><span id="Completion-Builtin-Commands"></span>
|
||
<span id="Completion-Builtin-Commands-1"></span></p>
|
||
<h2 id="193-completion-builtin-commands"><a class="header" href="#193-completion-builtin-commands">19.3 Completion Builtin Commands</a></h2>
|
||
<p><span id="index-compadd"></span>
|
||
<span id="index-completion-widgets_002c-adding-specified-matches"></span></p>
|
||
<p><code>compadd </code>[ <code>-akqQfenUl12C</code> ] [ <code>-F</code> <code>array</code> ]</p>
|
||
<p><code> </code>[<code>-P</code> <code>prefix</code> ] [ <code>-S</code> <code>suffix</code> ]</p>
|
||
<p><code> </code>[<code>-p</code> <code>hidden-prefix</code> ] [ <code>-s</code> <code>hidden-suffix</code> ]</p>
|
||
<p><code> </code>[<code>-i</code> <code>ignored-prefix</code> ] [ <code>-I</code> <code>ignored-suffix</code> ]</p>
|
||
<p><code> </code>[<code>-W</code> <code>file-prefix</code> ] [ <code>-d</code> <code>array</code> ]</p>
|
||
<p><code> </code>[<code>-J</code> <code>group-name</code> ] [ <code>-X</code> <code>explanation</code> ] [ <code>-x</code>
|
||
<code>message</code> ]</p>
|
||
<p><code> </code>[<code>-V</code> <code>group-name</code> ] [ <code>-o</code> [ <code>order</code> ] ]</p>
|
||
<p><code> </code>[<code>-r</code> <code>remove-chars</code> ] [ <code>-R</code> <code>remove-func</code> ]</p>
|
||
<p><code> </code>[<code>-D</code> <code>array</code> ] [ <code>-O</code> <code>array</code> ] [ <code>-A</code> <code>array</code> ]</p>
|
||
<p><code> </code>[<code>-E</code> <code>number</code> ]</p>
|
||
<p><code> </code>[<code>-M</code> <code>match-spec</code> ] [ <code>-``-</code> ] [ <code>words</code> ... ]</p>
|
||
<p>This builtin command can be used to add matches directly and control all
|
||
the information the completion code stores with each possible match. The
|
||
return status is zero if at least one match was added and non-zero if no
|
||
matches were added.</p>
|
||
<p>The completion code breaks the string to complete into seven fields in
|
||
the order:</p>
|
||
<blockquote>
|
||
<p><code><ipre><apre><hpre><word><hsuf><asuf><isuf></code></p>
|
||
</blockquote>
|
||
<p>The first field is an ignored prefix taken from the command line, the
|
||
contents of the <code>IPREFIX</code> parameter plus the string given with the <code>-i</code>
|
||
option. With the <code>-U</code> option, only the string from the <code>-i</code> option is
|
||
used. The field <code><apre></code> is an optional prefix string given with the
|
||
<code>-P</code> option. The <code><hpre></code> field is a string that is considered part of
|
||
the match but that should not be shown when listing completions, given
|
||
with the <code>-p</code> option; for example, functions that do filename generation
|
||
might specify a common path prefix this way. <code><word></code> is the part of the
|
||
match that should appear in the list of completions, i.e. one of the
|
||
<code>words</code> given at the end of the <code>compadd</code> command line. The suffixes
|
||
<code><hsuf></code>, <code><asuf></code> and <code><isuf></code> correspond to the prefixes <code><hpre></code>,
|
||
<code><apre></code> and <code><ipre></code> and are given by the options <code>-s</code>, <code>-S</code> and <code>-I</code>,
|
||
respectively.</p>
|
||
<p>The supported flags are:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-P</code> <code>prefix</code><br />
|
||
This gives a string to be inserted before the given <code>words</code>. The
|
||
string given is not considered as part of the match and any shell
|
||
metacharacters in it will not be quoted when the string is inserted.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-S</code> <code>suffix</code><br />
|
||
Like <code>-P</code>, but gives a string to be inserted after the match.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-p</code> <code>hidden-prefix</code><br />
|
||
This gives a string that should be inserted into the command line
|
||
before the match but that should not appear in the list of matches.
|
||
Unless the <code>-U</code> option is given, this string must be matched as part
|
||
of the string on the command line.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-s</code> <code>hidden-suffix</code><br />
|
||
Like ‘<code>-p</code>’, but gives a string to insert after the match.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-i</code> <code>ignored-prefix</code><br />
|
||
This gives a string to insert into the command line just before any
|
||
string given with the ‘<code>-P</code>’ option. Without ‘<code>-P</code>’ the string is
|
||
inserted before the string given with ‘<code>-p</code>’ or directly before the
|
||
match.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-I</code> <code>ignored-suffix</code><br />
|
||
Like <code>-i</code>, but gives an ignored suffix.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-a</code><br />
|
||
With this flag the <code>words</code> are taken as names of arrays and the
|
||
possible matches are their values. If only some elements of the
|
||
arrays are needed, the <code>words</code> may also contain subscripts, as in
|
||
‘<code>foo[2,-1]</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-k</code><br />
|
||
With this flag the <code>words</code> are taken as names of associative arrays
|
||
and the possible matches are their keys. As for <code>-a</code>, the <code>words</code>
|
||
may also contain subscripts, as in ‘<code>foo[(R)*bar*]</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-d</code> <code>array</code><br />
|
||
This adds per-match display strings. The <code>array</code> should contain one
|
||
element per <code>word</code> given. The completion code will then display the
|
||
first element instead of the first <code>word</code>, and so on. The <code>array</code>
|
||
may be given as the name of an array parameter or directly as a
|
||
space-separated list of words in parentheses.</p>
|
||
<p>If there are fewer display strings than <code>words</code>, the leftover
|
||
<code>words</code> will be displayed unchanged and if there are more display
|
||
strings than <code>words</code>, the leftover display strings will be silently
|
||
ignored.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-l</code><br />
|
||
This option only has an effect if used together with the <code>-d</code>
|
||
option. If it is given, the display strings are listed one per line,
|
||
not arrayed in columns.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-o</code> [ <code>order</code> ]<br />
|
||
This controls the order in which matches are sorted. <code>order</code> is a
|
||
comma-separated list comprising the following possible values. These
|
||
values can be abbreviated to their initial two or three characters.
|
||
Note that the order forms part of the group name space so matches
|
||
with different orderings will not be in the same group.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>match</code><br />
|
||
If given, the order of the output is determined by the match
|
||
strings; otherwise it is determined by the display strings (i.e.
|
||
the strings given by the <code>-d</code> option). This is the default if
|
||
‘<code>-o</code>’ is specified but the <code>order</code> argument is omitted.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>nosort</code><br />
|
||
This specifies that the matches are pre-sorted and their order
|
||
should be preserved. This value only makes sense alone and
|
||
cannot be combined with any others.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>numeric</code><br />
|
||
If the matches include numbers, sort them numerically rather
|
||
than lexicographically.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>reverse</code><br />
|
||
Arrange the matches backwards by reversing the sort ordering.</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p><code>-J</code> <code>group-name</code><br />
|
||
Gives the name of the group of matches the words should be stored
|
||
in.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-V</code> <code>group-name</code><br />
|
||
Like <code>-J</code> but naming an unsorted group. This option is identical to
|
||
the combination of <code>-J</code> and <code>-o nosort</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-1</code><br />
|
||
If given together with the <code>-V</code> option, makes only consecutive
|
||
duplicates in the group be removed. If combined with the <code>-J</code>
|
||
option, this has no visible effect. Note that groups with and
|
||
without this flag are in different name spaces.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-2</code><br />
|
||
If given together with the <code>-J</code> or <code>-V</code> option, makes all duplicates
|
||
be kept. Again, groups with and without this flag are in different
|
||
name spaces.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-X</code> <code>explanation</code><br />
|
||
The <code>explanation</code> string will be printed with the list of matches,
|
||
above the group currently selected.</p>
|
||
<p>Within the <code>explanation</code>, the following sequences may be used to
|
||
specify output attributes (see <a href="Prompt-Expansion.html#Prompt-Expansion">Prompt
|
||
Expansion</a>): ‘<code>%B</code>’, ‘<code>%S</code>’,
|
||
‘<code>%U</code>’, ‘<code>%F</code>’, ‘<code>%K</code>’ and their lower case counterparts, as well as
|
||
‘<code>%{</code>...<code>%}</code>’. ‘<code>%F</code>’, ‘<code>%K</code>’ and ‘<code>%{</code>...<code>%}</code>’ take arguments in
|
||
the same form as prompt expansion. (Note that the sequence ‘<code>%G</code>’ is
|
||
not available; an argument to ‘<code>%{</code>’ should be used instead.) The
|
||
sequence ‘<code>%%</code>’ produces a literal ‘<code>%</code>’.</p>
|
||
<p>These sequences are most often employed by users when customising
|
||
the <code>format</code> style (see <a href="Completion-System.html#Completion-System">Completion
|
||
System</a>), but they must
|
||
also be taken into account when writing completion functions, as
|
||
passing descriptions with unescaped ‘<code>%</code>’ characters to utility
|
||
functions such as <code>_arguments</code> and <code>_message</code> may produce unexpected
|
||
results. If arbitrary text is to be passed in a description, it can
|
||
be escaped using e.g. <code>${my_str//\%/%%}</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-x</code> <code>message</code><br />
|
||
Like <code>-X</code>, but the <code>message</code> will be printed even if there are no
|
||
matches in the group.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-q</code><br />
|
||
The suffix given with <code>-S</code> will be automatically removed if the next
|
||
character typed is a blank or does not insert anything, or if the
|
||
suffix consists of only one character and the next character typed
|
||
is the same character.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-r</code> <code>remove-chars</code><br />
|
||
This is a more versatile form of the <code>-q</code> option. The suffix given
|
||
with <code>-S</code> or the slash automatically added after completing
|
||
directories will be automatically removed if the next character
|
||
typed inserts one of the characters given in the <code>remove-chars</code>.
|
||
This string is parsed as a characters class and understands the
|
||
backslash sequences used by the <code>print</code> command. For example, ‘<code>-r "a-z\t"</code>’ removes the suffix if the next character typed inserts a
|
||
lower case character or a TAB, and ‘<code>-r "^0-9"</code>’ removes the suffix
|
||
if the next character typed inserts anything but a digit. One extra
|
||
backslash sequence is understood in this string: ‘<code>\-</code>’ stands for
|
||
all characters that insert nothing. Thus ‘<code>-S "=" -q</code>’ is the same
|
||
as ‘<code>-S "=" -r "= \t\n\-"</code>’.</p>
|
||
<p>This option may also be used without the <code>-S</code> option; then any
|
||
automatically added space will be removed when one of the characters
|
||
in the list is typed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-R</code> <code>remove-func</code><br />
|
||
This is another form of the <code>-r</code> option. When a suffix has been
|
||
inserted and the completion accepted, the function <code>remove-func</code>
|
||
will be called after the next character typed. It is passed the
|
||
length of the suffix as an argument and can use the special
|
||
parameters available in ordinary (non-completion) zle widgets (see
|
||
<a href="Zsh-Line-Editor.html#Zsh-Line-Editor">Zsh Line Editor</a>) to analyse
|
||
and modify the command line.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-f</code><br />
|
||
If this flag is given, all of the matches built from <code>words</code> are
|
||
marked as being the names of files. They are not required to be
|
||
actual filenames, but if they are, and the option <code>LIST_TYPES</code> is
|
||
set, the characters describing the types of the files in the
|
||
completion lists will be shown. This also forces a slash to be added
|
||
when the name of a directory is completed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-e</code><br />
|
||
This flag can be used to tell the completion code that the matches
|
||
added are parameter names for a parameter expansion. This will make
|
||
the <code>AUTO_PARAM_SLASH</code> and <code>AUTO_PARAM_KEYS</code> options be used for the
|
||
matches.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-W</code> <code>file-prefix</code><br />
|
||
This string is a pathname that will be prepended to each of the
|
||
matches formed by the given <code>words</code> together with any prefix
|
||
specified by the <code>-p</code> option to form a complete filename for
|
||
testing. Hence it is only useful if combined with the <code>-f</code> flag, as
|
||
the tests will not otherwise be performed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-F</code> <code>array</code><br />
|
||
Specifies an array containing patterns. Words matching one of these
|
||
patterns are ignored, i.e. not considered to be possible matches.</p>
|
||
<p>The <code>array</code> may be the name of an array parameter or a list of
|
||
literal patterns enclosed in parentheses and quoted, as in ‘<code>-F "(*?.o *?.h)"</code>’. If the name of an array is given, the elements of
|
||
the array are taken as the patterns.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-Q</code><br />
|
||
This flag instructs the completion code not to quote any
|
||
metacharacters in the words when inserting them into the command
|
||
line.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-M</code> <code>match-spec</code><br />
|
||
This gives local match specifications as described below in
|
||
<a href="Completion-Widgets.html#Completion-Matching-Control">Completion Matching Control</a>. This
|
||
option may be given more than once. In this case all <code>match-spec</code>s
|
||
given are concatenated with spaces between them to form the
|
||
specification string to use. Note that they will only be used if the
|
||
<code>-U</code> option is not given.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-n</code><br />
|
||
Specifies that the words added are to be used as possible matches,
|
||
but are not to appear in the completion listing.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-U</code><br />
|
||
If this flag is given, all words given will be accepted and no
|
||
matching will be done by the completion code. Normally this is used
|
||
in functions that do the matching themselves.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-O</code> <code>array</code><br />
|
||
If this option is given, the <code>words</code> are <em>not</em> added to the set of
|
||
possible completions. Instead, matching is done as usual and all of
|
||
the <code>words</code> given as arguments that match the string on the command
|
||
line will be stored in the array parameter whose name is given as
|
||
<code>array</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-A</code> <code>array</code><br />
|
||
As the <code>-O</code> option, except that instead of those of the <code>words</code>
|
||
which match being stored in <code>array</code>, the strings generated
|
||
internally by the completion code are stored. For example, with a
|
||
matching specification of ‘<code>-M "L:|no="</code>’, the string ‘<code>nof</code>’ on the
|
||
command line and the string ‘<code>foo</code>’ as one of the <code>words</code>, this
|
||
option stores the string ‘<code>nofoo</code>’ in the array, whereas the <code>-O</code>
|
||
option stores the ‘<code>foo</code>’ originally given.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-D</code> <code>array</code><br />
|
||
As with <code>-O</code>, the <code>words</code> are not added to the set of possible
|
||
completions. Instead, the completion code tests whether each <code>word</code>
|
||
in turn matches what is on the line. If the <code>n</code>th <code>word</code> does not
|
||
match, the <code>n</code>th element of the <code>array</code> is removed. Elements for
|
||
which the corresponding <code>word</code> is matched are retained.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-C</code><br />
|
||
This option adds a special match which expands to all other matches
|
||
when inserted into the line, even those that are added after this
|
||
option is used. Together with the <code>-d</code> option it is possible to
|
||
specify a string that should be displayed in the list for this
|
||
special match. If no string is given, it will be shown as a string
|
||
containing the strings that would be inserted for the other matches,
|
||
truncated to the width of the screen.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-E</code> <code>number</code><br />
|
||
This option adds <code>number</code> empty matches after the <code>words</code> have been
|
||
added. An empty match takes up space in completion listings but will
|
||
never be inserted in the line and can’t be selected with menu
|
||
completion or menu selection. This makes empty matches only useful
|
||
to format completion lists and to make explanatory string be shown
|
||
in completion lists (since empty matches can be given display
|
||
strings with the <code>-d</code> option). And because all but one empty string
|
||
would otherwise be removed, this option implies the <code>-V</code> and <code>-2</code>
|
||
options (even if an explicit <code>-J</code> option is given). This can be
|
||
important to note as it affects the name space into which matches
|
||
are added.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-</code><br />
|
||
<code>-``-</code><br />
|
||
This flag ends the list of flags and options. All arguments after it
|
||
will be taken as the words to use as matches even if they begin with
|
||
hyphens.</p>
|
||
</li>
|
||
</ul>
|
||
<p>Except for the <code>-M</code> flag, if any of these flags is given more than once,
|
||
the first one (and its argument) will be used.</p>
|
||
<p><span id="index-compset"></span>
|
||
<span id="index-completion-widgets_002c-modifying-special-parameters"></span></p>
|
||
<p><code>compset -p</code> <code>number</code></p>
|
||
<p><code>compset -P</code> [ <code>number</code> ] <code>pattern</code></p>
|
||
<p><code>compset -s</code> <code>number</code></p>
|
||
<p><code>compset -S</code> [ <code>number</code> ] <code>pattern</code></p>
|
||
<p><code>compset -n</code> <code>begin</code> [ <code>end</code> ]</p>
|
||
<p><code>compset -N</code> <code>beg-pat</code> [ <code>end-pat</code> ]</p>
|
||
<p><code>compset -q</code></p>
|
||
<p>This command simplifies modification of the special parameters, while
|
||
its return status allows tests on them to be carried out.</p>
|
||
<p>The options are:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-p</code> <code>number</code><br />
|
||
If the value of the <code>PREFIX</code> parameter is at least <code>number</code>
|
||
characters long, the first <code>number</code> characters are removed from it
|
||
and appended to the contents of the <code>IPREFIX</code> parameter.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-P</code> [ <code>number</code> ] <code>pattern</code><br />
|
||
If the value of the <code>PREFIX</code> parameter begins with anything that
|
||
matches the <code>pattern</code>, the matched portion is removed from <code>PREFIX</code>
|
||
and appended to <code>IPREFIX</code>.</p>
|
||
<p>Without the optional <code>number</code>, the longest match is taken, but if
|
||
<code>number</code> is given, anything up to the <code>number</code>th match is moved. If
|
||
the <code>number</code> is negative, the <code>number</code>th longest match is moved. For
|
||
example, if <code>PREFIX</code> contains the string ‘<code>a=b=c</code>’, then <code>compset -P ’*=’</code> will move the string ‘<code>a=b=</code>’ into the <code>IPREFIX</code> parameter,
|
||
but <code>compset -P 1 ’*\=’</code> will move only the string ‘<code>a=</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-s</code> <code>number</code><br />
|
||
As <code>-p</code>, but transfer the last <code>number</code> characters from the value of
|
||
<code>SUFFIX</code> to the front of the value of <code>ISUFFIX</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-S</code> [ <code>number</code> ] <code>pattern</code><br />
|
||
As <code>-P</code>, but match the last portion of <code>SUFFIX</code> and transfer the
|
||
matched portion to the front of the value of <code>ISUFFIX</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-n</code> <code>begin</code> [ <code>end</code> ]<br />
|
||
If the current word position as specified by the parameter <code>CURRENT</code>
|
||
is greater than or equal to <code>begin</code>, anything up to the <code>begin</code>th
|
||
word is removed from the <code>words</code> array and the value of the
|
||
parameter <code>CURRENT</code> is decremented by <code>begin</code>.</p>
|
||
<p>If the optional <code>end</code> is given, the modification is done only if the
|
||
current word position is also less than or equal to <code>end</code>. In this
|
||
case, the words from position <code>end</code> onwards are also removed from
|
||
the <code>words</code> array.</p>
|
||
<p>Both <code>begin</code> and <code>end</code> may be negative to count backwards from the
|
||
last element of the <code>words</code> array.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-N</code> <code>beg-pat</code> [ <code>end-pat</code> ]<br />
|
||
If one of the elements of the <code>words</code> array before the one at the
|
||
index given by the value of the parameter <code>CURRENT</code> matches the
|
||
pattern <code>beg-pat</code>, all elements up to and including the matching one
|
||
are removed from the <code>words</code> array and the value of <code>CURRENT</code> is
|
||
changed to point to the same word in the changed array.</p>
|
||
<p>If the optional pattern <code>end-pat</code> is also given, and there is an
|
||
element in the <code>words</code> array matching this pattern, the parameters
|
||
are modified only if the index of this word is higher than the one
|
||
given by the <code>CURRENT</code> parameter (so that the matching word has to
|
||
be after the cursor). In this case, the words starting with the one
|
||
matching <code>end-pat</code> are also removed from the <code>words</code> array. If
|
||
<code>words</code> contains no word matching <code>end-pat</code>, the testing and
|
||
modification is performed as if it were not given.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-q</code><br />
|
||
The word currently being completed is split on spaces into separate
|
||
words, respecting the usual shell quoting conventions. The resulting
|
||
words are stored in the <code>words</code> array, and <code>CURRENT</code>, <code>PREFIX</code>,
|
||
<code>SUFFIX</code>, <code>QIPREFIX</code>, and <code>QISUFFIX</code> are modified to reflect the
|
||
word part that is completed.</p>
|
||
</li>
|
||
</ul>
|
||
<p>In all the above cases the return status is zero if the test succeeded
|
||
and the parameters were modified and non-zero otherwise. This allows one
|
||
to use this builtin in tests such as:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">if compset -P '*\='; then ...
|
||
</code></pre>
|
||
</div>
|
||
<p>This forces anything up to and including the last equal sign to be
|
||
ignored by the completion code.</p>
|
||
<p><code>compcall</code> [ <code>-TD</code> ]</p>
|
||
<p>This allows the use of completions defined with the <code>compctl</code> builtin
|
||
from within completion widgets. The list of matches will be generated as
|
||
if one of the non-widget completion functions (<code>complete-word</code>, etc.)
|
||
had been called, except that only <code>compctl</code>s given for specific commands
|
||
are used. To force the code to try completions defined with the <code>-T</code>
|
||
option of <code>compctl</code> and/or the default completion (whether defined by
|
||
<code>compctl -D</code> or the builtin default) in the appropriate places, the <code>-T</code>
|
||
and/or <code>-D</code> flags can be passed to <code>compcall</code>.</p>
|
||
<p>The return status can be used to test if a matching <code>compctl</code> definition
|
||
was found. It is non-zero if a <code>compctl</code> was found and zero otherwise.</p>
|
||
<p>Note that this builtin is defined by the <code>zsh/compctl</code> module.</p>
|
||
<hr />
|
||
<p><span id="Completion-Condition-Codes"></span>
|
||
<span id="Completion-Condition-Codes-1"></span></p>
|
||
<h2 id="194-completion-condition-codes"><a class="header" href="#194-completion-condition-codes">19.4 Completion Condition Codes</a></h2>
|
||
<p><span id="index-completion-widgets_002c-condition-codes"></span></p>
|
||
<p>The following additional condition codes for use within the <code>[[</code> <code>...</code>
|
||
<code>]]</code> construct are available in completion widgets. These work on the
|
||
special parameters. All of these tests can also be performed by the
|
||
<code>compset</code> builtin, but in the case of the condition codes the contents
|
||
of the special parameters are not modified.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-prefix</code> [ <code>number</code> ] <code>pattern</code><br />
|
||
true if the test for the <code>-P</code> option of <code>compset</code> would succeed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-suffix</code> [ <code>number</code> ] <code>pattern</code><br />
|
||
true if the test for the <code>-S</code> option of <code>compset</code> would succeed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-after</code> <code>beg-pat</code><br />
|
||
true if the test of the <code>-N</code> option with only the <code>beg-pat</code> given
|
||
would succeed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-between</code> <code>beg-pat end-pat</code><br />
|
||
true if the test for the <code>-N</code> option with both patterns would
|
||
succeed.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Completion-Matching-Control"></span>
|
||
<span id="Completion-Matching-Control-1"></span></p>
|
||
<h2 id="195-completion-matching-control"><a class="header" href="#195-completion-matching-control">19.5 Completion Matching Control</a></h2>
|
||
<p>It is possible by use of the <code>-M</code> option of the <code>compadd</code> builtin
|
||
command to specify how the characters in the string to be completed
|
||
(referred to here as the command line) map onto the characters in the
|
||
list of matches produced by the completion code (referred to here as the
|
||
trial completions). Note that this is not used if the command line
|
||
contains a glob pattern and the <code>GLOB_COMPLETE</code> option is set or the
|
||
<code>pattern_match</code> of the <code>compstate</code> special association is set to a
|
||
non-empty string.</p>
|
||
<p>The <code>match-spec</code> given as the argument to the <code>-M</code> option (see
|
||
<a href="Completion-Widgets.html#Completion-Builtin-Commands">Completion Builtin Commands</a>) consists of
|
||
one or more matching descriptions separated by whitespace. Each
|
||
description consists of a letter followed by a colon and then the
|
||
patterns describing which character sequences on the line match which
|
||
character sequences in the trial completion. Any sequence of characters
|
||
not handled in this fashion must match exactly, as usual.</p>
|
||
<p>The forms of <code>match-spec</code> understood are as follows. In each case, the
|
||
form with an upper case initial character retains the string already
|
||
typed on the command line as the final result of completion, while with
|
||
a lower case initial character the string on the command line is changed
|
||
into the corresponding part of the trial completion.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>m:``lpat``=``tpat</code><br />
|
||
<code>M:``lpat``=``tpat</code><br />
|
||
Here, <code>lpat</code> is a pattern that matches on the command line,
|
||
corresponding to <code>tpat</code> which matches in the trial completion.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>l:``lanchor``|``lpat``=``tpat</code><br />
|
||
<code>L:``lanchor``|``lpat``=``tpat</code><br />
|
||
<code>l:``lanchor``||``ranchor``=``tpat</code><br />
|
||
<code>L:``lanchor``||``ranchor``=``tpat</code><br />
|
||
<code>b:``lpat``=``tpat</code><br />
|
||
<code>B:``lpat``=``tpat</code><br />
|
||
These letters are for patterns that are anchored by another pattern
|
||
on the left side. Matching for <code>lpat</code> and <code>tpat</code> is as for <code>m</code> and
|
||
<code>M</code>, but the pattern <code>lpat</code> matched on the command line must be
|
||
preceded by the pattern <code>lanchor</code>. The <code>lanchor</code> can be blank to
|
||
anchor the match to the start of the command line string; otherwise
|
||
the anchor can occur anywhere, but must match in both the command
|
||
line and trial completion strings.</p>
|
||
<p>If no <code>lpat</code> is given but a <code>ranchor</code> is, this matches the gap
|
||
between substrings matched by <code>lanchor</code> and <code>ranchor</code>. Unlike
|
||
<code>lanchor</code>, the <code>ranchor</code> only needs to match the trial completion
|
||
string.</p>
|
||
<p>The <code>b</code> and <code>B</code> forms are similar to <code>l</code> and <code>L</code> with an empty
|
||
anchor, but need to match only the beginning of the word on the
|
||
command line or trial completion, respectively.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>r:``lpat``|``ranchor``=``tpat</code><br />
|
||
<code>R:``lpat``|``ranchor``=``tpat</code><br />
|
||
<code>r:``lanchor``||``ranchor``=``tpat</code><br />
|
||
<code>R:``lanchor``||``ranchor``=``tpat</code><br />
|
||
<code>e:``lpat``=``tpat</code><br />
|
||
<code>E:``lpat``=``tpat</code><br />
|
||
As <code>l</code>, <code>L</code>, <code>b</code> and <code>B</code>, with the difference that the command line
|
||
and trial completion patterns are anchored on the right side. Here
|
||
an empty <code>ranchor</code> and the <code>e</code> and <code>E</code> forms force the match to the
|
||
end of the command line or trial completion string.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>x:</code><br />
|
||
This form is used to mark the end of matching specifications:
|
||
subsequent specifications are ignored. In a single standalone list
|
||
of specifications this has no use but where matching specifications
|
||
are accumulated, such as from nested function calls, it can allow
|
||
one function to override another.</p>
|
||
</li>
|
||
</ul>
|
||
<p>Each <code>lpat</code>, <code>tpat</code> or <code>anchor</code> is either an empty string or consists of
|
||
a sequence of literal characters (which may be quoted with a backslash),
|
||
question marks, character classes, and correspondence classes; ordinary
|
||
shell patterns are not used. Literal characters match only themselves,
|
||
question marks match any character, and character classes are formed as
|
||
for globbing and match any character in the given set.</p>
|
||
<p>Correspondence classes are defined like character classes, but with two
|
||
differences: they are delimited by a pair of braces, and negated classes
|
||
are not allowed, so the characters <code>!</code> and <code>^</code> have no special meaning
|
||
directly after the opening brace. They indicate that a range of
|
||
characters on the line match a range of characters in the trial
|
||
completion, but (unlike ordinary character classes) paired according to
|
||
the corresponding position in the sequence. For example, to make any
|
||
ASCII lower case letter on the line match the corresponding upper case
|
||
letter in the trial completion, you can use ‘<code>m:{a-z}={A-Z}</code>’ (however,
|
||
see below for the recommended form for this). More than one pair of
|
||
classes can occur, in which case the first class before the <code>=</code>
|
||
corresponds to the first after it, and so on. If one side has more such
|
||
classes than the other side, the superfluous classes behave like normal
|
||
character classes. In anchor patterns correspondence classes also behave
|
||
like normal character classes.</p>
|
||
<p>The standard ‘<code>[:``name``:]</code>’ forms described for standard shell
|
||
patterns (see <a href="Expansion.html#Filename-Generation">Filename Generation</a>)
|
||
may appear in correspondence classes as well as normal character
|
||
classes. The only special behaviour in correspondence classes is if the
|
||
form on the left and the form on the right are each one of <code>[:upper:]</code>,
|
||
<code>[:lower:]</code>. In these cases the character in the word and the character
|
||
on the line must be the same up to a difference in case. Hence to make
|
||
any lower case character on the line match the corresponding upper case
|
||
character in the trial completion you can use
|
||
‘<code>m:{[:lower:]}={[:upper:]}</code>’. Although the matching system does not
|
||
yet handle multibyte characters, this is likely to be a future
|
||
extension, at which point this syntax will handle arbitrary alphabets;
|
||
hence this form, rather than the use of explicit ranges, is the
|
||
recommended form. In other cases ‘<code>[:``name``:]</code>’ forms are allowed. If
|
||
the two forms on the left and right are the same, the characters must
|
||
match exactly. In remaining cases, the corresponding tests are applied
|
||
to both characters, but they are not otherwise constrained; any matching
|
||
character in one set goes with any matching character in the other set:
|
||
this is equivalent to the behaviour of ordinary character classes.</p>
|
||
<p>The pattern <code>tpat</code> may also be one or two stars, ‘<code>*</code>’ or ‘<code>**</code>’. This
|
||
means that the pattern on the command line can match any number of
|
||
characters in the trial completion. In this case the pattern must be
|
||
anchored (on either side); in the case of a single star, the <code>anchor</code>
|
||
then determines how much of the trial completion is to be included —
|
||
only the characters up to the next appearance of the anchor will be
|
||
matched. With two stars, substrings matched by the anchor can be
|
||
matched, too.</p>
|
||
<p>Examples:</p>
|
||
<p>The keys of the <code>options</code> association defined by the <code>parameter</code> module
|
||
are the option names in all-lower-case form, without underscores, and
|
||
without the optional <code>no</code> at the beginning even though the builtins
|
||
<code>setopt</code> and <code>unsetopt</code> understand option names with upper case letters,
|
||
underscores, and the optional <code>no</code>. The following alters the matching
|
||
rules so that the prefix <code>no</code> and any underscore are ignored when trying
|
||
to match the trial completions generated and upper case letters on the
|
||
line match the corresponding lower case letters in the words:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compadd -M 'L:|[nN][oO]= M:_= M:{[:upper:]}={[:lower:]}' - \
|
||
${(k)options}
|
||
</code></pre>
|
||
</div>
|
||
<p>The first part says that the pattern ‘<code>[nN][oO]</code>’ at the beginning (the
|
||
empty anchor before the pipe symbol) of the string on the line matches
|
||
the empty string in the list of words generated by completion, so it
|
||
will be ignored if present. The second part does the same for an
|
||
underscore anywhere in the command line string, and the third part uses
|
||
correspondence classes so that any upper case letter on the line matches
|
||
the corresponding lower case letter in the word. The use of the upper
|
||
case forms of the specification characters (<code>L</code> and <code>M</code>) guarantees that
|
||
what has already been typed on the command line (in particular the
|
||
prefix <code>no</code>) will not be deleted.</p>
|
||
<p>Note that the use of <code>L</code> in the first part means that it matches only
|
||
when at the beginning of both the command line string and the trial
|
||
completion. I.e., the string ‘<code>_NO_f</code>’ would not be completed to
|
||
‘<code>_NO_foo</code>’, nor would ‘<code>NONO_f</code>’ be completed to ‘<code>NONO_foo</code>’ because
|
||
of the leading underscore or the second ‘<code>NO</code>’ on the line which makes
|
||
the pattern fail even though they are otherwise ignored. To fix this,
|
||
one would use ‘<code>B:[nN][oO]=</code>’ instead of the first part. As described
|
||
above, this matches at the beginning of the trial completion,
|
||
independent of other characters or substrings at the beginning of the
|
||
command line word which are ignored by the same or other <code>match-spec</code>s.</p>
|
||
<p>The second example makes completion case insensitive. This is just the
|
||
same as in the option example, except here we wish to retain the
|
||
characters in the list of completions:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compadd -M 'm:{[:lower:]}={[:upper:]}' ...
|
||
</code></pre>
|
||
</div>
|
||
<p>This makes lower case letters match their upper case counterparts. To
|
||
make upper case letters match the lower case forms as well:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compadd -M 'm:{[:lower:][:upper:]}={[:upper:][:lower:]}' ...
|
||
</code></pre>
|
||
</div>
|
||
<p>A nice example for the use of <code>*</code> patterns is partial word completion.
|
||
Sometimes you would like to make strings like ‘<code>c.s.u</code>’ complete to
|
||
strings like ‘<code>comp.source.unix</code>’, i.e. the word on the command line
|
||
consists of multiple parts, separated by a dot in this example, where
|
||
each part should be completed separately — note, however, that the case
|
||
where each part of the word, i.e. ‘<code>comp</code>’, ‘<code>source</code>’ and ‘<code>unix</code>’ in
|
||
this example, is to be completed from separate sets of matches is a
|
||
different problem to be solved by the implementation of the completion
|
||
widget. The example can be handled by:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compadd -M 'r:|.=* r:|=*' \
|
||
- comp.sources.unix comp.sources.misc ...
|
||
</code></pre>
|
||
</div>
|
||
<p>The first specification says that <code>lpat</code> is the empty string, while
|
||
<code>anchor</code> is a dot; <code>tpat</code> is <code>*</code>, so this can match anything except for
|
||
the ‘<code>.</code>’ from the anchor in the trial completion word. So in ‘<code>c.s.u</code>’,
|
||
the matcher sees ‘<code>c</code>’, followed by the empty string, followed by the
|
||
anchor ‘<code>.</code>’, and likewise for the second dot, and replaces the empty
|
||
strings before the anchors, giving
|
||
‘<code>c</code>[<code>omp</code>]<code>.s</code>[<code>ources</code>]<code>.u</code>[<code>nix</code>]’, where the last part of
|
||
the completion is just as normal.</p>
|
||
<p>With the pattern shown above, the string ‘<code>c.u</code>’ could not be completed
|
||
to ‘<code>comp.sources.unix</code>’ because the single star means that no dot
|
||
(matched by the anchor) can be skipped. By using two stars as in
|
||
‘<code>r:|.=**</code>’, however, ‘<code>c.u</code>’ could be completed to
|
||
‘<code>comp.sources.unix</code>’. This also shows that in some cases, especially
|
||
if the anchor is a real pattern, like a character class, the form with
|
||
two stars may result in more matches than one would like.</p>
|
||
<p>The second specification is needed to make this work when the cursor is
|
||
in the middle of the string on the command line and the option
|
||
<code>COMPLETE_IN_WORD</code> is set. In this case the completion code would
|
||
normally try to match trial completions that end with the string as
|
||
typed so far, i.e. it will only insert new characters at the cursor
|
||
position rather than at the end. However in our example we would like
|
||
the code to recognise matches which contain extra characters after the
|
||
string on the line (the ‘<code>nix</code>’ in the example). Hence we say that the
|
||
empty string at the end of the string on the line matches any characters
|
||
at the end of the trial completion.</p>
|
||
<p>More generally, the specification</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compadd -M 'r:|[.,_-]=* r:|=*' ...
|
||
</code></pre>
|
||
</div>
|
||
<p>allows one to complete words with abbreviations before any of the
|
||
characters in the square brackets. For example, to complete
|
||
<code>veryverylongfile.c</code> rather than <code>veryverylongheader.h</code> with the above
|
||
in effect, you can just type <code>very.c</code> before attempting completion.</p>
|
||
<p>The specifications with both a left and a right anchor are useful to
|
||
complete partial words whose parts are not separated by some special
|
||
character. For example, in some places strings have to be completed that
|
||
are formed ‘<code>LikeThis</code>’ (i.e. the separate parts are determined by a
|
||
leading upper case letter) or maybe one has to complete strings with
|
||
trailing numbers. Here one could use the simple form with only one
|
||
anchor as in:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compadd -M 'r:|[[:upper:]0-9]=* r:|=*' LikeTHIS FooHoo 5foo123 5bar234
|
||
</code></pre>
|
||
</div>
|
||
<p>But with this, the string ‘<code>H</code>’ would neither complete to ‘<code>FooHoo</code>’ nor
|
||
to ‘<code>LikeTHIS</code>’ because in each case there is an upper case letter
|
||
before the ‘<code>H</code>’ and that is matched by the anchor. Likewise, a ‘<code>2</code>’
|
||
would not be completed. In both cases this could be changed by using
|
||
‘<code>r:|[[:upper:]0-9]=**</code>’, but then ‘<code>H</code>’ completes to both
|
||
‘<code>LikeTHIS</code>’ and ‘<code>FooHoo</code>’ and a ‘<code>2</code>’ matches the other strings
|
||
because characters can be inserted before every upper case letter and
|
||
digit. To avoid this one would use:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compadd -M 'r:[^[:upper:]0-9]||[[:upper:]0-9]=** r:|=*' \
|
||
LikeTHIS FooHoo foo123 bar234
|
||
</code></pre>
|
||
</div>
|
||
<p>By using these two anchors, a ‘<code>H</code>’ matches only upper case ‘<code>H</code>’s that
|
||
are immediately preceded by something matching the left anchor
|
||
‘<code>[^[:upper:]0-9]</code>’. The effect is, of course, that ‘<code>H</code>’ matches only
|
||
the string ‘<code>FooHoo</code>’, a ‘<code>2</code>’ matches only ‘<code>bar234</code>’ and so on.</p>
|
||
<p>When using the completion system (see <a href="Completion-System.html#Completion-System">Completion
|
||
System</a>), users can define
|
||
match specifications that are to be used for specific contexts by using
|
||
the <code>matcher</code> and <code>matcher-list</code> styles. The values for the latter will
|
||
be used everywhere.</p>
|
||
<hr />
|
||
<p><span id="Completion-Widget-Example"></span>
|
||
<span id="Completion-Widget-Example-1"></span></p>
|
||
<h2 id="196-completion-widget-example"><a class="header" href="#196-completion-widget-example">19.6 Completion Widget Example</a></h2>
|
||
<p><span id="index-completion-widgets_002c-example"></span></p>
|
||
<p>The first step is to define the widget:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle -C complete complete-word complete-files
|
||
</code></pre>
|
||
</div>
|
||
<p>Then the widget can be bound to a key using the <code>bindkey</code> builtin
|
||
command:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">bindkey '^X\t' complete
|
||
</code></pre>
|
||
</div>
|
||
<p>After that the shell function <code>complete-files</code> will be invoked after
|
||
typing control-X and TAB. The function should then generate the matches,
|
||
e.g.:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">complete-files () { compadd - * }
|
||
</code></pre>
|
||
</div>
|
||
<p>This function will complete files in the current directory matching the
|
||
current word.</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>
|
||
<!-- 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="Completion-System.html#20-completion-system">20 Completion System</a>
|
||
<ul>
|
||
<li><a href="Completion-System.html#201-description">20.1 Description</a></li>
|
||
<li><a href="Completion-System.html#202-initialization">20.2 Initialization</a>
|
||
<ul>
|
||
<li><a href="Completion-System.html#2021-use-of-compinit">20.2.1 Use of compinit</a></li>
|
||
<li><a href="Completion-System.html#2022-autoloaded-files">20.2.2 Autoloaded files</a></li>
|
||
<li><a href="Completion-System.html#2023-functions">20.2.3 Functions</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Completion-System.html#203-completion-system-configuration">20.3 Completion System Configuration</a>
|
||
<ul>
|
||
<li><a href="Completion-System.html#2031-overview">20.3.1 Overview</a></li>
|
||
<li><a href="Completion-System.html#2032-standard-tags">20.3.2 Standard Tags</a></li>
|
||
<li><a href="Completion-System.html#2033-standard-styles">20.3.3 Standard Styles</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Completion-System.html#204-control-functions">20.4 Control Functions</a></li>
|
||
<li><a href="Completion-System.html#205-bindable-commands">20.5 Bindable Commands</a></li>
|
||
<li><a href="Completion-System.html#206-utility-functions">20.6 Utility Functions</a></li>
|
||
<li><a href="Completion-System.html#207-completion-system-variables">20.7 Completion System Variables</a></li>
|
||
<li><a href="Completion-System.html#208-completion-directories">20.8 Completion Directories</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Completion-System"></span>
|
||
<span id="Completion-System-1"></span></p>
|
||
<h1 id="20-completion-system"><a class="header" href="#20-completion-system">20 Completion System</a></h1>
|
||
<p><span id="index-completion-system"></span>
|
||
<span id="index-completion_002c-programmable-1"></span>
|
||
<span id="index-completion_002c-controlling-1"></span></p>
|
||
<hr />
|
||
<p><span id="Description-3"></span></p>
|
||
<h2 id="201-description"><a class="header" href="#201-description">20.1 Description</a></h2>
|
||
<p>This describes the shell code for the ‘new’ completion system, referred
|
||
to as <code>compsys</code>. It is written in shell functions based on the features
|
||
described in the previous chapter, <a href="Completion-Widgets.html#Completion-Widgets">Completion
|
||
Widgets</a>.</p>
|
||
<p>The features are contextual, sensitive to the point at which completion
|
||
is started. Many completions are already provided. For this reason, a
|
||
user can perform a great many tasks without knowing any details beyond
|
||
how to initialize the system, which is described in
|
||
<a href="Completion-System.html#Initialization">Initialization</a>.</p>
|
||
<p>The context that decides what completion is to be performed may be</p>
|
||
<ul>
|
||
<li>an argument or option position: these describe the position on the
|
||
command line at which completion is requested. For example ‘first
|
||
argument to rmdir, the word being completed names a directory’;</li>
|
||
<li>a special context, denoting an element in the shell’s syntax. For
|
||
example ‘a word in command position’ or ‘an array subscript’.</li>
|
||
</ul>
|
||
<p>A full context specification contains other elements, as we shall
|
||
describe.</p>
|
||
<p>Besides commands names and contexts, the system employs two more
|
||
concepts, <em>styles</em> and <em>tags</em>. These provide ways for the user to
|
||
configure the system’s behaviour.</p>
|
||
<p>Tags play a dual role. They serve as a classification system for the
|
||
matches, typically indicating a class of object that the user may need
|
||
to distinguish. For example, when completing arguments of the <code>ls</code>
|
||
command the user may prefer to try <code>files</code> before <code>directories</code>, so both
|
||
of these are tags. They also appear as the rightmost element in a
|
||
context specification.</p>
|
||
<p>Styles modify various operations of the completion system, such as
|
||
output formatting, but also what kinds of completers are used (and in
|
||
what order), or which tags are examined. Styles may accept arguments and
|
||
are manipulated using the <code>zstyle</code> command described in <a href="Zsh-Modules.html#The-zsh_002fzutil-Module">The zsh/zutil
|
||
Module</a>.</p>
|
||
<p>In summary, tags describe <em>what</em> the completion objects are, and style
|
||
<code>how</code> they are to be completed. At various points of execution, the
|
||
completion system checks what styles and/or tags are defined for the
|
||
current context, and uses that to modify its behavior. The full
|
||
description of context handling, which determines how tags and other
|
||
elements of the context influence the behaviour of styles, is described
|
||
in <a href="Completion-System.html#Completion-System-Configuration">Completion System Configuration</a>.</p>
|
||
<p>When a completion is requested, a dispatcher function is called; see the
|
||
description of <code>_main_complete</code> in the list of control functions below.
|
||
This dispatcher decides which function should be called to produce the
|
||
completions, and calls it. The result is passed to one or more
|
||
<em>completers</em>, functions that implement individual completion strategies:
|
||
simple completion, error correction, completion with error correction,
|
||
menu selection, etc.</p>
|
||
<p>More generally, the shell functions contained in the completion system
|
||
are of two types:</p>
|
||
<ul>
|
||
<li>those beginning ‘<code>comp</code>’ are to be called directly; there are only a
|
||
few of these;</li>
|
||
<li>those beginning ‘<code>_</code>’ are called by the completion code. The shell
|
||
functions of this set, which implement completion behaviour and may
|
||
be bound to keystrokes, are referred to as ‘widgets’. These
|
||
proliferate as new completions are required.</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Initialization"></span> <span id="Initialization-1"></span></p>
|
||
<h2 id="202-initialization"><a class="header" href="#202-initialization">20.2 Initialization</a></h2>
|
||
<p><span id="index-compinstall"></span>
|
||
<span id="index-completion-system_002c-installing"></span></p>
|
||
<p>If the system was installed completely, it should be enough to call the
|
||
shell function <code>compinit</code> from your initialization file; see the next
|
||
section. However, the function <code>compinstall</code> can be run by a user to
|
||
configure various aspects of the completion system.</p>
|
||
<p>Usually, <code>compinstall</code> will insert code into <code>.zshrc</code>, although if
|
||
file’s location. Note that it is up to you to make sure that the lines
|
||
added to <code>.zshrc</code> are actually run; you may, for example, need to move
|
||
them to an earlier place in the file if <code>.zshrc</code> usually returns early.
|
||
So long as you keep them all together (including the comment lines at
|
||
the start and finish), you can rerun <code>compinstall</code> and it will correctly
|
||
locate and modify these lines. Note, however, that any code you add to
|
||
this section by hand is likely to be lost if you rerun <code>compinstall</code>,
|
||
although lines using the command ‘<code>zstyle</code>’ should be gracefully
|
||
handled.</p>
|
||
<p>The new code will take effect next time you start the shell, or run
|
||
<code>.zshrc</code> by hand; there is also an option to make them take effect
|
||
immediately. However, if <code>compinstall</code> has removed definitions, you will
|
||
need to restart the shell to see the changes.</p>
|
||
<p>To run <code>compinstall</code> you will need to make sure it is in a directory
|
||
mentioned in your <code>fpath</code> parameter, which should already be the case if
|
||
zsh was properly configured as long as your startup files do not remove
|
||
the appropriate directories from <code>fpath</code>. Then it must be autoloaded
|
||
(‘<code>autoload -U compinstall</code>’ is recommended). You can abort the
|
||
installation any time you are being prompted for information, and your
|
||
<code>.zshrc</code> will not be altered at all; changes only take place right at
|
||
the end, where you are specifically asked for confirmation.</p>
|
||
<hr />
|
||
<p><span id="Use-of-compinit"></span></p>
|
||
<h3 id="2021-use-of-compinit"><a class="header" href="#2021-use-of-compinit">20.2.1 Use of compinit</a></h3>
|
||
<p><span id="index-compinit"></span>
|
||
<span id="index-completion-system_002c-initializing"></span></p>
|
||
<p>This section describes the use of <code>compinit</code> to initialize completion
|
||
for the current session when called directly; if you have run
|
||
<code>compinstall</code> it will be called automatically from your <code>.zshrc</code>.</p>
|
||
<p>To initialize the system, the function <code>compinit</code> should be in a
|
||
directory mentioned in the <code>fpath</code> parameter, and should be autoloaded
|
||
(‘<code>autoload -U compinit</code>’ is recommended), and then run simply as
|
||
‘<code>compinit</code>’. This will define a few utility functions, arrange for
|
||
all the necessary shell functions to be autoloaded, and will then
|
||
re-define all widgets that do completion to use the new system. If you
|
||
use the <code>menu-select</code> widget, which is part of the <code>zsh/complist</code>
|
||
module, you should make sure that that module is loaded before the call
|
||
to <code>compinit</code> so that that widget is also re-defined. If completion
|
||
styles (see below) are set up to perform expansion as well as completion
|
||
by default, and the TAB key is bound to <code>expand-or-complete</code>, <code>compinit</code>
|
||
will rebind it to <code>complete-word</code>; this is necessary to use the correct
|
||
form of expansion.</p>
|
||
<p>Should you need to use the original completion commands, you can still
|
||
bind keys to the old widgets by putting a ‘<code>.</code>’ in front of the widget
|
||
name, e.g. ‘<code>.expand-or-complete</code>’.</p>
|
||
<p>To speed up the running of <code>compinit</code>, it can be made to produce a
|
||
dumped configuration that will be read in on future invocations; this is
|
||
the default, but can be turned off by calling <code>compinit</code> with the option
|
||
<code>-D</code>. The dumped file is <code>.zcompdump</code> in the same directory as the
|
||
startup files (i.e. <code>$ZDOTDIR</code> or <code>$HOME</code>); alternatively, an explicit
|
||
file name can be given by ‘<code>compinit -d</code> <code>dumpfile</code>’. The next
|
||
invocation of <code>compinit</code> will read the dumped file instead of performing
|
||
a full initialization.</p>
|
||
<p>If the number of completion files changes, <code>compinit</code> will recognise
|
||
this and produce a new dump file. However, if the name of a function or
|
||
the arguments in the first line of a <code>#compdef</code> function (as described
|
||
below) change, it is easiest to delete the dump file by hand so that
|
||
<code>compinit</code> will re-create it the next time it is run. The check
|
||
performed to see if there are new functions can be omitted by giving the
|
||
option <code>-C</code>. In this case the dump file will only be created if there
|
||
isn’t one already.</p>
|
||
<p>The dumping is actually done by another function, <code>compdump</code>, but you
|
||
will only need to run this yourself if you change the configuration
|
||
(e.g. using <code>compdef</code>) and then want to dump the new one. The name of
|
||
the old dumped file will be remembered for this purpose.</p>
|
||
<p>If the parameter <code>_compdir</code> is set, <code>compinit</code> uses it as a directory
|
||
where completion functions can be found; this is only necessary if they
|
||
are not already in the function search path.</p>
|
||
<p>For security reasons <code>compinit</code> also checks if the completion system
|
||
would use files not owned by root or by the current user, or files in
|
||
root or by the current user. If such files or directories are found,
|
||
<code>compinit</code> will ask if the completion system should really be used. To
|
||
avoid these tests and make all files found be used without asking, use
|
||
the option <code>-u</code>, and to make <code>compinit</code> silently ignore all insecure
|
||
files and directories use the option <code>-i</code>. This security check is
|
||
skipped entirely when the <code>-C</code> option is given.</p>
|
||
<p><span id="index-compaudit"></span></p>
|
||
<p>The security check can be retried at any time by running the function
|
||
<code>compaudit</code>. This is the same check used by <code>compinit</code>, but when it is
|
||
executed directly any changes to <code>fpath</code> are made local to the function
|
||
so they do not persist. The directories to be checked may be passed as
|
||
arguments; if none are given, <code>compaudit</code> uses <code>fpath</code> and <code>_compdir</code> to
|
||
find completion system directories, adding missing ones to <code>fpath</code> as
|
||
necessary. To force a check of exactly the directories currently named
|
||
in <code>fpath</code>, set <code>_compdir</code> to an empty string before calling <code>compaudit</code>
|
||
or <code>compinit</code>.</p>
|
||
<p><span id="index-bashcompinit"></span></p>
|
||
<p>The function <code>bashcompinit</code> provides compatibility with bash’s
|
||
programmable completion system. When run it will define the functions,
|
||
<code>compgen</code> and <code>complete</code> which correspond to the bash builtins with the
|
||
same names. It will then be possible to use completion specifications
|
||
and functions written for bash.</p>
|
||
<hr />
|
||
<p><span id="Autoloaded-files"></span></p>
|
||
<h3 id="2022-autoloaded-files"><a class="header" href="#2022-autoloaded-files">20.2.2 Autoloaded files</a></h3>
|
||
<p><span id="index-completion-system_002c-autoloaded-functions"></span></p>
|
||
<p>The convention for autoloaded functions used in completion is that they
|
||
start with an underscore; as already mentioned, the <code>fpath/FPATH</code>
|
||
parameter must contain the directory in which they are stored. If <code>zsh</code>
|
||
was properly installed on your system, then <code>fpath/FPATH</code> automatically
|
||
contains the required directories for the standard functions.</p>
|
||
<p>For incomplete installations, if <code>compinit</code> does not find enough files
|
||
beginning with an underscore (fewer than twenty) in the search path, it
|
||
will try to find more by adding the directory <code>_compdir</code> to the search
|
||
path. If that directory has a subdirectory named <code>Base</code>, all
|
||
subdirectories will be added to the path. Furthermore, if the
|
||
subdirectory <code>Base</code> has a subdirectory named <code>Core</code>, <code>compinit</code> will add
|
||
all subdirectories of the subdirectories to the path: this allows the
|
||
functions to be in the same format as in the <code>zsh</code> source distribution.</p>
|
||
<p><span id="index-compdef_002c-use-of-by-compinit"></span></p>
|
||
<p>When <code>compinit</code> is run, it searches all such files accessible via
|
||
<code>fpath/FPATH</code> and reads the first line of each of them. This line should
|
||
contain one of the tags described below. Files whose first line does not
|
||
start with one of these tags are not considered to be part of the
|
||
completion system and will not be treated specially.</p>
|
||
<p>The tags are:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>#compdef</code> <code>name</code> ... [ <code>-</code>{<code>p</code>|<code>P</code>} <code>pattern</code> ... [ <code>-N</code> <code>name</code>
|
||
... ] ]<br />
|
||
The file will be made autoloadable and the function defined in it
|
||
will be called when completing <code>name</code>s, each of which is either the
|
||
name of a command whose arguments are to be completed or one of a
|
||
number of special contexts in the form <code>-``context``-</code> described
|
||
below.</p>
|
||
<p>Each <code>name</code> may also be of the form ‘<code>cmd``=``service</code>’. When
|
||
completing the command <code>cmd</code>, the function typically behaves as if
|
||
the command (or special context) <code>service</code> was being completed
|
||
instead. This provides a way of altering the behaviour of functions
|
||
that can perform many different completions. It is implemented by
|
||
setting the parameter <code>$service</code> when calling the function; the
|
||
function may choose to interpret this how it wishes, and simpler
|
||
functions will probably ignore it.</p>
|
||
<p>If the <code>#compdef</code> line contains one of the options <code>-p</code> or <code>-P</code>, the
|
||
words following are taken to be patterns. The function will be
|
||
called when completion is attempted for a command or context that
|
||
matches one of the patterns. The options <code>-p</code> and <code>-P</code> are used to
|
||
specify patterns to be tried before or after other completions
|
||
respectively. Hence <code>-P</code> may be used to specify default actions.</p>
|
||
<p>The option <code>-N</code> is used after a list following <code>-p</code> or <code>-P</code>; it
|
||
specifies that remaining words no longer define patterns. It is
|
||
possible to toggle between the three options as many times as
|
||
necessary.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>#compdef -k</code> <code>style key-sequence</code> ...<br />
|
||
This option creates a widget behaving like the builtin widget
|
||
<code>style</code> and binds it to the given <code>key-sequence</code>s, if any. The
|
||
<code>style</code> must be one of the builtin widgets that perform completion,
|
||
namely <code>complete-word</code>, <code>delete-char-or-list</code>, <code>expand-or-complete</code>,
|
||
<code>expand-or-complete-prefix</code>, <code>list-choices</code>, <code>menu-complete</code>,
|
||
<code>menu-expand-or-complete</code>, or <code>reverse-menu-complete</code>. If the
|
||
<code>zsh/complist</code> module is loaded (see <a href="Zsh-Modules.html#The-zsh_002fcomplist-Module">The zsh/complist
|
||
Module</a>) the widget
|
||
<code>menu-select</code> is also available.</p>
|
||
<p>When one of the <code>key-sequence</code>s is typed, the function in the file
|
||
will be invoked to generate the matches. Note that a key will not be
|
||
re-bound if it already was (that is, was bound to something other
|
||
than <code>undefined-key</code>). The widget created has the same name as the
|
||
file and can be bound to any other keys using <code>bindkey</code> as usual.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>#compdef -K</code> <code>widget-name</code> <code>style</code> <code>key-sequence</code> [ <code>name</code> <code>style</code>
|
||
<code>seq</code> ... ]<br />
|
||
This is similar to <code>-k</code> except that only one <code>key-sequence</code> argument
|
||
may be given for each <code>widget-name</code> <code>style</code> pair. However, the
|
||
entire set of three arguments may be repeated with a different set
|
||
of arguments. Note in particular that the <code>widget-name</code> must be
|
||
distinct in each set. If it does not begin with ‘<code>_</code>’ this will be
|
||
added. The <code>widget-name</code> should not clash with the name of any
|
||
existing widget: names based on the name of the function are most
|
||
useful. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">#compdef -K _foo_complete complete-word "^X^C" \
|
||
_foo_list list-choices "^X^D"
|
||
</code></pre>
|
||
</div>
|
||
<p>(all on one line) defines a widget <code>_foo_complete</code> for completion,
|
||
bound to ‘<code>^X^C</code>’, and a widget <code>_foo_list</code> for listing, bound to
|
||
‘<code>^X^D</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>#autoload</code> [ <code>options</code> ]<br />
|
||
Functions with the <code>#autoload</code> tag are marked for autoloading but
|
||
are not otherwise treated specially. Typically they are to be called
|
||
from within one of the completion functions. Any <code>options</code> supplied
|
||
will be passed to the <code>autoload</code> builtin; a typical use is <code>+X</code> to
|
||
force the function to be loaded immediately. Note that the <code>-U</code> and
|
||
<code>-z</code> flags are always added implicitly.</p>
|
||
</li>
|
||
</ul>
|
||
<p>The <code>#</code> is part of the tag name and no white space is allowed after it.
|
||
The <code>#compdef</code> tags use the <code>compdef</code> function described below; the main
|
||
difference is that the name of the function is supplied implicitly.</p>
|
||
<p>The special contexts for which completion functions can be defined are:</p>
|
||
<p><span id="index-_002darray_002dvalue_002d_002c-completion-context"></span></p>
|
||
<p><code>-array-value-</code></p>
|
||
<p>The right hand side of an array-assignment (‘<code>name``=(``...``)</code>’)</p>
|
||
<p><span id="index-_002dbrace_002dparameter_002d_002c-completion-context"></span></p>
|
||
<p><code>-brace-parameter-</code></p>
|
||
<p>The name of a parameter expansion within braces (‘<code>${``...``}</code>’)</p>
|
||
<p><span id="index-_002dassign_002dparameter_002d_002c-completion-context"></span></p>
|
||
<p><code>-assign-parameter-</code></p>
|
||
<p>The name of a parameter in an assignment, i.e. on the left hand side of
|
||
an ‘<code>=</code>’</p>
|
||
<p><span id="index-_002dcommand_002d_002c-completion-context"></span></p>
|
||
<p><code>-command-</code></p>
|
||
<p>A word in command position</p>
|
||
<p><span id="index-_002dcondition_002d_002c-completion-context"></span></p>
|
||
<p><code>-condition-</code></p>
|
||
<p>A word inside a condition (‘<code>[[``...``]]</code>’)</p>
|
||
<p><span id="index-_002ddefault_002d_002c-completion-context"></span></p>
|
||
<p><code>-default-</code></p>
|
||
<p>Any word for which no other completion is defined</p>
|
||
<p><span id="index-_002dequal_002d_002c-completion-context"></span></p>
|
||
<p><code>-equal-</code></p>
|
||
<p>A word beginning with an equals sign</p>
|
||
<p><span id="index-_002dfirst_002d_002c-completion-context"></span></p>
|
||
<p><code>-first-</code></p>
|
||
<p>This is tried before any other completion function. The function called
|
||
may set the <code>_compskip</code> parameter to one of various values: <code>all</code>: no
|
||
further completion is attempted; a string containing the substring
|
||
<code>patterns</code>: no pattern completion functions will be called; a string
|
||
containing <code>default</code>: the function for the ‘<code>-default-</code>’ context will
|
||
not be called, but functions defined for commands will be.</p>
|
||
<p><span id="index-_002dmath_002d_002c-completion-context"></span></p>
|
||
<p><code>-math-</code></p>
|
||
<p>Inside mathematical contexts, such as ‘<code>((``...``))</code>’</p>
|
||
<p><span id="index-_002dparameter_002d_002c-completion-context"></span></p>
|
||
<p><code>-parameter-</code></p>
|
||
<p>The name of a parameter expansion (‘<code>$``...</code>’)</p>
|
||
<p><span id="index-_002dredirect_002d_002c-completion-context"></span></p>
|
||
<p><code>-redirect-</code></p>
|
||
<p>The word after a redirection operator.</p>
|
||
<p><span id="index-_002dsubscript_002d_002c-completion-context"></span></p>
|
||
<p><code>-subscript-</code></p>
|
||
<p>The contents of a parameter subscript.</p>
|
||
<p><span id="index-_002dtilde_002d_002c-completion-context"></span></p>
|
||
<p><code>-tilde-</code></p>
|
||
<p>After an initial tilde (‘<code>~</code>’), but before the first slash in the word.</p>
|
||
<p><span id="index-_002dvalue_002d_002c-completion-context"></span></p>
|
||
<p><code>-value-</code></p>
|
||
<p>On the right hand side of an assignment.</p>
|
||
<p>Default implementations are supplied for each of these contexts. In most
|
||
cases the context <code>-``context``-</code> is implemented by a corresponding
|
||
function <code>_``context</code>, for example the context ‘<code>-tilde-</code>’ and the
|
||
function ‘<code>_tilde</code>’).</p>
|
||
<p>The contexts <code>-redirect-</code> and <code>-value-</code> allow extra context-specific
|
||
information. (Internally, this is handled by the functions for each
|
||
context calling the function <code>_dispatch</code>.) The extra information is
|
||
added separated by commas.</p>
|
||
<p>For the <code>-redirect-</code> context, the extra information is in the form
|
||
‘<code>-redirect-,``op``,``command</code>’, where <code>op</code> is the redirection
|
||
operator and <code>command</code> is the name of the command on the line. If there
|
||
is no command on the line yet, the <code>command</code> field will be empty.</p>
|
||
<p>For the <code>-value-</code> context, the form is ‘<code>-value-,``name``,``command</code>’,
|
||
where <code>name</code> is the name of the parameter on the left hand side of the
|
||
assignment. In the case of elements of an associative array, for example
|
||
‘<code>assoc=(key <TAB></code>’, <code>name</code> is expanded to ‘<code>name``-``key</code>’. In certain
|
||
special contexts, such as completing after ‘<code>make CFLAGS=</code>’, the
|
||
<code>command</code> part gives the name of the command, here <code>make</code>; otherwise it
|
||
is empty.</p>
|
||
<p>It is not necessary to define fully specific completions as the
|
||
functions provided will try to generate completions by progressively
|
||
replacing the elements with ‘<code>-default-</code>’. For example, when completing
|
||
after ‘<code>foo=<TAB></code>’, <code>_value</code> will try the names ‘<code>-value-,foo,</code>’ (note
|
||
the empty <code>command</code> part), ‘<code>-value-,foo,-default-</code>’
|
||
and‘<code>-value-,-default-,-default-</code>’, in that order, until it finds a
|
||
function to handle the context.</p>
|
||
<p>As an example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compdef '_files -g "*.log"' '-redirect-,2>,-default-'
|
||
</code></pre>
|
||
</div>
|
||
<p>completes files matching ‘<code>*.log</code>’ after ‘<code>2> <TAB></code>’ for any command
|
||
with no more specific handler defined.</p>
|
||
<p>Also:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compdef _foo -value-,-default-,-default-
|
||
</code></pre>
|
||
</div>
|
||
<p>specifies that <code>_foo</code> provides completions for the values of parameters
|
||
for which no special function has been defined. This is usually handled
|
||
by the function <code>_value</code> itself.</p>
|
||
<p>The same lookup rules are used when looking up styles (as described
|
||
below); for example</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*:*:-redirect-,2>,*:*' file-patterns '*.log'
|
||
</code></pre>
|
||
</div>
|
||
<p>is another way to make completion after ‘<code>2> <TAB></code>’ complete files
|
||
matching ‘<code>*.log</code>’.</p>
|
||
<hr />
|
||
<p><span id="Functions-4"></span></p>
|
||
<h3 id="2023-functions"><a class="header" href="#2023-functions">20.2.3 Functions</a></h3>
|
||
<p>The following function is defined by <code>compinit</code> and may be called
|
||
directly.</p>
|
||
<p><span id="index-compdef"></span>
|
||
<span id="index-completion-system_002c-adding-definitions"></span></p>
|
||
<ul>
|
||
<li>
|
||
<p><code>compdef</code> [ <code>-ane</code> ] <code>function name</code> ... [ <code>-</code>{<code>p</code>|<code>P</code>} <code>pattern</code>
|
||
... [ <code>-N</code> <code>name</code> ...]]<br />
|
||
<code>compdef -d</code> <code>name</code> ...<br />
|
||
<code>compdef -k</code> [ <code>-an</code> ] <code>function style key-sequence</code> [
|
||
<code>key-sequence</code> ... ]<br />
|
||
<code>compdef -K</code> [ <code>-an</code> ] <code>function name style key-seq</code> [ <code>name style seq</code> ... ]<br />
|
||
The first form defines the <code>function</code> to call for completion in the
|
||
given contexts as described for the <code>#compdef</code> tag above.</p>
|
||
<p>Alternatively, all the arguments may have the form
|
||
‘<code>cmd``=``service</code>’. Here <code>service</code> should already have been
|
||
defined by ‘<code>cmd1``=``service</code>’ lines in <code>#compdef</code> files, as
|
||
described above. The argument for <code>cmd</code> will be completed in the
|
||
same way as <code>service</code>.</p>
|
||
<p>The <code>function</code> argument may alternatively be a string containing
|
||
almost any shell code. If the string contains an equal sign, the
|
||
above will take precedence. The option <code>-e</code> may be used to specify
|
||
the first argument is to be evaluated as shell code even if it
|
||
contains an equal sign. The string will be executed using the <code>eval</code>
|
||
builtin command to generate completions. This provides a way of
|
||
avoiding having to define a new completion function. For example, to
|
||
complete files ending in ‘<code>.h</code>’ as arguments to the command <code>foo</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compdef '_files -g "*.h"' foo
|
||
</code></pre>
|
||
</div>
|
||
<p>The option <code>-n</code> prevents any completions already defined for the
|
||
command or context from being overwritten.</p>
|
||
<p>The option <code>-d</code> deletes any completion defined for the command or
|
||
contexts listed.</p>
|
||
<p>The <code>name</code>s may also contain <code>-p</code>, <code>-P</code> and <code>-N</code> options as
|
||
described for the <code>#compdef</code> tag. The effect on the argument list is
|
||
identical, switching between definitions of patterns tried
|
||
initially, patterns tried finally, and normal commands and contexts.</p>
|
||
<p>The parameter <code>$_compskip</code> may be set by any function defined for a
|
||
pattern context. If it is set to a value containing the substring
|
||
‘<code>patterns</code>’ none of the pattern-functions will be called; if it
|
||
is set to a value containing the substring ‘<code>all</code>’, no other
|
||
function will be called. Setting <code>$_compskip</code> in this manner is of
|
||
particular utility when using the <code>-p</code> option, as otherwise the
|
||
dispatcher will move on to additional functions (likely the default
|
||
one) after calling the pattern-context one, which can mangle the
|
||
display of completion possibilities if not handled properly.</p>
|
||
<p>The form with <code>-k</code> defines a widget with the same name as the
|
||
<code>function</code> that will be called for each of the <code>key-sequence</code>s; this
|
||
is like the <code>#compdef -k</code> tag. The function should generate the
|
||
completions needed and will otherwise behave like the builtin widget
|
||
whose name is given as the <code>style</code> argument. The widgets usable for
|
||
this are: <code>complete-word</code>, <code>delete-char-or-list</code>,
|
||
<code>expand-or-complete</code>, <code>expand-or-complete-prefix</code>, <code>list-choices</code>,
|
||
<code>menu-complete</code>, <code>menu-expand-or-complete</code>, and
|
||
<code>reverse-menu-complete</code>, as well as <code>menu-select</code> if the
|
||
<code>zsh/complist</code> module is loaded. The option <code>-n</code> prevents the key
|
||
being bound if it is already to bound to something other than
|
||
<code>undefined-key</code>.</p>
|
||
<p>The form with <code>-K</code> is similar and defines multiple widgets based on
|
||
the same <code>function</code>, each of which requires the set of three
|
||
arguments <code>name</code>, <code>style</code> and <code>key-seq</code>uence, where the latter two
|
||
are as for <code>-k</code> and the first must be a unique widget name beginning
|
||
with an underscore.</p>
|
||
<p>Wherever applicable, the <code>-a</code> option makes the <code>function</code>
|
||
autoloadable, equivalent to <code> autoload -U ``function</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<p>The function <code>compdef</code> can be used to associate existing completion
|
||
functions with new commands. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compdef _pids foo
|
||
</code></pre>
|
||
</div>
|
||
<p>uses the function <code>_pids</code> to complete process IDs for the command <code>foo</code>.</p>
|
||
<p>Note also the <code>_gnu_generic</code> function described below, which can be used
|
||
to complete options for commands that understand the ‘<code>-``-help</code>’
|
||
option.</p>
|
||
<hr />
|
||
<p><span id="Completion-System-Configuration"></span>
|
||
<span id="Completion-System-Configuration-1"></span></p>
|
||
<h2 id="203-completion-system-configuration"><a class="header" href="#203-completion-system-configuration">20.3 Completion System Configuration</a></h2>
|
||
<p><span id="index-completion-system_002c-configuration"></span></p>
|
||
<p>This section gives a short overview of how the completion system works,
|
||
and then more detail on how users can configure how and when matches are
|
||
generated.</p>
|
||
<hr />
|
||
<p><span id="Overview-1"></span></p>
|
||
<h3 id="2031-overview"><a class="header" href="#2031-overview">20.3.1 Overview</a></h3>
|
||
<p>When completion is attempted somewhere on the command line the
|
||
completion system begins building the context. The context represents
|
||
everything that the shell knows about the meaning of the command line
|
||
and the significance of the cursor position. This takes account of a
|
||
number of things including the command word (such as ‘<code>grep</code>’ or
|
||
‘<code>zsh</code>’) and options to which the current word may be an argument
|
||
(such as the ‘<code>-o</code>’ option to <code>zsh</code> which takes a shell option as an
|
||
argument).</p>
|
||
<p>The context starts out very generic ("we are beginning a completion")
|
||
and becomes more specific as more is learned ("the current word is in a
|
||
position that is usually a command name" or "the current word might be a
|
||
variable name" and so on). Therefore the context will vary during the
|
||
same call to the completion system.</p>
|
||
<p>This context information is condensed into a string consisting of
|
||
multiple fields separated by colons, referred to simply as ‘the context’
|
||
in the remainder of the documentation. Note that a user of the
|
||
completion system rarely needs to compose a context string, unless for
|
||
example a new function is being written to perform completion for a new
|
||
command. What a user may need to do is compose a <em>style</em> pattern, which
|
||
is matched against a context when needed to look up context-sensitive
|
||
options that configure the completion system.</p>
|
||
<p>The next few paragraphs explain how a context is composed within the
|
||
completion function suite. Following that is discussion of how <em>styles</em>
|
||
are defined. Styles determine such things as how the matches are
|
||
generated, similarly to shell options but with much more control. They
|
||
are defined with the <code>zstyle</code> builtin command (<a href="Zsh-Modules.html#The-zsh_002fzutil-Module">The zsh/zutil
|
||
Module</a>).</p>
|
||
<p>The context string always consists of a fixed set of fields, separated
|
||
by colons and with a leading colon before the first. Fields which are
|
||
not yet known are left empty, but the surrounding colons appear anyway.
|
||
The fields are always in the order
|
||
<code>:completion:``function``:``completer``:``command``:``argument``:``tag</code>.
|
||
These have the following meaning:</p>
|
||
<ul>
|
||
<li>The literal string <code>completion</code>, saying that this style is used by
|
||
the completion system. This distinguishes the context from those
|
||
used by, for example, zle widgets and ZFTP functions.</li>
|
||
<li>The <code>function</code>, if completion is called from a named widget rather
|
||
than through the normal completion system. Typically this is blank,
|
||
but it is set by special widgets such as <code>predict-on</code> and the
|
||
various functions in the <code>Widget</code> directory of the distribution to
|
||
the name of that function, often in an abbreviated form.</li>
|
||
<li>The <code>completer</code> currently active, the name of the function without
|
||
the leading underscore and with other underscores converted to
|
||
hyphens. A ‘completer’ is in overall control of how completion is to
|
||
be performed; ‘<code>complete</code>’ is the simplest, but other completers
|
||
exist to perform related tasks such as correction, or to modify the
|
||
behaviour of a later completer. See <a href="Completion-System.html#Control-Functions">Control
|
||
Functions</a> for more information.</li>
|
||
<li>The <code>command</code> or a special <code>-``context``-</code>, just at it appears
|
||
following the <code>#compdef</code> tag or the <code>compdef</code> function. Completion
|
||
functions for commands that have sub-commands usually modify this
|
||
field to contain the name of the command followed by a minus sign
|
||
and the sub-command. For example, the completion function for the
|
||
<code>cvs</code> command sets this field to <code>cvs-add</code> when completing arguments
|
||
to the <code>add</code> subcommand.</li>
|
||
<li>The <code>argument</code>; this indicates which command line or option argument
|
||
we are completing. For command arguments this generally takes the
|
||
form <code>argument-``n</code>, where <code>n</code> is the number of the argument, and
|
||
for arguments to options the form <code>option-``opt``-``n</code> where <code>n</code> is
|
||
the number of the argument to option <code>opt</code>. However, this is only
|
||
the case if the command line is parsed with standard UNIX-style
|
||
options and arguments, so many completions do not set this.</li>
|
||
<li>The <code>tag</code>. As described previously, tags are used to discriminate
|
||
between the types of matches a completion function can generate in a
|
||
certain context. Any completion function may use any tag name it
|
||
likes, but a list of the more common ones is given below.</li>
|
||
</ul>
|
||
<p>The context is gradually put together as the functions are executed,
|
||
starting with the main entry point, which adds <code>:completion:</code> and the
|
||
<code>function</code> element if necessary. The completer then adds the <code>completer</code>
|
||
element. The contextual completion adds the <code>command</code> and <code>argument</code>
|
||
options. Finally, the <code>tag</code> is added when the types of completion are
|
||
known. For example, the context name</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">:completion::complete:dvips:option-o-1:files
|
||
</code></pre>
|
||
</div>
|
||
<p>says that normal completion was attempted as the first argument to the
|
||
option <code>-o</code> of the command <code>dvips</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">dvips -o ...
|
||
</code></pre>
|
||
</div>
|
||
<p>and the completion function will generate filenames.</p>
|
||
<p>Usually completion will be tried for all possible tags in an order given
|
||
by the completion function. However, this can be altered by using the
|
||
<code>tag-order</code> style. Completion is then restricted to the list of given
|
||
tags in the given order.</p>
|
||
<p>The <code>_complete_help</code> bindable command shows all the contexts and tags
|
||
available for completion at a particular point. This provides an easy
|
||
way of finding information for <code>tag-order</code> and other styles. It is
|
||
described in <a href="Completion-System.html#Bindable-Commands">Bindable Commands</a>.</p>
|
||
<p>When looking up styles the completion system uses full context names,
|
||
including the tag. Looking up the value of a style therefore consists of
|
||
two things: the context, which is matched to the most specific (best
|
||
fitting) style pattern, and the name of the style itself, which must be
|
||
matched exactly. The following examples demonstrate that style patterns
|
||
may be loosely defined for styles that apply broadly, or as tightly
|
||
defined as desired for styles that apply in narrower circumstances.</p>
|
||
<p>For example, many completion functions can generate matches in a simple
|
||
and a verbose form and use the <code>verbose</code> style to decide which form
|
||
should be used. To make all such functions use the verbose form, put</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*' verbose yes
|
||
</code></pre>
|
||
</div>
|
||
<p>in a startup file (probably <code>.zshrc</code>). This gives the <code>verbose</code> style
|
||
the value <code>yes</code> in every context inside the completion system, unless
|
||
that context has a more specific definition. It is best to avoid giving
|
||
the context as ‘<code>*</code>’ in case the style has some meaning outside the
|
||
completion system.</p>
|
||
<p>Many such general purpose styles can be configured simply by using the
|
||
<code>compinstall</code> function.</p>
|
||
<p>A more specific example of the use of the <code>verbose</code> style is by the
|
||
completion for the <code>kill</code> builtin. If the style is set, the builtin
|
||
lists full job texts and process command lines; otherwise it shows the
|
||
bare job numbers and PIDs. To turn the style off for this use only:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*:*:kill:*:*' verbose no
|
||
</code></pre>
|
||
</div>
|
||
<p>For even more control, the style can use one of the tags ‘<code>jobs</code>’ or
|
||
‘<code>processes</code>’. To turn off verbose display only for jobs:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*:*:kill:*:jobs' verbose no
|
||
</code></pre>
|
||
</div>
|
||
<p>The <code>-e</code> option to <code>zstyle</code> even allows completion function code to
|
||
appear as the argument to a style; this requires some understanding of
|
||
the internals of completion functions (see <a href="Completion-Widgets.html#Completion-Widgets">Completion
|
||
Widgets</a>)). For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle -e ':completion:*' hosts 'reply=($myhosts)'
|
||
</code></pre>
|
||
</div>
|
||
<p>This forces the value of the <code>hosts</code> style to be read from the variable
|
||
<code>myhosts</code> each time a host name is needed; this is useful if the value
|
||
of <code>myhosts</code> can change dynamically. For another useful example, see the
|
||
example in the description of the <code>file-list</code> style below. This form can
|
||
be slow and should be avoided for commonly examined styles such as
|
||
<code>menu</code> and <code>list-rows-first</code>.</p>
|
||
<p>Note that the order in which styles are <em>defined</em> does not matter; the
|
||
style mechanism uses the most specific possible match for a particular
|
||
style to determine the set of values. More precisely, strings are
|
||
preferred over patterns (for example, ‘<code>:completion::complete:::foo</code>’ is
|
||
more specific than ‘<code>:completion::complete:::*’</code>), and longer patterns
|
||
are preferred over shorter patterns.</p>
|
||
<p>A good rule of thumb is that any completion style pattern that needs to
|
||
include more than one wildcard (<code>*</code>) and that does not end in a tag
|
||
name, should include all six colons (<code>:</code>), possibly surrounding
|
||
additional wildcards.</p>
|
||
<p>Style names like those of tags are arbitrary and depend on the
|
||
completion function. However, the following two sections list some of
|
||
the most common tags and styles.</p>
|
||
<hr />
|
||
<p><span id="Standard-Tags"></span></p>
|
||
<h3 id="2032-standard-tags"><a class="header" href="#2032-standard-tags">20.3.2 Standard Tags</a></h3>
|
||
<p><span id="index-completion-system_002c-tags"></span></p>
|
||
<p>Some of the following are only used when looking up particular styles
|
||
and do not refer to a type of match.</p>
|
||
<p><span id="index-accounts_002c-completion-tag"></span></p>
|
||
<p><code>accounts</code></p>
|
||
<p>used to look up the <code>users-hosts</code> style</p>
|
||
<p><span id="index-all_002dexpansions_002c-completion-tag"></span></p>
|
||
<p><code>all-expansions</code></p>
|
||
<p>used by the <code>_expand</code> completer when adding the single string containing
|
||
all possible expansions</p>
|
||
<p><span id="index-all_002dfiles_002c-completion-tag"></span></p>
|
||
<p><code>all-files</code></p>
|
||
<p>for the names of all files (as distinct from a particular subset, see
|
||
the <code>globbed-files</code> tag).</p>
|
||
<p><span id="index-arguments_002c-completion-tag"></span></p>
|
||
<p><code>arguments</code></p>
|
||
<p>for arguments to a command</p>
|
||
<p><span id="index-arrays_002c-completion-tag"></span></p>
|
||
<p><code>arrays</code></p>
|
||
<p>for names of array parameters</p>
|
||
<p><span id="index-association_002dkeys_002c-completion-tag"></span></p>
|
||
<p><code>association-keys</code></p>
|
||
<p>for keys of associative arrays; used when completing inside a subscript
|
||
to a parameter of this type</p>
|
||
<p><span id="index-bookmarks_002c-completion-tag"></span></p>
|
||
<p><code>bookmarks</code></p>
|
||
<p>when completing bookmarks (e.g. for URLs and the <code>zftp</code> function suite)</p>
|
||
<p><span id="index-builtins_002c-completion-tag"></span></p>
|
||
<p><code>builtins</code></p>
|
||
<p>for names of builtin commands</p>
|
||
<p><span id="index-characters_002c-completion-tag"></span></p>
|
||
<p><code>characters</code></p>
|
||
<p>for single characters in arguments of commands such as <code>stty</code>. Also used
|
||
when completing character classes after an opening bracket</p>
|
||
<p><span id="index-colormapids_002c-completion-tag"></span></p>
|
||
<p><code>colormapids</code></p>
|
||
<p>for X colormap ids</p>
|
||
<p><span id="index-colors_002c-completion-tag"></span></p>
|
||
<p><code>colors</code></p>
|
||
<p>for color names</p>
|
||
<p><span id="index-commands_002c-completion-tag"></span></p>
|
||
<p><code>commands</code></p>
|
||
<p>for names of external commands. Also used by complex commands such as
|
||
<code>cvs</code> when completing names subcommands.</p>
|
||
<p><span id="index-contexts_002c-completion-tag"></span></p>
|
||
<p><code>contexts</code></p>
|
||
<p>for contexts in arguments to the <code>zstyle</code> builtin command</p>
|
||
<p><span id="index-corrections_002c-completion-tag"></span></p>
|
||
<p><code>corrections</code></p>
|
||
<p>used by the <code>_approximate</code> and <code>_correct</code> completers for possible
|
||
corrections</p>
|
||
<p><span id="index-cursors_002c-completion-tag"></span></p>
|
||
<p><code>cursors</code></p>
|
||
<p>for cursor names used by X programs</p>
|
||
<p><span id="index-default_002c-completion-tag"></span></p>
|
||
<p><code>default</code></p>
|
||
<p>used in some contexts to provide a way of supplying a default when more
|
||
specific tags are also valid. Note that this tag is used when only the
|
||
<code>function</code> field of the context name is set</p>
|
||
<p><span id="index-descriptions_002c-completion-tag"></span></p>
|
||
<p><code>descriptions</code></p>
|
||
<p>used when looking up the value of the <code>format</code> style to generate
|
||
descriptions for types of matches</p>
|
||
<p><span id="index-devices_002c-completion-tag"></span></p>
|
||
<p><code>devices</code></p>
|
||
<p>for names of device special files</p>
|
||
<p><span id="index-directories_002c-completion-tag"></span></p>
|
||
<p><code>directories</code></p>
|
||
<p>for names of directories — <code>local-directories</code> is used instead when
|
||
completing arguments of <code>cd</code> and related builtin commands when the
|
||
<code>cdpath</code> array is set</p>
|
||
<p><span id="index-directory_002dstack_002c-completion-tag"></span></p>
|
||
<p><code>directory-stack</code></p>
|
||
<p>for entries in the directory stack</p>
|
||
<p><span id="index-displays_002c-completion-tag"></span></p>
|
||
<p><code>displays</code></p>
|
||
<p>for X display names</p>
|
||
<p><span id="index-domains_002c-completion-tag"></span></p>
|
||
<p><code>domains</code></p>
|
||
<p>for network domains</p>
|
||
<p><span id="index-email_002d_002a_002c-completion-tag"></span></p>
|
||
<p><code>email-``plugin</code></p>
|
||
<p>for email addresses from the ‘<code>_email-``plugin</code>’ backend of
|
||
<code>_email_addresses</code></p>
|
||
<p><span id="index-expansions_002c-completion-tag"></span></p>
|
||
<p><code>expansions</code></p>
|
||
<p>used by the <code>_expand</code> completer for individual words (as opposed to the
|
||
complete set of expansions) resulting from the expansion of a word on
|
||
the command line</p>
|
||
<p><span id="index-extensions_002c-completion-tag"></span></p>
|
||
<p><code>extensions</code></p>
|
||
<p>for X server extensions</p>
|
||
<p><span id="index-file_002ddescriptors_002c-completion-tag"></span></p>
|
||
<p><code>file-descriptors</code></p>
|
||
<p>for numbers of open file descriptors</p>
|
||
<p><span id="index-files_002c-completion-tag"></span></p>
|
||
<p><code>files</code></p>
|
||
<p>the generic file-matching tag used by functions completing filenames</p>
|
||
<p><span id="index-fonts_002c-completion-tag"></span></p>
|
||
<p><code>fonts</code></p>
|
||
<p>for X font names</p>
|
||
<p><span id="index-fstypes_002c-completion-tag"></span></p>
|
||
<p><code>fstypes</code></p>
|
||
<p>for file system types (e.g. for the <code>mount</code> command)</p>
|
||
<p><span id="index-functions_002c-completion-tag"></span></p>
|
||
<p><code>functions</code></p>
|
||
<p>names of functions — normally shell functions, although certain commands
|
||
may understand other kinds of function</p>
|
||
<p><span id="index-globbed_002dfiles_002c-completion-tag"></span></p>
|
||
<p><code>globbed-files</code></p>
|
||
<p>for filenames when the name has been generated by pattern matching</p>
|
||
<p><span id="index-groups_002c-completion-tag"></span></p>
|
||
<p><code>groups</code></p>
|
||
<p>for names of user groups</p>
|
||
<p><span id="index-history_002dwords_002c-completion-tag"></span></p>
|
||
<p><code>history-words</code></p>
|
||
<p>for words from the history</p>
|
||
<p><span id="index-hosts_002c-completion-tag"></span></p>
|
||
<p><code>hosts</code></p>
|
||
<p>for hostnames</p>
|
||
<p><span id="index-indexes_002c-completion-tag"></span></p>
|
||
<p><code>indexes</code></p>
|
||
<p>for array indexes</p>
|
||
<p><span id="index-jobs_002c-completion-tag"></span></p>
|
||
<p><code>jobs</code></p>
|
||
<p>for jobs (as listed by the ‘<code>jobs</code>’ builtin)</p>
|
||
<p><span id="index-interfaces_002c-completion-tag"></span></p>
|
||
<p><code>interfaces</code></p>
|
||
<p>for network interfaces</p>
|
||
<p><span id="index-keymaps_002c-completion-tag"></span></p>
|
||
<p><code>keymaps</code></p>
|
||
<p>for names of zsh keymaps</p>
|
||
<p><span id="index-keysyms_002c-completion-tag"></span></p>
|
||
<p><code>keysyms</code></p>
|
||
<p>for names of X keysyms</p>
|
||
<p><span id="index-libraries_002c-completion-tag"></span></p>
|
||
<p><code>libraries</code></p>
|
||
<p>for names of system libraries</p>
|
||
<p><span id="index-limits_002c-completion-tag"></span></p>
|
||
<p><code>limits</code></p>
|
||
<p>for system limits</p>
|
||
<p><span id="index-local_002ddirectories_002c-completion-tag"></span></p>
|
||
<p><code>local-directories</code></p>
|
||
<p>for names of directories that are subdirectories of the current working
|
||
directory when completing arguments of <code>cd</code> and related builtin commands
|
||
(compare <code>path-directories</code>) — when the <code>cdpath</code> array is unset,
|
||
<code>directories</code> is used instead</p>
|
||
<p><span id="index-manuals_002c-completion-tag"></span></p>
|
||
<p><code>manuals</code></p>
|
||
<p>for names of manual pages</p>
|
||
<p><span id="index-mailboxes_002c-completion-tag"></span></p>
|
||
<p><code>mailboxes</code></p>
|
||
<p>for e-mail folders</p>
|
||
<p><span id="index-maps_002c-completion-tag"></span></p>
|
||
<p><code>maps</code></p>
|
||
<p>for map names (e.g. NIS maps)</p>
|
||
<p><span id="index-messages_002c-completion-tag"></span></p>
|
||
<p><code>messages</code></p>
|
||
<p>used to look up the <code>format</code> style for messages</p>
|
||
<p><span id="index-modifiers_002c-completion-tag"></span></p>
|
||
<p><code>modifiers</code></p>
|
||
<p>for names of X modifiers</p>
|
||
<p><span id="index-modules_002c-completion-tag"></span></p>
|
||
<p><code>modules</code></p>
|
||
<p>for modules (e.g. <code>zsh</code> modules)</p>
|
||
<p><span id="index-my_002daccounts_002c-completion-tag"></span></p>
|
||
<p><code>my-accounts</code></p>
|
||
<p>used to look up the <code>users-hosts</code> style</p>
|
||
<p><span id="index-named_002ddirectories_002c-completion-tag"></span></p>
|
||
<p><code>named-directories</code></p>
|
||
<p>for named directories (you wouldn’t have guessed that, would you?)</p>
|
||
<p><span id="index-names_002c-completion-tag"></span></p>
|
||
<p><code>names</code></p>
|
||
<p>for all kinds of names</p>
|
||
<p><span id="index-newsgroups_002c-completion-tag"></span></p>
|
||
<p><code>newsgroups</code></p>
|
||
<p>for USENET groups</p>
|
||
<p><span id="index-nicknames_002c-completion-tag"></span></p>
|
||
<p><code>nicknames</code></p>
|
||
<p>for nicknames of NIS maps</p>
|
||
<p><span id="index-options_002c-completion-tag"></span></p>
|
||
<p><code>options</code></p>
|
||
<p>for command options</p>
|
||
<p><span id="index-original_002c-completion-tag"></span></p>
|
||
<p><code>original</code></p>
|
||
<p>used by the <code>_approximate</code>, <code>_correct</code> and <code>_expand</code> completers when
|
||
offering the original string as a match</p>
|
||
<p><span id="index-other_002daccounts_002c-completion-tag"></span></p>
|
||
<p><code>other-accounts</code></p>
|
||
<p>used to look up the <code>users-hosts</code> style</p>
|
||
<p><span id="index-other_002dfiles_002c-completion-tag"></span></p>
|
||
<p><code>other-files</code></p>
|
||
<p>for the names of any non-directory files. This is used instead of
|
||
<code>all-files</code> when the <code>list-dirs-first</code> style is in effect.</p>
|
||
<p><span id="index-packages_002c-completion-tag"></span></p>
|
||
<p><code>packages</code></p>
|
||
<p>for packages (e.g. <code>rpm</code> or installed <code>Debian</code> packages)</p>
|
||
<p><span id="index-parameters_002c-completion-tag"></span></p>
|
||
<p><code>parameters</code></p>
|
||
<p>for names of parameters</p>
|
||
<p><span id="index-path_002ddirectories_002c-completion-tag"></span></p>
|
||
<p><code>path-directories</code></p>
|
||
<p>for names of directories found by searching the <code>cdpath</code> array when
|
||
completing arguments of <code>cd</code> and related builtin commands (compare
|
||
<code>local-directories</code>)</p>
|
||
<p><span id="index-paths_002c-completion-tag"></span></p>
|
||
<p><code>paths</code></p>
|
||
<p>used to look up the values of the <code>expand</code>, <code>ambiguous</code> and
|
||
<code>special-dirs</code> styles</p>
|
||
<p><span id="index-pods_002c-completion-tag"></span></p>
|
||
<p><code>pods</code></p>
|
||
<p>for perl pods (documentation files)</p>
|
||
<p><span id="index-ports_002c-completion-tag"></span></p>
|
||
<p><code>ports</code></p>
|
||
<p>for communication ports</p>
|
||
<p><span id="index-prefixes_002c-completion-tag"></span></p>
|
||
<p><code>prefixes</code></p>
|
||
<p>for prefixes (like those of a URL)</p>
|
||
<p><span id="index-printers_002c-completion-tag"></span></p>
|
||
<p><code>printers</code></p>
|
||
<p>for print queue names</p>
|
||
<p><span id="index-processes_002c-completion-tag"></span></p>
|
||
<p><code>processes</code></p>
|
||
<p>for process identifiers</p>
|
||
<p><span id="index-processes_002dnames_002c-completion-tag"></span></p>
|
||
<p><code>processes-names</code></p>
|
||
<p>used to look up the <code>command</code> style when generating the names of
|
||
processes for <code>killall</code></p>
|
||
<p><span id="index-sequences_002c-completion-tag"></span></p>
|
||
<p><code>sequences</code></p>
|
||
<p>for sequences (e.g. <code>mh</code> sequences)</p>
|
||
<p><span id="index-sessions_002c-completion-tag"></span></p>
|
||
<p><code>sessions</code></p>
|
||
<p>for sessions in the <code>zftp</code> function suite</p>
|
||
<p><span id="index-signals_002c-completion-tag"></span></p>
|
||
<p><code>signals</code></p>
|
||
<p>for signal names</p>
|
||
<p><span id="index-strings_002c-completion-tag"></span></p>
|
||
<p><code>strings</code></p>
|
||
<p>for strings (e.g. the replacement strings for the <code>cd</code> builtin command)</p>
|
||
<p><span id="index-styles_002c-completion-tag"></span></p>
|
||
<p><code>styles</code></p>
|
||
<p>for styles used by the zstyle builtin command</p>
|
||
<p><span id="index-suffixes_002c-completion-tag"></span></p>
|
||
<p><code>suffixes</code></p>
|
||
<p>for filename extensions</p>
|
||
<p><span id="index-tags_002c-completion-tag"></span></p>
|
||
<p><code>tags</code></p>
|
||
<p>for tags (e.g. <code>rpm</code> tags)</p>
|
||
<p><span id="index-targets_002c-completion-tag"></span></p>
|
||
<p><code>targets</code></p>
|
||
<p>for makefile targets</p>
|
||
<p><span id="index-time_002dzones_002c-completion-tag"></span></p>
|
||
<p><code>time-zones</code></p>
|
||
<p>for time zones (e.g. when setting the <code>TZ</code> parameter)</p>
|
||
<p><span id="index-types_002c-completion-tag"></span></p>
|
||
<p><code>types</code></p>
|
||
<p>for types of whatever (e.g. address types for the <code>xhost</code> command)</p>
|
||
<p><span id="index-urls_002c-completion-tag"></span></p>
|
||
<p><code>urls</code></p>
|
||
<p>used to look up the <code>urls</code> and <code>local</code> styles when completing URLs</p>
|
||
<p><span id="index-users_002c-completion-tag"></span></p>
|
||
<p><code>users</code></p>
|
||
<p>for usernames</p>
|
||
<p><span id="index-values_002c-completion-tag"></span></p>
|
||
<p><code>values</code></p>
|
||
<p>for one of a set of values in certain lists</p>
|
||
<p><span id="index-variant_002c-completion-tag"></span></p>
|
||
<p><code>variant</code></p>
|
||
<p>used by <code>_pick_variant</code> to look up the command to run when determining
|
||
what program is installed for a particular command name.</p>
|
||
<p><span id="index-visuals_002c-completion-tag"></span></p>
|
||
<p><code>visuals</code></p>
|
||
<p>for X visuals</p>
|
||
<p><span id="index-warnings_002c-completion-tag"></span></p>
|
||
<p><code>warnings</code></p>
|
||
<p>used to look up the <code>format</code> style for warnings</p>
|
||
<p><span id="index-widgets_002c-completion-tag"></span></p>
|
||
<p><code>widgets</code></p>
|
||
<p>for zsh widget names</p>
|
||
<p><span id="index-windows_002c-completion-tag"></span></p>
|
||
<p><code>windows</code></p>
|
||
<p>for IDs of X windows</p>
|
||
<p><span id="index-zsh_002doptions_002c-completion-tag"></span></p>
|
||
<p><code>zsh-options</code></p>
|
||
<p>for shell options</p>
|
||
<hr />
|
||
<p><span id="Standard-Styles"></span></p>
|
||
<h3 id="2033-standard-styles"><a class="header" href="#2033-standard-styles">20.3.3 Standard Styles</a></h3>
|
||
<p><span id="index-completion-system_002c-styles"></span></p>
|
||
<p>Note that the values of several of these styles represent boolean
|
||
values. Any of the strings ‘<code>true</code>’, ‘<code>on</code>’, ‘<code>yes</code>’, and ‘<code>1</code>’ can be
|
||
used for the value ‘true’ and any of the strings ‘<code>false</code>’, ‘<code>off</code>’,
|
||
‘<code>no</code>’, and ‘<code>0</code>’ for the value ‘false’. The behavior for any other
|
||
value is undefined except where explicitly mentioned. The default value
|
||
may be either ‘true’ or ‘false’ if the style is not set.</p>
|
||
<p>Some of these styles are tested first for every possible tag
|
||
corresponding to a type of match, and if no style was found, for the
|
||
<code>list-colors</code> and styles controlling completion listing such as
|
||
<code>list-packed</code> and <code>last-prompt</code>. When tested for the <code>default</code> tag, only
|
||
the <code>function</code> field of the context will be set so that a style using
|
||
the <code>default</code> tag will normally be defined along the lines of:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*:default' menu ...
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-accept_002dexact_002c-completion-style"></span></p>
|
||
<p><code>accept-exact</code></p>
|
||
<p>This is tested for the <code>default</code> tag in addition to the tags valid for
|
||
the current context. If it is set to ‘true’ and any of the trial matches
|
||
is the same as the string on the command line, this match will
|
||
immediately be accepted (even if it would otherwise be considered
|
||
ambiguous).</p>
|
||
<p>When completing pathnames (where the tag used is ‘<code>paths</code>’) this style
|
||
accepts any number of patterns as the value in addition to the boolean
|
||
values. Pathnames matching one of these patterns will be accepted
|
||
immediately even if the command line contains some more partially typed
|
||
pathname components and these match no file under the directory
|
||
accepted.</p>
|
||
<p>This style is also used by the <code>_expand</code> completer to decide if words
|
||
beginning with a tilde or parameter expansion should be expanded. For
|
||
example, if there are parameters <code>foo</code> and <code>foobar</code>, the string ‘<code>$foo</code>’
|
||
will only be expanded if <code>accept-exact</code> is set to ‘true’; otherwise the
|
||
completion system will be allowed to complete <code>$foo</code> to <code>$foobar</code>. If
|
||
the style is set to ‘<code>continue</code>’, <code>_expand</code> will add the expansion as a
|
||
match and the completion system will also be allowed to continue.</p>
|
||
<p><span id="index-accept_002dexact_002ddirs_002c-completion-style"></span></p>
|
||
<p><code>accept-exact-dirs</code></p>
|
||
<p>This is used by filename completion. Unlike <code>accept-exact</code> it is a
|
||
boolean. By default, filename completion examines all components of a
|
||
path to see if there are completions of that component, even if the
|
||
component matches an existing directory. For example, when completion
|
||
after <code>/usr/bin/</code>, the function examines possible completions to <code>/usr</code>.</p>
|
||
<p>When this style is ‘true’, any prefix of a path that matches an existing
|
||
directory is accepted without any attempt to complete it further. Hence,
|
||
in the given example, the path <code>/usr/bin/</code> is accepted immediately and
|
||
completion tried in that directory.</p>
|
||
<p>This style is also useful when completing after directories that
|
||
magically appear when referenced, such as ZFS <code>.zfs</code> directories or
|
||
NetApp <code>.snapshot</code> directories. When the style is set the shell does not
|
||
check for the existence of the directory within the parent directory.</p>
|
||
<p>If you wish to inhibit this behaviour entirely, set the
|
||
<code>path-completion</code> style (see below) to ‘false’.</p>
|
||
<p><span id="index-add_002dspace_002c-completion-style"></span></p>
|
||
<p><code>add-space</code></p>
|
||
<p>This style is used by the <code>_expand</code> completer. If it is ‘true’ (the
|
||
default), a space will be inserted after all words resulting from the
|
||
expansion, or a slash in the case of directory names. If the value is
|
||
‘<code>file</code>’, the completer will only add a space to names of existing
|
||
files. Either a boolean ‘true’ or the value ‘<code>file</code>’ may be combined
|
||
with ‘<code>subst</code>’, in which case the completer will not add a space to
|
||
words generated from the expansion of a substitution of the form
|
||
‘<code>$(``...``)</code>’ or ‘<code>${``...``}</code>’.</p>
|
||
<p>The <code>_prefix</code> completer uses this style as a simple boolean value to
|
||
decide if a space should be inserted before the suffix.</p>
|
||
<p><span id="index-ambiguous_002c-completion-style"></span></p>
|
||
<p><code>ambiguous</code></p>
|
||
<p>This applies when completing non-final components of filename paths, in
|
||
other words those with a trailing slash. If it is set, the cursor is
|
||
left after the first ambiguous component, even if menu completion is in
|
||
use. The style is always tested with the <code>paths</code> tag.</p>
|
||
<p><span id="index-assign_002dlist_002c-completion-style"></span></p>
|
||
<p><code>assign-list</code></p>
|
||
<p>When completing after an equals sign that is being treated as an
|
||
assignment, the completion system normally completes only one filename.
|
||
In some cases the value may be a list of filenames separated by colons,
|
||
as with <code>PATH</code> and similar parameters. This style can be set to a list
|
||
of patterns matching the names of such parameters.</p>
|
||
<p>The default is to complete lists when the word on the line already
|
||
contains a colon.</p>
|
||
<p><span id="index-auto_002ddescription_002c-completion-style"></span></p>
|
||
<p><code>auto-description</code></p>
|
||
<p>If set, this style’s value will be used as the description for options
|
||
that are not described by the completion functions, but that have
|
||
exactly one argument. The sequence ‘<code>%d</code>’ in the value will be replaced
|
||
by the description for this argument. Depending on personal preferences,
|
||
it may be useful to set this style to something like ‘<code>specify: %d</code>’.
|
||
Note that this may not work for some commands.</p>
|
||
<p><span id="index-avoid_002dcompleter_002c-completion-style"></span></p>
|
||
<p><code>avoid-completer</code></p>
|
||
<p>This is used by the <code>_all_matches</code> completer to decide if the string
|
||
consisting of all matches should be added to the list currently being
|
||
generated. Its value is a list of names of completers. If any of these
|
||
is the name of the completer that generated the matches in this
|
||
completion, the string will not be added.</p>
|
||
<p>The default value for this style is ‘<code>_expand _old_list _correct _approximate</code>’, i.e. it contains the completers for which a string with
|
||
all matches will almost never be wanted.</p>
|
||
<p><span id="index-cache_002dpath_002c-completion-style"></span></p>
|
||
<p><code>cache-path</code></p>
|
||
<p>This style defines the path where any cache files containing dumped
|
||
completion data are stored. It defaults to ‘<code>$ZDOTDIR/.zcompcache</code>’, or
|
||
‘<code>$HOME/.zcompcache</code>’ if <code>$ZDOTDIR</code> is not defined. The completion
|
||
cache will not be used unless the <code>use-cache</code> style is set.</p>
|
||
<p><span id="index-cache_002dpolicy_002c-completion-style"></span></p>
|
||
<p><code>cache-policy</code></p>
|
||
<p>This style defines the function that will be used to determine whether a
|
||
cache needs rebuilding. See the section on the <code>_cache_invalid</code> function
|
||
below.</p>
|
||
<p><span id="index-call_002dcommand_002c-completion-style"></span></p>
|
||
<p><code>call-command</code></p>
|
||
<p>This style is used in the function for commands such as <code>make</code> and <code>ant</code>
|
||
where calling the command directly to generate matches suffers problems
|
||
such as being slow or, as in the case of <code>make</code> can potentially cause
|
||
actions in the makefile to be executed. If it is set to ‘true’ the
|
||
command is called to generate matches. The default value of this style
|
||
is ‘false’.</p>
|
||
<p><span id="index-command_002c-completion-style"></span></p>
|
||
<p><code>command</code></p>
|
||
<p>In many places, completion functions need to call external commands to
|
||
generate the list of completions. This style can be used to override the
|
||
command that is called in some such cases. The elements of the value are
|
||
joined with spaces to form a command line to execute. The value can also
|
||
start with a hyphen, in which case the usual command will be added to
|
||
the end; this is most useful for putting ‘<code>builtin</code>’ or ‘<code>command</code>’ in
|
||
front to make sure the appropriate version of a command is called, for
|
||
example to avoid calling a shell function with the same name as an
|
||
external command.</p>
|
||
<p>As an example, the completion function for process IDs uses this style
|
||
with the <code>processes</code> tag to generate the IDs to complete and the list of
|
||
processes to display (if the <code>verbose</code> style is ‘true’). The list
|
||
produced by the command should look like the output of the <code>ps</code> command.
|
||
The first line is not displayed, but is searched for the string ‘<code>PID</code>’
|
||
(or ‘<code>pid</code>’) to find the position of the process IDs in the following
|
||
lines. If the line does not contain ‘<code>PID</code>’, the first numbers in each
|
||
of the other lines are taken as the process IDs to complete.</p>
|
||
<p>Note that the completion function generally has to call the specified
|
||
command for each attempt to generate the completion list. Hence care
|
||
should be taken to specify only commands that take a short time to run,
|
||
and in particular to avoid any that may never terminate.</p>
|
||
<p><span id="index-command_002dpath_002c-completion-style"></span></p>
|
||
<p><code>command-path</code></p>
|
||
<p>This is a list of directories to search for commands to complete. The
|
||
default for this style is the value of the special parameter <code>path</code>.</p>
|
||
<p><span id="index-commands_002c-completion-style"></span></p>
|
||
<p><code>commands</code></p>
|
||
<p>This is used by the function completing sub-commands for the system
|
||
initialisation scripts (residing in <code>/etc/init.d</code> or somewhere not too
|
||
far away from that). Its values give the default commands to complete
|
||
for those commands for which the completion function isn’t able to find
|
||
them out automatically. The default for this style are the two strings
|
||
‘<code>start</code>’ and ‘<code>stop</code>’.</p>
|
||
<p><span id="index-complete_002c-completion-style"></span></p>
|
||
<p><code>complete</code></p>
|
||
<p>This is used by the <code>_expand_alias</code> function when invoked as a bindable
|
||
command. If set to ‘true’ and the word on the command line is not the
|
||
name of an alias, matching alias names will be completed.</p>
|
||
<p><span id="index-complete_002doptions_002c-completion-style"></span></p>
|
||
<p><code>complete-options</code></p>
|
||
<p>This is used by the completer for <code>cd</code>, <code>chdir</code> and <code>pushd</code>. For these
|
||
commands a <code>-</code> is used to introduce a directory stack entry and
|
||
completion of these is far more common than completing options. Hence
|
||
unless the value of this style is ‘true’ options will not be completed,
|
||
even after an initial <code>-</code>. If it is ‘true’, options will be completed
|
||
after an initial <code>-</code> unless there is a preceding <code>-``-</code> on the command
|
||
line.</p>
|
||
<p><span id="index-completer_002c-completion-style"></span></p>
|
||
<p><code>completer</code></p>
|
||
<p>The strings given as the value of this style provide the names of the
|
||
completer functions to use. The available completer functions are
|
||
described in <a href="Completion-System.html#Control-Functions">Control Functions</a>.</p>
|
||
<p>Each string may be either the name of a completer function or a string
|
||
of the form ‘<code>function``:``name</code>’. In the first case the <code>completer</code>
|
||
field of the context will contain the name of the completer without the
|
||
leading underscore and with all other underscores replaced by hyphens.
|
||
In the second case the <code>function</code> is the name of the completer to call,
|
||
but the context will contain the user-defined <code>name</code> in the <code>completer</code>
|
||
field of the context. If the <code>name</code> starts with a hyphen, the string for
|
||
the context will be build from the name of the completer function as in
|
||
the first case with the <code>name</code> appended to it. For example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*' completer _complete _complete:-foo
|
||
</code></pre>
|
||
</div>
|
||
<p>Here, completion will call the <code>_complete</code> completer twice, once using
|
||
‘<code>complete</code>’ and once using ‘<code>complete-foo</code>’ in the <code>completer</code> field
|
||
of the context. Normally, using the same completer more than once only
|
||
makes sense when used with the ‘<code>functions``:``name</code>’ form, because
|
||
otherwise the context name will be the same in all calls to the
|
||
completer; possible exceptions to this rule are the <code>_ignored</code> and
|
||
<code>_prefix</code> completers.</p>
|
||
<p>The default value for this style is ‘<code>_complete _ignored</code>’: only
|
||
completion will be done, first using the <code>ignored-patterns</code> style and
|
||
the <code>$fignore</code> array and then without ignoring matches.</p>
|
||
<p><span id="index-condition_002c-completion-style"></span></p>
|
||
<p><code>condition</code></p>
|
||
<p>This style is used by the <code>_list</code> completer function to decide if
|
||
insertion of matches should be delayed unconditionally. The default is
|
||
‘true’.</p>
|
||
<p><span id="index-delimiters_002c-completion-style"></span></p>
|
||
<p><code>delimiters</code></p>
|
||
<p>This style is used when adding a delimiter for use with history
|
||
modifiers or glob qualifiers that have delimited arguments. It is an
|
||
array of preferred delimiters to add. Non-special characters are
|
||
preferred as the completion system may otherwise become confused. The
|
||
default list is <code>:</code>, <code>+</code>, <code>/</code>, <code>-</code>, <code>%</code>. The list may be empty to force
|
||
a delimiter to be typed.</p>
|
||
<p><span id="index-disabled_002c-completion-style"></span></p>
|
||
<p><code>disabled</code></p>
|
||
<p>If this is set to ‘true’, the <code>_expand_alias</code> completer and bindable
|
||
command will try to expand disabled aliases, too. The default is
|
||
‘false’.</p>
|
||
<p><span id="index-domains_002c-completion-style"></span></p>
|
||
<p><code>domains</code></p>
|
||
<p>A list of names of network domains for completion. If this is not set,
|
||
domain names will be taken from the file <code>/etc/resolv.conf</code>.</p>
|
||
<p><span id="index-environ_002c-completion-style"></span></p>
|
||
<p><code>environ</code></p>
|
||
<p>The environ style is used when completing for ‘<code>sudo</code>’. It is set to an
|
||
array of ‘<code>VAR``=``value</code>’ assignments to be exported into the local
|
||
environment before the completion for the target command is invoked.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*:sudo::' environ \
|
||
PATH="/sbin:/usr/sbin:$PATH" HOME="/root"
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-expand_002c-completion-style"></span></p>
|
||
<p><code>expand</code></p>
|
||
<p>This style is used when completing strings consisting of multiple parts,
|
||
such as path names.</p>
|
||
<p>If one of its values is the string ‘<code>prefix</code>’, the partially typed word
|
||
from the line will be expanded as far as possible even if trailing parts
|
||
cannot be completed.</p>
|
||
<p>If one of its values is the string ‘<code>suffix</code>’, matching names for
|
||
components after the first ambiguous one will also be added. This means
|
||
that the resulting string is the longest unambiguous string possible.
|
||
However, menu completion can be used to cycle through all matches.</p>
|
||
<p><span id="index-fake_002c-completion-style"></span></p>
|
||
<p><code>fake</code></p>
|
||
<p>This style may be set for any completion context. It specifies
|
||
additional strings that will always be completed in that context. The
|
||
form of each string is ‘<code>value``:``description</code>’; the colon and
|
||
description may be omitted, but any literal colons in <code>value</code> must be
|
||
quoted with a backslash. Any <code>description</code> provided is shown alongside
|
||
the value in completion listings.</p>
|
||
<p>It is important to use a sufficiently restrictive context when
|
||
specifying fake strings. Note that the styles <code>fake-files</code> and
|
||
<code>fake-parameters</code> provide additional features when completing files or
|
||
parameters.</p>
|
||
<p><span id="index-fake_002dalways_002c-completion-style"></span></p>
|
||
<p><code>fake-always</code></p>
|
||
<p>This works identically to the <code>fake</code> style except that the
|
||
<code>ignored-patterns</code> style is not applied to it. This makes it possible to
|
||
override a set of matches completely by setting the ignored patterns to
|
||
‘<code>*</code>’.</p>
|
||
<p>The following shows a way of supplementing any tag with arbitrary data,
|
||
but having it behave for display purposes like a separate tag. In this
|
||
example we use the features of the <code>tag-order</code> style to divide the
|
||
<code>named-directories</code> tag into two when performing completion with the
|
||
standard completer <code>complete</code> for arguments of <code>cd</code>. The tag
|
||
<code>named-directories-normal</code> behaves as normal, but the tag
|
||
<code>named-directories-mine</code> contains a fixed set of directories. This has
|
||
the effect of adding the match group ‘<code>extra directories</code>’ with the
|
||
given completions.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion::complete:cd:*' tag-order \
|
||
'named-directories:-mine:extra\ directories
|
||
named-directories:-normal:named\ directories *'
|
||
zstyle ':completion::complete:cd:*:named-directories-mine' \
|
||
fake-always mydir1 mydir2
|
||
zstyle ':completion::complete:cd:*:named-directories-mine' \
|
||
ignored-patterns '*'
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-fake_002dfiles_002c-completion-style"></span></p>
|
||
<p><code>fake-files</code></p>
|
||
<p>This style is used when completing files and looked up without a tag.
|
||
Its values are of the form ‘<code>dir``:``names...</code>’. This will add the
|
||
<code>names</code> (strings separated by spaces) as possible matches when
|
||
completing in the directory <code>dir</code>, even if no such files really exist.
|
||
The dir may be a pattern; pattern characters or colons in <code>dir</code> should
|
||
be quoted with a backslash to be treated literally.</p>
|
||
<p>This can be useful on systems that support special file systems whose
|
||
top-level pathnames can not be listed or generated with glob patterns
|
||
(but see <code>accept-exact-dirs</code> for a more general way of dealing with this
|
||
problem). It can also be used for directories for which one does not
|
||
have read permission.</p>
|
||
<p>The pattern form can be used to add a certain ‘magic’ entry to all
|
||
directories on a particular file system.</p>
|
||
<p><span id="index-fake_002dparameters_002c-completion-style"></span></p>
|
||
<p><code>fake-parameters</code></p>
|
||
<p>This is used by the completion function for parameter names. Its values
|
||
are names of parameters that might not yet be set but should be
|
||
completed nonetheless. Each name may also be followed by a colon and a
|
||
string specifying the type of the parameter (like ‘<code>scalar</code>’, ‘<code>array</code>’
|
||
or ‘<code>integer</code>’). If the type is given, the name will only be completed
|
||
if parameters of that type are required in the particular context. Names
|
||
for which no type is specified will always be completed.</p>
|
||
<p><span id="index-file_002dlist_002c-completion-style"></span></p>
|
||
<p><code>file-list</code></p>
|
||
<p>This style controls whether files completed using the standard builtin
|
||
mechanism are to be listed with a long list similar to <code>ls -l</code>. Note
|
||
that this feature uses the shell module <code>zsh/stat</code> for file information;
|
||
this loads the builtin <code>stat</code> this the following code can be included in
|
||
an initialization file:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zmodload -i zsh/stat
|
||
disable stat
|
||
</code></pre>
|
||
</div>
|
||
<p>The style may either be set to a ‘true’ value (or ‘<code>all</code>’), or one of
|
||
the values ‘<code>insert</code>’ or ‘<code>list</code>’, indicating that files are to be
|
||
listed in long format in all circumstances, or when attempting to insert
|
||
a file name, or when listing file names without attempting to insert
|
||
one.</p>
|
||
<p>More generally, the value may be an array of any of the above values,
|
||
optionally followed by <code>=``num</code>. If <code>num</code> is present it gives the
|
||
maximum number of matches for which long listing style will be used. For
|
||
example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*' file-list list=20 insert=10
|
||
</code></pre>
|
||
</div>
|
||
<p>specifies that long format will be used when listing up to 20 files or
|
||
inserting a file with up to 10 matches (assuming a listing is to be
|
||
shown at all, for example on an ambiguous completion), else short format
|
||
will be used.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle -e ':completion:*' file-list \
|
||
'(( ${+NUMERIC} )) && reply=(true)'
|
||
</code></pre>
|
||
</div>
|
||
<p>specifies that long format will be used any time a numeric argument is
|
||
supplied, else short format.</p>
|
||
<p><span id="index-file_002dpatterns_002c-completion-style"></span></p>
|
||
<p><code>file-patterns</code></p>
|
||
<p>This is used by the standard function for completing filenames,
|
||
<code>_files</code>. If the style is unset up to three tags are offered,
|
||
‘<code>globbed-files</code>’,‘<code>directories</code>’ and ‘<code>all-files</code>’, depending on the
|
||
types of files expected by the caller of <code>_files</code>. The first two
|
||
(‘<code>globbed-files</code>’ and ‘<code>directories</code>’) are normally offered together
|
||
to make it easier to complete files in sub-directories.</p>
|
||
<p>The <code>file-patterns</code> style provides alternatives to the default tags,
|
||
which are not used. Its value consists of elements of the form
|
||
‘<code>pattern``:``tag</code>’; each string may contain any number of such
|
||
specifications separated by spaces.</p>
|
||
<p>The <code>pattern</code> is a pattern that is to be used to generate filenames. Any
|
||
occurrence of the sequence ‘<code>%p</code>’ is replaced by any pattern(s) passed
|
||
by the function calling <code>_files</code>. Colons in the pattern must be preceded
|
||
by a backslash to make them distinguishable from the colon before the
|
||
<code>tag</code>. If more than one pattern is needed, the patterns can be given
|
||
inside braces, separated by commas.</p>
|
||
<p>The <code>tag</code>s of all strings in the value will be offered by <code>_files</code> and
|
||
used when looking up other styles. Any <code>tag</code>s in the same word will be
|
||
offered at the same time and before later words. If no ‘<code>:``tag</code>’ is
|
||
given the ‘<code>files</code>’ tag will be used.</p>
|
||
<p>The <code>tag</code> may also be followed by an optional second colon and a
|
||
description, which will be used for the ‘<code>%d</code>’ in the value of the
|
||
<code>format</code> style (if that is set) instead of the default description
|
||
supplied by the completion function. If the description given here
|
||
contains itself a ‘<code>%d</code>’, that is replaced with the description supplied
|
||
by the completion function.</p>
|
||
<p>For example, to make the <code>rm</code> command first complete only names of
|
||
object files and then the names of all files if there is no matching
|
||
object file:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*:*:rm:*:*' file-patterns \
|
||
'*.o:object-files' '%p:all-files'
|
||
</code></pre>
|
||
</div>
|
||
<p>To alter the default behaviour of file completion — offer files matching
|
||
a pattern and directories on the first attempt, then all files — to
|
||
offer only matching files on the first attempt, then directories, and
|
||
finally all files:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*' file-patterns \
|
||
'%p:globbed-files' '*(-/):directories' '*:all-files'
|
||
</code></pre>
|
||
</div>
|
||
<p>This works even where there is no special pattern: <code>_files</code> matches all
|
||
files using the pattern ‘<code>*</code>’ at the first step and stops when it sees
|
||
this pattern. Note also it will never try a pattern more than once for a
|
||
single completion attempt.</p>
|
||
<p>During the execution of completion functions, the <code>EXTENDED_GLOB</code> option
|
||
is in effect, so the characters ‘<code>#</code>’, ‘<code>~</code>’ and ‘<code>^</code>’ have special
|
||
meanings in the patterns.</p>
|
||
<p><span id="index-file_002dsort_002c-completion-style"></span></p>
|
||
<p><code>file-sort</code></p>
|
||
<p>The standard filename completion function uses this style without a tag
|
||
to determine in which order the names should be listed; menu completion
|
||
will cycle through them in the same order. The possible values are:
|
||
‘<code>size</code>’ to sort by the size of the file; ‘<code>links</code>’ to sort by the
|
||
number of links to the file; ‘<code>modification</code>’ (or ‘<code>time</code>’ or ‘<code>date</code>’)
|
||
to sort by the last modification time; ‘<code>access</code>’ to sort by the last
|
||
access time; and ‘<code>inode</code>’ (or ‘<code>change</code>’) to sort by the last inode
|
||
change time. If the style is set to any other value, or is unset, files
|
||
will be sorted alphabetically by name. If the value contains the string
|
||
‘<code>reverse</code>’, sorting is done in the opposite order. If the value
|
||
contains the string ‘<code>follow</code>’, timestamps are associated with the
|
||
targets of symbolic links; the default is to use the timestamps of the
|
||
links themselves.</p>
|
||
<p><span id="index-file_002dsplit_002dchars_002c-completion-style"></span></p>
|
||
<p><code>file-split-chars</code></p>
|
||
<p>A set of characters that will cause <em>all</em> file completions for the given
|
||
context to be split at the point where any of the characters occurs. A
|
||
typical use is to set the style to <code>:</code>; then everything up to and
|
||
including the last <code>:</code> in the string so far is ignored when completing
|
||
files. As this is quite heavy-handed, it is usually preferable to update
|
||
completion functions for contexts where this behaviour is useful.</p>
|
||
<p><span id="index-filter_002c-completion-style"></span></p>
|
||
<p><code>filter</code></p>
|
||
<p>The <code>ldap</code> plugin of email address completion (see <code>_email_addresses</code>)
|
||
uses this style to specify the attributes to match against when
|
||
filtering entries. So for example, if the style is set to ‘<code>sn</code>’,
|
||
matching is done against surnames. Standard LDAP filtering is used so
|
||
normal completion matching is bypassed. If this style is not set, the
|
||
LDAP plugin is skipped. You may also need to set the <code>command</code> style to
|
||
specify how to connect to your LDAP server.</p>
|
||
<p><span id="index-force_002dlist_002c-completion-style"></span></p>
|
||
<p><code>force-list</code></p>
|
||
<p>This forces a list of completions to be shown at any point where listing
|
||
is done, even in cases where the list would usually be suppressed. For
|
||
example, normally the list is only shown if there are at least two
|
||
different matches. By setting this style to ‘<code>always</code>’, the list will
|
||
always be shown, even if there is only a single match that will
|
||
immediately be accepted. The style may also be set to a number. In this
|
||
case the list will be shown if there are at least that many matches,
|
||
even if they would all insert the same string.</p>
|
||
<p>This style is tested for the default tag as well as for each tag valid
|
||
for the current completion. Hence the listing can be forced only for
|
||
certain types of match.</p>
|
||
<p><span id="index-format_002c-completion-style"></span></p>
|
||
<p><code>format</code></p>
|
||
<p>If this is set for the <code>descriptions</code> tag, its value is used as a string
|
||
to display above matches in completion lists. The sequence ‘<code>%d</code>’ in
|
||
this string will be replaced with a short description of what these
|
||
matches are. This string may also contain the output attribute sequences
|
||
understood by <code>compadd -X</code> (see <a href="Completion-Widgets.html#Completion-Widgets">Completion
|
||
Widgets</a>).</p>
|
||
<p>The style is tested with each tag valid for the current completion
|
||
before it is tested for the <code>descriptions</code> tag. Hence different format
|
||
strings can be defined for different types of match.</p>
|
||
<p>Note also that some completer functions define additional
|
||
‘<code>%</code>’-sequences. These are described for the completer functions
|
||
that make use of them.</p>
|
||
<p>Some completion functions display messages that may be customised by
|
||
setting this style for the <code>messages</code> tag. Here, the ‘<code>%d</code>’ is replaced
|
||
with a message given by the completion function.</p>
|
||
<p>Finally, the format string is looked up with the <code>warnings</code> tag, for use
|
||
when no matches could be generated at all. In this case the ‘<code>%d</code>’ is
|
||
replaced with the descriptions for the matches that were expected
|
||
separated by spaces. The sequence ‘<code>%D</code>’ is replaced with the same
|
||
descriptions separated by newlines.</p>
|
||
<p>It is possible to use printf-style field width specifiers with ‘<code>%d</code>’
|
||
and similar escape sequences. This is handled by the <code>zformat</code> builtin
|
||
command from the <code>zsh/zutil</code> module, see <a href="Zsh-Modules.html#The-zsh_002fzutil-Module">The zsh/zutil
|
||
Module</a>.</p>
|
||
<p><span id="index-glob_002c-completion-style"></span></p>
|
||
<p><code>glob</code></p>
|
||
<p>This is used by the <code>_expand</code> completer. If it is set to ‘true’ (the
|
||
default), globbing will be attempted on the words resulting from a
|
||
previous substitution (see the <code>substitute</code> style) or else the original
|
||
string from the line.</p>
|
||
<p><span id="index-global_002c-completion-style"></span></p>
|
||
<p><code>global</code></p>
|
||
<p>If this is set to ‘true’ (the default), the <code>_expand_alias</code> completer
|
||
and bindable command will try to expand global aliases.</p>
|
||
<p><span id="index-group_002dname_002c-completion-style"></span></p>
|
||
<p><code>group-name</code></p>
|
||
<p>The completion system can group different types of matches, which appear
|
||
in separate lists. This style can be used to give the names of groups
|
||
for particular tags. For example, in command position the completion
|
||
system generates names of builtin and external commands, names of
|
||
aliases, shell functions and parameters and reserved words as possible
|
||
completions. To have the external commands and shell functions listed
|
||
separately:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*:*:-command-:*:commands' \
|
||
group-name commands
|
||
zstyle ':completion:*:*:-command-:*:functions' \
|
||
group-name functions
|
||
</code></pre>
|
||
</div>
|
||
<p>As a consequence, any match with the same tag will be displayed in the
|
||
same group.</p>
|
||
<p>If the name given is the empty string the name of the tag for the
|
||
matches will be used as the name of the group. So, to have all different
|
||
types of matches displayed separately, one can just set:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*' group-name ''
|
||
</code></pre>
|
||
</div>
|
||
<p>All matches for which no group name is defined will be put in a group
|
||
named <code>-default-</code>.</p>
|
||
<p><span id="index-group_002dorder_002c-completion-style"></span></p>
|
||
<p><code>group-order</code></p>
|
||
<p>This style is additional to the <code>group-name</code> style to specify the order
|
||
for display of the groups defined by that style (compare <code>tag-order</code>,
|
||
which determines which completions appear at all). The groups named are
|
||
shown in the given order; any other groups are shown in the order
|
||
defined by the completion function.</p>
|
||
<p>For example, to have names of builtin commands, shell functions and
|
||
external commands appear in that order when completing in command
|
||
position:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*:*:-command-:*:*' group-order \
|
||
builtins functions commands
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-groups_002c-completion-style"></span></p>
|
||
<p><code>groups</code></p>
|
||
<p>A list of names of UNIX groups. If this is not set, group names are
|
||
taken from the YP database or the file ‘<code>/etc/group</code>’.</p>
|
||
<p><span id="index-hidden_002c-completion-style"></span></p>
|
||
<p><code>hidden</code></p>
|
||
<p>If this is set to ‘true’, matches for the given context will not be
|
||
listed, although any description for the matches set with the <code>format</code>
|
||
style will be shown. If it is set to ‘<code>all</code>’, not even the description
|
||
will be displayed.</p>
|
||
<p>Note that the matches will still be completed; they are just not shown
|
||
in the list. To avoid having matches considered as possible completions
|
||
at all, the <code>tag-order</code> style can be modified as described below.</p>
|
||
<p><span id="index-hosts_002c-completion-style"></span></p>
|
||
<p><code>hosts</code></p>
|
||
<p>A list of names of hosts that should be completed. If this is not set,
|
||
hostnames are taken from the file ‘<code>/etc/hosts</code>’.</p>
|
||
<p><span id="index-hosts_002dports_002c-completion-style"></span></p>
|
||
<p><code>hosts-ports</code></p>
|
||
<p>This style is used by commands that need or accept hostnames and network
|
||
ports. The strings in the value should be of the form ‘<code>host``:``port</code>’.
|
||
Valid ports are determined by the presence of hostnames; multiple ports
|
||
for the same host may appear.</p>
|
||
<p><span id="index-ignore_002dline_002c-completion-style"></span></p>
|
||
<p><code>ignore-line</code></p>
|
||
<p>This is tested for each tag valid for the current completion. If it is
|
||
set to ‘true’, none of the words that are already on the line will be
|
||
considered as possible completions. If it is set to ‘<code>current</code>’, the
|
||
word the cursor is on will not be considered as a possible completion.
|
||
The value ‘<code>current-shown</code>’ is similar but only applies if the list of
|
||
completions is currently shown on the screen. Finally, if the style is
|
||
set to ‘<code>other</code>’, all words on the line except for the current one will
|
||
be excluded from the possible completions.</p>
|
||
<p>The values ‘<code>current</code>’ and ‘<code>current-shown</code>’ are a bit like the opposite
|
||
of the <code>accept-exact</code> style: only strings with missing characters will
|
||
be completed.</p>
|
||
<p>Note that you almost certainly don’t want to set this to ‘true’ or
|
||
‘<code>other</code>’ for a general context such as ‘<code>:completion:*</code>’. This is
|
||
because it would disallow completion of, for example, options multiple
|
||
times even if the command in question accepts the option more than once.</p>
|
||
<p><span id="index-ignore_002dparents_002c-completion-style"></span></p>
|
||
<p><code>ignore-parents</code></p>
|
||
<p>The style is tested without a tag by the function completing pathnames
|
||
in order to determine whether to ignore the names of directories already
|
||
mentioned in the current word, or the name of the current working
|
||
directory. The value must include one or both of the following strings:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>parent</code><br />
|
||
The name of any directory whose path is already contained in the
|
||
word on the line is ignored. For example, when completing after
|
||
<code>foo/../</code>, the directory <code>foo</code> will not be considered a valid
|
||
completion.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>pwd</code><br />
|
||
The name of the current working directory will not be completed;
|
||
hence, for example, completion after <code>../</code> will not use the name of
|
||
the current directory.</p>
|
||
</li>
|
||
</ul>
|
||
<p>In addition, the value may include one or both of:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>..</code><br />
|
||
Ignore the specified directories only when the word on the line
|
||
contains the substring ‘<code>../</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>directory</code><br />
|
||
Ignore the specified directories only when names of directories are
|
||
completed, not when completing names of files.</p>
|
||
</li>
|
||
</ul>
|
||
<p>Excluded values act in a similar fashion to values of the
|
||
<code>ignored-patterns</code> style, so they can be restored to consideration by
|
||
the <code>_ignored</code> completer.</p>
|
||
<p><span id="index-extra_002dverbose_002c-completion-style"></span></p>
|
||
<p><code>extra-verbose</code></p>
|
||
<p>If set, the completion listing is more verbose at the cost of a probable
|
||
decrease in completion speed. Completion performance will suffer if this
|
||
style is set to ‘true’.</p>
|
||
<p><span id="index-ignored_002dpatterns_002c-completion-style"></span></p>
|
||
<p><code>ignored-patterns</code></p>
|
||
<p>A list of patterns; any trial completion matching one of the patterns
|
||
will be excluded from consideration. The <code>_ignored</code> completer can appear
|
||
in the list of completers to restore the ignored matches. This is a more
|
||
configurable version of the shell parameter <code>$fignore</code>.</p>
|
||
<p>Note that the <code>EXTENDED_GLOB</code> option is set during the execution of
|
||
completion functions, so the characters ‘<code>#</code>’, ‘<code>~</code>’ and ‘<code>^</code>’ have
|
||
special meanings in the patterns.</p>
|
||
<p><span id="index-insert_002c-completion-style"></span></p>
|
||
<p><code>insert</code></p>
|
||
<p>This style is used by the <code>_all_matches</code> completer to decide whether to
|
||
insert the list of all matches unconditionally instead of adding the
|
||
list as another match.</p>
|
||
<p><span id="index-insert_002dids_002c-completion-style"></span></p>
|
||
<p><code>insert-ids</code></p>
|
||
<p>When completing process IDs, for example as arguments to the <code>kill</code> and
|
||
<code>wait</code> builtins the name of a command may be converted to the
|
||
appropriate process ID. A problem arises when the process name typed is
|
||
not unique. By default (or if this style is set explicitly to ‘<code>menu</code>’)
|
||
the name will be converted immediately to a set of possible IDs, and
|
||
menu completion will be started to cycle through them.</p>
|
||
<p>If the value of the style is ‘<code>single</code>’, the shell will wait until the
|
||
user has typed enough to make the command unique before converting the
|
||
name to an ID; attempts at completion will be unsuccessful until that
|
||
point. If the value is any other string, menu completion will be started
|
||
when the string typed by the user is longer than the common prefix to
|
||
the corresponding IDs.</p>
|
||
<p><span id="index-insert_002dtab_002c-completion-style"></span></p>
|
||
<p><code>insert-tab</code></p>
|
||
<p>If this is set to ‘true’, the completion system will insert a TAB
|
||
character (assuming that was used to start completion) instead of
|
||
performing completion when there is no non-blank character to the left
|
||
of the cursor. If it is set to ‘false’, completion will be done even
|
||
there.</p>
|
||
<p>The value may also contain the substrings ‘<code>pending</code>’ or
|
||
‘<code>pending=``val</code>’. In this case, the typed character will be inserted
|
||
instead of starting completion when there is unprocessed input pending.
|
||
If a <code>val</code> is given, completion will not be done if there are at least
|
||
that many characters of unprocessed input. This is often useful when
|
||
pasting characters into a terminal. Note however, that it relies on the
|
||
<code>$PENDING</code> special parameter from the <code>zsh/zle</code> module being set
|
||
properly which is not guaranteed on all platforms.</p>
|
||
<p>The default value of this style is ‘true’ except for completion within
|
||
<code>vared</code> builtin command where it is ‘false’.</p>
|
||
<p><span id="index-insert_002dunambiguous_002c-completion-style"></span></p>
|
||
<p><code>insert-unambiguous</code></p>
|
||
<p>This is used by the <code>_match</code> and <code>_approximate</code> completers. These
|
||
completers are often used with menu completion since the word typed may
|
||
bear little resemblance to the final completion. However, if this style
|
||
is ‘true’, the completer will start menu completion only if it could
|
||
find no unambiguous initial string at least as long as the original
|
||
string typed by the user.</p>
|
||
<p>In the case of the <code>_approximate</code> completer, the completer field in the
|
||
context will already have been set to one of <code>correct-``num</code> or
|
||
<code>approximate-``num</code>, where <code>num</code> is the number of errors that were
|
||
accepted.</p>
|
||
<p>In the case of the <code>_match</code> completer, the style may also be set to the
|
||
string ‘<code>pattern</code>’. Then the pattern on the line is left unchanged if it
|
||
does not match unambiguously.</p>
|
||
<p><span id="index-gain_002dprivileges_002c-completion-style"></span></p>
|
||
<p><code>gain-privileges</code></p>
|
||
<p>If set to <code>true</code>, this style enables the use of commands like <code>sudo</code> or
|
||
<code>doas</code> to gain extra privileges when retrieving information for
|
||
completion. This is only done when a command such as <code>sudo</code> appears on
|
||
the command-line. To force the use of, e.g. <code>sudo</code> or to override any
|
||
prefix that might be added due to <code>gain-privileges</code>, the <code>command</code> style
|
||
can be used with a value that begins with a hyphen.</p>
|
||
<p><span id="index-keep_002dprefix_002c-completion-style"></span></p>
|
||
<p><code>keep-prefix</code></p>
|
||
<p>This style is used by the <code>_expand</code> completer. If it is ‘true’, the
|
||
completer will try to keep a prefix containing a tilde or parameter
|
||
expansion. Hence, for example, the string ‘<code>~/f*</code>’ would be expanded to
|
||
‘<code>~/foo</code>’ instead of ‘<code>/home/user/foo</code>’. If the style is set to
|
||
‘<code>changed</code>’ (the default), the prefix will only be left unchanged if
|
||
there were other changes between the expanded words and the original
|
||
word from the command line. Any other value forces the prefix to be
|
||
expanded unconditionally.</p>
|
||
<p>The behaviour of <code>_expand</code> when this style is ‘true’ is to cause
|
||
<code>_expand</code> to give up when a single expansion with the restored prefix is
|
||
the same as the original; hence any remaining completers may be called.</p>
|
||
<p><span id="index-last_002dprompt_002c-completion-style"></span></p>
|
||
<p><code>last-prompt</code></p>
|
||
<p>This is a more flexible form of the <code>ALWAYS_LAST_PROMPT</code> option. If it
|
||
is ‘true’, the completion system will try to return the cursor to the
|
||
previous command line after displaying a completion list. It is tested
|
||
for all tags valid for the current completion, then the <code>default</code> tag.
|
||
The cursor will be moved back to the previous line if this style is
|
||
‘true’ for all types of match. Note that unlike the
|
||
<code>ALWAYS_LAST_PROMPT</code> option this is independent of the numeric argument.</p>
|
||
<p><span id="index-known_002dhosts_002dfiles"></span></p>
|
||
<p><code>known-hosts-files</code></p>
|
||
<p>This style should contain a list of files to search for host names and
|
||
(if the <code>use-ip</code> style is set) IP addresses in a format compatible with
|
||
ssh <code>known_hosts</code> files. If it is not set, the files
|
||
<code>/etc/ssh/ssh_known_hosts</code> and <code>~/.ssh/known_hosts</code> are used.</p>
|
||
<p><span id="index-list_002c-completion-style"></span></p>
|
||
<p><code>list</code></p>
|
||
<p>This style is used by the <code>_history_complete_word</code> bindable command. If
|
||
it is set to ‘true’ it has no effect. If it is set to ‘false’ matches
|
||
will not be listed. This overrides the setting of the options
|
||
controlling listing behaviour, in particular <code>AUTO_LIST</code>. The context
|
||
always starts with ‘<code>:completion:history-words</code>’.</p>
|
||
<p><span id="index-list_002dcolors_002c-completion-style"></span></p>
|
||
<p><code>list-colors</code></p>
|
||
<p>If the <code>zsh/complist</code> module is loaded, this style can be used to set
|
||
color specifications. This mechanism replaces the use of the
|
||
<code>ZLS_COLORS</code> and <code>ZLS_COLOURS</code> parameters described in <a href="Zsh-Modules.html#The-zsh_002fcomplist-Module">The zsh/complist
|
||
Module</a>, but the syntax is
|
||
the same.</p>
|
||
<p>If this style is set for the <code>default</code> tag, the strings in the value are
|
||
taken as specifications that are to be used everywhere. If it is set for
|
||
other tags, the specifications are used only for matches of the type
|
||
described by the tag. For this to work best, the <code>group-name</code> style must
|
||
be set to an empty string.</p>
|
||
<p>In addition to setting styles for specific tags, it is also possible to
|
||
use group names specified explicitly by the <code>group-name</code> tag together
|
||
with the ‘<code>(group)</code>’ syntax allowed by the <code>ZLS_COLORS</code> and
|
||
<code>ZLS_COLOURS</code> parameters and simply using the <code>default</code> tag.</p>
|
||
<p>It is possible to use any color specifications already set up for the
|
||
GNU version of the <code>ls</code> command:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*:default' list-colors \
|
||
${(s.:.)LS_COLORS}
|
||
</code></pre>
|
||
</div>
|
||
<p>The default colors are the same as for the GNU <code>ls</code> command and can be
|
||
obtained by setting the style to an empty string (i.e. <code>’’</code>).</p>
|
||
<p><span id="index-list_002ddirs_002dfirst_002c-completion-style"></span></p>
|
||
<p><code>list-dirs-first</code></p>
|
||
<p>This is used by file completion. If set, directories to be completed are
|
||
listed separately from and before completion for other files, regardless
|
||
of tag ordering. In addition, the tag <code>other-files</code> is used in place of
|
||
<code>all-files</code> for the remaining files, to indicate that no directories are
|
||
presented with that tag.</p>
|
||
<p><span id="index-list_002dgrouped_002c-completion-style"></span></p>
|
||
<p><code>list-grouped</code></p>
|
||
<p>If this style is ‘true’ (the default), the completion system will try to
|
||
make certain completion listings more compact by grouping matches. For
|
||
example, options for commands that have the same description (shown when
|
||
the <code>verbose</code> style is set to ‘true’) will appear as a single entry.
|
||
However, menu selection can be used to cycle through all the matches.</p>
|
||
<p><span id="index-list_002dpacked_002c-completion-style"></span></p>
|
||
<p><code>list-packed</code></p>
|
||
<p>This is tested for each tag valid in the current context as well as the
|
||
<code>default</code> tag. If it is set to ‘true’, the corresponding matches appear
|
||
in listings as if the <code>LIST_PACKED</code> option were set. If it is set to
|
||
‘false’, they are listed normally.</p>
|
||
<p><span id="index-list_002dprompt_002c-completion-style"></span></p>
|
||
<p><code>list-prompt</code></p>
|
||
<p>If this style is set for the <code>default</code> tag, completion lists that don’t
|
||
fit on the screen can be scrolled (see <a href="Zsh-Modules.html#The-zsh_002fcomplist-Module">The zsh/complist
|
||
Module</a>). The value, if
|
||
not the empty string, will be displayed after every screenful and the
|
||
shell will prompt for a key press; if the style is set to the empty
|
||
string, a default prompt will be used.</p>
|
||
<p>The value may contain the escape sequences: ‘<code>%l</code>’ or ‘<code>%L</code>’, which will
|
||
be replaced by the number of the last line displayed and the total
|
||
number of lines; ‘<code>%m</code>’ or ‘<code>%M</code>’, the number of the last match shown
|
||
and the total number of matches; and ‘<code>%p</code>’ and ‘<code>%P</code>’, ‘<code>Top</code>’ when at
|
||
the beginning of the list, ‘<code>Bottom</code>’ when at the end and the position
|
||
shown as a percentage of the total length otherwise. In each case the
|
||
form with the uppercase letter will be replaced by a string of fixed
|
||
width, padded to the right with spaces, while the lowercase form will be
|
||
replaced by a variable width string. As in other prompt strings, the
|
||
escape sequences ‘<code>%S</code>’, ‘<code>%s</code>’, ‘<code>%B</code>’, ‘<code>%b</code>’, ‘<code>%U</code>’, ‘<code>%u</code>’ for
|
||
entering and leaving the display modes standout, bold and underline, and
|
||
‘<code>%F</code>’, ‘<code>%f</code>’, ‘<code>%K</code>’, ‘<code>%k</code>’ for changing the foreground background
|
||
colour, are also available, as is the form ‘<code>%{</code>...<code>%}</code>’ for enclosing
|
||
escape sequences which display with zero (or, with a numeric argument,
|
||
some other) width.</p>
|
||
<p>After deleting this prompt the variable <code>LISTPROMPT</code> should be unset for
|
||
the removal to take effect.</p>
|
||
<p><span id="index-list_002drows_002dfirst_002c-completion-style"></span></p>
|
||
<p><code>list-rows-first</code></p>
|
||
<p>This style is tested in the same way as the <code>list-packed</code> style and
|
||
determines whether matches are to be listed in a rows-first fashion as
|
||
if the <code>LIST_ROWS_FIRST</code> option were set.</p>
|
||
<p><span id="index-list_002dsuffixes_002c-completion-style"></span></p>
|
||
<p><code>list-suffixes</code></p>
|
||
<p>This style is used by the function that completes filenames. If it is
|
||
‘true’, and completion is attempted on a string containing multiple
|
||
partially typed pathname components, all ambiguous components will be
|
||
shown. Otherwise, completion stops at the first ambiguous component.</p>
|
||
<p><span id="index-list_002dseparator_002c-completion-style"></span></p>
|
||
<p><code>list-separator</code></p>
|
||
<p>The value of this style is used in completion listing to separate the
|
||
string to complete from a description when possible (e.g. when
|
||
completing options). It defaults to ‘<code>-``-</code>’ (two hyphens).</p>
|
||
<p><span id="index-local_002c-completion-style"></span></p>
|
||
<p><code>local</code></p>
|
||
<p>This is for use with functions that complete URLs for which the
|
||
corresponding files are available directly from the file system. Its
|
||
value should consist of three strings: a hostname, the path to the
|
||
default web pages for the server, and the directory name used by a user
|
||
placing web pages within their home area.</p>
|
||
<p>For example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*' local toast \
|
||
/var/http/public/toast public_html
|
||
</code></pre>
|
||
</div>
|
||
<p>Completion after ‘<code>http://toast/stuff/</code>’ will look for files in the
|
||
directory <code>/var/http/public/toast/stuff</code>, while completion after
|
||
‘<code>http://toast/~yousir/</code>’ will look for files in the directory
|
||
<code>~yousir/public_html</code>.</p>
|
||
<p><span id="index-mail_002ddirectory_002c-completion-style"></span></p>
|
||
<p><code>mail-directory</code></p>
|
||
<p>If set, zsh will assume that mailbox files can be found in the directory
|
||
specified. It defaults to ‘<code>~/Mail</code>’.</p>
|
||
<p><span id="index-match_002doriginal_002c-completion-style"></span></p>
|
||
<p><code>match-original</code></p>
|
||
<p>This is used by the <code>_match</code> completer. If it is set to <code>only</code>, <code>_match</code>
|
||
will try to generate matches without inserting a ‘<code>*</code>’ at the cursor
|
||
position. If set to any other non-empty value, it will first try to
|
||
generate matches without inserting the ‘<code>*</code>’ and if that yields no
|
||
matches, it will try again with the ‘<code>*</code>’ inserted. If it is unset or
|
||
set to the empty string, matching will only be performed with the ‘<code>*</code>’
|
||
inserted.</p>
|
||
<p><span id="index-matcher_002c-completion-style"></span></p>
|
||
<p><code>matcher</code></p>
|
||
<p>This style is tested separately for each tag valid in the current
|
||
context. Its value is placed before any match specifications given by
|
||
the <code>matcher-list</code> style so can override them via the use of an <code>x:</code>
|
||
specification. The value should be in the form described in <a href="Completion-Widgets.html#Completion-Matching-Control">Completion
|
||
Matching Control</a>.
|
||
For examples of this, see the description of the <code>tag-order</code> style.</p>
|
||
<p>For notes comparing the use of this and the <code>matcher-list</code> style, see
|
||
under the description of the <code>tag-order</code> style.</p>
|
||
<p><span id="index-matcher_002dlist_002c-completion-style"></span></p>
|
||
<p><code>matcher-list</code></p>
|
||
<p>This style can be set to a list of match specifications that are to be
|
||
applied everywhere. Match specifications are described in <a href="Completion-Widgets.html#Completion-Matching-Control">Completion
|
||
Matching Control</a>.
|
||
The completion system will try them one after another for each completer
|
||
selected. For example, to try first simple completion and, if that
|
||
generates no matches, case-insensitive completion:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*' matcher-list '' 'm:{a-zA-Z}={A-Za-z}'
|
||
</code></pre>
|
||
</div>
|
||
<p>By default each specification replaces the previous one; however, if a
|
||
specification is prefixed with <code>+</code>, it is added to the existing list.
|
||
Hence it is possible to create increasingly general specifications
|
||
without repetition:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*' matcher-list \
|
||
'' '+m:{a-z}={A-Z}' '+m:{A-Z}={a-z}'
|
||
</code></pre>
|
||
</div>
|
||
<p>It is possible to create match specifications valid for particular
|
||
completers by using the third field of the context. This applies only to
|
||
completers that override the global matcher-list, which as of this
|
||
writing includes only <code>_prefix</code> and <code>_ignored</code>. For example, to use the
|
||
completers <code>_complete</code> and <code>_prefix</code> but allow case-insensitive
|
||
completion only with <code>_complete</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*' completer _complete _prefix
|
||
zstyle ':completion:*:complete:*:*:*' matcher-list \
|
||
'' 'm:{a-zA-Z}={A-Za-z}'
|
||
</code></pre>
|
||
</div>
|
||
<p>User-defined names, as explained for the <code>completer</code> style, are
|
||
available. This makes it possible to try the same completer more than
|
||
once with different match specifications each time. For example, to try
|
||
normal completion without a match specification, then normal completion
|
||
with case-insensitive matching, then correction, and finally
|
||
partial-word completion:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*' completer \
|
||
_complete _correct _complete:foo
|
||
zstyle ':completion:*:complete:*:*:*' matcher-list \
|
||
'' 'm:{a-zA-Z}={A-Za-z}'
|
||
zstyle ':completion:*:foo:*:*:*' matcher-list \
|
||
'm:{a-zA-Z}={A-Za-z} r:|[-_./]=* r:|=*'
|
||
</code></pre>
|
||
</div>
|
||
<p>If the style is unset in any context no match specification is applied.
|
||
Note also that some completers such as <code>_correct</code> and <code>_approximate</code> do
|
||
not use the match specifications at all, though these completers will
|
||
only ever be called once even if the <code>matcher-list</code> contains more than
|
||
one element.</p>
|
||
<p>Where multiple specifications are useful, note that the <em>entire</em>
|
||
completion is done for each element of <code>matcher-list</code>, which can quickly
|
||
reduce the shell’s performance. As a rough rule of thumb, hand, putting
|
||
multiple space-separated values into the same string does not have an
|
||
appreciable impact on performance.</p>
|
||
<p>If there is no current matcher or it is empty, and the option
|
||
<code>NO_CASE_GLOB</code> is in effect, the matching for files is performed
|
||
case-insensitively in any case. However, any matcher must explicitly
|
||
specify case-insensitive matching if that is required.</p>
|
||
<p>For notes comparing the use of this and the <code>matcher</code> style, see under
|
||
the description of the <code>tag-order</code> style.</p>
|
||
<p><span id="index-max_002derrors_002c-completion-style"></span></p>
|
||
<p><code>max-errors</code></p>
|
||
<p>This is used by the <code>_approximate</code> and <code>_correct</code> completer functions to
|
||
determine the maximum number of errors to allow. The completer will try
|
||
to generate completions by first allowing one error, then two errors,
|
||
and so on, until either a match or matches were found or the maximum
|
||
number of errors given by this style has been reached.</p>
|
||
<p>If the value for this style contains the string ‘<code>numeric</code>’, the
|
||
completer function will take any numeric argument as the maximum number
|
||
of errors allowed. For example, with</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*:approximate:::' max-errors 2 numeric
|
||
</code></pre>
|
||
</div>
|
||
<p>two errors are allowed if no numeric argument is given, but with a
|
||
numeric argument of six (as in ‘<code>ESC-6 TAB</code>’), up to six errors are
|
||
accepted. Hence with a value of ‘<code>0 numeric</code>’, no correcting completion
|
||
will be attempted unless a numeric argument is given.</p>
|
||
<p>If the value contains the string ‘<code>not-numeric</code>’, the completer will
|
||
<em>not</em> try to generate corrected completions when given a numeric
|
||
argument, so in this case the number given should be greater than zero.
|
||
For example, ‘<code>2 not-numeric</code>’ specifies that correcting completion with
|
||
two errors will usually be performed, but if a numeric argument is
|
||
given, correcting completion will not be performed.</p>
|
||
<p>The default value for this style is ‘<code>2 numeric</code>’.</p>
|
||
<p><span id="index-max_002dmatches_002dwidth_002c-completion-style"></span></p>
|
||
<p><code>max-matches-width</code></p>
|
||
<p>This style is used to determine the trade off between the width of the
|
||
display used for matches and the width used for their descriptions when
|
||
the <code>verbose</code> style is in effect. The value gives the number of display
|
||
columns to reserve for the matches. The default is half the width of the
|
||
screen.</p>
|
||
<p>This has the most impact when several matches have the same description
|
||
and so will be grouped together. Increasing the style will allow more
|
||
matches to be grouped together; decreasing it will allow more of the
|
||
description to be visible.</p>
|
||
<p><span id="index-menu_002c-completion-style"></span></p>
|
||
<p><code>menu</code></p>
|
||
<p>If this is ‘true’ in the context of any of the tags defined for the
|
||
current completion menu completion will be used. The value for a
|
||
specific tag will take precedence over that for the ‘<code>default</code>’ tag.</p>
|
||
<p>If none of the values found in this way is ‘true’ but at least one is
|
||
set to ‘<code>auto</code>’, the shell behaves as if the <code>AUTO_MENU</code> option is set.</p>
|
||
<p>If one of the values is explicitly set to ‘false’, menu completion will
|
||
be explicitly turned off, overriding the <code>MENU_COMPLETE</code> option and
|
||
other settings.</p>
|
||
<p>In the form ‘<code>yes=``num</code>’, where ‘<code>yes</code>’ may be any of the ‘true’ values
|
||
(‘<code>yes</code>’, ‘<code>true</code>’, ‘<code>on</code>’ and ‘<code>1</code>’), menu completion will be turned on
|
||
if there are at least <code>num</code> matches. In the form ‘<code>yes=long</code>’, menu
|
||
completion will be turned on if the list does not fit on the screen.
|
||
This does not activate menu completion if the widget normally only lists
|
||
completions, but menu completion can be activated in that case with the
|
||
value ‘<code>yes=long-list</code>’ (Typically, the value ‘<code>select=long-list</code>’
|
||
described later is more useful as it provides control over scrolling.)</p>
|
||
<p>Similarly, with any of the ‘false’ values (as in ‘<code>no=10</code>’), menu
|
||
completion will <em>not</em> be used if there are <code>num</code> or more matches.</p>
|
||
<p>The value of this widget also controls menu selection, as implemented by
|
||
the <code>zsh/complist</code> module. The following values may appear either
|
||
alongside or instead of the values above.</p>
|
||
<p>If the value contains the string ‘<code>select</code>’, menu selection will be
|
||
started unconditionally.</p>
|
||
<p>In the form ‘<code>select=``num</code>’, menu selection will only be started if
|
||
there are at least <code>num</code> matches. If the values for more than one tag
|
||
provide a number, the smallest number is taken.</p>
|
||
<p>Menu selection can be turned off explicitly by defining a value
|
||
containing the string‘<code>no-select</code>’.</p>
|
||
<p>It is also possible to start menu selection only if the list of matches
|
||
does not fit on the screen by using the value ‘<code>select=long</code>’. To start
|
||
menu selection even if the current widget only performs listing, use the
|
||
value ‘<code>select=long-list</code>’.</p>
|
||
<p>To turn on menu completion or menu selection when there are a certain
|
||
number of matches <em>or</em> the list of matches does not fit on the screen,
|
||
both of ‘<code>yes=</code>’ and ‘<code>select=</code>’ may be given twice, once with a number
|
||
and once with ‘<code>long</code>’ or ‘<code>long-list</code>’.</p>
|
||
<p>Finally, it is possible to activate two special modes of menu selection.
|
||
The word ‘<code>interactive</code>’ in the value causes interactive mode to be
|
||
entered immediately when menu selection is started; see <a href="Zsh-Modules.html#The-zsh_002fcomplist-Module">The
|
||
zsh/complist Module</a> for a
|
||
description of interactive mode. Including the string ‘<code>search</code>’ does
|
||
the same for incremental search mode. To select backward incremental
|
||
search, include the string ‘<code>search-backward</code>’.</p>
|
||
<p><span id="index-muttrc_002c-completion-style"></span></p>
|
||
<p><code>muttrc</code></p>
|
||
<p>If set, gives the location of the mutt configuration file. It defaults
|
||
to ‘<code>~/.muttrc</code>’.</p>
|
||
<p><span id="index-numbers_002c-completion-style"></span></p>
|
||
<p><code>numbers</code></p>
|
||
<p>This is used with the <code>jobs</code> tag. If it is ‘true’, the shell will
|
||
complete job numbers instead of the shortest unambiguous prefix of the
|
||
job command text. If the value is a number, job numbers will only be
|
||
used if that many words from the job descriptions are required to
|
||
resolve ambiguities. For example, if the value is ‘<code>1</code>’, strings will
|
||
only be used if all jobs differ in the first word on their command
|
||
lines.</p>
|
||
<p><span id="index-old_002dlist_002c-completion-style"></span></p>
|
||
<p><code>old-list</code></p>
|
||
<p>This is used by the <code>_oldlist</code> completer. If it is set to ‘<code>always</code>’,
|
||
then standard widgets which perform listing will retain the current list
|
||
of matches, however they were generated; this can be turned off
|
||
explicitly with the value ‘<code>never</code>’, giving the behaviour without the
|
||
<code>_oldlist</code> completer. If the style is unset, or any other value, then
|
||
the existing list of completions is displayed if it is not already;
|
||
otherwise, the standard completion list is generated; this is the
|
||
default behaviour of <code>_oldlist</code>. However, if there is an old list and
|
||
this style contains the name of the completer function that generated
|
||
the list, then the old list will be used even if it was generated by a
|
||
widget which does not do listing.</p>
|
||
<p>For example, suppose you type <code>^Xc</code> to use the <code>_correct_word</code> widget,
|
||
which generates a list of corrections for the word under the cursor.
|
||
Usually, typing <code>^D</code> would generate a standard list of completions for
|
||
the word on the command line, and show that. With <code>_oldlist</code>, it will
|
||
instead show the list of corrections already generated.</p>
|
||
<p>As another example consider the <code>_match</code> completer: with the
|
||
<code>insert-unambiguous</code> style set to ‘true’ it inserts only a common prefix
|
||
string, if there is any. However, this may remove parts of the original
|
||
pattern, so that further completion could produce more matches than on
|
||
the first attempt. By using the <code>_oldlist</code> completer and setting this
|
||
style to <code>_match</code>, the list of matches generated on the first attempt
|
||
will be used again.</p>
|
||
<p><span id="index-old_002dmatches_002c-completion-style"></span></p>
|
||
<p><code>old-matches</code></p>
|
||
<p>This is used by the <code>_all_matches</code> completer to decide if an old list of
|
||
matches should be used if one exists. This is selected by one of the
|
||
‘true’ values or by the string ‘<code>only</code>’. If the value is ‘<code>only</code>’,
|
||
<code>_all_matches</code> will only use an old list and won’t have any effect on
|
||
the list of matches currently being generated.</p>
|
||
<p>If this style is set it is generally unwise to call the <code>_all_matches</code>
|
||
completer unconditionally. One possible use is for either this style or
|
||
the <code>completer</code> style to be defined with the <code>-e</code> option to <code>zstyle</code> to
|
||
make the style conditional.</p>
|
||
<p><span id="index-old_002dmenu_002c-completion-style"></span></p>
|
||
<p><code>old-menu</code></p>
|
||
<p>This is used by the <code>_oldlist</code> completer. It controls how menu
|
||
completion behaves when a completion has already been inserted and the
|
||
user types a standard completion key such as <code>TAB</code>. The default
|
||
behaviour of <code>_oldlist</code> is that menu completion always continues with
|
||
the existing list of completions. If this style is set to ‘false’,
|
||
however, a new completion is started if the old list was generated by a
|
||
different completion command; this is the behaviour without the
|
||
<code>_oldlist</code> completer.</p>
|
||
<p>For example, suppose you type <code>^Xc</code> to generate a list of corrections,
|
||
and menu completion is started in one of the usual ways. Usually, or
|
||
with this style set to ‘false’, typing <code>TAB</code> at this point would start
|
||
trying to complete the line as it now appears. With <code>_oldlist</code>, it
|
||
instead continues to cycle through the list of corrections.</p>
|
||
<p><span id="index-original_002c-completion-style"></span></p>
|
||
<p><code>original</code></p>
|
||
<p>This is used by the <code>_approximate</code> and <code>_correct</code> completers to decide
|
||
if the original string should be added as a possible completion.
|
||
Normally, this is done only if there are at least two possible
|
||
corrections, but if this style is set to ‘true’, it is always added.
|
||
Note that the style will be examined with the completer field in the
|
||
context name set to <code>correct-``num</code> or <code>approximate-``num</code>, where <code>num</code>
|
||
is the number of errors that were accepted.</p>
|
||
<p><span id="index-packageset_002c-completion-style"></span></p>
|
||
<p><code>packageset</code></p>
|
||
<p>This style is used when completing arguments of the Debian ‘<code>dpkg</code>’
|
||
program. It contains an override for the default package set for a given
|
||
context. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*:complete:dpkg:option--status-1:*' \
|
||
packageset avail
|
||
</code></pre>
|
||
</div>
|
||
<p>causes available packages, rather than only installed packages, to be
|
||
completed for ‘<code>dpkg -``-status</code>’.</p>
|
||
<p><span id="index-path_002c-completion-style"></span></p>
|
||
<p><code>path</code></p>
|
||
<p>The function that completes color names uses this style with the
|
||
<code>colors</code> tag. The value should be the pathname of a file containing
|
||
color names in the format of an X11 <code>rgb.txt</code> file. If the style is not
|
||
set but this file is found in one of various standard locations it will
|
||
be used as the default.</p>
|
||
<p><span id="index-path_002dcompletion_002c-completion-style"></span></p>
|
||
<p><code>path-completion</code></p>
|
||
<p>This is used by filename completion. By default, filename completion
|
||
examines all components of a path to see if there are completions of
|
||
that component. For example, <code>/u/b/z</code> can be completed to
|
||
<code>/usr/bin/zsh</code>. Explicitly setting this style to ‘false’ inhibits this
|
||
behaviour for path components up to the <code>/</code> before the cursor; this
|
||
overrides the setting of <code>accept-exact-dirs</code>.</p>
|
||
<p>Even with the style set to ‘false’, it is still possible to complete
|
||
multiple paths by setting the option <code>COMPLETE_IN_WORD</code> and moving the
|
||
cursor back to the first component in the path to be completed. For
|
||
example, <code>/u/b/z</code> can be completed to <code>/usr/bin/zsh</code> if the cursor is
|
||
after the <code>/u</code>.</p>
|
||
<p><span id="index-pine_002ddirectory_002c-completion-style"></span></p>
|
||
<p><code>pine-directory</code></p>
|
||
<p>If set, specifies the directory containing PINE mailbox files. There is
|
||
no default, since recursively searching this directory is inconvenient
|
||
for anyone who doesn’t use PINE.</p>
|
||
<p><span id="index-ports_002c-completion-style"></span></p>
|
||
<p><code>ports</code></p>
|
||
<p>A list of Internet service names (network ports) to complete. If this is
|
||
not set, service names are taken from the file ‘<code>/etc/services</code>’.</p>
|
||
<p><span id="index-prefix_002dhidden_002c-completion-style"></span></p>
|
||
<p><code>prefix-hidden</code></p>
|
||
<p>This is used for certain completions which share a common prefix, for
|
||
example command options beginning with dashes. If it is ‘true’, the
|
||
prefix will not be shown in the list of matches.</p>
|
||
<p>The default value for this style is ‘false’.</p>
|
||
<p><span id="index-prefix_002dneeded_002c-completion-style"></span></p>
|
||
<p><code>prefix-needed</code></p>
|
||
<p>This style is also relevant for matches with a common prefix. If it is
|
||
set to ‘true’ this common prefix must be typed by the user to generate
|
||
the matches.</p>
|
||
<p>The style is applicable to the <code>options</code>, <code>signals</code>, <code>jobs</code>,
|
||
<code>functions</code>, and <code>parameters</code> completion tags.</p>
|
||
<p>For command options, this means that the initial ‘<code>-</code>’, ‘<code>+</code>’, or
|
||
‘<code>-``-</code>’ must be typed explicitly before option names will be
|
||
completed.</p>
|
||
<p>For signals, an initial ‘<code>-</code>’ is required before signal names will be
|
||
completed.</p>
|
||
<p>For jobs, an initial ‘<code>%</code>’ is required before job names will be
|
||
completed.</p>
|
||
<p>For function and parameter names, an initial ‘<code>_</code>’ or ‘<code>.</code>’ is required
|
||
before function or parameter names starting with those characters will
|
||
be completed.</p>
|
||
<p>The default value for this style is ‘false’ for <code>function</code> and
|
||
<code>parameter</code> completions, and ‘true’ otherwise.</p>
|
||
<p><span id="index-preserve_002dprefix_002c-completion-style"></span></p>
|
||
<p><code>preserve-prefix</code></p>
|
||
<p>This style is used when completing path names. Its value should be a
|
||
pattern matching an initial prefix of the word to complete that should
|
||
be left unchanged under all circumstances. For example, on some Unices
|
||
an initial ‘<code>//</code>’ (double slash) has a special meaning; setting this
|
||
style to the string ‘<code>//</code>’ will preserve it. As another example, setting
|
||
this style to ‘<code>?:/</code>’ under Cygwin would allow completion after
|
||
‘<code>a:/...</code>’ and so on.</p>
|
||
<p><span id="index-range_002c-completion-style"></span></p>
|
||
<p><code>range</code></p>
|
||
<p>This is used by the <code>_history</code> completer and the
|
||
<code>_history_complete_word</code> bindable command to decide which words should
|
||
be completed.</p>
|
||
<p>If it is a single number, only the last <code>N</code> words from the history will
|
||
be completed.</p>
|
||
<p>If it is a range of the form ‘<code>max``:``slice</code>’, the last <code>slice</code> words
|
||
will be completed; then if that yields no matches, the <code>slice</code> words
|
||
before those will be tried and so on. This process stops either when at
|
||
least one match has been found, or <code>max</code> words have been tried.</p>
|
||
<p>The default is to complete all words from the history at once.</p>
|
||
<p><span id="index-recursive_002dfiles_002c-completion-style"></span></p>
|
||
<p><code>recursive-files</code></p>
|
||
<p>If this style is set, its value is an array of patterns to be tested
|
||
against ‘<code>$PWD/</code>’: note the trailing slash, which allows directories in
|
||
the pattern to be delimited unambiguously by including slashes on both
|
||
sides. If an ordinary file completion fails and the word on the command
|
||
line does not yet have a directory part to its name, the style is
|
||
retrieved using the same tag as for the completion just attempted, then
|
||
the elements tested against <code>$PWD/</code> in turn. If one matches, then the
|
||
shell reattempts completion by prepending the word on the command line
|
||
with each directory in the expansion of <code>**/*(/)</code> in turn. Typically the
|
||
elements of the style will be set to restrict the number of directories
|
||
beneath the current one to a manageable number, for example
|
||
‘<code>*/.git/*</code>’.</p>
|
||
<p>For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*' recursive-files '*/zsh/*'
|
||
</code></pre>
|
||
</div>
|
||
<p>If the current directory is <code>/home/pws/zsh/Src</code>, then <code>zle_tr</code><em>TAB</em> can
|
||
be completed to <code>Zle/zle_tricky.c</code>.</p>
|
||
<p><span id="index-regular_002c-completion-style"></span></p>
|
||
<p><code>regular</code></p>
|
||
<p>This style is used by the <code>_expand_alias</code> completer and bindable
|
||
command. If set to ‘true’ (the default), regular aliases will be
|
||
expanded but only in command position. If it is set to ‘false’, regular
|
||
aliases will never be expanded. If it is set to ‘<code>always</code>’, regular
|
||
aliases will be expanded even if not in command position.</p>
|
||
<p><span id="index-rehash_002c-completion-style"></span></p>
|
||
<p><code>rehash</code></p>
|
||
<p>If this is set when completing external commands, the internal list
|
||
(hash) of commands will be updated for each search by issuing the
|
||
<code>rehash</code> command. There is a speed penalty for this which is only likely
|
||
to be noticeable when directories in the path have slow file access.</p>
|
||
<p><span id="index-remote_002daccess_002c-completion-style"></span></p>
|
||
<p><code>remote-access</code></p>
|
||
<p>If set to ‘false’, certain commands will be prevented from making
|
||
Internet connections to retrieve remote information. This includes the
|
||
completion for the <code>CVS</code> command.</p>
|
||
<p>It is not always possible to know if connections are in fact to a remote
|
||
site, so some may be prevented unnecessarily.</p>
|
||
<p><span id="index-remove_002dall_002ddups_002c-completion-style"></span></p>
|
||
<p><code>remove-all-dups</code></p>
|
||
<p>The <code>_history_complete_word</code> bindable command and the <code>_history</code>
|
||
completer use this to decide if all duplicate matches should be removed,
|
||
rather than just consecutive duplicates.</p>
|
||
<p><span id="index-select_002dprompt_002c-completion-style"></span></p>
|
||
<p><code>select-prompt</code></p>
|
||
<p>If this is set for the <code>default</code> tag, its value will be displayed during
|
||
menu selection (see the <code>menu</code> style above) when the completion list
|
||
does not fit on the screen as a whole. The same escapes as for the
|
||
<code>list-prompt</code> style are understood, except that the numbers refer to the
|
||
match or line the mark is on. A default prompt is used when the value is
|
||
the empty string.</p>
|
||
<p><span id="index-select_002dscroll_002c-completion-style"></span></p>
|
||
<p><code>select-scroll</code></p>
|
||
<p>This style is tested for the <code>default</code> tag and determines how a
|
||
completion list is scrolled during a menu selection (see the <code>menu</code>
|
||
style above) when the completion list does not fit on the screen as a
|
||
whole. If the value is ‘<code>0</code>’ (zero), the list is scrolled by
|
||
half-screenfuls; if it is a positive integer, the list is scrolled by
|
||
the given number of lines; if it is a negative number, the list is
|
||
scrolled by a screenful minus the absolute value of the given number of
|
||
lines. The default is to scroll by single lines.</p>
|
||
<p><span id="index-separate_002dsections_002c-completion-style"></span></p>
|
||
<p><code>separate-sections</code></p>
|
||
<p>This style is used with the <code>manuals</code> tag when completing names of
|
||
manual pages. If it is ‘true’, entries for different sections are added
|
||
separately using tag names of the form ‘<code>manual.``X</code>’, where <code>X</code> is the
|
||
section number. When the <code>group-name</code> style is also in effect, pages
|
||
from different sections will appear separately. This style is also used
|
||
similarly with the <code>words</code> style when completing words for the dict
|
||
command. It allows words from different dictionary databases to be added
|
||
separately. The default for this style is ‘false’.</p>
|
||
<p><span id="index-show_002dambiguity_002c-completion-style"></span></p>
|
||
<p><code>show-ambiguity</code></p>
|
||
<p>If the <code>zsh/complist</code> module is loaded, this style can be used to
|
||
highlight the first ambiguous character in completion lists. The value
|
||
is either a color indication such as those supported by the
|
||
<code>list-colors</code> style or, with a value of ‘true’, a default of underlining
|
||
is selected. The highlighting is only applied if the completion display
|
||
strings correspond to the actual matches.</p>
|
||
<p><span id="index-show_002dcompleter_002c-completion-style"></span></p>
|
||
<p><code>show-completer</code></p>
|
||
<p>Tested whenever a new completer is tried. If it is ‘true’, the
|
||
completion system outputs a progress message in the listing area showing
|
||
what completer is being tried. The message will be overwritten by any
|
||
output when completions are found and is removed after completion is
|
||
finished.</p>
|
||
<p><span id="index-single_002dignored_002c-completion-style"></span></p>
|
||
<p><code>single-ignored</code></p>
|
||
<p>This is used by the <code>_ignored</code> completer when there is only one match.
|
||
If its value is ‘<code>show</code>’, the single match will be displayed but not
|
||
inserted. If the value is ‘<code>menu</code>’, then the single match and the
|
||
original string are both added as matches and menu completion is
|
||
started, making it easy to select either of them.</p>
|
||
<p><span id="index-sort_002c-completion-style"></span></p>
|
||
<p><code>sort</code></p>
|
||
<p>This allows the standard ordering of matches to be overridden.</p>
|
||
<p>If its value is ‘<code>true</code>’ or ‘<code>false</code>’, sorting is enabled or disabled.
|
||
Additionally the values associated with the ‘<code>-o</code>’ option to <code>compadd</code>
|
||
can also be listed: <code>match</code>, <code>nosort</code>, <code>numeric</code>, <code>reverse</code>. If it is
|
||
not set for the context, the standard behaviour of the calling widget is
|
||
used.</p>
|
||
<p>The style is tested first against the full context including the tag,
|
||
and if that fails to produce a value against the context without the
|
||
tag.</p>
|
||
<p>In many cases where a calling widget explicitly selects a particular
|
||
ordering in lieu of the default, a value of ‘<code>true</code>’ is not honoured. An
|
||
example of where this is not the case is for command history where the
|
||
default of sorting matches chronologically may be overridden by setting
|
||
the style to ‘true’.</p>
|
||
<p>In the <code>_expand</code> completer, if it is set to ‘true’, the expansions
|
||
generated will always be sorted. If it is set to ‘<code>menu</code>’, then the
|
||
expansions are only sorted when they are offered as single strings but
|
||
not in the string containing all possible expansions.</p>
|
||
<p><span id="index-special_002ddirs_002c-completion-style"></span></p>
|
||
<p><code>special-dirs</code></p>
|
||
<p>Normally, the completion code will not produce the directory names ‘<code>.</code>’
|
||
and ‘<code>..</code>’ as possible completions. If this style is set to ‘true’, it
|
||
will add both ‘<code>.</code>’ and ‘<code>..</code>’ as possible completions; if it is set to
|
||
‘<code>..</code>’, only ‘<code>..</code>’ will be added.</p>
|
||
<p>The following example sets <code>special-dirs</code> to ‘<code>..</code>’ when the current
|
||
prefix is empty, is a single ‘<code>.</code>’, or consists only of a path beginning
|
||
with ‘<code>../</code>’. Otherwise the value is ‘false’.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle -e ':completion:*' special-dirs \
|
||
'[[ $PREFIX = (../)#(|.|..) ]] && reply=(..)'
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-squeeze_002dslashes_002c-completion-style"></span></p>
|
||
<p><code>squeeze-slashes</code></p>
|
||
<p>If set to ‘true’, sequences of slashes in filename paths (for example in
|
||
‘<code>foo//bar</code>’) will be treated as a single slash. This is the usual
|
||
behaviour of UNIX paths. However, by default the file completion
|
||
function behaves as if there were a ‘<code>*</code>’ between the slashes.</p>
|
||
<p><span id="index-stop_002c-completion-style"></span></p>
|
||
<p><code>stop</code></p>
|
||
<p>If set to ‘true’, the <code>_history_complete_word</code> bindable command will
|
||
stop once when reaching the beginning or end of the history. Invoking
|
||
<code>_history_complete_word</code> will then wrap around to the opposite end of
|
||
the history. If this style is set to ‘false’ (the default),
|
||
<code>_history_complete_word</code> will loop immediately as in a menu completion.</p>
|
||
<p><span id="index-strip_002dcomments_002c-completion-style"></span></p>
|
||
<p><code>strip-comments</code></p>
|
||
<p>If set to ‘true’, this style causes non-essential comment text to be
|
||
removed from completion matches. Currently it is only used when
|
||
completing e-mail addresses where it removes any display name from the
|
||
addresses, cutting them down to plain <code>user@host</code> form.</p>
|
||
<p><span id="index-subst_002dglobs_002donly_002c-completion-style"></span></p>
|
||
<p><code>subst-globs-only</code></p>
|
||
<p>This is used by the <code>_expand</code> completer. If it is set to ‘true’, the
|
||
expansion will only be used if it resulted from globbing; hence, if
|
||
expansions resulted from the use of the <code>substitute</code> style described
|
||
below, but these were not further changed by globbing, the expansions
|
||
will be rejected.</p>
|
||
<p>The default for this style is ‘false’.</p>
|
||
<p><span id="index-substitute_002c-completion-style"></span></p>
|
||
<p><code>substitute</code></p>
|
||
<p>This boolean style controls whether the <code>_expand</code> completer will first
|
||
try to expand all substitutions in the string (such as ‘<code>$(``...``)</code>’
|
||
and ‘<code>${``...``}</code>’).</p>
|
||
<p>The default is ‘true’.</p>
|
||
<p><span id="index-suffix_002c-completion-style"></span></p>
|
||
<p><code>suffix</code></p>
|
||
<p>This is used by the <code>_expand</code> completer if the word starts with a tilde
|
||
or contains a parameter expansion. If it is set to ‘true’, the word will
|
||
only be expanded if it doesn’t have a suffix, i.e. if it is something
|
||
like ‘<code>~foo</code>’ or ‘<code>$foo</code>’ rather than ‘<code>~foo/</code>’ or ‘<code>$foo/bar</code>’, unless
|
||
that suffix itself contains characters eligible for expansion. The
|
||
default for this style is ‘true’.</p>
|
||
<p><span id="index-tag_002dorder_002c-completion-style"></span></p>
|
||
<p><code>tag-order</code></p>
|
||
<p>This provides a mechanism for sorting how the tags available in a
|
||
particular context will be used.</p>
|
||
<p>The values for the style are sets of space-separated lists of tags. The
|
||
tags in each value will be tried at the same time; if no match is found,
|
||
the next value is used. (See the <code>file-patterns</code> style for an exception
|
||
to this behavior.)</p>
|
||
<p>For example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*:complete:-command-:*:*' tag-order \
|
||
'commands functions'
|
||
</code></pre>
|
||
</div>
|
||
<p>specifies that completion in command position first offers external
|
||
commands and shell functions. Remaining tags will be tried if no
|
||
completions are found.</p>
|
||
<p>In addition to tag names, each string in the value may take one of the
|
||
following forms:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-</code><br />
|
||
If any value consists of only a hyphen, then <em>only</em> the tags
|
||
specified in the other values are generated. Normally all tags not
|
||
explicitly selected are tried last if the specified tags fail to
|
||
generate any matches. This means that a single value consisting only
|
||
of a single hyphen turns off completion.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>!</code> <code>tags</code>...<br />
|
||
A string starting with an exclamation mark specifies names of tags
|
||
that are <em>not</em> to be used. The effect is the same as if all other
|
||
possible tags for the context had been listed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>tag``:``label</code> ...<br />
|
||
Here, <code>tag</code> is one of the standard tags and <code>label</code> is an arbitrary
|
||
name. Matches are generated as normal but the name <code>label</code> is used
|
||
in contexts instead of <code>tag</code>. This is not useful in words starting
|
||
with <code>!</code>.</p>
|
||
<p>If the <code>label</code> starts with a hyphen, the <code>tag</code> is prepended to the
|
||
<code>label</code> to form the name used for lookup. This can be used to make
|
||
the completion system try a certain tag more than once, supplying
|
||
different style settings for each attempt; see below for an example.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>tag``:``label``:``description</code><br />
|
||
As before, but <code>description</code> will replace the ‘<code>%d</code>’ in the value of
|
||
the <code>format</code> style instead of the default description supplied by
|
||
the completion function. Spaces in the description must be quoted
|
||
with a backslash. A ‘<code>%d</code>’ appearing in <code>description</code> is replaced
|
||
with the description given by the completion function.</p>
|
||
</li>
|
||
</ul>
|
||
<p>In any of the forms above the tag may be a pattern or several patterns
|
||
in the form ‘<code>{``pat1``,``pat2...``}</code>’. In this case all matching tags
|
||
will be used except for any given explicitly in the same string.</p>
|
||
<p>One use of these features is to try one tag more than once, setting
|
||
other styles differently on each attempt, but still to use all the other
|
||
tags without having to repeat them all. For example, to make completion
|
||
of function names in command position ignore all the completion
|
||
functions starting with an underscore the first time completion is
|
||
tried:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*:*:-command-:*:*' tag-order \
|
||
'functions:-non-comp *' functions
|
||
zstyle ':completion:*:functions-non-comp' \
|
||
ignored-patterns '_*'
|
||
</code></pre>
|
||
</div>
|
||
<p>On the first attempt, all tags will be offered but the <code>functions</code> tag
|
||
will be replaced by <code>functions-non-comp</code>. The <code>ignored-patterns</code> style
|
||
is set for this tag to exclude functions starting with an underscore. If
|
||
there are no matches, the second value of the <code>tag-order</code> style is used
|
||
which completes functions using the default tag, this time presumably
|
||
including all function names.</p>
|
||
<p>The matches for one tag can be split into different groups. For example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*' tag-order \
|
||
'options:-long:long\ options
|
||
options:-short:short\ options
|
||
options:-single-letter:single\ letter\ options'
|
||
zstyle ':completion:*:options-long' \
|
||
ignored-patterns '[-+](|-|[^-]*)'
|
||
zstyle ':completion:*:options-short' \
|
||
ignored-patterns '--*' '[-+]?'
|
||
zstyle ':completion:*:options-single-letter' \
|
||
ignored-patterns '???*'
|
||
</code></pre>
|
||
</div>
|
||
<p>With the <code>group-names</code> style set, options beginning with ‘<code>-``-</code>’,
|
||
options beginning with a single ‘<code>-</code>’ or ‘<code>+</code>’ but containing multiple
|
||
characters, and single-letter options will be displayed in separate
|
||
groups with different descriptions.</p>
|
||
<p>Another use of patterns is to try multiple match specifications one
|
||
after another. The <code>matcher-list</code> style offers something similar, but it
|
||
is tested very early in the completion system and hence can’t be set for
|
||
single commands nor for more specific contexts. Here is how to try
|
||
normal completion without any match specification and, if that generates
|
||
no matches, try again with case-insensitive matching, restricting the
|
||
effect to arguments of the command <code>foo</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*:*:foo:*:*' tag-order '*' '*:-case'
|
||
zstyle ':completion:*-case' matcher 'm:{a-z}={A-Z}'
|
||
</code></pre>
|
||
</div>
|
||
<p>First, all the tags offered when completing after <code>foo</code> are tried using
|
||
the normal tag name. If that generates no matches, the second value of
|
||
<code>tag-order</code> is used, which tries all tags again except that this time
|
||
each has <code>-case</code> appended to its name for lookup of styles. Hence this
|
||
time the value for the <code>matcher</code> style from the second call to <code>zstyle</code>
|
||
in the example is used to make completion case-insensitive.</p>
|
||
<p>It is possible to use the <code>-e</code> option of the <code>zstyle</code> builtin command to
|
||
specify conditions for the use of particular tags. For example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle -e '*:-command-:*' tag-order '
|
||
if [[ -n $PREFIX$SUFFIX ]]; then
|
||
reply=( )
|
||
else
|
||
reply=( - )
|
||
fi'
|
||
</code></pre>
|
||
</div>
|
||
<p>Completion in command position will be attempted only if the string
|
||
typed so far is not empty. This is tested using the <code>PREFIX</code> special
|
||
parameter; see <a href="Completion-Widgets.html#Completion-Widgets">Completion
|
||
Widgets</a> for a description
|
||
of parameters which are special inside completion widgets. Setting
|
||
<code>reply</code> to an empty array provides the default behaviour of trying all
|
||
tags at once; setting it to an array containing only a hyphen disables
|
||
the use of all tags and hence of all completions.</p>
|
||
<p>If no <code>tag-order</code> style has been defined for a context, the strings
|
||
‘<code>(|*-)argument-* (|*-)option-* values</code>’ and ‘<code>options</code>’ plus all tags
|
||
offered by the completion function will be used to provide a sensible
|
||
default behavior that causes arguments (whether normal command arguments
|
||
or arguments of options) to be completed before option names for most
|
||
commands.</p>
|
||
<p><span id="index-urls_002c-completion-style"></span></p>
|
||
<p><code>urls</code></p>
|
||
<p>This is used together with the <code>urls</code> tag by functions completing URLs.</p>
|
||
<p>If the value consists of more than one string, or if the only string
|
||
does not name a file or directory, the strings are used as the URLs to
|
||
complete.</p>
|
||
<p>If the value contains only one string which is the name of a normal file
|
||
the URLs are taken from that file (where the URLs may be separated by
|
||
white space or newlines).</p>
|
||
<p>Finally, if the only string in the value names a directory, the
|
||
directory hierarchy rooted at this directory gives the completions. The
|
||
top level directory should be the file access method, such as ‘<code>http</code>’,
|
||
‘<code>ftp</code>’, ‘<code>bookmark</code>’ and so on. In many cases the next level of
|
||
directories will be a filename. The directory hierarchy can descend as
|
||
deep as necessary.</p>
|
||
<p>For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*' urls ~/.urls
|
||
mkdir -p ~/.urls/ftp/ftp.zsh.org/pub
|
||
</code></pre>
|
||
</div>
|
||
<p>allows completion of all the components of the URL ‘<code>netscape</code>’ or
|
||
‘<code>lynx</code>’. Note, however, that access methods and files are completed
|
||
separately, so if the <code>hosts</code> style is set hosts can be completed
|
||
without reference to the <code>urls</code> style.</p>
|
||
<p>See the description in the function <code>_urls</code> itself for more information
|
||
(e.g. ‘<code>more $^fpath/_urls(N)</code>’).</p>
|
||
<p><span id="index-use_002dcache_002c-completion-style"></span></p>
|
||
<p><code>use-cache</code></p>
|
||
<p>If this is set, the completion caching layer is activated for any
|
||
completions which use it (via the <code>_store_cache</code>, <code>_retrieve_cache</code>, and
|
||
<code>_cache_invalid</code> functions). The directory containing the cache files
|
||
can be changed with the <code>cache-path</code> style.</p>
|
||
<p><span id="index-use_002dcompctl_002c-completion-style"></span></p>
|
||
<p><code>use-compctl</code></p>
|
||
<p>If this style is set to a string <em>not</em> equal to <code>false</code>, <code>0</code>, <code>no</code>, and
|
||
<code>off</code>, the completion system may use any completion specifications
|
||
defined with the <code>compctl</code> builtin command. If the style is unset, this
|
||
is done only if the <code>zsh/compctl</code> module is loaded. The string may also
|
||
contain the substring ‘<code>first</code>’ to use completions defined with
|
||
‘<code>compctl -T</code>’, and the substring ‘<code>default</code>’ to use the completion
|
||
defined with ‘<code>compctl -D</code>’.</p>
|
||
<p>Note that this is only intended to smooth the transition from <code>compctl</code>
|
||
to the new completion system and may disappear in the future.</p>
|
||
<p>Note also that the definitions from <code>compctl</code> will only be used if there
|
||
is no specific completion function for the command in question. For
|
||
example, if there is a function <code>_foo</code> to complete arguments to the
|
||
command <code>foo</code>, <code>compctl</code> will never be invoked for <code>foo</code>. However, the
|
||
<code>compctl</code> version will be tried if <code>foo</code> only uses default completion.</p>
|
||
<p><span id="index-use_002dip_002c-completion-style"></span></p>
|
||
<p><code>use-ip</code></p>
|
||
<p>By default, the function <code>_hosts</code> that completes host names strips IP
|
||
addresses from entries read from host databases such as NIS and ssh
|
||
files. If this style is ‘true’, the corresponding IP addresses can be
|
||
completed as well. This style is not use in any context where the
|
||
<code>hosts</code> style is set; note also it must be set before the cache of host
|
||
names is generated (typically the first completion attempt).</p>
|
||
<p><span id="index-users_002c-completion-style"></span></p>
|
||
<p><code>users</code></p>
|
||
<p>This may be set to a list of usernames to be completed. If it is not set
|
||
all usernames will be completed. Note that if it is set only that list
|
||
of users will be completed; this is because on some systems querying all
|
||
users can take a prohibitive amount of time.</p>
|
||
<p><span id="index-users_002dhosts_002c-completion-style"></span></p>
|
||
<p><code>users-hosts</code></p>
|
||
<p>The values of this style should be of the form ‘<code>user``@``host</code>’ or
|
||
‘<code>user``:``host</code>’. It is used for commands that need pairs of user-
|
||
and hostnames. These commands will complete usernames from this style
|
||
(only), and will restrict subsequent hostname completion to hosts paired
|
||
with that user in one of the values of the style.</p>
|
||
<p>It is possible to group values for sets of commands which allow a remote
|
||
login, such as <code>rlogin</code> and <code>ssh</code>, by using the <code>my-accounts</code> tag.
|
||
Similarly, values for sets of commands which usually refer to the
|
||
accounts of other people, such as <code>talk</code> and <code>finger</code>, can be grouped by
|
||
using the <code>other-accounts</code> tag. More ambivalent commands may use the
|
||
<code>accounts</code> tag.</p>
|
||
<p><span id="index-users_002dhosts_002dports_002c-completion-style"></span></p>
|
||
<p><code>users-hosts-ports</code></p>
|
||
<p>Like <code>users-hosts</code> but used for commands like <code>telnet</code> and containing
|
||
strings of the form ‘<code>user``@``host``:``port</code>’.</p>
|
||
<p><span id="index-verbose_002c-completion-style"></span></p>
|
||
<p><code>verbose</code></p>
|
||
<p>If set, as it is by default, the completion listing is more verbose. In
|
||
particular many commands show descriptions for options if this style is
|
||
‘true’.</p>
|
||
<p><span id="index-word_002c-completion-style"></span></p>
|
||
<p><code>word</code></p>
|
||
<p>This is used by the <code>_list</code> completer, which prevents the insertion of
|
||
completions until a second completion attempt when the line has not
|
||
changed. The normal way of finding out if the line has changed is to
|
||
compare its entire contents between the two occasions. If this style is
|
||
‘true’, the comparison is instead performed only on the current word.
|
||
Hence if completion is performed on another word with the same contents,
|
||
completion will not be delayed.</p>
|
||
<hr />
|
||
<p><span id="Control-Functions"></span>
|
||
<span id="Control-Functions-1"></span></p>
|
||
<h2 id="204-control-functions"><a class="header" href="#204-control-functions">20.4 Control Functions</a></h2>
|
||
<p><span id="index-completion-system_002c-choosing-completers"></span></p>
|
||
<p>The initialization script <code>compinit</code> redefines all the widgets which
|
||
perform completion to call the supplied widget function
|
||
<code>_main_complete</code>. This function acts as a wrapper calling the so-called
|
||
‘completer’ functions that generate matches. If <code>_main_complete</code> is
|
||
called with arguments, these are taken as the names of completer
|
||
functions to be called in the order given. If no arguments are given,
|
||
the set of functions to try is taken from the <code>completer</code> style. For
|
||
example, to use normal completion and correction if that doesn’t
|
||
generate any matches:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*' completer _complete _correct
|
||
</code></pre>
|
||
</div>
|
||
<p>after calling <code>compinit</code>. The default value for this style is
|
||
‘<code>_complete _ignored</code>’, i.e. normally only ordinary completion is
|
||
tried, first with the effect of the <code>ignored-patterns</code> style and then
|
||
without it. The <code>_main_complete</code> function uses the return status of the
|
||
completer functions to decide if other completers should be called. If
|
||
the return status is zero, no other completers are tried and the
|
||
<code>_main_complete</code> function returns.</p>
|
||
<p>If the first argument to <code>_main_complete</code> is a single hyphen, the
|
||
arguments will not be taken as names of completers. Instead, the second
|
||
argument gives a name to use in the <code>completer</code> field of the context and
|
||
the other arguments give a command name and arguments to call to
|
||
generate the matches.</p>
|
||
<p>The following completer functions are contained in the distribution,
|
||
although users may write their own. Note that in contexts the leading
|
||
underscore is stripped, for example basic completion is performed in the
|
||
context ‘<code>:completion::complete:``...</code>’.</p>
|
||
<p><span id="index-completion-system_002c-completers"></span></p>
|
||
<p><span id="index-_005fall_005fmatches"></span></p>
|
||
<p><code>_all_matches</code></p>
|
||
<p>This completer can be used to add a string consisting of all other
|
||
matches. As it influences later completers it must appear as the first
|
||
completer in the list. The list of all matches is affected by the
|
||
<code>avoid-completer</code> and <code>old-matches</code> styles described above.</p>
|
||
<p>It may be useful to use the <code>_generic</code> function described below to bind
|
||
<code>_all_matches</code> to its own keystroke, for example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle -C all-matches complete-word _generic
|
||
bindkey '^Xa' all-matches
|
||
zstyle ':completion:all-matches:*' old-matches only
|
||
zstyle ':completion:all-matches::::' completer _all_matches
|
||
</code></pre>
|
||
</div>
|
||
<p>Note that this does not generate completions by itself: first use any of
|
||
the standard ways of generating a list of completions, then use <code>^Xa</code> to
|
||
show all matches. It is possible instead to add a standard completer to
|
||
the list and request that the list of all matches should be directly
|
||
inserted:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:all-matches::::' completer \
|
||
_all_matches _complete
|
||
zstyle ':completion:all-matches:*' insert true
|
||
</code></pre>
|
||
</div>
|
||
<p>In this case the <code>old-matches</code> style should not be set.</p>
|
||
<p><span id="index-_005fapproximate"></span></p>
|
||
<p><code>_approximate</code></p>
|
||
<p>This is similar to the basic <code>_complete</code> completer but allows the
|
||
completions to undergo corrections. The maximum number of errors can be
|
||
specified by the <code>max-errors</code> style; see the description of approximate
|
||
matching in <a href="Expansion.html#Filename-Generation">Filename Generation</a>
|
||
for how errors are counted. Normally this completer will only be tried
|
||
after the normal <code>_complete</code> completer:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*' completer _complete _approximate
|
||
</code></pre>
|
||
</div>
|
||
<p>This will give correcting completion if and only if normal completion
|
||
yields no possible completions. When corrected completions are found,
|
||
the completer will normally start menu completion allowing you to cycle
|
||
through these strings.</p>
|
||
<p>This completer uses the tags <code>corrections</code> and <code>original</code> when
|
||
generating the possible corrections and the original string. The
|
||
<code>format</code> style for the former may contain the additional sequences
|
||
‘<code>%e</code>’ and ‘<code>%o</code>’ which will be replaced by the number of errors
|
||
accepted to generate the corrections and the original string,
|
||
respectively.</p>
|
||
<p>The completer progressively increases the number of errors allowed up to
|
||
the limit by the <code>max-errors</code> style, hence if a completion is found with
|
||
one error, no completions with two errors will be shown, and so on. It
|
||
modifies the completer name in the context to indicate the number of
|
||
errors being tried: on the first try the completer field contains
|
||
‘<code>approximate-1</code>’, on the second try ‘<code>approximate-2</code>’, and so on.</p>
|
||
<p>When <code>_approximate</code> is called from another function, the number of
|
||
errors to accept may be passed with the <code>-a</code> option. The argument is in
|
||
the same format as the <code>max-errors</code> style, all in one string.</p>
|
||
<p>Note that this completer (and the <code>_correct</code> completer mentioned below)
|
||
can be quite expensive to call, especially when a large number of errors
|
||
are allowed. One way to avoid this is to set up the <code>completer</code> style
|
||
using the <code>-e</code> option to zstyle so that some completers are only used
|
||
when completion is attempted a second time on the same string, e.g.:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle -e ':completion:*' completer '
|
||
if [[ $_last_try != "$HISTNO$BUFFER$CURSOR" ]]; then
|
||
_last_try="$HISTNO$BUFFER$CURSOR"
|
||
reply=(_complete _match _prefix)
|
||
else
|
||
reply=(_ignored _correct _approximate)
|
||
fi'
|
||
</code></pre>
|
||
</div>
|
||
<p>This uses the <code>HISTNO</code> parameter and the <code>BUFFER</code> and <code>CURSOR</code> special
|
||
parameters that are available inside zle and completion widgets to find
|
||
out if the command line hasn’t changed since the last time completion
|
||
was tried. Only then are the <code>_ignored</code>, <code>_correct</code> and <code>_approximate</code>
|
||
completers called.</p>
|
||
<p><span id="index-_005fcanonical_005fpaths"></span></p>
|
||
<p><code>_canonical_paths</code> [ <code>-A</code> <code>var</code> ] [ <code>-N</code> ] [ <code>-MJV12nfX</code> ] <code>tag</code>
|
||
<code>descr</code> [ <code>paths</code> ... ]</p>
|
||
<p>This completion function completes all paths given to it, and also tries
|
||
to offer completions which point to the same file as one of the paths
|
||
given (relative path when an absolute path is given, and vice versa;
|
||
when <code>..</code>’s are present in the word to be completed; and some paths got
|
||
from symlinks).</p>
|
||
<p><code>-A</code>, if specified, takes the paths from the array variable specified.
|
||
Paths can also be specified on the command line as shown above. <code>-N</code>, if
|
||
specified, prevents canonicalizing the paths given before using them for
|
||
completion, in case they are already so. The options <code>-M</code>, <code>-J</code>, <code>-V</code>,
|
||
<code>-1</code>, <code>-2</code>, <code>-n</code>, <code>-F</code>, <code>-X</code> are passed to <code>compadd</code>.</p>
|
||
<p>See <code>_description</code> for a description of <code>tag</code> and <code>descr</code>.</p>
|
||
<p><span id="index-_005fcmdambivalent"></span></p>
|
||
<p><code>_cmdambivalent</code></p>
|
||
<p>Completes the remaining positional arguments as an external command. The
|
||
external command and its arguments are completed as separate arguments
|
||
(in a manner appropriate for completing <code>/usr/bin/env</code>) if there are two
|
||
or more remaining positional arguments on the command line, and as a
|
||
quoted command string (in the manner of <code>system(...)</code>) otherwise. See
|
||
also <code>_cmdstring</code> and <code>_precommand</code>.</p>
|
||
<p>This function takes no arguments.</p>
|
||
<p><span id="index-_005fcmdstring"></span></p>
|
||
<p><code>_cmdstring</code></p>
|
||
<p>Completes an external command as a single argument, as for
|
||
<code>system(...)</code>.</p>
|
||
<p><span id="index-_005fcomplete"></span></p>
|
||
<p><code>_complete</code></p>
|
||
<p>This completer generates all possible completions in a context-sensitive
|
||
manner, i.e. using the settings defined with the <code>compdef</code> function
|
||
explained above and the current settings of all special parameters. This
|
||
gives the normal completion behaviour.</p>
|
||
<p>To complete arguments of commands, <code>_complete</code> uses the utility function
|
||
<code>_normal</code>, which is in turn responsible for finding the particular
|
||
function; it is described below. Various contexts of the form
|
||
<code>-``context``-</code> are handled specifically. These are all mentioned above
|
||
as possible arguments to the <code>#compdef</code> tag.</p>
|
||
<p>Before trying to find a function for a specific context, <code>_complete</code>
|
||
checks if the parameter ‘<code>compcontext</code>’ is set. Setting ‘<code>compcontext</code>’
|
||
allows the usual completion dispatching to be overridden which is useful
|
||
in places such as a function that uses <code>vared</code> for input. If it is set
|
||
to an array, the elements are taken to be the possible matches which
|
||
will be completed using the tag ‘<code>values</code>’ and the description
|
||
‘<code>value</code>’. If it is set to an associative array, the keys are used
|
||
as the possible completions and the values (if non-empty) are used as
|
||
descriptions for the matches. If ‘<code>compcontext</code>’ is set to a string
|
||
containing colons, it should be of the form
|
||
‘<code>tag``:``descr``:``action</code>’. In this case the <code>tag</code> and <code>descr</code>
|
||
give the tag and description to use and the <code>action</code> indicates what
|
||
should be completed in one of the forms accepted by the <code>_arguments</code>
|
||
utility function described below.</p>
|
||
<p>Finally, if ‘<code>compcontext</code>’ is set to a string without colons, the value
|
||
is taken as the name of the context to use and the function defined for
|
||
that context will be called. For this purpose, there is a special
|
||
context named <code>-command-line-</code> that completes whole command lines
|
||
(commands and their arguments). This is not used by the completion
|
||
system itself but is nonetheless handled when explicitly called.</p>
|
||
<p><span id="index-_005fcorrect"></span></p>
|
||
<p><code>_correct</code></p>
|
||
<p>Generate corrections, but not completions, for the current word; this is
|
||
similar to <code>_approximate</code> but will not allow any number of extra
|
||
characters at the cursor as that completer does. The effect is similar
|
||
to spell-checking. It is based on <code>_approximate</code>, but the completer
|
||
field in the context name is <code>correct</code>.</p>
|
||
<p>For example, with:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:::::' completer \
|
||
_complete _correct _approximate
|
||
zstyle ':completion:*:correct:::' max-errors 2 not-numeric
|
||
zstyle ':completion:*:approximate:::' max-errors 3 numeric
|
||
</code></pre>
|
||
</div>
|
||
<p>correction will accept up to two errors. If a numeric argument is given,
|
||
correction will not be performed, but correcting completion will be, and
|
||
will accept as many errors as given by the numeric argument. Without a
|
||
numeric argument, first correction and then correcting completion will
|
||
be tried, with the first one accepting two errors and the second one
|
||
accepting three errors.</p>
|
||
<p>When <code>_correct</code> is called as a function, the number of errors to accept
|
||
may be given following the <code>-a</code> option. The argument is in the same form
|
||
a values to the <code>accept</code> style, all in one string.</p>
|
||
<p>This completer function is intended to be used without the
|
||
<code>_approximate</code> completer or, as in the example, just before it. Using it
|
||
after the <code>_approximate</code> completer is useless since <code>_approximate</code> will
|
||
at least generate the corrected strings generated by the <code>_correct</code>
|
||
completer — and probably more.</p>
|
||
<p><span id="index-_005fexpand"></span></p>
|
||
<p><code>_expand</code></p>
|
||
<p>This completer function does not really perform completion, but instead
|
||
checks if the word on the command line is eligible for expansion and, if
|
||
it is, gives detailed control over how this expansion is done. For this
|
||
to happen, the completion system needs to be invoked with
|
||
<code>complete-word</code>, not <code>expand-or-complete</code> (the default binding for
|
||
<code>TAB</code>), as otherwise the string will be expanded by the shell’s internal
|
||
mechanism before the completion system is started. Note also this
|
||
completer should be called before the <code>_complete</code> completer function.</p>
|
||
<p>The tags used when generating expansions are <code>all-expansions</code> for the
|
||
string containing all possible expansions, <code>expansions</code> when adding the
|
||
possible expansions as single matches and <code>original</code> when adding the
|
||
original string from the line. The order in which these strings are
|
||
generated, if at all, can be controlled by the <code>group-order</code> and
|
||
<code>tag-order</code> styles, as usual.</p>
|
||
<p>The format string for <code>all-expansions</code> and for <code>expansions</code> may contain
|
||
the sequence ‘<code>%o</code>’ which will be replaced by the original string from
|
||
the line.</p>
|
||
<p>The kind of expansion to be tried is controlled by the <code>substitute</code>,
|
||
<code>glob</code> and <code>subst-globs-only</code> styles.</p>
|
||
<p>It is also possible to call <code>_expand</code> as a function, in which case the
|
||
different modes may be selected with options: <code>-s</code> for <code>substitute</code>,
|
||
<code>-g</code> for <code>glob</code> and <code>-o</code> for <code>subst-globs-only</code>.</p>
|
||
<p><span id="index-_005fexpand_005falias"></span></p>
|
||
<p><code>_expand_alias</code></p>
|
||
<p>If the word the cursor is on is an alias, it is expanded and no other
|
||
completers are called. The types of aliases which are to be expanded can
|
||
be controlled with the styles <code>regular</code>, <code>global</code> and <code>disabled</code>.</p>
|
||
<p>This function is also a bindable command, see <a href="Completion-System.html#Bindable-Commands">Bindable
|
||
Commands</a>.</p>
|
||
<p><span id="index-_005fextensions"></span></p>
|
||
<p><code>_extensions</code></p>
|
||
<p>If the cursor follows the string ‘<code>*.</code>’, filename extensions are
|
||
completed. The extensions are taken from files in current directory or a
|
||
directory specified at the beginning of the current word. For exact
|
||
matches, completion continues to allow other completers such as
|
||
<code>_expand</code> to expand the pattern. The standard <code>add-space</code> and
|
||
<code>prefix-hidden</code> styles are observed.</p>
|
||
<p><span id="index-_005fexternal_005fpwds"></span></p>
|
||
<p><code>_external_pwds</code></p>
|
||
<p>Completes current directories of other zsh processes belonging to the
|
||
current user.</p>
|
||
<p>This is intended to be used via <code>_generic</code>, bound to a custom key
|
||
combination. Note that pattern matching is enabled so matching is
|
||
performed similar to how it works with the <code>_match</code> completer.</p>
|
||
<p><span id="index-_005fhistory"></span></p>
|
||
<p><code>_history</code></p>
|
||
<p>Complete words from the shell’s command history. This completer can be
|
||
controlled by the <code>remove-all-dups</code>, and <code>sort</code> styles as for the
|
||
<code>_history_complete_word</code> bindable command, see <a href="Completion-System.html#Bindable-Commands">Bindable
|
||
Commands</a> and <a href="Completion-System.html#Completion-System-Configuration">Completion System
|
||
Configuration</a>.</p>
|
||
<p><span id="index-_005fignored"></span></p>
|
||
<p><code>_ignored</code></p>
|
||
<p>The <code>ignored-patterns</code> style can be set to a list of patterns which are
|
||
compared against possible completions; matching ones are removed. With
|
||
this completer those matches can be reinstated, as if no
|
||
<code>ignored-patterns</code> style were set. The completer actually generates its
|
||
own list of matches; which completers are invoked is determined in the
|
||
same way as for the <code>_prefix</code> completer. The <code>single-ignored</code> style is
|
||
also available as described above.</p>
|
||
<p><span id="index-_005flist"></span></p>
|
||
<p><code>_list</code></p>
|
||
<p>This completer allows the insertion of matches to be delayed until
|
||
completion is attempted a second time without the word on the line being
|
||
changed. On the first attempt, only the list of matches will be shown.
|
||
It is affected by the styles <code>condition</code> and <code>word</code>, see <a href="Completion-System.html#Completion-System-Configuration">Completion
|
||
System Configuration</a>.</p>
|
||
<p><span id="index-_005fmatch"></span></p>
|
||
<p><code>_match</code></p>
|
||
<p>This completer is intended to be used after the <code>_complete</code> completer.
|
||
It behaves similarly but the string on the command line may be a pattern
|
||
to match against trial completions. This gives the effect of the
|
||
<code>GLOB_COMPLETE</code> option.</p>
|
||
<p>Normally completion will be performed by taking the pattern from the
|
||
line, inserting a ‘<code>*</code>’ at the cursor position and comparing the
|
||
resulting pattern with the possible completions generated. This can be
|
||
modified with the <code>match-original</code> style described above.</p>
|
||
<p>The generated matches will be offered in a menu completion unless the
|
||
<code>insert-unambiguous</code> style is set to ‘true’; see the description above
|
||
for other options for this style.</p>
|
||
<p>Note that matcher specifications defined globally or used by the
|
||
completion functions (the styles <code>matcher-list</code> and <code>matcher</code>) will not
|
||
be used.</p>
|
||
<p><span id="index-_005fmenu"></span></p>
|
||
<p><code>_menu</code></p>
|
||
<p>This completer was written as simple example function to show how menu
|
||
effect of disabling menu selection which can be useful with <code>_generic</code>
|
||
based widgets. It should be used as the first completer in the list.
|
||
Note that this is independent of the setting of the <code>MENU_COMPLETE</code>
|
||
option and does not work with the other menu completion widgets such as
|
||
<code>reverse-menu-complete</code>, or <code>accept-and-menu-complete</code>.</p>
|
||
<p><span id="index-_005foldlist"></span></p>
|
||
<p><code>_oldlist</code></p>
|
||
<p>This completer controls how the standard completion widgets behave when
|
||
there is an existing list of completions which may have been generated
|
||
by a special completion (i.e. a separately-bound completion command). It
|
||
allows the ordinary completion keys to continue to use the list of
|
||
completions thus generated, instead of producing a new list of ordinary
|
||
contextual completions. It should appear in the list of completers
|
||
before any of the widgets which generate matches. It uses two styles:
|
||
<code>old-list</code> and <code>old-menu</code>, see <a href="Completion-System.html#Completion-System-Configuration">Completion System
|
||
Configuration</a>.</p>
|
||
<p><span id="index-_005fprecommand"></span></p>
|
||
<p><code>_precommand</code></p>
|
||
<p>Complete an external command in word-separated arguments, as for <code>exec</code>
|
||
and <code>/usr/bin/env</code>.</p>
|
||
<p><span id="index-_005fprefix"></span></p>
|
||
<p><code>_prefix</code></p>
|
||
<p>This completer can be used to try completion with the suffix (everything
|
||
after the cursor) ignored. In other words, the suffix will not be
|
||
considered to be part of the word to complete. The effect is similar to
|
||
the <code>expand-or-complete-prefix</code> command.</p>
|
||
<p>The <code>completer</code> style is used to decide which other completers are to be
|
||
called to generate matches. If this style is unset, the list of
|
||
completers set for the current context is used — except, of course, the
|
||
<code>_prefix</code> completer itself. Furthermore, if this completer appears more
|
||
than once in the list of completers only those completers not already
|
||
tried by the last invocation of <code>_prefix</code> will be called.</p>
|
||
<p>For example, consider this global <code>completer</code> style:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*' completer \
|
||
_complete _prefix _correct _prefix:foo
|
||
</code></pre>
|
||
</div>
|
||
<p>Here, the <code>_prefix</code> completer tries normal completion but ignoring the
|
||
suffix. If that doesn’t generate any matches, and neither does the call
|
||
to the <code>_correct</code> completer after it, <code>_prefix</code> will be called a second
|
||
time and, now only trying correction with the suffix ignored. On the
|
||
second invocation the completer part of the context appears as ‘<code>foo</code>’.</p>
|
||
<p>To use <code>_prefix</code> as the last resort and try only normal completion when
|
||
it is invoked:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*' completer _complete ... _prefix
|
||
zstyle ':completion::prefix:*' completer _complete
|
||
</code></pre>
|
||
</div>
|
||
<p>The <code>add-space</code> style is also respected. If it is set to ‘true’ then
|
||
<code>_prefix</code> will insert a space between the matches generated (if any) and
|
||
the suffix.</p>
|
||
<p>Note that this completer is only useful if the <code>COMPLETE_IN_WORD</code> option
|
||
is set; otherwise, the cursor will be moved to the end of the current
|
||
word before the completion code is called and hence there will be no
|
||
suffix.</p>
|
||
<p><span id="index-_005fuser_005fexpand"></span></p>
|
||
<p><code>_user_expand</code></p>
|
||
<p>This completer behaves similarly to the <code>_expand</code> completer but instead
|
||
performs expansions defined by users. The styles <code>add-space</code> and <code>sort</code>
|
||
styles specific to the <code>_expand</code> completer are usable with
|
||
<code>_user_expand</code> in addition to other styles handled more generally by the
|
||
completion system. The tag <code>all-expansions</code> is also available.</p>
|
||
<p>The expansion depends on the array style <code>user-expand</code> being defined for
|
||
the current context; remember that the context for completers is less
|
||
specific than that for contextual completion as the full context has not
|
||
yet been determined. Elements of the array may have one of the following
|
||
forms:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>$``hash</code><br />
|
||
<code>hash</code> is the name of an associative array. Note this is not a full
|
||
parameter expression, merely a <code>$</code>, suitably quoted to prevent
|
||
immediate expansion, followed by the name of an associative array.
|
||
If the trial expansion word matches a key in <code>hash</code>, the resulting
|
||
expansion is the corresponding value.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>_func</code><br />
|
||
<code>_func</code> is the name of a shell function whose name must begin with
|
||
<code>_</code> but is not otherwise special to the completion system. The
|
||
function is called with the trial word as an argument. If the word
|
||
is to be expanded, the function should set the array <code>reply</code> to a
|
||
list of expansions. Optionally, it can set <code>REPLY</code> to a word that
|
||
will be used as a description for the set of expansions. The return
|
||
status of the function is irrelevant.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Bindable-Commands"></span>
|
||
<span id="Bindable-Commands-1"></span></p>
|
||
<h2 id="205-bindable-commands"><a class="header" href="#205-bindable-commands">20.5 Bindable Commands</a></h2>
|
||
<p><span id="index-completion-system_002c-bindable-commands"></span></p>
|
||
<p>In addition to the context-dependent completions provided, which are
|
||
expected to work in an intuitively obvious way, there are a few widgets
|
||
implementing special behaviour which can be bound separately to keys.
|
||
The following is a list of these and their default bindings.</p>
|
||
<p><span id="index-_005fbash_005fcompletions"></span></p>
|
||
<p><code>_bash_completions</code></p>
|
||
<p>This function is used by two widgets, <code>_bash_complete-word</code> and
|
||
<code>_bash_list-choices</code>. It exists to provide compatibility with completion
|
||
bindings in bash. The last character of the binding determines what is
|
||
completed: ‘<code>!</code>’, command names; ‘<code>$</code>’, environment variables; ‘<code>@</code>’,
|
||
host names; ‘<code>/</code>’, file names; ‘<code>~</code>’ user names. In bash, the binding
|
||
preceded by ‘<code>\e</code>’ gives completion, and preceded by ‘<code>^X</code>’ lists
|
||
options. As some of these bindings clash with standard zsh bindings,
|
||
only ‘<code>\e~</code>’ and ‘<code>^X~</code>’ are bound by default. To add the rest, the
|
||
following should be added to <code>.zshrc</code> after <code>compinit</code> has been run:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">for key in '!' '$' '@' '/' '~'; do
|
||
bindkey "\e$key" _bash_complete-word
|
||
bindkey "^X$key" _bash_list-choices
|
||
done
|
||
</code></pre>
|
||
</div>
|
||
<p>This includes the bindings for ‘<code>~</code>’ in case they were already bound to
|
||
something else; the completion code does not override user bindings.</p>
|
||
<p><span id="index-_005fcorrect_005ffilename-_0028_005eXC_0029"></span></p>
|
||
<p><code>_correct_filename</code> (<code>^XC</code>)</p>
|
||
<p>Correct the filename path at the cursor position. Allows up to six
|
||
errors in the name. Can also be called with an argument to correct a
|
||
filename path, independently of zle; the correction is printed on
|
||
standard output.</p>
|
||
<p><span id="index-_005fcorrect_005fword-_0028_005eXc_0029"></span></p>
|
||
<p><code>_correct_word</code> (<code>^Xc</code>)</p>
|
||
<p>Performs correction of the current argument using the usual contextual
|
||
completions as possible choices. This stores the string ‘<code>correct-word</code>’
|
||
in the <code>function</code> field of the context name and then calls the
|
||
<code>_correct</code> completer.</p>
|
||
<p><span id="index-_005fexpand_005falias-_0028_005eXa_0029"></span></p>
|
||
<p><code>_expand_alias</code> (<code>^Xa</code>)</p>
|
||
<p>This function can be used as a completer and as a bindable command. It
|
||
expands the word the cursor is on if it is an alias. The types of alias
|
||
expanded can be controlled with the styles <code>regular</code>, <code>global</code> and
|
||
<code>disabled</code>.</p>
|
||
<p>When used as a bindable command there is one additional feature that can
|
||
be selected by setting the <code>complete</code> style to ‘true’. In this case, if
|
||
the word is not the name of an alias, <code>_expand_alias</code> tries to complete
|
||
the word to a full alias name without expanding it. It leaves the cursor
|
||
directly after the completed word so that invoking <code>_expand_alias</code> once
|
||
more will expand the now-complete alias name.</p>
|
||
<p><span id="index-_005fexpand_005fword-_0028_005eXe_0029"></span></p>
|
||
<p><code>_expand_word</code> (<code>^Xe</code>)</p>
|
||
<p>Performs expansion on the current word: equivalent to the standard
|
||
<code>expand-word</code> command, but using the <code>_expand</code> completer. Before calling
|
||
it, the <code>function</code> field of the context is set to ‘<code>expand-word</code>’.</p>
|
||
<p><span id="index-_005fgeneric"></span></p>
|
||
<p><code>_generic</code></p>
|
||
<p>This function is not defined as a widget and not bound by default.
|
||
However, it can be used to define a widget and will then store the name
|
||
of the widget in the <code>function</code> field of the context and call the
|
||
completion system. This allows custom completion widgets with their own
|
||
set of style settings to be defined easily. For example, to define a
|
||
widget that performs normal completion and starts menu selection:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle -C foo complete-word _generic
|
||
bindkey '...' foo
|
||
zstyle ':completion:foo:*' menu yes select=1
|
||
</code></pre>
|
||
</div>
|
||
<p>Note in particular that the <code>completer</code> style may be set for the context
|
||
in order to change the set of functions used to generate possible
|
||
matches. If <code>_generic</code> is called with arguments, those are passed
|
||
through to <code>_main_complete</code> as the list of completers in place of those
|
||
defined by the <code>completer</code> style.</p>
|
||
<p><span id="index-_005fhistory_005fcomplete_005fword-_0028_005ce_002f_0029"></span></p>
|
||
<p><code>_history_complete_word</code> (<code>\e/</code>)</p>
|
||
<p>Complete words from the shell’s command history. This uses the <code>list</code>,
|
||
<code>remove-all-dups</code>, <code>sort</code>, and <code>stop</code> styles.</p>
|
||
<p><span id="index-_005fmost_005frecent_005ffile-_0028_005eXm_0029"></span></p>
|
||
<p><code>_most_recent_file</code> (<code>^Xm</code>)</p>
|
||
<p>Complete the name of the most recently modified file matching the
|
||
pattern on the command line (which may be blank). If given a numeric
|
||
argument <code>N</code>, complete the <code>N</code>th most recently modified file. Note the
|
||
completion, if any, is always unique.</p>
|
||
<p><span id="index-_005fnext_005ftags-_0028_005eXn_0029"></span></p>
|
||
<p><code>_next_tags</code> (<code>^Xn</code>)</p>
|
||
<p>This command alters the set of matches used to that for the next tag, or
|
||
set of tags, either as given by the <code>tag-order</code> style or as set by
|
||
default; these matches would otherwise not be available. Successive
|
||
invocations of the command cycle through all possible sets of tags.</p>
|
||
<p><span id="index-_005fread_005fcomp-_0028_005eX_005eR_0029"></span></p>
|
||
<p><code>_read_comp</code> (<code>^X^R</code>)</p>
|
||
<p>Prompt the user for a string, and use that to perform completion on the
|
||
current word. There are two possibilities for the string. First, it can
|
||
be a set of words beginning ‘<code>_</code>’, for example ‘<code>_files -/</code>’, in which
|
||
case the function with any arguments will be called to generate the
|
||
completions. Unambiguous parts of the function name will be completed
|
||
automatically (normal completion is not available at this point) until a
|
||
space is typed.</p>
|
||
<p>Second, any other string will be passed as a set of arguments to
|
||
<code>compadd</code> and should hence be an expression specifying what should be
|
||
completed.</p>
|
||
<p>A very restricted set of editing commands is available when reading the
|
||
string: ‘<code>DEL</code>’ and ‘<code>^H</code>’ delete the last character; ‘<code>^U</code>’ deletes the
|
||
line, and ‘<code>^C</code>’ and ‘<code>^G</code>’ abort the function, while ‘<code>RET</code>’ accepts
|
||
the completion. Note the string is used verbatim as a command line, so
|
||
arguments must be quoted in accordance with standard shell rules.</p>
|
||
<p>Once a string has been read, the next call to <code>_read_comp</code> will use the
|
||
existing string instead of reading a new one. To force a new string to
|
||
be read, call <code>_read_comp</code> with a numeric argument.</p>
|
||
<p><span id="index-_005fcomplete_005fdebug-_0028_005eX_003f_0029"></span></p>
|
||
<p><code>_complete_debug</code> (<code>^X?</code>)</p>
|
||
<p>This widget performs ordinary completion, but captures in a temporary
|
||
file a trace of the shell commands executed by the completion system.
|
||
Each completion attempt gets its own file. A command to view each of
|
||
these files is pushed onto the editor buffer stack.</p>
|
||
<p><span id="index-_005fcomplete_005fhelp-_0028_005eXh_0029"></span></p>
|
||
<p><code>_complete_help</code> (<code>^Xh</code>)</p>
|
||
<p>This widget displays information about the context names, the tags, and
|
||
the completion functions used when completing at the current cursor
|
||
position. If given a numeric argument other than <code>1</code> (as in ‘<code>ESC-2 ^Xh</code>’), then the styles used and the contexts for which they are used
|
||
will be shown, too.</p>
|
||
<p>Note that the information about styles may be incomplete; it depends on
|
||
the information available from the completion functions called, which in
|
||
turn is determined by the user’s own styles and other settings.</p>
|
||
<p><span id="index-_005fcomplete_005fhelp_005fgeneric"></span></p>
|
||
<p><code>_complete_help_generic</code></p>
|
||
<p>Unlike other commands listed here, this must be created as a normal ZLE
|
||
widget rather than a completion widget (i.e. with <code>zle -N</code>). It is used
|
||
for generating help with a widget bound to the <code>_generic</code> widget that is
|
||
described above.</p>
|
||
<p>If this widget is created using the name of the function, as it is by
|
||
default, then when executed it will read a key sequence. This is
|
||
expected to be bound to a call to a completion function that uses the
|
||
<code>_generic</code> widget. That widget will be executed, and information
|
||
provided in the same format that the <code>_complete_help</code> widget displays
|
||
for contextual completion.</p>
|
||
<p>If the widget’s name contains <code>debug</code>, for example if it is created as
|
||
‘<code>zle -N _complete_debug_generic _complete_help_generic</code>’, it will
|
||
read and execute the keystring for a generic widget as before, but then
|
||
generate debugging information as done by <code>_complete_debug</code> for
|
||
contextual completion.</p>
|
||
<p>If the widget’s name contains <code>noread</code>, it will not read a keystring but
|
||
instead arrange that the next use of a generic widget run in the same
|
||
shell will have the effect as described above.</p>
|
||
<p>The widget works by setting the shell parameter
|
||
<code>ZSH_TRACE_GENERIC_WIDGET</code> which is read by <code>_generic</code>. Unsetting the
|
||
parameter cancels any pending effect of the <code>noread</code> form.</p>
|
||
<p>For example, after executing the following:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle -N _complete_debug_generic _complete_help_generic
|
||
bindkey '^x:' _complete_debug_generic
|
||
</code></pre>
|
||
</div>
|
||
<p>typing ‘<code>C-x :</code>’ followed by the key sequence for a generic widget will
|
||
cause trace output for that widget to be saved to a file.</p>
|
||
<p><span id="index-_005fcomplete_005ftag-_0028_005eXt_0029"></span></p>
|
||
<p><code>_complete_tag</code> (<code>^Xt</code>)</p>
|
||
<p>This widget completes symbol tags created by the <code>etags</code> or <code>ctags</code>
|
||
programmes (note there is no connection with the completion system’s
|
||
tags) stored in a file <code>TAGS</code>, in the format used by <code>etags</code>, or <code>tags</code>,
|
||
in the format created by <code>ctags</code>. It will look back up the path
|
||
hierarchy for the first occurrence of either file; if both exist, the
|
||
file <code>TAGS</code> is preferred. You can specify the full path to a <code>TAGS</code> or
|
||
<code>tags</code> file by setting the parameter <code>$TAGSFILE</code> or <code>$tagsfile</code>
|
||
respectively. The corresponding completion tags used are <code>etags</code> and
|
||
<code>vtags</code>, after emacs and vi respectively.</p>
|
||
<hr />
|
||
<p><span id="Completion-Functions"></span>
|
||
<span id="Utility-Functions-1"></span></p>
|
||
<h2 id="206-utility-functions"><a class="header" href="#206-utility-functions">20.6 Utility Functions</a></h2>
|
||
<p><span id="index-completion-system_002c-utility-functions"></span></p>
|
||
<p>Descriptions follow for utility functions that may be useful when
|
||
writing completion functions. If functions are installed in
|
||
subdirectories, most of these reside in the <code>Base</code> subdirectory. Like
|
||
the example functions for commands in the distribution, the utility
|
||
functions generating matches all follow the convention of returning
|
||
status zero if they generated completions and non-zero if no matching
|
||
completions could be added.</p>
|
||
<p><span id="index-_005fabsolute_005fcommand_005fpaths"></span></p>
|
||
<p><code>_absolute_command_paths</code></p>
|
||
<p>This function completes external commands as absolute paths (unlike
|
||
<code>_command_names -e</code> which completes their basenames). It takes no
|
||
arguments.</p>
|
||
<p><span id="index-_005fall_005flabels"></span></p>
|
||
<p><code>_all_labels</code> [ <code>-x</code> ] [ <code>-12VJ</code> ] <code>tag</code> <code>name</code> <code>descr</code> [ <code>command</code>
|
||
<code>arg</code> ... ]</p>
|
||
<p>This is a convenient interface to the <code>_next_label</code> function below,
|
||
implementing the loop shown in the <code>_next_label</code> example. The <code>command</code>
|
||
and its arguments are called to generate the matches. The options stored
|
||
in the parameter <code>name</code> will automatically be inserted into the <code>arg</code>s
|
||
passed to the <code>command</code>. Normally, they are put directly after the
|
||
<code>command</code>, but if one of the <code>arg</code>s is a single hyphen, they are
|
||
inserted directly before that. If the hyphen is the last argument, it
|
||
will be removed from the argument list before the <code>command</code> is called.
|
||
This allows <code>_all_labels</code> to be used in almost all cases where the
|
||
matches can be generated by a single call to the <code>compadd</code> builtin
|
||
command or by a call to one of the utility functions.</p>
|
||
<p>For example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">local expl
|
||
...
|
||
if _requested foo; then
|
||
...
|
||
_all_labels foo expl '...' compadd ... - $matches
|
||
fi
|
||
</code></pre>
|
||
</div>
|
||
<p>Will complete the strings from the <code>matches</code> parameter, using <code>compadd</code>
|
||
with additional options which will take precedence over those generated
|
||
by <code>_all_labels</code>.</p>
|
||
<p><span id="index-_005falternative"></span></p>
|
||
<p><code>_alternative</code> [ <code>-O</code> <code>name</code> ] [ <code>-C</code> <code>name</code> ] <code>spec</code> ...</p>
|
||
<p>This function is useful in simple cases where multiple tags are
|
||
available. Essentially it implements a loop like the one described for
|
||
the <code>_tags</code> function below.</p>
|
||
<p>The tags to use and the action to perform if a tag is requested are
|
||
described using the <code>spec</code>s which are of the form:
|
||
‘<code>tag``:``descr``:``action</code>’. The <code>tag</code>s are offered using <code>_tags</code> and
|
||
if the tag is requested, the <code>action</code> is executed with the given
|
||
description <code>descr</code>. The <code>action</code>s are those accepted by the
|
||
<code>_arguments</code> function (described below), excluding the ‘<code>->``state</code>’ and
|
||
‘<code>=``...</code>’ forms.</p>
|
||
<p>For example, the <code>action</code> may be a simple function call:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">_alternative \
|
||
'users:user:_users' \
|
||
'hosts:host:_hosts'
|
||
</code></pre>
|
||
</div>
|
||
<p>offers usernames and hostnames as possible matches, generated by the
|
||
<code>_users</code> and <code>_hosts</code> functions respectively.</p>
|
||
<p>Like <code>_arguments</code>, this function uses <code>_all_labels</code> to execute the
|
||
actions, which will loop over all sets of tags. Special handling is only
|
||
required if there is an additional valid tag, for example inside a
|
||
function called from <code>_alternative</code>.</p>
|
||
<p>The option ‘<code>-O</code> <code>name</code>’ is used in the same way as by the <code>_arguments</code>
|
||
function. In other words, the elements of the <code>name</code> array will be
|
||
passed to <code>compadd</code> when executing an action.</p>
|
||
<p>Like <code>_tags</code> this function supports the <code>-C</code> option to give a different
|
||
name for the argument context field.</p>
|
||
<p><span id="index-_005farguments"></span></p>
|
||
<p><code>_arguments </code>[ <code>-nswWCRS</code> ] [ <code>-A</code> <code>pat</code> ] [ <code>-O</code> <code>name</code> ] [
|
||
<code>-M</code> <code>matchspec</code> ]</p>
|
||
<p><code> </code>[ <code>:</code> ] <code>spec</code> ...</p>
|
||
<p><code>_arguments </code>[ <code>opt</code> ... ] <code>-``-</code> [ <code>-l</code> ] [ <code>-i</code> <code>pats</code> ] [
|
||
<code>-s</code> <code>pair</code> ]</p>
|
||
<p><code> </code>[ <code>helpspec</code> ...]</p>
|
||
<p>This function can be used to give a complete specification for
|
||
completion for a command whose arguments follow standard UNIX option and
|
||
argument conventions.</p>
|
||
<p><em>Options Overview</em></p>
|
||
<p>Options to <code>_arguments</code> itself must be in separate words, i.e. <code>-s -w</code>,
|
||
not <code>-sw</code>. The options are followed by <code>spec</code>s that describe options and
|
||
arguments of the analyzed command. To avoid ambiguity, all options to
|
||
<code>_arguments</code> itself may be separated from the <code>spec</code> forms by a single
|
||
colon.</p>
|
||
<p>The ‘<code>-``-</code>’ form is used to intuit <code>spec</code> forms from the help output of
|
||
the command being analyzed, and is described in detail below. The <code>opts</code>
|
||
for the ‘<code>-``-</code>’ form are otherwise the same options as the first form.
|
||
Note that ‘<code>-s</code>’ following ‘<code>-``-</code>’ has a distinct meaning from ‘<code>-s</code>’
|
||
preceding ‘<code>-``-</code>’, and both may appear.</p>
|
||
<p>The option switches <code>-s</code>, <code>-S</code>, <code>-A</code>, <code>-w</code>, and <code>-W</code> affect how
|
||
<code>_arguments</code> parses the analyzed command line’s options. These switches
|
||
are useful for commands with standard argument parsing.</p>
|
||
<p>The options of <code>_arguments</code> have the following meanings:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-n</code><br />
|
||
With this option, <code>_arguments</code> sets the parameter <code>NORMARG</code> to the
|
||
position of the first normal argument in the <code>$words</code> array, i.e.
|
||
the position after the end of the options. If that argument has not
|
||
been reached, <code>NORMARG</code> is set to <code>-1</code>. The caller should declare
|
||
‘<code>integer NORMARG</code>’ if the <code>-n</code> option is passed; otherwise the
|
||
parameter is not used.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-s</code><br />
|
||
Enable <em>option stacking</em> for single-letter options, whereby multiple
|
||
single-letter options may be combined into a single word. For
|
||
example, the two options ‘<code>-x</code>’ and ‘<code>-y</code>’ may be combined into a
|
||
single word ‘<code>-xy</code>’. By default, every word corresponds to a single
|
||
option name (‘<code>-xy</code>’ is a single option named ‘<code>xy</code>’).</p>
|
||
<p>Options beginning with a single hyphen or plus sign are eligible for
|
||
stacking; words beginning with two hyphens are not.</p>
|
||
<p>Note that <code>-s</code> after <code>-``-</code> has a different meaning, which is
|
||
documented in the segment entitled ‘Deriving <code>spec</code> forms from the
|
||
help output’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-w</code><br />
|
||
In combination with <code>-s</code>, allow option stacking even if one or more
|
||
of the options take arguments. For example, if <code>-x</code> takes an
|
||
argument, with no <code>-s</code>, ‘<code>-xy</code>’ is considered as a single
|
||
(unhandled) option; with <code>-s</code>, <code>-xy</code> is an option with the argument
|
||
‘<code>y</code>’; with both <code>-s</code> and <code>-w</code>, <code>-xy</code> is the option <code>-x</code> and the
|
||
option <code>-y</code> with arguments to <code>-x</code> (and to <code>-y</code>, if it takes
|
||
arguments) still to come in subsequent words.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-W</code><br />
|
||
This option takes <code>-w</code> a stage further: it is possible to complete
|
||
single-letter options even after an argument that occurs in the same
|
||
word. However, it depends on the action performed whether options
|
||
will really be completed at this point. For more control, use a
|
||
utility function like <code>_guard</code> as part of the action.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-C</code><br />
|
||
Modify the <code>curcontext</code> parameter for an action of the form
|
||
‘<code>->``state</code>’. This is discussed in detail below.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-R</code><br />
|
||
Return status 300 instead of zero when a <code>$state</code> is to be handled,
|
||
in the ‘<code>->``string</code>’ syntax.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-S</code><br />
|
||
Do not complete options after a ‘<code>-``-</code>’ appearing on the line, and
|
||
ignore the ‘<code>-``-</code>’. For example, with <code>-S</code>, in the line</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">foobar -x -- -y
|
||
</code></pre>
|
||
</div>
|
||
<p>the ‘<code>-x</code>’ is considered an option, the ‘<code>-y</code>’ is considered an
|
||
argument, and the ‘<code>-``-</code>’ is considered to be neither.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-A</code> <code>pat</code><br />
|
||
Do not complete options after the first non-option argument on the
|
||
line. <code>pat</code> is a pattern matching all strings which are not to be
|
||
taken as arguments. For example, to make <code>_arguments</code> stop
|
||
completing options after the first normal argument, but ignoring all
|
||
strings starting with a hyphen even if they are not described by one
|
||
of the <code>optspec</code>s, the form is ‘<code>-A "-*"</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-O</code> <code>name</code><br />
|
||
Pass the elements of the array <code>name</code> as arguments to functions
|
||
called to execute <code>action</code>s. This is discussed in detail below.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-M</code> <code>matchspec</code><br />
|
||
Use the match specification <code>matchspec</code> for completing option names
|
||
and values. The default <code>matchspec</code> allows partial word completion
|
||
after ‘<code>_</code>’ and ‘<code>-</code>’, such as completing ‘<code>-f-b</code>’ to ‘<code>-foo-bar</code>’.
|
||
The default <code>matchspec</code> is:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">r:|[_-]=* r:|=*
|
||
</code></pre>
|
||
</div>
|
||
</li>
|
||
</ul>
|
||
<p><em><code>spec</code>s: overview</em></p>
|
||
<p>Each of the following forms is a <code>spec</code> describing individual sets of
|
||
options or arguments on the command line being analyzed.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>n``:``message``:``action</code><br />
|
||
<code>n``::``message``:``action</code><br />
|
||
This describes the <code>n</code>’th normal argument. The <code>message</code> will be
|
||
printed above the matches generated and the <code>action</code> indicates what
|
||
can be completed in this position (see below). If there are two
|
||
colons before the <code>message</code> the argument is optional. If the
|
||
<code>message</code> contains only white space, nothing will be printed above
|
||
the matches unless the action adds an explanation string itself.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>:``message``:``action</code><br />
|
||
<code>::``message``:``action</code><br />
|
||
Similar, but describes the <em>next</em> argument, whatever number that
|
||
happens to be. If all arguments are specified in this form in the
|
||
correct order the numbers are unnecessary.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>*:``message``:``action</code><br />
|
||
<code>*::``message``:``action</code><br />
|
||
<code>*:::``message``:``action</code><br />
|
||
This describes how arguments (usually non-option arguments, those
|
||
not beginning with <code>-</code> or <code>+</code>) are to be completed when neither of
|
||
the first two forms was provided. Any number of arguments can be
|
||
completed in this fashion.</p>
|
||
<p>With two colons before the <code>message</code>, the <code>words</code> special array and
|
||
the <code>CURRENT</code> special parameter are modified to refer only to the
|
||
normal arguments when the <code>action</code> is executed or evaluated. With
|
||
three colons before the <code>message</code> they are modified to refer only to
|
||
the normal arguments covered by this description.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>optspec</code><br />
|
||
<code>optspec``:``...</code><br />
|
||
This describes an option. The colon indicates handling for one or
|
||
more arguments to the option; if it is not present, the option is
|
||
assumed to take no arguments.</p>
|
||
<p>The following forms are available for the initial <code>optspec</code>, whether
|
||
or not the option has arguments.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>*``optspec</code><br />
|
||
Here <code>optspec</code> is one of the remaining forms below. This
|
||
indicates the following <code>optspec</code> may be repeated. Otherwise if
|
||
the corresponding option is already present on the command line
|
||
to the left of the cursor it will not be offered again.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-``optname</code><br />
|
||
<code>+``optname</code><br />
|
||
In the simplest form the <code>optspec</code> is just the option name
|
||
beginning with a minus or a plus sign, such as ‘<code>-foo</code>’. The
|
||
first argument for the option (if any) must follow as a
|
||
<em>separate</em> word directly after the option.</p>
|
||
<p>Either of ‘<code>-+``optname</code>’ and ‘<code>+-``optname</code>’ can be used to
|
||
specify that <code>-``optname</code> and <code>+``optname</code> are both valid.</p>
|
||
<p>In all the remaining forms, the leading ‘<code>-</code>’ may be replaced by
|
||
or paired with ‘<code>+</code>’ in this way.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-``optname``-</code><br />
|
||
The first argument of the option must come directly after the
|
||
option name <em>in the same word</em>. For example, ‘<code>-foo-:``...</code>’
|
||
specifies that the completed option and argument will look like
|
||
‘<code>-foo``arg</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-``optname``+</code><br />
|
||
The first argument may appear immediately after <code>optname</code> in the
|
||
same word, or may appear as a separate word after the option.
|
||
For example, ‘<code>-foo+:``...</code>’ specifies that the completed option
|
||
and argument will look like either ‘<code>-foo``arg</code>’ or ‘<code>-foo</code>
|
||
<code>arg</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-``optname``=</code><br />
|
||
The argument may appear as the next word, or in same word as the
|
||
option name provided that it is separated from it by an equals
|
||
sign, for example ‘<code>-foo=``arg</code>’ or ‘<code>-foo</code> <code>arg</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-``optname``=-</code><br />
|
||
The argument to the option must appear after an equals sign in
|
||
the same word, and may not be given in the next argument.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>optspec``[``explanation``]</code><br />
|
||
An explanation string may be appended to any of the preceding
|
||
forms of <code>optspec</code> by enclosing it in brackets, as in ‘<code>-q[query operation]</code>’.</p>
|
||
<p>The <code>verbose</code> style is used to decide whether the explanation
|
||
strings are displayed with the option in a completion listing.</p>
|
||
<p>If no bracketed explanation string is given but the
|
||
<code>auto-description</code> style is set and only one argument is
|
||
described for this <code>optspec</code>, the value of the style is
|
||
displayed, with any appearance of the sequence ‘<code>%d</code>’ in it
|
||
replaced by the <code>message</code> of the first <code>optarg</code> that follows the
|
||
<code>optspec</code>; see below.</p>
|
||
</li>
|
||
</ul>
|
||
<p>It is possible for options with a literal ‘<code>+</code>’ or ‘<code>=</code>’ to appear,
|
||
but that character must be quoted, for example ‘<code>-\+</code>’.</p>
|
||
<p>Each <code>optarg</code> following an <code>optspec</code> must take one of the following
|
||
forms:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>:``message``:``action</code><br />
|
||
<code>::``message``:``action</code><br />
|
||
An argument to the option; <code>message</code> and <code>action</code> are treated as
|
||
for ordinary arguments. In the first form, the argument is
|
||
mandatory, and in the second form it is optional.</p>
|
||
<p>This group may be repeated for options which take multiple
|
||
arguments. In other words,
|
||
<code>:``message1``:``action1``:``message2``:``action2</code> specifies
|
||
that the option takes two arguments.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>:*``pattern``:``message``:``action</code><br />
|
||
<code>:*``pattern``::``message``:``action</code><br />
|
||
<code>:*``pattern``:::``message``:``action</code><br />
|
||
This describes multiple arguments. Only the last <code>optarg</code> for an
|
||
option taking multiple arguments may be given in this form. If
|
||
the <code>pattern</code> is empty (i.e. <code>:*:</code>), all the remaining words on
|
||
the line are to be completed as described by the <code>action</code>;
|
||
otherwise, all the words up to and including a word matching the
|
||
<code>pattern</code> are to be completed using the <code>action</code>.</p>
|
||
<p>Multiple colons are treated as for the ‘<code>*:``...</code>’ forms for
|
||
ordinary arguments: when the <code>message</code> is preceded by two
|
||
colons, the <code>words</code> special array and the <code>CURRENT</code> special
|
||
parameter are modified during the execution or evaluation of the
|
||
<code>action</code> to refer only to the words after the option. When
|
||
preceded by three colons, they are modified to refer only to the
|
||
words covered by this description.</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<p>Any literal colon in an <code>optname</code>, <code>message</code>, or <code>action</code> must be
|
||
preceded by a backslash, ‘<code>\:</code>’.</p>
|
||
<p>Each of the forms above may be preceded by a list in parentheses of
|
||
option names and argument numbers. If the given option is on the command
|
||
line, the options and arguments indicated in parentheses will not be
|
||
offered. For example, ‘<code>(-two -three 1)-one:``...</code>’ completes the option
|
||
‘<code>-one</code>’; if this appears on the command line, the options <code>-two</code> and
|
||
<code>-three</code> and the first ordinary argument will not be completed after it.
|
||
‘<code>(-foo):``...</code>’ specifies an ordinary argument completion; <code>-foo</code> will
|
||
not be completed if that argument is already present.</p>
|
||
<p>Other items may appear in the list of excluded options to indicate
|
||
various other items that should not be applied when the current
|
||
specification is matched: a single star (<code>*</code>) for the rest arguments
|
||
(i.e. a specification of the form ‘<code>*:``...</code>’); a colon (<code>:</code>) for all
|
||
normal (non-option-) arguments; and a hyphen (<code>-</code>) for all options. For
|
||
example, if ‘<code>(*)</code>’ appears before an option and the option appears on
|
||
the command line, the list of remaining arguments completed.</p>
|
||
<p>To aid in reuse of specifications, it is possible to precede any of the
|
||
forms above with ‘<code>!</code>’; then the form will no longer be completed,
|
||
although if the option or argument appears on the command line they will
|
||
be skipped as normal. The main use for this is when the arguments are
|
||
given by an array, and <code>_arguments</code> is called repeatedly for more
|
||
specific contexts: on the first call ‘<code>_arguments $global_options</code>’ is
|
||
used, and on subsequent calls ‘<code>_arguments !$^global_options</code>’.</p>
|
||
<p><em><code>spec</code>s: actions</em></p>
|
||
<p>In each of the forms above the <code>action</code> determines how completions
|
||
should be generated. Except for the ‘<code>->``string</code>’ form below, the
|
||
<code>action</code> will be executed by calling the <code>_all_labels</code> function to
|
||
process all tag labels. No special handling of tags is needed unless a
|
||
function call introduces a new one.</p>
|
||
<p>The functions called to execute <code>action</code>s will be called with the
|
||
elements of the array named by the ‘<code>-O</code> <code>name</code>’ option as arguments.
|
||
This can be used, for example, to pass the same set of options for the
|
||
<code>compadd</code> builtin to all <code>action</code>s.</p>
|
||
<p>The forms for <code>action</code> are as follows.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code> </code>(single unquoted space)<br />
|
||
This is useful where an argument is required but it is not possible
|
||
or desirable to generate matches for it. The <code>message</code> will be
|
||
displayed but no completions listed. Note that even in this case the
|
||
colon at the end of the <code>message</code> is needed; it may only be omitted
|
||
when neither a <code>message</code> nor an <code>action</code> is given.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>(``item1</code> <code>item2</code> <code>...``)</code><br />
|
||
One of a list of possible matches, for example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">:foo:(foo bar baz)
|
||
</code></pre>
|
||
</div>
|
||
</li>
|
||
<li>
|
||
<p><code>((item1\:desc1 ...))</code><br />
|
||
Similar to the above, but with descriptions for each possible match.
|
||
Note the backslash before the colon. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">:foo:((a\:bar b\:baz))
|
||
</code></pre>
|
||
</div>
|
||
<p>The matches will be listed together with their descriptions if the
|
||
<code>description</code> style is set with the <code>values</code> tag in the context.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>->``string</code><br />
|
||
<span id="index-context_002c-use-of"></span>
|
||
<span id="index-line_002c-use-of"></span>
|
||
<span id="index-opt_005fargs_002c-use-of"></span></p>
|
||
<p>In this form, <code>_arguments</code> processes the arguments and options and
|
||
then returns control to the calling function with parameters set to
|
||
indicate the state of processing; the calling function then makes
|
||
its own arrangements for generating completions. For example,
|
||
functions that implement a state machine can use this type of
|
||
action.</p>
|
||
<p>Where <code>_arguments</code> encounters <code>action</code> in the ‘<code>->``string</code>’ format,
|
||
it will strip all leading and trailing whitespace from <code>string</code> and
|
||
set the array <code>state</code> to the set of all <code>string</code>s for which an
|
||
action is to be performed. The elements of the array <code>state_descr</code>
|
||
are assigned the corresponding <code>message</code> field from each <code>optarg</code>
|
||
containing such an <code>action</code>.</p>
|
||
<p>By default and in common with all other well behaved completion
|
||
functions, _arguments returns status zero if it was able to add
|
||
matches and non-zero otherwise. However, if the <code>-R</code> option is
|
||
given, <code>_arguments</code> will instead return a status of 300 to indicate
|
||
that <code>$state</code> is to be handled.</p>
|
||
<p>In addition to <code>$state</code> and <code>$state_descr</code>, <code>_arguments</code> also sets
|
||
the global parameters ‘<code>context</code>’, ‘<code>line</code>’ and ‘<code>opt_args</code>’ as
|
||
described below, and does not reset any changes made to the special
|
||
parameters such as <code>PREFIX</code> and <code>words</code>. This gives the calling
|
||
function the choice of resetting these parameters or propagating
|
||
changes in them.</p>
|
||
<p>A function calling <code>_arguments</code> with at least one action containing
|
||
a ‘<code>->``string</code>’ must therefore declare appropriate local
|
||
parameters:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">local context state state_descr line
|
||
typeset -A opt_args
|
||
</code></pre>
|
||
</div>
|
||
<p>to prevent <code>_arguments</code> from altering the global environment.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>{``eval-string``}</code><br />
|
||
<span id="index-expl_002c-use-of"></span></p>
|
||
<p>A string in braces is evaluated as shell code to generate matches.
|
||
If the <code>eval-string</code> itself does not begin with an opening
|
||
parenthesis or brace it is split into separate words before
|
||
execution.</p>
|
||
</li>
|
||
<li>
|
||
<p><code> = ``action</code><br />
|
||
If the <code>action</code> starts with ‘<code>= </code>’ (an equals sign followed by a
|
||
space), <code>_arguments</code> will insert the contents of the <code>argument</code>
|
||
field of the current context as the new first element in the <code>words</code>
|
||
special array and increment the value of the <code>CURRENT</code> special
|
||
parameter. This has the effect of inserting a dummy word onto the
|
||
completion command line while not changing the point at which
|
||
completion is taking place.</p>
|
||
<p>This is most useful with one of the specifiers that restrict the
|
||
words on the command line on which the <code>action</code> is to operate (the
|
||
two- and three-colon forms above). One particular use is when an
|
||
<code>action</code> itself causes <code>_arguments</code> on a restricted range; it is
|
||
necessary to use this trick to insert an appropriate command name
|
||
into the range for the second call to <code>_arguments</code> to be able to
|
||
parse the line.</p>
|
||
</li>
|
||
<li>
|
||
<p><code> word...</code><br />
|
||
<code>word...</code><br />
|
||
This covers all forms other than those above. If the <code>action</code> starts
|
||
with a space, the remaining list of words will be invoked unchanged.</p>
|
||
<p>Otherwise it will be invoked with some extra strings placed after
|
||
the first word; these are to be passed down as options to the
|
||
<code>compadd</code> builtin. They ensure that the state specified by
|
||
<code>_arguments</code>, in particular the descriptions of options and
|
||
arguments, is correctly passed to the completion command. These
|
||
additional arguments are taken from the array parameter ‘<code>expl</code>’;
|
||
this will be set up before executing the <code>action</code> and hence may be
|
||
referred to inside it, typically in an expansion of the form
|
||
‘<code>$expl[@]</code>’ which preserves empty elements of the array.</p>
|
||
</li>
|
||
</ul>
|
||
<p>During the performance of the action the array ‘<code>line</code>’ will be set to
|
||
the normal arguments from the command line, i.e. the words from the
|
||
command line after the command name excluding all options and their
|
||
arguments. Options are stored in the associative array ‘<code>opt_args</code>’ with
|
||
option names as keys and their arguments as the values. For options that
|
||
have more than one argument these are given as one string, separated by
|
||
colons. All colons and backslashes in the original arguments are
|
||
preceded with backslashes.</p>
|
||
<p>The parameter ‘<code>context</code>’ is set when returning to the calling function
|
||
to perform an action of the form ‘<code>->``string</code>’. It is set to an array
|
||
of elements corresponding to the elements of <code>$state</code>. Each string of
|
||
the form ‘<code>option``-opt``-``n</code>’ for the <code>n</code>’th argument of the option
|
||
<code>-opt</code>, or a string of the form ‘<code>argument-``n</code>’ for the <code>n</code>’th
|
||
argument. For ‘rest’ arguments, that is those in the list at the end not
|
||
handled by position, <code>n</code> is the string ‘<code>rest</code>’. For example, when
|
||
completing the argument of the <code>-o</code> option, the name is ‘<code>option-o-1</code>’,
|
||
while for the second normal (non-option-) argument it is ‘<code>argument-2</code>’.</p>
|
||
<p>Furthermore, during the evaluation of the <code>action</code> the context name in
|
||
the <code>curcontext</code> parameter is altered to append the same string that is
|
||
stored in the <code>context</code> parameter.</p>
|
||
<p>The option <code>-C</code> tells <code>_arguments</code> to modify the <code>curcontext</code> parameter
|
||
for an action of the form ‘<code>->``state</code>’. This is the standard parameter
|
||
used to keep track of the current context. Here it (and not the
|
||
<code>context</code> array) should be made local to the calling function to avoid
|
||
passing back the modified value and should be initialised to the current
|
||
value at the start of the function:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">local curcontext="$curcontext"
|
||
</code></pre>
|
||
</div>
|
||
<p>This is useful where it is not possible for multiple states to be valid
|
||
together.</p>
|
||
<p><em>Grouping Options</em></p>
|
||
<p>Options can be grouped to simplify exclusion lists. A group is
|
||
introduced with ‘<code>+</code>’ followed by a name for the group in the subsequent
|
||
word. Whole groups can then be referenced in an exclusion list or a
|
||
group name can be used to disambiguate between two forms of the same
|
||
option. For example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">_arguments \
|
||
'(group2--x)-a' \
|
||
+ group1 \
|
||
-m \
|
||
'(group2)-n' \
|
||
+ group2 \
|
||
-x -y
|
||
</code></pre>
|
||
</div>
|
||
<p>If the name of a group is specified in the form ‘<code>(``name``)</code>’ then only
|
||
one value from that group will ever be completed; more formally, all
|
||
specifications are mutually exclusive to all other specifications in
|
||
that group. This is useful for defining options that are aliases for
|
||
each other. For example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">_arguments \
|
||
-a -b \
|
||
+ '(operation)' \
|
||
{-c,--compress}'[compress]' \
|
||
{-d,--decompress}'[decompress]' \
|
||
{-l,--list}'[list]'
|
||
</code></pre>
|
||
</div>
|
||
<p>If an option in a group appears on the command line, it is stored in the
|
||
associative array ‘<code>opt_args</code>’ with ’<code>group``-``option</code>’ as a key. In
|
||
the example above, a key ‘<code>operation–c</code>’ is used if the option ‘<code>-c</code>’ is
|
||
present on the command line.</p>
|
||
<p><em>Specifying Multiple Sets of Arguments</em></p>
|
||
<p>It is possible to specify multiple sets of options and arguments with
|
||
the sets separated by single hyphens. This differs from groups in that
|
||
sets are considered to be mutually exclusive of each other.</p>
|
||
<p>Specifications before the first set and from any group are common to all
|
||
sets. For example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">_arguments \
|
||
-a \
|
||
- set1 \
|
||
-c \
|
||
- set2 \
|
||
-d \
|
||
':arg:(x2 y2)'
|
||
</code></pre>
|
||
</div>
|
||
<p>This defines two sets. When the command line contains the option ‘<code>-c</code>’,
|
||
the ‘<code>-d</code>’ option and the argument will not be considered possible
|
||
completions. When it contains ‘<code>-d</code>’ or an argument, the option ‘<code>-c</code>’
|
||
will not be considered. However, after ‘<code>-a</code>’ both sets will still be
|
||
considered valid.</p>
|
||
<p>As for groups, the name of a set may appear in exclusion lists, either
|
||
alone or preceding a normal option or argument specification.</p>
|
||
<p>The completion code has to parse the command line separately for each
|
||
set. This can be slow so sets should only be used when necessary. A
|
||
useful alternative is often an option specification with rest-arguments
|
||
(as in ‘<code>-foo:*:...</code>’); here the option <code>-foo</code> swallows up all remaining
|
||
arguments as described by the <code>optarg</code> definitions.</p>
|
||
<p><em>Deriving <code>spec</code> forms from the help output</em></p>
|
||
<p>The option ‘<code>-``-</code>’ allows <code>_arguments</code> to work out the names of long
|
||
options that support the ‘<code>-``-help</code>’ option which is standard in many
|
||
GNU commands. The command word is called with the argument ‘<code>-``-help</code>’
|
||
and the output examined for option names. Clearly, it can be dangerous
|
||
to pass this to commands which may not support this option as the
|
||
behaviour of the command is unspecified.</p>
|
||
<p>In addition to options, ‘<code>_arguments -``-</code>’ will try to deduce the types
|
||
of arguments available for options when the form ‘<code>-``-``opt``=``val</code>’
|
||
is valid. It is also possible to provide hints by examining the help
|
||
text of the command and adding <code>helpspec</code> of the form
|
||
‘<code>pattern``:``message``:``action</code>’; note that other <code>_arguments</code>
|
||
<code>spec</code> forms are not used. The <code>pattern</code> is matched against the help
|
||
text for an option, and if it matches the <code>message</code> and <code>action</code> are
|
||
used as for other argument specifiers. The special case of ‘<code>*:</code>’ means
|
||
both <code>message</code> and <code>action</code> are empty, which has the effect of causing
|
||
options having no description in the help output to be ordered in
|
||
listings ahead of options that have a description.</p>
|
||
<p>For example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">_arguments -- '*\*:toggle:(yes no)' \
|
||
'*=FILE*:file:_files' \
|
||
'*=DIR*:directory:_files -/' \
|
||
'*=PATH*:directory:_files -/'
|
||
</code></pre>
|
||
</div>
|
||
<p>Here, ‘<code>yes</code>’ and ‘<code>no</code>’ will be completed as the argument of options
|
||
whose description ends in a star; file names will be completed for
|
||
options that contain the substring ‘<code>=FILE</code>’ in the description; and
|
||
directories will be completed for options whose description contains
|
||
‘<code>=DIR</code>’ or ‘<code>=PATH</code>’. The last three are in fact the default and so
|
||
need not be given explicitly, although it is possible to override the
|
||
use of these patterns. A typical help text which uses this feature is:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example"> -C, --directory=DIR change to directory DIR
|
||
</code></pre>
|
||
</div>
|
||
<p>so that the above specifications will cause directories to be completed
|
||
after ‘<code>-``-directory</code>’, though not after ‘<code>-C</code>’.</p>
|
||
<p>Note also that <code>_arguments</code> tries to find out automatically if the
|
||
argument for an option is optional. This can be specified explicitly by
|
||
doubling the colon before the <code>message</code>.</p>
|
||
<p>If the <code>pattern</code> ends in ‘<code>(-)</code>’, this will be removed from the pattern
|
||
and the <code>action</code> will be used only directly after the ‘<code>=</code>’, not in the
|
||
next word. This is the behaviour of a normal specification defined with
|
||
the form ‘<code>=-</code>’.</p>
|
||
<p>By default, the command (with the option ‘<code>–help</code>’) is run after
|
||
resetting all the locale categories (except for <code>LC_CTYPE</code>) to ‘<code>C</code>’. If
|
||
the localized help output is known to work, the option ‘<code>-l</code>’ can be
|
||
specified after the ‘<code>_arguments -``-</code>’ so that the command is run in
|
||
the current locale.</p>
|
||
<p>The ‘<code>_arguments -``-</code>’ can be followed by the option ‘<code>-i</code> <code>patterns</code>’
|
||
to give patterns for options which are not to be completed. The patterns
|
||
can be given as the name of an array parameter or as a literal list in
|
||
parentheses. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">_arguments -- -i \
|
||
"(--(en|dis)able-FEATURE*)"
|
||
</code></pre>
|
||
</div>
|
||
<p>will cause completion to ignore the options ‘<code>-``-enable-FEATURE</code>’ and
|
||
‘<code>-``-disable-FEATURE</code>’ (this example is useful with GNU <code>configure</code>).</p>
|
||
<p>The ‘<code>_arguments -``-</code>’ form can also be followed by the option ‘<code>-s</code>
|
||
<code>pair</code>’ to describe option aliases. The <code>pair</code> consists of a list of
|
||
alternating patterns and corresponding replacements, enclosed in parens
|
||
and quoted so that it forms a single argument word in the <code>_arguments</code>
|
||
call.</p>
|
||
<p>For example, some <code>configure</code>-script help output describes options only
|
||
as ‘<code>-``-enable-foo</code>’, but the script also accepts the negated form
|
||
‘<code>-``-disable-foo</code>’. To allow completion of the second form:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">_arguments -- -s "((#s)--enable- --disable-)"
|
||
</code></pre>
|
||
</div>
|
||
<p><em>Miscellaneous notes</em></p>
|
||
<p>Finally, note that <code>_arguments</code> generally expects to be the primary
|
||
function handling any completion for which it is used. It may have side
|
||
effects which change the treatment of any matches added by other
|
||
functions called after it. To combine <code>_arguments</code> with other functions,
|
||
those functions should be called either before <code>_arguments</code>, as an
|
||
<code>action</code> within a <code>spec</code>, or in handlers for ‘<code>->``state</code>’ actions.</p>
|
||
<p>Here is a more general example of the use of <code>_arguments</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">_arguments '-l+:left border:' \
|
||
'-format:paper size:(letter A4)' \
|
||
'*-copy:output file:_files::resolution:(300 600)' \
|
||
':postscript file:_files -g \*.\(ps\|eps\)' \
|
||
'*:page number:'
|
||
</code></pre>
|
||
</div>
|
||
<p>This describes three options: ‘<code>-l</code>’, ‘<code>-format</code>’, and ‘<code>-copy</code>’. The
|
||
first takes one argument described as ‘<code>left border</code>’ for which no
|
||
completion will be offered because of the empty action. Its argument may
|
||
come directly after the ‘<code>-l</code>’ or it may be given as the next word on
|
||
the line.</p>
|
||
<p>The ‘<code>-format</code>’ option takes one argument in the next word, described as
|
||
‘<code>paper size</code>’ for which only the strings ‘<code>letter</code>’ and ‘<code>A4</code>’ will be
|
||
completed.</p>
|
||
<p>The ‘<code>-copy</code>’ option may appear more than once on the command line and
|
||
takes two arguments. The first is mandatory and will be completed as a
|
||
filename. The second is optional (because of the second colon before the
|
||
description ‘<code>resolution</code>’) and will be completed from the strings
|
||
‘<code>300</code>’ and ‘<code>600</code>’.</p>
|
||
<p>The last two descriptions say what should be completed as arguments. The
|
||
first describes the first argument as a ‘<code>postscript file</code>’ and makes
|
||
files ending in ‘<code>ps</code>’ or ‘<code>eps</code>’ be completed. The last description
|
||
gives all other arguments the description ‘<code>page numbers</code>’ but does not
|
||
offer completions.</p>
|
||
<p><span id="index-_005fcache_005finvalid"></span></p>
|
||
<p><code>_cache_invalid</code> <code>cache_identifier</code></p>
|
||
<p>This function returns status zero if the completions cache corresponding
|
||
to the given cache identifier needs rebuilding. It determines this by
|
||
looking up the <code>cache-policy</code> style for the current context. This should
|
||
provide a function name which is run with the full path to the relevant
|
||
cache file as the only argument.</p>
|
||
<p>Example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">_example_caching_policy () {
|
||
# rebuild if cache is more than a week old
|
||
local -a oldp
|
||
oldp=( "$1"(Nm+7) )
|
||
(( $#oldp ))
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-_005fcall_005ffunction"></span></p>
|
||
<p><code>_call_function</code> <code>return</code> <code>name</code> [ <code>arg</code> ... ]</p>
|
||
<p>If a function <code>name</code> exists, it is called with the arguments <code>arg</code>s. The
|
||
<code>return</code> argument gives the name of a parameter in which the return
|
||
status from the function <code>name</code> should be stored; if <code>return</code> is empty
|
||
or a single hyphen it is ignored.</p>
|
||
<p>The return status of <code>_call_function</code> itself is zero if the function
|
||
<code>name</code> exists and was called and non-zero otherwise.</p>
|
||
<p><span id="index-_005fcall_005fprogram"></span></p>
|
||
<p><code>_call_program</code> [ <code>-l</code> ] [ <code>-p</code> ] <code>tag</code> <code>string</code> ...</p>
|
||
<p>This function provides a mechanism for the user to override the use of
|
||
an external command. It looks up the <code>command</code> style with the supplied
|
||
<code>tag</code>. If the style is set, its value is used as the command to execute.
|
||
The <code>string</code>s from the call to <code>_call_program</code>, or from the style if
|
||
set, are concatenated with spaces between them and the resulting string
|
||
is evaluated. The return status is the return status of the command
|
||
called.</p>
|
||
<p>By default, the command is run in an environment where all the locale
|
||
categories (except for <code>LC_CTYPE</code>) are reset to ‘<code>C</code>’ by calling the
|
||
utility function <code>_comp_locale</code> (see below). If the option ‘<code>-l</code>’ is
|
||
given, the command is run with the current locale.</p>
|
||
<p>If the option ‘<code>-p</code>’ is supplied it indicates that the command output is
|
||
influenced by the permissions it is run with. If the <code>gain-privileges</code>
|
||
style is set to true, <code>_call_program</code> will make use of commands such as
|
||
<code>sudo</code>, if present on the command-line, to match the permissions to
|
||
whatever the final command is likely to run under. When looking up the
|
||
<code>gain-privileges</code> and <code>command</code> styles, the command component of the
|
||
zstyle context will end with a slash (‘<code>/</code>’) followed by the command
|
||
that would be used to gain privileges.</p>
|
||
<p><span id="index-_005fcombination"></span></p>
|
||
<p><code>_combination</code> [ <code>-s</code> <code>pattern</code> ] <code>tag</code> <code>style</code> <code>spec</code> ... <code>field</code>
|
||
<code>opts</code> ...</p>
|
||
<p>This function is used to complete combinations of values, for example
|
||
pairs of hostnames and usernames. The <code>style</code> argument gives the style
|
||
which defines the pairs; it is looked up in a context with the <code>tag</code>
|
||
specified.</p>
|
||
<p>The style name consists of field names separated by hyphens, for example
|
||
‘<code>users-hosts-ports</code>’. For each field for a value is already known, a
|
||
<code>spec</code> of the form ‘<code>field``=``pattern</code>’ is given. For example, if the
|
||
command line so far specifies a user ‘<code>pws</code>’, the argument ‘<code>users=pws</code>’
|
||
should appear.</p>
|
||
<p>The next argument with no equals sign is taken as the name of the field
|
||
for which completions should be generated (presumably not one of the
|
||
<code>field</code>s for which the value is known).</p>
|
||
<p>The matches generated will be taken from the value of the style. These
|
||
should contain the possible values for the combinations in the
|
||
appropriate order (users, hosts, ports in the example above). The values
|
||
for the different fields are separated by colons. This can be altered
|
||
with the option <code>-s</code> to <code>_combination</code> which specifies a pattern.
|
||
Typically this is a character class, as for example ‘<code>-s "[:@]"</code>’ in the
|
||
case of the <code>users-hosts</code> style. Each ‘<code>field``=``pattern</code>’
|
||
specification restricts the completions which apply to elements of the
|
||
style with appropriately matching fields.</p>
|
||
<p>If no style with the given name is defined for the given tag, or if none
|
||
of the strings in style’s value match, but a function name of the
|
||
required field preceded by an underscore is defined, that function will
|
||
be called to generate the matches. For example, if there is no
|
||
‘<code>users-hosts-ports</code>’ or no matching hostname when a host is required,
|
||
the function ‘<code>_hosts</code>’ will automatically be called.</p>
|
||
<p>If the same name is used for more than one field, in both the
|
||
‘<code>field``=``pattern</code>’ and the argument that gives the name of the
|
||
field to be completed, the number of the field (starting with one) may
|
||
be given after the fieldname, separated from it by a colon.</p>
|
||
<p>All arguments after the required field name are passed to <code>compadd</code> when
|
||
generating matches from the style value, or to the functions for the
|
||
fields if they are called.</p>
|
||
<p><span id="index-_005fcommand_005fnames"></span></p>
|
||
<p><code>_command_names</code> [ <code>-e</code> | <code>-</code> ]</p>
|
||
<p>This function completes words that are valid at command position: names
|
||
of aliases, builtins, hashed commands, functions, and so on. With the
|
||
<code>-e</code> flag, only hashed commands are completed. The <code>-</code> flag is ignored.</p>
|
||
<p><span id="index-_005fcomp_005flocale"></span></p>
|
||
<p><code>_comp_locale</code></p>
|
||
<p>This function resets all the locale categories other than <code>LC_CTYPE</code> to
|
||
‘<code>C</code>’ so that the output from external commands can be easily analyzed
|
||
by the completion system. <code>LC_CTYPE</code> retains the current value (taking
|
||
<code>LC_ALL</code> and <code>LANG</code> into account), ensuring that non-ASCII characters in
|
||
file names are still handled properly.</p>
|
||
<p>This function should normally be run only in a subshell, because the new
|
||
locale is exported to the environment. Typical usage would be
|
||
‘<code> $(_comp_locale; ``command</code> ...<code>)</code>’.</p>
|
||
<p><span id="index-_005fcompleters"></span></p>
|
||
<p><code>_completers</code> [ <code>-p</code> ]</p>
|
||
<p>This function completes names of completers.</p>
|
||
<ul>
|
||
<li><code>-p</code><br />
|
||
Include the leading underscore (‘<code>_</code>’) in the matches.</li>
|
||
</ul>
|
||
<p><span id="index-_005fdescribe"></span></p>
|
||
<p><code>_describe </code>[<code>-12JVx</code>] [ <code>-oO</code> | <code>-t</code> <code>tag</code> ] <code>descr</code> <code>name1</code> [
|
||
<code>name2</code> ] [ <code>opt</code> ... ]</p>
|
||
<p><code> </code>[ <code>-``-</code> <code>name1</code> [ <code>name2</code> ] [ <code>opt</code> ... ] ... ]</p>
|
||
<p>This function associates completions with descriptions. Multiple groups
|
||
separated by <code>-``-</code> can be supplied, potentially with different
|
||
completion options <code>opt</code>s.</p>
|
||
<p>The <code>descr</code> is taken as a string to display above the matches if the
|
||
<code>format</code> style for the <code>descriptions</code> tag is set. This is followed by
|
||
one or two names of arrays followed by options to pass to <code>compadd</code>. The
|
||
array <code>name1</code> contains the possible completions with their descriptions
|
||
in the form ‘<code>completion``:``description</code>’. Any literal colons in
|
||
<code>completion</code> must be quoted with a backslash. If a <code>name2</code> is given, it
|
||
should have the same number of elements as <code>name1</code>; in this case the
|
||
corresponding elements are added as possible completions instead of the
|
||
<code>completion</code> strings from <code>name1</code>. The completion list will retain the
|
||
descriptions from <code>name1</code>. Finally, a set of completion options can
|
||
appear.</p>
|
||
<p>If the option ‘<code>-o</code>’ appears before the first argument, the matches
|
||
added will be treated as names of command options (N.B. not shell
|
||
options), typically following a ‘<code>-</code>’, ‘<code>-``-</code>’ or ‘<code>+</code>’ on the command
|
||
line. In this case <code>_describe</code> uses the <code>prefix-hidden</code>, <code>prefix-needed</code>
|
||
and <code>verbose</code> styles to find out if the strings should be added as
|
||
completions and if the descriptions should be shown. Without the ‘<code>-o</code>’
|
||
option, only the <code>verbose</code> style is used to decide how descriptions are
|
||
shown. If ‘<code>-O</code>’ is used instead of ‘<code>-o</code>’, command options are
|
||
completed as above but <code>_describe</code> will not handle the <code>prefix-needed</code>
|
||
style.</p>
|
||
<p>With the <code>-t</code> option a <code>tag</code> can be specified. The default is ‘<code>values</code>’
|
||
or, if the <code>-o</code> option is given, ‘<code>options</code>’.</p>
|
||
<p>The options <code>-1</code>, <code>-2</code>, <code>-J</code>, <code>-V</code>, <code>-x</code> are passed to <code>_next_label</code>.</p>
|
||
<p>If selected by the <code>list-grouped</code> style, strings with the same
|
||
description will appear together in the list.</p>
|
||
<p><code>_describe</code> uses the <code>_all_labels</code> function to generate the matches, so
|
||
it does not need to appear inside a loop over tag labels.</p>
|
||
<p><span id="index-_005fdescription"></span></p>
|
||
<p><code>_description</code> [ <code>-x</code> ] [ <code>-12VJ</code> ] <code>tag</code> <code>name</code> <code>descr</code> [ <code>spec</code>
|
||
... ]</p>
|
||
<p>This function is not to be confused with the previous one; it is used as
|
||
a helper function for creating options to <code>compadd</code>. It is buried inside
|
||
many of the higher level completion functions and so often does not need
|
||
to be called directly.</p>
|
||
<p>The styles listed below are tested in the current context using the
|
||
given <code>tag</code>. The resulting options for <code>compadd</code> are put into the array
|
||
named <code>name</code> (this is traditionally ‘<code>expl</code>’, but this convention is not
|
||
enforced). The description for the corresponding set of matches is
|
||
passed to the function in <code>descr</code>.</p>
|
||
<p>The styles tested are: <code>format</code>, <code>hidden</code>, <code>matcher</code>, <code>ignore-line</code>,
|
||
<code>ignored-patterns</code>, <code>group-name</code> and <code>sort</code>. The <code>format</code> style is first
|
||
tested for the given <code>tag</code> and then for the <code>descriptions</code> tag if no
|
||
value was found, while the remainder are only tested for the tag given
|
||
as the first argument. The function also calls <code>_setup</code> which tests some
|
||
more styles.</p>
|
||
<p>The string returned by the <code>format</code> style (if any) will be modified so
|
||
that the sequence ‘<code>%d</code>’ is replaced by the <code>descr</code> given as the third
|
||
argument without any leading or trailing white space. If, after removing
|
||
the white space, the <code>descr</code> is the empty string, the format style will
|
||
not be used and the options put into the <code>name</code> array will not contain
|
||
an explanation string to be displayed above the matches.</p>
|
||
<p>If <code>_description</code> is called with more than three arguments, the
|
||
additional <code>spec</code>s should be of the form ‘<code>char``:``str</code>’. These supply
|
||
escape sequence replacements for the <code>format</code> style: every appearance of
|
||
‘<code>%``char</code>’ will be replaced by <code>string</code>.</p>
|
||
<p>If the <code>-x</code> option is given, the description will be passed to <code>compadd</code>
|
||
using the <code>-x</code> option instead of the default <code>-X</code>. This means that the
|
||
description will be displayed even if there are no corresponding
|
||
matches.</p>
|
||
<p>The options placed in the array <code>name</code> take account of the <code>group-name</code>
|
||
style, so matches are placed in a separate group where necessary. The
|
||
group normally has its elements sorted (by passing the option <code>-J</code> to
|
||
<code>compadd</code>), but if an option starting with ‘<code>-V</code>’, ‘<code>-J</code>’, ‘<code>-1</code>’, or
|
||
‘<code>-2</code>’ is passed to <code>_description</code>, that option will be included in
|
||
the array. Hence it is possible for the completion group to be unsorted
|
||
by giving the option ‘<code>-V</code>’, ‘<code>-1V</code>’, or ‘<code>-2V</code>’.</p>
|
||
<p>In most cases, the function will be used like this:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">local expl
|
||
_description files expl file
|
||
compadd "$expl[@]" - "$files[@]"
|
||
</code></pre>
|
||
</div>
|
||
<p>Note the use of the parameter <code>expl</code>, the hyphen, and the list of
|
||
matches. Almost all calls to <code>compadd</code> within the completion system use
|
||
a similar format; this ensures that user-specified styles are correctly
|
||
passed down to the builtins which implement the internals of completion.</p>
|
||
<p><span id="index-_005fdir_005flist"></span></p>
|
||
<p><code>_dir_list</code> [ <code>-s</code> <code>sep</code> ] [ <code>-S</code> ]</p>
|
||
<p>Complete a list of directory names separated by colons (the same format
|
||
as <code>$PATH</code>).</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-s</code> <code>sep</code><br />
|
||
Use <code>sep</code> as separator between items. <code>sep</code> defaults to a colon
|
||
(‘<code>:</code>’).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-S</code><br />
|
||
Add <code>sep</code> instead of slash (‘<code>/</code>’) as an autoremoveable suffix.</p>
|
||
</li>
|
||
</ul>
|
||
<p><span id="index-_005fdispatch"></span></p>
|
||
<p><code>_dispatch</code> <code>context string</code> ...</p>
|
||
<p>This sets the current context to <code>context</code> and looks for completion
|
||
functions to handle this context by hunting through the list of command
|
||
names or special contexts (as described above for <code>compdef</code>) given as
|
||
<code>string</code>s. The first completion function to be defined for one of the
|
||
contexts in the list is used to generate matches. Typically, the last
|
||
<code>string</code> is <code>-default-</code> to cause the function for default completion to
|
||
be used as a fallback.</p>
|
||
<p>The function sets the parameter <code>$service</code> to the <code>string</code> being tried,
|
||
and sets the <code>context/command</code> field (the fourth) of the <code>$curcontext</code>
|
||
parameter to the <code>context</code> given as the first argument.</p>
|
||
<p><span id="index-_005femail_005faddresses"></span></p>
|
||
<p><code>_email_addresses</code> [ <code>-c</code> ] [ <code>-n</code> <code>plugin</code> ]</p>
|
||
<p>Complete email addresses. Addresses are provided by plugins.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-c</code><br />
|
||
Complete bare <code>localhost@domain.tld</code> addresses, without a name part
|
||
or a comment. Without this option, RFC822 ‘<code>Firstname Lastname</code>
|
||
<code><``address``></code>’ strings are completed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-n</code> <code>plugin</code><br />
|
||
Complete aliases from <code>plugin</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<p>The following plugins are available by default: <code>_email-ldap</code> (see the
|
||
<code>filter</code> style), <code>_email-local</code> (completes <code>user``@``hostname</code> Unix
|
||
addresses), <code>_email-mail</code> (completes aliases from <code>~/.mailrc</code>),
|
||
<code>_email-mush</code>, <code>_email-mutt</code>, and <code>_email-pine</code>.</p>
|
||
<p>Addresses from the <code>_email-``foo</code> plugin are added under the tag
|
||
‘<code>email-``foo</code>’.</p>
|
||
<p><em>Writing plugins</em></p>
|
||
<p>Plugins are written as separate functions with names starting with
|
||
‘<code>_email-</code>’. They are invoked with the <code>-c</code> option and <code>compadd</code>
|
||
options. They should either do their own completion or set the <code>$reply</code>
|
||
array to a list of ‘<code>alias``:``address</code>’ elements and return <code>300</code>. New
|
||
plugins will be picked up and run automatically.</p>
|
||
<p><span id="index-_005ffiles"></span></p>
|
||
<p><code>_files</code></p>
|
||
<p>The function <code>_files</code> is a wrapper around <code>_path_files</code>. It supports all
|
||
of the same functionality, with some enhancements — notably, it respects
|
||
the <code>list-dirs-first</code> style, and it allows users to override the
|
||
behaviour of the <code>-g</code> and <code>-/</code> options with the <code>file-patterns</code> style.
|
||
<code>_files</code> should therefore be preferred over <code>_path_files</code> in most cases.</p>
|
||
<p>This function accepts the full set of options allowed by <code>_path_files</code>,
|
||
described below.</p>
|
||
<p><span id="index-_005fgnu_005fgeneric"></span></p>
|
||
<p><code>_gnu_generic</code></p>
|
||
<p>This function is a simple wrapper around the <code>_arguments</code> function
|
||
described above. It can be used to determine automatically the long
|
||
options understood by commands that produce a list when passed the
|
||
option ‘<code>-``-help</code>’. It is intended to be used as a top-level completion
|
||
function in its own right. For example, to enable option completion for
|
||
the commands <code>foo</code> and <code>bar</code>, use</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compdef _gnu_generic foo bar
|
||
</code></pre>
|
||
</div>
|
||
<p>after the call to <code>compinit</code>.</p>
|
||
<p>The completion system as supplied is conservative in its use of this
|
||
function, since it is important to be sure the command understands the
|
||
option ‘<code>-``-help</code>’.</p>
|
||
<p><span id="index-_005fguard"></span></p>
|
||
<p><code>_guard</code> [ <code>options</code> ] <code>pattern descr</code></p>
|
||
<p>This function displays <code>descr</code> if <code>pattern</code> matches the string to be
|
||
completed. It is intended to be used in the <code>action</code> for the
|
||
specifications passed to <code>_arguments</code> and similar functions.</p>
|
||
<p>The return status is zero if the message was displayed and the word to
|
||
complete is not empty, and non-zero otherwise.</p>
|
||
<p>The <code>pattern</code> may be preceded by any of the options understood by
|
||
<code>compadd</code> that are passed down from <code>_description</code>, namely <code>-M</code>, <code>-J</code>,
|
||
<code>-V</code>, <code>-1</code>, <code>-2</code>, <code>-n</code>, <code>-F</code> and <code>-X</code>. All of these options will be
|
||
ignored. This fits in conveniently with the argument-passing conventions
|
||
of actions for <code>_arguments</code>.</p>
|
||
<p>As an example, consider a command taking the options <code>-n</code> and <code>-none</code>,
|
||
where <code>-n</code> must be followed by a numeric value in the same word. By
|
||
using:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">_arguments '-n-: :_guard "[0-9]#" "numeric value"' '-none'
|
||
</code></pre>
|
||
</div>
|
||
<p><code>_arguments</code> can be made to both display the message ‘<code>numeric value</code>’
|
||
and complete options after ‘<code>-n<TAB></code>’. If the ‘<code>-n</code>’ is already
|
||
followed by one or more digits (the pattern passed to <code>_guard</code>) only the
|
||
message will be displayed; if the ‘<code>-n</code>’ is followed by another
|
||
character, only options are completed.</p>
|
||
<p><span id="index-_005fmessage"></span></p>
|
||
<p><code>_message</code> [ <code>-r12</code> ] [ <code>-VJ</code> <code>group</code> ] <code>descr</code></p>
|
||
<p><code>_message -e</code> [ <code>tag</code> ] <code>descr</code></p>
|
||
<p>The <code>descr</code> is used in the same way as the third argument to the
|
||
<code>_description</code> function, except that the resulting string will always be
|
||
shown whether or not matches were generated. This is useful for
|
||
displaying a help message in places where no completions can be
|
||
generated.</p>
|
||
<p>The <code>format</code> style is examined with the <code>messages</code> tag to find a
|
||
message; the usual tag, <code>descriptions</code>, is used only if the style is not
|
||
set with the former.</p>
|
||
<p>If the <code>-r</code> option is given, no style is used; the <code>descr</code> is taken
|
||
literally as the string to display. This is most useful when the <code>descr</code>
|
||
comes from a pre-processed argument list which already contains an
|
||
expanded description. Note that this option does not disable the
|
||
‘<code>%</code>’-sequence parsing done by <code>compadd</code>.</p>
|
||
<p>The <code>-12VJ</code> options and the <code>group</code> are passed to <code>compadd</code> and hence
|
||
determine the group the message string is added to.</p>
|
||
<p>The second <code>-e</code> form gives a description for completions with the tag
|
||
<code>tag</code> to be shown even if there are no matches for that tag. This form
|
||
is called by <code>_arguments</code> in the event that there is no action for an
|
||
option specification. The tag can be omitted and if so the tag is taken
|
||
from the parameter <code>$curtag</code>; this is maintained by the completion
|
||
system and so is usually correct. Note that if there are no matches at
|
||
the time this function is called, <code>compstate[insert]</code> is cleared, so
|
||
additional matches generated later are not inserted on the command line.</p>
|
||
<p><span id="index-_005fmulti_005fparts"></span></p>
|
||
<p><code>_multi_parts</code> [ <code>-i</code> ] <code>sep</code> <code>array</code></p>
|
||
<p>The argument <code>sep</code> is a separator character. The <code>array</code> may be either
|
||
the name of an array parameter or a literal array in the form ‘<code>(foo bar``)</code>’, a parenthesised list of words separated by whitespace. The
|
||
possible completions are the strings from the array. However, each chunk
|
||
delimited by <code>sep</code> will be completed separately. For example, the <code>_tar</code>
|
||
function uses ‘<code>_multi_parts</code> <code>/</code> <code>patharray</code>’ to complete partial file
|
||
paths from the given array of complete file paths.</p>
|
||
<p>The <code>-i</code> option causes <code>_multi_parts</code> to insert a unique match even if
|
||
that requires multiple separators to be inserted. This is not usually
|
||
the expected behaviour with filenames, but certain other types of
|
||
completion, for example those with a fixed set of possibilities, may be
|
||
more suited to this form.</p>
|
||
<p>Like other utility functions, this function accepts the ‘<code>-V</code>’, ‘<code>-J</code>’,
|
||
‘<code>-1</code>’, ‘<code>-2</code>’, ‘<code>-n</code>’, ‘<code>-f</code>’, ‘<code>-X</code>’, ‘<code>-M</code>’, ‘<code>-P</code>’, ‘<code>-S</code>’,
|
||
‘<code>-r</code>’, ‘<code>-R</code>’, and ‘<code>-q</code>’ options and passes them to the <code>compadd</code>
|
||
builtin.</p>
|
||
<p><span id="index-_005fnext_005flabel"></span></p>
|
||
<p><code>_next_label</code> [ <code>-x</code> ] [ <code>-12VJ</code> ] <code>tag</code> <code>name</code> <code>descr</code> [ <code>option</code>
|
||
... ]</p>
|
||
<p>This function is used to implement the loop over different tag labels
|
||
for a particular tag as described above for the <code>tag-order</code> style. On
|
||
each call it checks to see if there are any more tag labels; if there is
|
||
it returns status zero, otherwise non-zero. As this function requires a
|
||
current tag to be set, it must always follow a call to <code>_tags</code> or
|
||
<code>_requested</code>.</p>
|
||
<p>The <code>-x12VJ</code> options and the first three arguments are passed to the
|
||
<code>_description</code> function. Where appropriate the <code>tag</code> will be replaced by
|
||
a tag label in this call. Any description given in the <code>tag-order</code> style
|
||
is preferred to the <code>descr</code> passed to <code>_next_label</code>.</p>
|
||
<p>The <code>option</code>s given after the <code>descr</code> are set in the parameter given by
|
||
<code>name</code>, and hence are to be passed to <code>compadd</code> or whatever function is
|
||
called to add the matches.</p>
|
||
<p>Here is a typical use of this function for the tag <code>foo</code>. The call to
|
||
<code>_requested</code> determines if tag <code>foo</code> is required at all; the loop over
|
||
<code>_next_label</code> handles any labels defined for the tag in the <code>tag-order</code>
|
||
style.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">local expl ret=1
|
||
...
|
||
if _requested foo; then
|
||
...
|
||
while _next_label foo expl '...'; do
|
||
compadd "$expl[@]" ... && ret=0
|
||
done
|
||
...
|
||
fi
|
||
return ret
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-_005fnormal"></span></p>
|
||
<p><code>_normal</code> [ <code>-P</code> | <code>-p</code> <code>precommand</code> ]</p>
|
||
<p>This is the standard function called to handle completion outside any
|
||
special <code>-``context``-</code>. It is called both to complete the command word
|
||
and also the arguments for a command. In the second case, <code>_normal</code>
|
||
looks for a special completion for that command, and if there is none it
|
||
uses the completion for the <code>-default-</code> context.</p>
|
||
<p>A second use is to reexamine the command line specified by the <code>$words</code>
|
||
array and the <code>$CURRENT</code> parameter after those have been modified. For
|
||
example, the function <code>_precommand</code>, which completes after precommand
|
||
specifiers such as <code>nohup</code>, removes the first word from the <code>words</code>
|
||
array, decrements the <code>CURRENT</code> parameter, then calls ‘<code>_normal -p $service</code>’. The effect is that ‘<code>nohup</code> <code>cmd ...</code>’ is treated in the
|
||
same way as ‘<code>cmd ...</code>’.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-P</code><br />
|
||
Reset the list of precommands. This option should be used if
|
||
completing a command line which allows internal commands (e.g.
|
||
builtins and functions) regardless of prior precommands (e.g. ‘<code>zsh -c</code>’).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-p</code> <code>precommand</code><br />
|
||
Append <code>precommand</code> to the list of precommands. This option should
|
||
be used in nearly all cases in which <code>-P</code> is not applicable.</p>
|
||
</li>
|
||
</ul>
|
||
<p>If the command name matches one of the patterns given by one of the
|
||
options <code>-p</code> or <code>-P</code> to <code>compdef</code>, the corresponding completion function
|
||
is called and then the parameter <code>_compskip</code> is checked. If it is set
|
||
completion is terminated at that point even if no matches have been
|
||
found. This is the same effect as in the <code>-first-</code> context.</p>
|
||
<p><span id="index-_005foptions"></span></p>
|
||
<p><code>_options</code></p>
|
||
<p>This can be used to complete the names of shell options. It provides a
|
||
matcher specification that ignores a leading ‘<code>no</code>’, ignores underscores
|
||
and allows upper-case letters to match their lower-case counterparts
|
||
(for example, ‘<code>glob</code>’, ‘<code>noglob</code>’, ‘<code>NO_GLOB</code>’ are all completed). Any
|
||
arguments are propagated to the <code>compadd</code> builtin.</p>
|
||
<p><span id="index-_005foptions_005fset"></span>
|
||
<span id="index-_005foptions_005funset"></span></p>
|
||
<p><code>_options_set</code> and <code>_options_unset</code></p>
|
||
<p>These functions complete only set or unset options, with the same
|
||
matching specification used in the <code>_options</code> function.</p>
|
||
<p>Note that you need to uncomment a few lines in the <code>_main_complete</code>
|
||
function for these functions to work properly. The lines in question are
|
||
used to store the option settings in effect before the completion widget
|
||
locally sets the options it needs. Hence these functions are not
|
||
generally used by the completion system.</p>
|
||
<p><span id="index-_005fparameters"></span></p>
|
||
<p><code>_parameters</code></p>
|
||
<p>This is used to complete the names of shell parameters.</p>
|
||
<p>The option ‘<code>-g</code> <code>pattern</code>’ limits the completion to parameters whose
|
||
type matches the <code>pattern</code>. The type of a parameter is that shown by
|
||
‘<code>print ${(t)``param``}</code>’, hence judicious use of ‘<code>*</code>’ in <code>pattern</code>
|
||
is probably necessary.</p>
|
||
<p>All other arguments are passed to the <code>compadd</code> builtin.</p>
|
||
<p><span id="index-_005fpath_005ffiles"></span></p>
|
||
<p><code>_path_files</code></p>
|
||
<p>This function is used throughout the completion system to complete
|
||
filenames. It allows completion of partial paths. For example, the
|
||
string ‘<code>/u/i/s/sig</code>’ may be completed to ‘<code>/usr/include/sys/signal.h</code>’.</p>
|
||
<p>The options accepted by both <code>_path_files</code> and <code>_files</code> are:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-f</code><br />
|
||
Complete all filenames. This is the default.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-/</code><br />
|
||
Specifies that only directories should be completed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-g</code> <code>pattern</code><br />
|
||
Specifies that only files matching the <code>pattern</code> should be
|
||
completed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-W</code> <code>paths</code><br />
|
||
Specifies path prefixes that are to be prepended to the string from
|
||
the command line to generate the filenames but that should not be
|
||
inserted as completions nor shown in completion listings. Here,
|
||
<code>paths</code> may be the name of an array parameter, a literal list of
|
||
paths enclosed in parentheses or an absolute pathname.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-F</code> <code>ignored-files</code><br />
|
||
This behaves as for the corresponding option to the <code>compadd</code>
|
||
builtin. It gives direct control over which filenames should be
|
||
ignored. If the option is not present, the <code>ignored-patterns</code> style
|
||
is used.</p>
|
||
</li>
|
||
</ul>
|
||
<p>Both <code>_path_files</code> and <code>_files</code> also accept the following options which
|
||
are passed to <code>compadd</code>: ‘<code>-J</code>’, ‘<code>-V</code>’, ‘<code>-1</code>’, ‘<code>-2</code>’, ‘<code>-n</code>’, ‘<code>-X</code>’,
|
||
‘<code>-M</code>’, ‘<code>-P</code>’, ‘<code>-S</code>’, ‘<code>-q</code>’, ‘<code>-r</code>’, and ‘<code>-R</code>’.</p>
|
||
<p>Finally, the <code>_path_files</code> function uses the styles <code>expand</code>,
|
||
<code>ambiguous</code>, <code>special-dirs</code>, <code>list-suffixes</code> and <code>file-sort</code> described
|
||
above.</p>
|
||
<p><span id="index-_005fpick_005fvariant"></span></p>
|
||
<p><code>_pick_variant </code>[ <code>-b</code> <code>builtin-label</code> ] [ <code>-c</code> <code>command</code> ] [
|
||
<code>-r</code> <code>name</code> ]</p>
|
||
<p><code> ``label``=``pattern</code> ... <code>label</code> [ <code>arg</code> ... ]</p>
|
||
<p>This function is used to resolve situations where a single command name
|
||
requires more than one type of handling, either because it has more than
|
||
one variant or because there is a name clash between two different
|
||
commands.</p>
|
||
<p>The command to run is taken from the first element of the array <code>words</code>
|
||
unless this is overridden by the option <code>-c</code>. This command is run and
|
||
its output is compared with a series of patterns. Arguments to be passed
|
||
to the command can be specified at the end after all the other
|
||
arguments. The patterns to try in order are given by the arguments
|
||
<code>label``=``pattern</code>; if the output of ‘<code>command</code> <code>arg</code> ...’ contains
|
||
<code>pattern</code>, then <code>label</code> is selected as the label for the command
|
||
variant. If none of the patterns match, the final command label is
|
||
selected and status 1 is returned.</p>
|
||
<p>If the ‘<code>-b</code> <code>builtin-label</code>’ is given, the command is tested to see if
|
||
it is provided as a shell builtin, possibly autoloaded; if so, the label
|
||
<code>builtin-label</code> is selected as the label for the variant.</p>
|
||
<p>If the ‘<code>-r</code> <code>name</code>’ is given, the <code>label</code> picked is stored in the
|
||
parameter named <code>name</code>.</p>
|
||
<p>The results are also cached in the <code>_cmd_variant</code> associative array
|
||
indexed by the name of the command run.</p>
|
||
<p><span id="index-_005fregex_005farguments"></span></p>
|
||
<p><code>_regex_arguments</code> <code>name</code> <code>spec</code> ...</p>
|
||
<p>This function generates a completion function <code>name</code> which matches the
|
||
specifications <code>spec</code>s, a set of regular expressions as described below.
|
||
After running <code>_regex_arguments</code>, the function <code>name</code> should be called
|
||
as a normal completion function. The pattern to be matched is given by
|
||
the contents of the <code>words</code> array up to the current cursor position
|
||
joined together with null characters; no quotation is applied.</p>
|
||
<p>The arguments are grouped as sets of alternatives separated by ‘<code>|</code>’,
|
||
which are tried one after the other until one matches. Each alternative
|
||
consists of a one or more specifications which are tried left to right,
|
||
with each pattern matched being stripped in turn from the command line
|
||
being tested, until all of the group succeeds or until one fails; in the
|
||
latter case, the next alternative is tried. This structure can be
|
||
repeated to arbitrary depth by using parentheses; matching proceeds from
|
||
inside to outside.</p>
|
||
<p>A special procedure is applied if no test succeeds but the remaining
|
||
command line string contains no null character (implying the remaining
|
||
word is the one for which completions are to be generated). The
|
||
completion target is restricted to the remaining word and any <code>action</code>s
|
||
for the corresponding patterns are executed. In this case, nothing is
|
||
stripped from the command line string. The order of evaluation of the
|
||
<code>action</code>s can be determined by the <code>tag-order</code> style; the various
|
||
formats supported by <code>_alternative</code> can be used in <code>action</code>. The <code>descr</code>
|
||
is used for setting up the array parameter <code>expl</code>.</p>
|
||
<p>Specification arguments take one of following forms, in which
|
||
metacharacters such as ‘<code>(</code>’, ‘<code>)</code>’, ‘<code>#</code>’ and ‘<code>|</code>’ should be quoted.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>/``pattern``/</code> [<code>%``lookahead``%</code>] [<code>-``guard</code>]
|
||
[<code>:``tag``:``descr``:``action</code>]<br />
|
||
This is a single primitive component. The function tests whether the
|
||
combined pattern ‘<code>(#b)((#B)``pattern``)``lookahead``*</code>’ matches the
|
||
command line string. If so, ‘<code>guard</code>’ is evaluated and its return
|
||
status is examined to determine if the test has succeeded. The
|
||
<code>pattern</code> string ‘<code>[]</code>’ is guaranteed never to match. The
|
||
<code>lookahead</code> is not stripped from the command line before the next
|
||
pattern is examined.</p>
|
||
<p>The argument starting with <code>:</code> is used in the same manner as an
|
||
argument to <code>_alternative</code>.</p>
|
||
<p>A component is used as follows: <code>pattern</code> is tested to see if the
|
||
component already exists on the command line. If it does, any
|
||
following specifications are examined to find something to complete.
|
||
If a component is reached but no such pattern exists yet on the
|
||
command line, the string containing the <code>action</code> is used to generate
|
||
matches to insert at that point.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>/``pattern``/+</code> [<code>%``lookahead``%</code>] [<code>-``guard</code>]
|
||
[<code>:``tag``:``descr``:``action</code>]<br />
|
||
This is similar to ‘<code>/``pattern``/</code> ...’ but the left part of the
|
||
command line string (i.e. the part already matched by previous
|
||
patterns) is also considered part of the completion target.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>/``pattern``/-</code> [<code>%``lookahead``%</code>] [<code>-``guard</code>]
|
||
[<code>:``tag``:``descr``:``action</code>]<br />
|
||
This is similar to ‘<code>/``pattern``/</code> ...’ but the <code>action</code>s of the
|
||
current and previously matched patterns are ignored even if the
|
||
following ‘<code>pattern</code>’ matches the empty string.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>(</code> <code>spec</code> <code>)</code><br />
|
||
Parentheses may be used to groups <code>spec</code>s; note each parenthesis is
|
||
a single argument to <code>_regex_arguments</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>spec</code> <code>#</code><br />
|
||
This allows any number of repetitions of <code>spec</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>spec</code> <code>spec</code><br />
|
||
The two <code>spec</code>s are to be matched one after the other as described
|
||
above.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>spec</code> <code>|</code> <code>spec</code><br />
|
||
Either of the two <code>spec</code>s can be matched.</p>
|
||
</li>
|
||
</ul>
|
||
<p>The function <code>_regex_words</code> can be used as a helper function to generate
|
||
matches for a set of alternative words possibly with their own arguments
|
||
as a command line argument.</p>
|
||
<p>Examples:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">_regex_arguments _tst /$'[^\0]#\0'/ \
|
||
/$'[^\0]#\0'/ :'compadd aaa'
|
||
</code></pre>
|
||
</div>
|
||
<p>This generates a function <code>_tst</code> that completes <code>aaa</code> as its only
|
||
argument. The <code>tag</code> and <code>description</code> for the action have been omitted
|
||
for brevity (this works but is not recommended in normal use). The first
|
||
component matches the command word, which is arbitrary; the second
|
||
matches any argument. As the argument is also arbitrary, any following
|
||
component would not depend on <code>aaa</code> being present.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">_regex_arguments _tst /$'[^\0]#\0'/ \
|
||
/$'aaa\0'/ :'compadd aaa'
|
||
</code></pre>
|
||
</div>
|
||
<p>This is a more typical use; it is similar, but any following patterns
|
||
would only match if <code>aaa</code> was present as the first argument.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">_regex_arguments _tst /$'[^\0]#\0'/ \( \
|
||
/$'aaa\0'/ :'compadd aaa' \
|
||
/$'bbb\0'/ :'compadd bbb' \) \#
|
||
</code></pre>
|
||
</div>
|
||
<p>In this example, an indefinite number of command arguments may be
|
||
completed. Odd arguments are completed as <code>aaa</code> and even arguments as
|
||
<code>bbb</code>. Completion fails unless the set of <code>aaa</code> and <code>bbb</code> arguments
|
||
before the current one is matched correctly.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">_regex_arguments _tst /$'[^\0]#\0'/ \
|
||
\( /$'aaa\0'/ :'compadd aaa' \| \
|
||
/$'bbb\0'/ :'compadd bbb' \) \#
|
||
</code></pre>
|
||
</div>
|
||
<p>This is similar, but either <code>aaa</code> or <code>bbb</code> may be completed for any
|
||
argument. In this case <code>_regex_words</code> could be used to generate</p>
|
||
<p><span id="index-_005fregex_005fwords-_005b-_002dt-term-_005d"></span></p>
|
||
<p><code>_regex_words</code> <code>tag</code> <code>description</code> <code>spec</code> ...</p>
|
||
<p>This function can be used to generate arguments for the
|
||
<code>_regex_arguments</code> command which may be inserted at any point where a
|
||
set of rules is expected. The <code>tag</code> and <code>description</code> give a standard
|
||
tag and description pertaining to the current context. Each <code>spec</code>
|
||
contains two or three arguments separated by a colon: note that there is
|
||
no leading colon in this case.</p>
|
||
<p>Each <code>spec</code> gives one of a set of words that may be completed at this
|
||
point, together with arguments. It is thus roughly equivalent to the
|
||
<code>_arguments</code> function when used in normal (non-regex) completion.</p>
|
||
<p>The part of the <code>spec</code> before the first colon is the word to be
|
||
completed. This may contain a <code>*</code>; the entire word, before and after the
|
||
<code>*</code> is completed, but only the text before the <code>*</code> is required for the
|
||
context to be matched, so that further arguments may be completed after
|
||
the abbreviated form.</p>
|
||
<p>The second part of <code>spec</code> is a description for the word being completed.</p>
|
||
<p>The optional third part of the <code>spec</code> describes how words following the
|
||
one being completed are themselves to be completed. It will be evaluated
|
||
in order to avoid problems with quoting. This means that typically it
|
||
contains a reference to an array containing previously generated regex
|
||
arguments.</p>
|
||
<p>The option <code>-t</code> <code>term</code> specifies a terminator for the word instead of
|
||
the usual space. This is handled as an auto-removable suffix in the
|
||
manner of the option <code>-s</code> <code>sep</code> to <code>_values</code>.</p>
|
||
<p>The result of the processing by <code>_regex_words</code> is placed in the array
|
||
<code>reply</code>, which should be made local to the calling function. If the set
|
||
of words and arguments may be matched repeatedly, a <code>#</code> should be
|
||
appended to the generated array at that point.</p>
|
||
<p>For example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">local -a reply
|
||
_regex_words mydb-commands 'mydb commands' \
|
||
'add:add an entry to mydb:$mydb_add_cmds' \
|
||
'show:show entries in mydb'
|
||
_regex_arguments _mydb "$reply[@]"
|
||
_mydb "$@"
|
||
</code></pre>
|
||
</div>
|
||
<p>This shows a completion function for a command <code>mydb</code> which takes two
|
||
command arguments, <code>add</code> and <code>show</code>. <code>show</code> takes no arguments, while
|
||
the arguments for <code>add</code> have already been prepared in an array
|
||
<code>mydb_add_cmds</code>, quite possibly by a previous call to <code>_regex_words</code>.</p>
|
||
<p><span id="index-_005frequested"></span></p>
|
||
<p><code>_requested</code> [ <code>-x</code> ] [ <code>-12VJ</code> ] <code>tag</code> [ <code>name</code> <code>descr</code> [
|
||
<code>command</code> [ <code>arg</code> ... ] ]</p>
|
||
<p>This function is called to decide whether a tag already registered by a
|
||
call to <code>_tags</code> (see below) has been requested by the user and hence
|
||
completion should be performed for it. It returns status zero if the tag
|
||
is requested and non-zero otherwise. The function is typically used as
|
||
part of a loop over different tags as follows:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">_tags foo bar baz
|
||
while _tags; do
|
||
if _requested foo; then
|
||
... # perform completion for foo
|
||
fi
|
||
... # test the tags bar and baz in the same way
|
||
... # exit loop if matches were generated
|
||
done
|
||
</code></pre>
|
||
</div>
|
||
<p>Note that the test for whether matches were generated is not performed
|
||
until the end of the <code>_tags</code> loop. This is so that the user can set the
|
||
<code>tag-order</code> style to specify a set of tags to be completed at the same
|
||
time.</p>
|
||
<p>If <code>name</code> and <code>descr</code> are given, <code>_requested</code> calls the <code>_description</code>
|
||
function with these arguments together with the options passed to
|
||
<code>_requested</code>.</p>
|
||
<p>If <code>command</code> is given, the <code>_all_labels</code> function will be called
|
||
immediately with the same arguments. In simple cases this makes it
|
||
possible to perform the test for the tag and the matching in one go. For
|
||
example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">local expl ret=1
|
||
_tags foo bar baz
|
||
while _tags; do
|
||
_requested foo expl 'description' \
|
||
compadd foobar foobaz && ret=0
|
||
...
|
||
(( ret )) || break
|
||
done
|
||
</code></pre>
|
||
</div>
|
||
<p>If the <code>command</code> is not <code>compadd</code>, it must nevertheless be prepared to
|
||
handle the same options.</p>
|
||
<p><span id="index-_005fretrieve_005fcache"></span></p>
|
||
<p><code>_retrieve_cache</code> <code>cache_identifier</code></p>
|
||
<p>This function retrieves completion information from the file given by
|
||
<code>cache_identifier</code>, stored in a directory specified by the <code>cache-path</code>
|
||
style which defaults to <code>~/.zcompcache</code>. The return status is zero if
|
||
retrieval was successful. It will only attempt retrieval if the
|
||
<code>use-cache</code> style is set, so you can call this function without worrying
|
||
about whether the user wanted to use the caching layer.</p>
|
||
<p>See <code>_store_cache</code> below for more details.</p>
|
||
<p><span id="index-_005fsep_005fparts"></span></p>
|
||
<p><code>_sep_parts</code></p>
|
||
<p>This function is passed alternating arrays and separators as arguments.
|
||
The arrays specify completions for parts of strings to be separated by
|
||
the separators. The arrays may be the names of array parameters or a
|
||
quoted list of words in parentheses. For example, with the array
|
||
‘<code>hosts=(ftp news)</code>’ the call ‘<code>_sep_parts ’(foo bar)’ @ hosts</code>’ will
|
||
complete the string ‘<code>f</code>’ to ‘<code>foo</code>’ and the string ‘<code>b@n</code>’ to
|
||
‘<code>bar@news</code>’.</p>
|
||
<p>This function accepts the <code>compadd</code> options ‘<code>-V</code>’, ‘<code>-J</code>’, ‘<code>-1</code>’,
|
||
‘<code>-2</code>’, ‘<code>-n</code>’, ‘<code>-X</code>’, ‘<code>-M</code>’, ‘<code>-P</code>’, ‘<code>-S</code>’, ‘<code>-r</code>’, ‘<code>-R</code>’, and
|
||
‘<code>-q</code>’ and passes them on to the <code>compadd</code> builtin used to add the
|
||
matches.</p>
|
||
<p><span id="index-_005fsequence"></span></p>
|
||
<p><code>_sequence</code> [ <code>-s</code> <code>sep</code> ] [ <code>-n</code> <code>max</code> ] [ <code>-d</code> ] <code>function</code> [
|
||
<code>-</code> ] ...</p>
|
||
<p>This function is a wrapper to other functions for completing items in a
|
||
separated list. The same function is used to complete each item in the
|
||
list. The separator is specified with the <code>-s</code> option. If <code>-s</code> is
|
||
omitted it will use ‘<code>,</code>’. Duplicate values are not matched unless <code>-d</code>
|
||
is specified. If there is a fixed or maximum number of items in the
|
||
list, this can be specified with the <code>-n</code> option.</p>
|
||
<p>Common <code>compadd</code> options are passed on to the function. It is possible
|
||
to use <code>compadd</code> directly with <code>_sequence</code>, though <code>_values</code> may be more
|
||
appropriate in this situation.</p>
|
||
<p><span id="index-_005fsetup"></span></p>
|
||
<p><code>_setup</code> <code>tag</code> [ <code>group</code> ]</p>
|
||
<p>This function sets up the special parameters used by the completion
|
||
system appropriately for the <code>tag</code> given as the first argument. It uses
|
||
the styles <code>list-colors</code>, <code>list-packed</code>, <code>list-rows-first</code>,
|
||
<code>last-prompt</code>, <code>accept-exact</code>, <code>menu</code> and <code>force-list</code>.</p>
|
||
<p>The optional <code>group</code> supplies the name of the group in which the matches
|
||
will be placed. If it is not given, the <code>tag</code> is used as the group name.</p>
|
||
<p>This function is called automatically from <code>_description</code> and hence is
|
||
not normally called explicitly.</p>
|
||
<p><span id="index-_005fstore_005fcache"></span></p>
|
||
<p><code>_store_cache</code> <code>cache_identifier</code> <code>param</code> ...</p>
|
||
<p>This function, together with <code>_retrieve_cache</code> and <code>_cache_invalid</code>,
|
||
implements a caching layer which can be used in any completion function.
|
||
Data obtained by costly operations are stored in parameters; this
|
||
function then dumps the values of those parameters to a file. The data
|
||
can then be retrieved quickly from that file via <code>_retrieve_cache</code>, even
|
||
in different instances of the shell.</p>
|
||
<p>The <code>cache_identifier</code> specifies the file which the data should be
|
||
dumped to. The file is stored in a directory specified by the
|
||
<code>cache-path</code> style which defaults to <code>~/.zcompcache</code>. The remaining
|
||
<code>param</code>s arguments are the parameters to dump to the file.</p>
|
||
<p>The return status is zero if storage was successful. The function will
|
||
only attempt storage if the <code>use-cache</code> style is set, so you can call
|
||
this function without worrying about whether the user wanted to use the
|
||
caching layer.</p>
|
||
<p>The completion function may avoid calling <code>_retrieve_cache</code> when it
|
||
already has the completion data available as parameters. However, in
|
||
that case it should call <code>_cache_invalid</code> to check whether the data in
|
||
the parameters and in the cache are still valid.</p>
|
||
<p>See the _perl_modules completion function for a simple example of the
|
||
usage of the caching layer.</p>
|
||
<p><span id="index-_005ftags"></span></p>
|
||
<p><code>_tags</code> [ [ <code>-C</code> <code>name</code> ] <code>tag</code> ... ]</p>
|
||
<p>If called with arguments, these are taken to be the names of tags valid
|
||
for completions in the current context. These tags are stored internally
|
||
and sorted by using the <code>tag-order</code> style.</p>
|
||
<p>Next, <code>_tags</code> is called repeatedly without arguments from the same
|
||
completion function. This successively selects the first, second, etc.
|
||
set of tags requested by the user. The return status is zero if at least
|
||
one of the tags is requested and non-zero otherwise. To test if a
|
||
particular tag is to be tried, the <code>_requested</code> function should be
|
||
called (see above).</p>
|
||
<p>If ‘<code>-C</code> <code>name</code>’ is given, <code>name</code> is temporarily stored in the
|
||
<code>argument</code> field (the fifth) of the context in the <code>curcontext</code>
|
||
parameter during the call to <code>_tags</code>; the field is restored on exit.
|
||
This allows <code>_tags</code> to use a more specific context without having to
|
||
change and reset the <code>curcontext</code> parameter (which has the same effect).</p>
|
||
<p><span id="index-_005ftilde_005ffiles"></span></p>
|
||
<p><code>_tilde_files</code></p>
|
||
<p>Like <code>_files</code>, but resolve leading tildes according to the rules of
|
||
filename expansion, so the suggested completions don’t start with a
|
||
‘<code>~</code>’ even if the filename on the command-line does.</p>
|
||
<p><span id="index-_005fvalues"></span></p>
|
||
<p><code>_values</code> [ <code>-O</code> <code>name</code> ] [ <code>-s</code> <code>sep</code> ] [ <code>-S</code> <code>sep</code> ] [ <code>-wC</code>
|
||
] <code>desc</code> <code>spec</code> ...</p>
|
||
<p>This is used to complete arbitrary keywords (values) and their
|
||
arguments, or lists of such combinations.</p>
|
||
<p>If the first argument is the option ‘<code>-O</code> <code>name</code>’, it will be used in
|
||
the same way as by the <code>_arguments</code> function. In other words, the
|
||
elements of the <code>name</code> array will be passed to <code>compadd</code> when executing
|
||
an action.</p>
|
||
<p>If the first argument (or the first argument after ‘<code>-O</code> <code>name</code>’) is
|
||
‘<code>-s</code>’, the next argument is used as the character that separates
|
||
multiple values. This character is automatically added after each value
|
||
in an auto-removable fashion (see below); all values completed by
|
||
‘<code>_values -s</code>’ appear in the same word on the command line, unlike
|
||
completion using <code>_arguments</code>. If this option is not present, only a
|
||
single value will be completed per word.</p>
|
||
<p>Normally, <code>_values</code> will only use the current word to determine which
|
||
values are already present on the command line and hence are not to be
|
||
completed again. If the <code>-w</code> option is given, other arguments are
|
||
examined as well.</p>
|
||
<p>The first non-option argument, <code>desc</code>, is used as a string to print as a
|
||
description before listing the values.</p>
|
||
<p>All other arguments describe the possible values and their arguments in
|
||
the same format used for the description of options by the <code>_arguments</code>
|
||
function (see above). The only differences are that no minus or plus
|
||
sign is required at the beginning, values can have only one argument,
|
||
and the forms of action beginning with an equal sign are not supported.</p>
|
||
<p>The character separating a value from its argument can be set using the
|
||
option <code>-S</code> (like <code>-s</code>, followed by the character to use as the
|
||
separator in the next argument). By default the equals sign will be used
|
||
as the separator between values and arguments.</p>
|
||
<p>Example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">_values -s , 'description' \
|
||
'*foo[bar]' \
|
||
'(two)*one[number]:first count:' \
|
||
'two[another number]::second count:(1 2 3)'
|
||
</code></pre>
|
||
</div>
|
||
<p>This describes three possible values: ‘<code>foo</code>’, ‘<code>one</code>’, and ‘<code>two</code>’. The
|
||
first is described as ‘<code>bar</code>’, takes no argument and may appear more
|
||
than once. The second is described as ‘<code>number</code>’, may appear more than
|
||
once, and takes one mandatory argument described as ‘<code>first count</code>’; no
|
||
action is specified, so it will not be completed. The ‘<code>(two)</code>’ at the
|
||
beginning says that if the value ‘<code>one</code>’ is on the line, the value
|
||
‘<code>two</code>’ will no longer be considered a possible completion. Finally,
|
||
the last value (‘<code>two</code>’) is described as ‘<code>another number</code>’ and takes an
|
||
optional argument described as ‘<code>second count</code>’ for which the
|
||
completions (to appear after an ‘<code>=</code>’) are ‘<code>1</code>’, ‘<code>2</code>’, and ‘<code>3</code>’. The
|
||
<code>_values</code> function will complete lists of these values separated by
|
||
commas.</p>
|
||
<p>Like <code>_arguments</code>, this function temporarily adds another context name
|
||
component to the arguments element (the fifth) of the current context
|
||
while executing the <code>action</code>. Here this name is just the name of the
|
||
value for which the argument is completed.</p>
|
||
<p>The style <code>verbose</code> is used to decide if the descriptions for the values
|
||
(but not those for the arguments) should be printed.</p>
|
||
<p>The associative array <code>val_args</code> is used to report values and their
|
||
arguments; this works similarly to the <code>opt_args</code> associative array used
|
||
by <code>_arguments</code>. Hence the function calling <code>_values</code> should declare the
|
||
local parameters <code>state</code>, <code>state_descr</code>, <code>line</code>, <code>context</code> and
|
||
<code>val_args</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">local context state state_descr line
|
||
typeset -A val_args
|
||
</code></pre>
|
||
</div>
|
||
<p>when using an action of the form ‘<code>->``string</code>’. With this function the
|
||
<code>context</code> parameter will be set to the name of the value whose argument
|
||
is to be completed. Note that for <code>_values</code>, the <code>state</code> and
|
||
<code>state_descr</code> are scalars rather than arrays. Only a single matching
|
||
state is returned.</p>
|
||
<p>Note also that <code>_values</code> normally adds the character used as the
|
||
separator between values as an auto-removable suffix (similar to a ‘<code>/</code>’
|
||
after a directory). However, this is not possible for a ‘<code>->``string</code>’
|
||
action as the matches for the argument are generated by the calling
|
||
function. To get the usual behaviour, the calling function can add the
|
||
separator <code>x</code> as a suffix by passing the options ‘<code>-qS</code> <code>x</code>’ either
|
||
directly or indirectly to <code>compadd</code>.</p>
|
||
<p>The option <code>-C</code> is treated in the same way as it is by <code>_arguments</code>. In
|
||
that case the parameter <code>curcontext</code> should be made local instead of
|
||
<code>context</code> (as described above).</p>
|
||
<p><span id="index-_005fwanted"></span></p>
|
||
<p><code>_wanted</code> [ <code>-x</code> ] [ <code>-C</code> <code>name</code> ] [ <code>-12VJ</code> ] <code>tag</code> <code>name</code>
|
||
<code>descr</code> <code>command</code> [ <code>arg</code> ...]</p>
|
||
<p>In many contexts, completion can only generate one particular set of
|
||
matches, usually corresponding to a single tag. However, it is still
|
||
necessary to decide whether the user requires matches of this type. This
|
||
function is useful in such a case.</p>
|
||
<p>The arguments to <code>_wanted</code> are the same as those to <code>_requested</code>, i.e.
|
||
arguments to be passed to <code>_description</code>. However, in this case the
|
||
<code>command</code> is not optional; all the processing of tags, including the
|
||
loop over both tags and tag labels and the generation of matches, is
|
||
carried out automatically by <code>_wanted</code>.</p>
|
||
<p>Hence to offer only one tag and immediately add the corresponding
|
||
matches with the given description:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">local expl
|
||
_wanted tag expl 'description' \
|
||
compadd matches...
|
||
</code></pre>
|
||
</div>
|
||
<p>Note that, as for <code>_requested</code>, the <code>command</code> must be able to accept
|
||
options to be passed down to <code>compadd</code>.</p>
|
||
<p>Like <code>_tags</code> this function supports the <code>-C</code> option to give a different
|
||
name for the argument context field. The <code>-x</code> option has the same
|
||
meaning as for <code>_description</code>.</p>
|
||
<p><span id="index-_005fwidgets"></span></p>
|
||
<p><code>_widgets</code> [ <code>-g</code> <code>pattern</code> ]</p>
|
||
<p>This function completes names of zle widgets (see
|
||
<a href="Zsh-Line-Editor.html#Zle-Widgets">Widgets</a>). The <code>pattern</code>, if present,
|
||
is matched against values of the <code>$widgets</code> special parameter,
|
||
documented in <a href="Zsh-Modules.html#The-zsh_002fzleparameter-Module">The zsh/zleparameter
|
||
Module</a>.</p>
|
||
<hr />
|
||
<p><span id="Completion-System-Variables"></span>
|
||
<span id="Completion-System-Variables-1"></span></p>
|
||
<h2 id="207-completion-system-variables"><a class="header" href="#207-completion-system-variables">20.7 Completion System Variables</a></h2>
|
||
<p><span id="index-completion-system_002c-variables"></span></p>
|
||
<p>There are some standard variables, initialised by the <code>_main_complete</code>
|
||
function and then used from other functions.</p>
|
||
<p>The standard variables are:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>_comp_caller_options</code><br />
|
||
The completion system uses <code>setopt</code> to set a number of options. This
|
||
allows functions to be written without concern for compatibility
|
||
with every possible combination of user options. However, sometimes
|
||
completion needs to know what the user’s option preferences are.
|
||
These are saved in the <code>_comp_caller_options</code> associative array.
|
||
Option names, spelled in lowercase without underscores, are mapped
|
||
to one or other of the strings ‘<code>on</code>’ and ‘<code>off</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>_comp_priv_prefix</code><br />
|
||
Completion functions such as <code>_sudo</code> can set the <code>_comp_priv_prefix</code>
|
||
array to a command prefix that may then be used by <code>_call_program</code>
|
||
to match the privileges when calling programs to generate matches.</p>
|
||
</li>
|
||
</ul>
|
||
<p>Two more features are offered by the <code>_main_complete</code> function. The
|
||
arrays <code>compprefuncs</code> and <code>comppostfuncs</code> may contain names of functions
|
||
that are to be called immediately before or after completion has been
|
||
tried. A function will only be called once unless it explicitly
|
||
reinserts itself into the array.</p>
|
||
<hr />
|
||
<p><span id="Completion-Directories"></span>
|
||
<span id="Completion-Directories-1"></span></p>
|
||
<h2 id="208-completion-directories"><a class="header" href="#208-completion-directories">20.8 Completion Directories</a></h2>
|
||
<p><span id="index-completion-system_002c-directory-structure"></span></p>
|
||
<p>In the source distribution, the files are contained in various
|
||
subdirectories of the <code>Completion</code> directory. They may have been
|
||
installed in the same structure, or into one single function directory.
|
||
The following is a description of the files found in the original
|
||
directory structure. If you wish to alter an installed file, you will
|
||
need to copy it to some directory which appears earlier in your <code>fpath</code>
|
||
than the standard directory where it appears.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>Base</code><br />
|
||
The core functions and special completion widgets automatically
|
||
bound to keys. You will certainly need most of these, though will
|
||
probably not need to alter them. Many of these are documented above.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>Zsh</code><br />
|
||
Functions for completing arguments of shell builtin commands and
|
||
utility functions for this. Some of these are also used by functions
|
||
from the <code>Unix</code> directory.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>Unix</code><br />
|
||
Functions for completing arguments of external commands and suites
|
||
of commands. They may need modifying for your system, although in
|
||
many cases some attempt is made to decide which version of a command
|
||
is present. For example, completion for the <code>mount</code> command tries to
|
||
determine the system it is running on, while completion for many
|
||
other utilities try to decide whether the GNU version of the command
|
||
is in use, and hence whether the <code>-``-help</code> option is supported.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>X</code>, <code>AIX</code>, <code>BSD</code>, ...<br />
|
||
Completion and utility function for commands available only on some
|
||
systems. These are not arranged hierarchically, so, for example,
|
||
both the <code>Linux</code> and <code>Debian</code> directories, as well as the <code>X</code>
|
||
directory, may be useful on your system.</p>
|
||
</li>
|
||
</ul>
|
||
<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>
|
||
<!-- 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="Completion-Using-compctl.html#21-completion-using-compctl">21 Completion Using compctl</a>
|
||
<ul>
|
||
<li><a href="Completion-Using-compctl.html#211-types-of-completion">21.1 Types of completion</a></li>
|
||
<li><a href="Completion-Using-compctl.html#212-description">21.2 Description</a></li>
|
||
<li><a href="Completion-Using-compctl.html#213-command-flags">21.3 Command Flags</a></li>
|
||
<li><a href="Completion-Using-compctl.html#214-option-flags">21.4 Option Flags</a>
|
||
<ul>
|
||
<li><a href="Completion-Using-compctl.html#2141-simple-flags">21.4.1 Simple Flags</a></li>
|
||
<li><a href="Completion-Using-compctl.html#2142-flags-with-arguments">21.4.2 Flags with Arguments</a></li>
|
||
<li><a href="Completion-Using-compctl.html#2143-control-flags">21.4.3 Control Flags</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Completion-Using-compctl.html#215-alternative-completion">21.5 Alternative Completion</a></li>
|
||
<li><a href="Completion-Using-compctl.html#216-extended-completion">21.6 Extended Completion</a></li>
|
||
<li><a href="Completion-Using-compctl.html#217-example">21.7 Example</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Completion-Using-compctl"></span>
|
||
<span id="Completion-Using-compctl-1"></span></p>
|
||
<h1 id="21-completion-using-compctl"><a class="header" href="#21-completion-using-compctl">21 Completion Using compctl</a></h1>
|
||
<p><span id="index-completion_002c-programmable-2"></span>
|
||
<span id="index-completion_002c-controlling-2"></span></p>
|
||
<hr />
|
||
<p><span id="Types-of-completion"></span></p>
|
||
<h2 id="211-types-of-completion"><a class="header" href="#211-types-of-completion">21.1 Types of completion</a></h2>
|
||
<p>This version of zsh has two ways of performing completion of words on
|
||
the command line. New users of the shell may prefer to use the newer and
|
||
more powerful system based on shell functions; this is described in
|
||
<a href="Completion-System.html#Completion-System">Completion System</a>, and the
|
||
basic shell mechanisms which support it are described in <a href="Completion-Widgets.html#Completion-Widgets">Completion
|
||
Widgets</a>. This chapter
|
||
describes the older <code>compctl</code> command.</p>
|
||
<hr />
|
||
<p><span id="Description-7"></span></p>
|
||
<h2 id="212-description"><a class="header" href="#212-description">21.2 Description</a></h2>
|
||
<p><span id="index-compctl"></span></p>
|
||
<p><code>compctl</code> [ <code>-CDT</code> ] <code>options</code> [ <code>command</code> ... ]</p>
|
||
<p><code>compctl </code>[ <code>-CDT</code> ] <code>options</code> [ <code>-x</code> <code>pattern</code> <code>options</code> <code>-</code> ...
|
||
<code>-``-</code> ]</p>
|
||
<p><code> </code>[ <code>+</code> <code>options</code> [ <code>-x</code> ... <code>-``-</code> ] ... [<code>+</code>] ] [
|
||
<code>command</code> ... ]</p>
|
||
<p><code>compctl</code> <code>-M</code> <code>match-specs</code> ...</p>
|
||
<p><code>compctl</code> <code>-L</code> [ <code>-CDTM</code> ] [ <code>command</code> ... ]</p>
|
||
<p><code>compctl</code> <code>+</code> <code>command</code> ...</p>
|
||
<p>Control the editor’s completion behavior according to the supplied set
|
||
of <code>options</code>. Various editing commands, notably
|
||
<code>expand-or-complete-word</code>, usually bound to tab, will attempt to
|
||
complete a word typed by the user, while others, notably
|
||
<code>delete-char-or-list</code>, usually bound to ^D in EMACS editing mode, list
|
||
the possibilities; <code>compctl</code> controls what those possibilities are. They
|
||
may for example be filenames (the most common case, and hence the
|
||
default), shell variables, or words from a user-specified list.</p>
|
||
<hr />
|
||
<p><span id="Command-Flags"></span> <span id="Command-Flags-1"></span></p>
|
||
<h2 id="213-command-flags"><a class="header" href="#213-command-flags">21.3 Command Flags</a></h2>
|
||
<p>Completion of the arguments of a command may be different for each
|
||
command or may use the default. The behavior when completing the command
|
||
word itself may also be separately specified. These correspond to the
|
||
following flags and arguments, all of which (except for <code>-L</code>) may be
|
||
combined with any combination of the <code>options</code> described subsequently in
|
||
<a href="Completion-Using-compctl.html#Option-Flags">Option Flags</a>:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>command</code> ...<br />
|
||
controls completion for the named commands, which must be listed
|
||
last on the command line. If completion is attempted for a command
|
||
with a pathname containing slashes and no completion definition is
|
||
found, the search is retried with the last pathname component. If
|
||
the command starts with a <code>=</code>, completion is tried with the pathname
|
||
of the command.</p>
|
||
<p>Any of the <code>command</code> strings may be patterns of the form normally
|
||
used for filename generation. These should be quoted to protect them
|
||
from immediate expansion; for example the command string <code>’foo*’</code>
|
||
arranges for completion of the words of any command beginning with
|
||
<code>foo</code>. When completion is attempted, all pattern completions are
|
||
tried in the reverse order of their definition until one matches. By
|
||
default, completion then proceeds as normal, i.e. the shell will try
|
||
to generate more matches for the specific command on the command
|
||
line; this can be overridden by including <code>-tn</code> in the flags for the
|
||
pattern completion.</p>
|
||
<p>Note that aliases are expanded before the command name is determined
|
||
unless the <code>COMPLETE_ALIASES</code> option is set. Commands may not be
|
||
combined with the <code>-C</code>, <code>-D</code> or <code>-T</code> flags.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-C</code><br />
|
||
controls completion when the command word itself is being completed.
|
||
If no <code>compctl -C</code> command has been issued, the names of any as
|
||
aliases or functions) are completed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-D</code><br />
|
||
controls default completion behavior for the arguments of commands
|
||
not assigned any special behavior. If no <code>compctl -D</code> command has
|
||
been issued, filenames are completed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-T</code><br />
|
||
supplies completion flags to be used before any other processing is
|
||
done, even before processing for <code>compctl</code>s defined for specific
|
||
commands. This is especially useful when combined with extended
|
||
completion (the <code>-x</code> flag, see <a href="Completion-Using-compctl.html#Extended-Completion">Extended
|
||
Completion</a> below). Using this flag you can
|
||
define default behavior which will apply to all commands without
|
||
exception, or you can alter the standard behavior for all commands.
|
||
For example, if your access to the user database is too slow and/or
|
||
it contains too many users (so that completion after ‘<code>~</code>’ is too
|
||
slow to be usable), you can use</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compctl -T -x 's[~] C[0,[^/]#]' -k friends -S/ -tn
|
||
</code></pre>
|
||
</div>
|
||
<p>to complete the strings in the array <code>friends</code> after a ‘<code>~</code>’. The
|
||
<code>C[``...``]</code> argument is necessary so that this form of
|
||
<code>~</code>-completion is not tried after the directory name is finished.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-L</code><br />
|
||
<em>no argument</em><br />
|
||
If no argument is given, <code>compctl</code> lists all defined completions in
|
||
an abbreviated form; with a list of <code>options</code>, all completions with
|
||
those flags set (not counting extended completion) are listed.</p>
|
||
</li>
|
||
</ul>
|
||
<p>If the <code>+</code> flag is alone and followed immediately by the <code>command</code> list,
|
||
the completion behavior for all the commands in the list is reset to the
|
||
default. In other words, completion will subsequently use the options
|
||
specified by the <code>-D</code> flag.</p>
|
||
<p>The form with <code>-M</code> as the first and only option defines global matching
|
||
specifications (see <a href="Completion-Widgets.html#Completion-Matching-Control">Completion Matching
|
||
Control</a>). The
|
||
match specifications given will be used for every completion attempt
|
||
(only when using <code>compctl</code>, not with the new completion system) and are
|
||
tried in the order in which they are defined until one generates at
|
||
least one match. E.g.:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compctl -M '' 'm:{a-zA-Z}={A-Za-z}'
|
||
</code></pre>
|
||
</div>
|
||
<p>This will first try completion without any global match specifications
|
||
(the empty string) and, if that generates no matches, will try case
|
||
insensitive completion.</p>
|
||
<hr />
|
||
<p><span id="Option-Flags"></span> <span id="Option-Flags-1"></span></p>
|
||
<h2 id="214-option-flags"><a class="header" href="#214-option-flags">21.4 Option Flags</a></h2>
|
||
<p>[ <code>-fcFBdeaRGovNAIOPZEnbjrzu/12</code> ]</p>
|
||
<p>[ <code>-k</code> <code>array</code> ] [ <code>-g</code> <code>globstring</code> ] [ <code>-s</code> <code>subststring</code> ]</p>
|
||
<p>[ <code>-K</code> <code>function</code> ]</p>
|
||
<p>[ <code>-Q</code> ] [ <code>-P</code> <code>prefix</code> ] [ <code>-S</code> <code>suffix</code> ]</p>
|
||
<p>[ <code>-W</code> <code>file-prefix</code> ] [ <code>-H</code> <code>num pattern</code> ]</p>
|
||
<p>[ <code>-q</code> ] [ <code>-X</code> <code>explanation</code> ] [ <code>-Y</code> <code>explanation</code> ]</p>
|
||
<p>[ <code>-y</code> <code>func-or-var</code> ] [ <code>-l</code> <code>cmd</code> ] [ <code>-h</code> <code>cmd</code> ] [ <code>-U</code> ]</p>
|
||
<p>[ <code>-t</code> <code>continue</code> ] [ <code>-J</code> <code>name</code> ] [ <code>-V</code> <code>name</code> ]</p>
|
||
<p>[ <code>-M</code> <code>match-spec</code> ]</p>
|
||
<p>The remaining <code>options</code> specify the type of command arguments to look
|
||
for during completion. Any combination of these flags may be specified;
|
||
the result is a sorted list of all the possibilities. The options are as
|
||
follows.</p>
|
||
<hr />
|
||
<p><span id="Simple-Flags"></span> <span id="Simple-Flags-1"></span></p>
|
||
<h3 id="2141-simple-flags"><a class="header" href="#2141-simple-flags">21.4.1 Simple Flags</a></h3>
|
||
<p>These produce completion lists made up by the shell itself:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-f</code><br />
|
||
Filenames and file system paths.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-/</code><br />
|
||
Just file system paths.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-c</code><br />
|
||
Command names, including aliases, shell functions, builtins and
|
||
reserved words.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-F</code><br />
|
||
Function names.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-B</code><br />
|
||
Names of builtin commands.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-m</code><br />
|
||
Names of external commands.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-w</code><br />
|
||
Reserved words.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-a</code><br />
|
||
Alias names.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-R</code><br />
|
||
Names of regular (non-global) aliases.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-G</code><br />
|
||
Names of global aliases.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-d</code><br />
|
||
This can be combined with <code>-F</code>, <code>-B</code>, <code>-w</code>, <code>-a</code>, <code>-R</code> and <code>-G</code> to
|
||
get names of disabled functions, builtins, reserved words or
|
||
aliases.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-e</code><br />
|
||
This option (to show enabled commands) is in effect by default, but
|
||
may be combined with <code>-d</code>; <code>-de</code> in combination with <code>-F</code>, <code>-B</code>,
|
||
<code>-w</code>, <code>-a</code>, <code>-R</code> and <code>-G</code> will complete names of functions,
|
||
builtins, reserved words or aliases whether or not they are
|
||
disabled.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-o</code><br />
|
||
Names of shell options (see <a href="Options.html#Options">Options</a>).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-v</code><br />
|
||
Names of any variable defined in the shell.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-N</code><br />
|
||
Names of scalar (non-array) parameters.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-A</code><br />
|
||
Array names.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-I</code><br />
|
||
Names of integer variables.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-O</code><br />
|
||
Names of read-only variables.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-p</code><br />
|
||
Names of parameters used by the shell (including special
|
||
parameters).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-Z</code><br />
|
||
Names of shell special parameters.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-E</code><br />
|
||
Names of environment variables.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-n</code><br />
|
||
Named directories.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-b</code><br />
|
||
Key binding names.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-j</code><br />
|
||
Job names: the first word of the job leader’s command line. This is
|
||
useful with the <code>kill</code> builtin.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-r</code><br />
|
||
Names of running jobs.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-z</code><br />
|
||
Names of suspended jobs.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-u</code><br />
|
||
User names.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Flags-with-Arguments"></span>
|
||
<span id="Flags-with-Arguments-1"></span></p>
|
||
<h3 id="2142-flags-with-arguments"><a class="header" href="#2142-flags-with-arguments">21.4.2 Flags with Arguments</a></h3>
|
||
<p>These have user supplied arguments to determine how the list of
|
||
completions is to be made up:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-k</code> <code>array</code><br />
|
||
Names taken from the elements of <code>$``array</code> (note that the ‘<code>$</code>’
|
||
does not appear on the command line). Alternatively, the argument
|
||
<code>array</code> itself may be a set of space- or comma-separated values in
|
||
parentheses, in which any delimiter may be escaped with a backslash;
|
||
in this case the argument should be quoted. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compctl -k "(cputime filesize datasize stacksize
|
||
coredumpsize resident descriptors)" limit
|
||
</code></pre>
|
||
</div>
|
||
</li>
|
||
<li>
|
||
<p><code>-g</code> <code>globstring</code><br />
|
||
The <code>globstring</code> is expanded using filename globbing; it should be
|
||
quoted to protect it from immediate expansion. The resulting
|
||
filenames are taken as the possible completions. Use ‘<code>*(/)</code>’
|
||
instead of ‘<code>*/</code>’ for directories. The <code>fignore</code> special parameter
|
||
is not applied to the resulting files. More than one pattern may be
|
||
given separated by blanks. (Note that brace expansion is <em>not</em> part
|
||
of globbing. Use the syntax ‘<code>(either|or)</code>’ to match alternatives.)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-s</code> <code>subststring</code><br />
|
||
The <code>subststring</code> is split into words and these words are than
|
||
expanded using all shell expansion mechanisms (see
|
||
<a href="Expansion.html#Expansion">Expansion</a>). The resulting words are
|
||
taken as possible completions. The <code>fignore</code> special parameter is
|
||
not applied to the resulting files. Note that <code>-g</code> is faster for
|
||
filenames.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-K</code> <code>function</code><br />
|
||
<span id="index-reply_002c-use-of-2"></span></p>
|
||
<p>Call the given function to get the completions. Unless the name
|
||
starts with an underscore, the function is passed two arguments: the
|
||
prefix and the suffix of the word on which completion is to be
|
||
attempted, in other words those characters before the cursor
|
||
position, and those from the cursor position onwards. The whole
|
||
command line can be accessed with the <code>-c</code> and <code>-l</code> flags of the
|
||
<code>read</code> builtin. The function should set the variable <code>reply</code> to an
|
||
array containing the completions (one completion per element); note
|
||
that <code>reply</code> should not be made local to the function. From such a
|
||
function the command line can be accessed with the <code>-c</code> and <code>-l</code>
|
||
flags to the <code>read</code> builtin. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">function whoson { reply=(`users`); }
|
||
compctl -K whoson talk
|
||
</code></pre>
|
||
</div>
|
||
<p>completes only logged-on users after ‘<code>talk</code>’. Note that ‘<code>whoson</code>’
|
||
must return an array, so ‘<code>reply=‘users‘</code>’ would be incorrect.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-H</code> <code>num pattern</code><br />
|
||
The possible completions are taken from the last <code>num</code> history
|
||
lines. Only words matching <code>pattern</code> are taken. If <code>num</code> is zero or
|
||
negative the whole history is searched and if <code>pattern</code> is the empty
|
||
string all words are taken (as with ‘<code>*</code>’). A typical use is</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compctl -D -f + -H 0 ''
|
||
</code></pre>
|
||
</div>
|
||
<p>which forces completion to look back in the history list for a word
|
||
if no filename matches.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Control-Flags"></span> <span id="Control-Flags-1"></span></p>
|
||
<h3 id="2143-control-flags"><a class="header" href="#2143-control-flags">21.4.3 Control Flags</a></h3>
|
||
<p>These do not directly specify types of name to be completed, but
|
||
manipulate the options that do:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-Q</code><br />
|
||
This instructs the shell not to quote any metacharacters in the
|
||
possible completions. Normally the results of a completion are
|
||
inserted into the command line with any metacharacters quoted so
|
||
that they are interpreted as normal characters. This is appropriate
|
||
for filenames and ordinary strings. However, for special effects,
|
||
such as inserting a backquoted expression from a completion array
|
||
(<code>-k</code>) so that the expression will not be evaluated until the
|
||
complete line is executed, this option must be used.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-P</code> <code>prefix</code><br />
|
||
The <code>prefix</code> is inserted just before the completed string; any
|
||
initial part already typed will be completed and the whole <code>prefix</code>
|
||
ignored for completion purposes. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compctl -j -P "%" kill
|
||
</code></pre>
|
||
</div>
|
||
<p>inserts a ‘%’ after the kill command and then completes job names.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-S</code> <code>suffix</code><br />
|
||
When a completion is found the <code>suffix</code> is inserted after the
|
||
completed string. In the case of menu completion the suffix is
|
||
inserted immediately, but it is still possible to cycle through the
|
||
list of completions by repeatedly hitting the same key.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-W</code> <code>file-prefix</code><br />
|
||
With directory <code>file-prefix</code>: for command, file, directory and
|
||
globbing completion (options <code>-c</code>, <code>-f</code>, <code>-/</code>, <code>-g</code>), the file
|
||
prefix is implicitly added in front of the completion. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compctl -/ -W ~/Mail maildirs
|
||
</code></pre>
|
||
</div>
|
||
<p>completes any subdirectories to any depth beneath the directory
|
||
<code>~/Mail</code>, although that prefix does not appear on the command line.
|
||
The <code>file-prefix</code> may also be of the form accepted by the <code>-k</code> flag,
|
||
i.e. the name of an array or a literal list in parenthesis. In this
|
||
case all the directories in the list will be searched for possible
|
||
completions.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-q</code><br />
|
||
If used with a suffix as specified by the <code>-S</code> option, this causes
|
||
the suffix to be removed if the next character typed is a blank or
|
||
does not insert anything or if the suffix consists of only one
|
||
character and the next character typed is the same character; this
|
||
the same rule used for the <code>AUTO_REMOVE_SLASH</code> option. The option is
|
||
most useful for list separators (comma, colon, etc.).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-l</code> <code>cmd</code><br />
|
||
This option restricts the range of command line words that are
|
||
considered to be arguments. If combined with one of the extended
|
||
completion patterns ‘<code>p[</code>...<code>]</code>’, ‘<code>r[</code>...<code>]</code>’, or ‘<code>R[</code>...<code>]</code>’ (see
|
||
<a href="Completion-Using-compctl.html#Extended-Completion">Extended Completion</a> below) the range is
|
||
restricted to the range of arguments specified in the brackets.
|
||
Completion is then performed as if these had been given as arguments
|
||
to the <code>cmd</code> supplied with the option. If the <code>cmd</code> string is empty
|
||
the first word in the range is instead taken as the command name,
|
||
and command name completion performed on the first word in the
|
||
range. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compctl -x 'r[-exec,;]' -l '' -- find
|
||
</code></pre>
|
||
</div>
|
||
<p>completes arguments between ‘<code>-exec</code>’ and the following ‘<code>;</code>’ (or
|
||
the end of the command line if there is no such string) as if they
|
||
were a separate command line.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-h</code> <code>cmd</code><br />
|
||
Normally zsh completes quoted strings as a whole. With this option,
|
||
completion can be done separately on different parts of such
|
||
strings. It works like the <code>-l</code> option but makes the completion code
|
||
work on the parts of the current word that are separated by spaces.
|
||
These parts are completed as if they were arguments to the given
|
||
<code>cmd</code>. If <code>cmd</code> is the empty string, the first part is completed as
|
||
a command name, as with <code>-l</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-U</code><br />
|
||
Use the whole list of possible completions, whether or not they
|
||
actually match the word on the command line. The word typed so far
|
||
will be deleted. This is most useful with a function (given by the
|
||
<code>-K</code> option) which can examine the word components passed to it (or
|
||
via the <code>read</code> builtin’s <code>-c</code> and <code>-l</code> flags) and use its own
|
||
criteria to decide what matches. If there is no completion, the
|
||
original word is retained. Since the produced possible completions
|
||
seldom have interesting common prefixes and suffixes, menu
|
||
completion is started immediately if <code>AUTO_MENU</code> is set and this
|
||
flag is used.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-y</code> <code>func-or-var</code><br />
|
||
<span id="index-reply_002c-use-of-3"></span></p>
|
||
<p>The list provided by <code>func-or-var</code> is displayed instead of the list
|
||
of completions whenever a listing is required; the actual
|
||
completions to be inserted are not affected. It can be provided in
|
||
two ways. Firstly, if <code>func-or-var</code> begins with a <code>$</code> it defines a
|
||
variable, or if it begins with a left parenthesis a literal array,
|
||
which contains the list. A variable may have been set by a call to a
|
||
function using the <code>-K</code> option. Otherwise it contains the name of a
|
||
function which will be executed to create the list. The function
|
||
will be passed as an argument list all matching completions,
|
||
including prefixes and suffixes expanded in full, and should set the
|
||
array <code>reply</code> to the result. In both cases, the display list will
|
||
only be retrieved after a complete list of matches has been created.</p>
|
||
<p>Note that the returned list does not have to correspond, even in
|
||
length, to the original set of matches, and may be passed as a
|
||
scalar instead of an array. No special formatting of characters is
|
||
performed on the output in this case; in particular, newlines are
|
||
printed literally and if they appear output in columns is
|
||
suppressed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-X</code> <code>explanation</code><br />
|
||
Print <code>explanation</code> when trying completion on the current set of
|
||
options. A ‘<code>%n</code>’ in this string is replaced by the number of
|
||
matches that were added for this explanation string. The explanation
|
||
only appears if completion was tried and there was no unique match,
|
||
or when listing completions. Explanation strings will be listed
|
||
together with the matches of the group specified together with the
|
||
<code>-X</code> option (using the <code>-J</code> or <code>-V</code> option). If the same explanation
|
||
string is given to multiple <code>-X</code> options, the string appears only
|
||
once (for each group) and the number of matches shown for the ‘<code>%n</code>’
|
||
is the total number of all matches for each of these uses. In any
|
||
case, the explanation string will only be shown if there was at
|
||
least one match added for the explanation string.</p>
|
||
<p>The sequences <code>%B</code>, <code>%b</code>, <code>%S</code>, <code>%s</code>, <code>%U</code>, and <code>%u</code> specify output
|
||
attributes (bold, standout, and underline), <code>%F</code>, <code>%f</code>, <code>%K</code>, <code>%k</code>
|
||
specify foreground and background colours, and <code>%{``...``%}</code> can be
|
||
used to include literal escape sequences as in prompts.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-Y</code> <code>explanation</code><br />
|
||
Identical to <code>-X</code>, except that the <code>explanation</code> first undergoes
|
||
expansion following the usual rules for strings in double quotes.
|
||
The expansion will be carried out after any functions are called for
|
||
the <code>-K</code> or <code>-y</code> options, allowing them to set variables.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-t</code> <code>continue</code><br />
|
||
The <code>continue</code>-string contains a character that specifies which set
|
||
of completion flags should be used next. It is useful:</p>
|
||
<p>(i) With <code>-T</code>, or when trying a list of pattern completions, when
|
||
<code>compctl</code> would usually continue with ordinary processing after
|
||
finding matches; this can be suppressed with ‘<code>-tn</code>’.</p>
|
||
<p>(ii) With a list of alternatives separated by <code>+</code>, when <code>compctl</code>
|
||
would normally stop when one of the alternatives generates matches.
|
||
It can be forced to consider the next set of completions by adding
|
||
‘<code>-t+</code>’ to the flags of the alternative before the ‘<code>+</code>’.</p>
|
||
<p>(iii) In an extended completion list (see below), when <code>compctl</code>
|
||
would normally continue until a set of conditions succeeded, then
|
||
use only the immediately following flags. With ‘<code>-t-</code>’, <code>compctl</code>
|
||
will continue trying extended completions after the next ‘<code>-</code>’; with
|
||
‘<code>-tx</code>’ it will attempt completion with the default flags, in other
|
||
words those before the ‘<code>-x</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-J</code> <code>name</code><br />
|
||
This gives the name of the group the matches should be placed in.
|
||
Groups are listed and sorted separately; likewise, menu completion
|
||
will offer the matches in the groups in the order in which the
|
||
groups were defined. If no group name is explicitly given, the
|
||
matches are stored in a group named <code>default</code>. The first time a
|
||
group name is encountered, a group with that name is created. After
|
||
that all matches with the same group name are stored in that group.</p>
|
||
<p>This can be useful with non-exclusive alternative completions. For
|
||
example, in</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compctl -f -J files -t+ + -v -J variables foo
|
||
</code></pre>
|
||
</div>
|
||
<p>both files and variables are possible completions, as the <code>-t+</code>
|
||
forces both sets of alternatives before and after the <code>+</code> to be
|
||
considered at once. Because of the <code>-J</code> options, however, all files
|
||
are listed before all variables.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-V</code> <code>name</code><br />
|
||
Like <code>-J</code>, but matches within the group will not be sorted in
|
||
listings nor in menu completion. These unsorted groups are in a
|
||
different name space from the sorted ones, so groups defined as <code>-J files</code> and <code>-V files</code> are distinct.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-1</code><br />
|
||
If given together with the <code>-V</code> option, makes only consecutive
|
||
duplicates in the group be removed. Note that groups with and
|
||
without this flag are in different name spaces.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-2</code><br />
|
||
If given together with the <code>-J</code> or <code>-V</code> option, makes all duplicates
|
||
be kept. Again, groups with and without this flag are in different
|
||
name spaces.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-M</code> <code>match-spec</code><br />
|
||
This defines additional matching control specifications that should
|
||
be used only when testing words for the list of flags this flag
|
||
appears in. The format of the <code>match-spec</code> string is described in
|
||
<a href="Completion-Widgets.html#Completion-Matching-Control">Completion Matching
|
||
Control</a>.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Alternative-Completion"></span>
|
||
<span id="Alternative-Completion-1"></span></p>
|
||
<h2 id="215-alternative-completion"><a class="header" href="#215-alternative-completion">21.5 Alternative Completion</a></h2>
|
||
<p><code>compctl</code> [ <code>-CDT</code> ] <code>options</code> <code>+</code> <code>options</code> [ <code>+</code> ... ] [ <code>+</code> ]
|
||
<code>command</code> ...</p>
|
||
<p>The form with ‘<code>+</code>’ specifies alternative options. Completion is tried
|
||
with the options before the first ‘<code>+</code>’. If this produces no matches
|
||
completion is tried with the flags after the ‘<code>+</code>’ and so on. If there
|
||
are no flags after the last ‘<code>+</code>’ and a match has not been found up to
|
||
that point, default completion is tried. If the list of flags contains a
|
||
<code>-t</code> with a <code>+</code> character, the next list of flags is used even if the
|
||
current list produced matches.</p>
|
||
<hr />
|
||
<p><span id="Extended-Completion"></span></p>
|
||
<p>Additional options are available that restrict completion to some part
|
||
of the command line; this is referred to as ‘extended completion’.</p>
|
||
<p><span id="Extended-Completion-1"></span></p>
|
||
<h2 id="216-extended-completion"><a class="header" href="#216-extended-completion">21.6 Extended Completion</a></h2>
|
||
<p><code>compctl </code>[ <code>-CDT</code> ] <code>options</code> <code>-x</code> <code>pattern</code> <code>options</code> <code>-</code> ...
|
||
<code>-``-</code></p>
|
||
<p><code> </code>[ <code>command</code> ... ]</p>
|
||
<p><code>compctl </code>[ <code>-CDT</code> ] <code>options</code> [ <code>-x</code> <code>pattern</code> <code>options</code> <code>-</code> ...
|
||
<code>-``-</code> ]</p>
|
||
<p><code> </code>[ <code>+</code> <code>options</code> [ <code>-x</code> ... <code>-``-</code> ] ... [<code>+</code>] ] [
|
||
<code>command</code> ... ]</p>
|
||
<p>The form with ‘<code>-x</code>’ specifies extended completion for the commands
|
||
given; as shown, it may be combined with alternative completion using
|
||
‘<code>+</code>’. Each <code>pattern</code> is examined in turn; when a match is found, the
|
||
corresponding <code>options</code>, as described in <a href="Completion-Using-compctl.html#Option-Flags">Option Flags</a>
|
||
above, are used to generate possible completions. If no <code>pattern</code>
|
||
matches, the <code>options</code> given before the <code>-x</code> are used.</p>
|
||
<p>Note that each pattern should be supplied as a single argument and
|
||
should be quoted to prevent expansion of metacharacters by the shell.</p>
|
||
<p>A <code>pattern</code> is built of sub-patterns separated by commas; it matches if
|
||
at least one of these sub-patterns matches (they are ‘or’ed). These
|
||
sub-patterns are in turn composed of other sub-patterns separated by
|
||
white spaces which match if all of the sub-patterns match (they are
|
||
‘and’ed). An element of the sub-patterns is of the form
|
||
‘<code>c``[</code>...<code>][</code>...<code>]</code>’, where the pairs of brackets may be repeated as
|
||
often as necessary, and matches if any of the sets of brackets match (an
|
||
‘or’). The example below makes this clearer.</p>
|
||
<p>The elements may be any of the following:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>s[``string``]</code>...<br />
|
||
Matches if the current word on the command line starts with one of
|
||
the strings given in brackets. The <code>string</code> is not removed and is
|
||
not part of the completion.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>S[``string``]</code>...<br />
|
||
Like <code>s[``string``]</code> except that the <code>string</code> is part of the
|
||
completion.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>p[``from``,``to``]</code>...<br />
|
||
Matches if the number of the current word is between one of the
|
||
<code>from</code> and <code>to</code> pairs inclusive. The comma and <code>to</code> are optional;
|
||
<code>to</code> defaults to the same value as <code>from</code>. The numbers may be
|
||
negative: <code>-``n</code> refers to the <code>n</code>’th last word on the line.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>c[``offset``,``string``]</code>...<br />
|
||
Matches if the <code>string</code> matches the word offset by <code>offset</code> from the
|
||
current word position. Usually <code>offset</code> will be negative.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>C[``offset``,``pattern``]</code>...<br />
|
||
Like <code>c</code> but using pattern matching instead.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>w[``index``,``string``]</code>...<br />
|
||
Matches if the word in position <code>index</code> is equal to the
|
||
corresponding <code>string</code>. Note that the word count is made after any
|
||
alias expansion.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>W[``index``,``pattern``]</code>...<br />
|
||
Like <code>w</code> but using pattern matching instead.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>n[``index``,``string``]</code>...<br />
|
||
Matches if the current word contains <code>string</code>. Anything up to and
|
||
including the <code>index</code>th occurrence of this string will not be
|
||
considered part of the completion, but the rest will. <code>index</code> may be
|
||
negative to count from the end: in most cases, <code>index</code> will be 1 or
|
||
-1. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">compctl -s '`users`' -x 'n[1,@]' -k hosts -- talk
|
||
</code></pre>
|
||
</div>
|
||
<p>will usually complete usernames, but if you insert an <code>@</code> after the
|
||
name, names from the array <code>hosts</code> (assumed to contain hostnames,
|
||
though you must make the array yourself) will be completed. Other
|
||
commands such as <code>rcp</code> can be handled similarly.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>N[``index``,``string``]</code>...<br />
|
||
Like <code>n</code> except that the string will be taken as a character class.
|
||
Anything up to and including the <code>index</code>th occurrence of any of the
|
||
characters in <code>string</code> will not be considered part of the
|
||
completion.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>m[``min``,``max``]</code>...<br />
|
||
Matches if the total number of words lies between <code>min</code> and <code>max</code>
|
||
inclusive.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>r[``str1``,``str2``]</code>...<br />
|
||
Matches if the cursor is after a word with prefix <code>str1</code>. If there
|
||
is also a word with prefix <code>str2</code> on the command line after the one
|
||
matched by <code>str1</code> it matches only if the cursor is before this word.
|
||
If the comma and <code>str2</code> are omitted, it matches if the cursor is
|
||
after a word with prefix <code>str1</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>R[``str1``,``str2``]</code>...<br />
|
||
Like <code>r</code> but using pattern matching instead.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>q[``str``]</code>...<br />
|
||
Matches the word currently being completed is in single quotes and
|
||
the <code>str</code> begins with the letter ‘s’, or if completion is done in
|
||
double quotes and <code>str</code> starts with the letter ‘d’, or if completion
|
||
is done in backticks and <code>str</code> starts with a ‘b’.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Example"></span> <span id="Example-3"></span></p>
|
||
<h2 id="217-example"><a class="header" href="#217-example">21.7 Example</a></h2>
|
||
<div class="example">
|
||
<pre><code class="language-example">compctl -u -x 's[+] c[-1,-f],s[-f+]' \
|
||
-g '~/Mail/*(:t)' - 's[-f],c[-1,-f]' -f -- mail
|
||
</code></pre>
|
||
</div>
|
||
<p>This is to be interpreted as follows:</p>
|
||
<p>If the current command is <code>mail</code>, then</p>
|
||
<blockquote>
|
||
<p>if ((the current word begins with <code>+</code> and the previous word is <code>-f</code>)
|
||
or (the current word begins with <code>-f+</code>)), then complete the
|
||
non-directory part (the ‘<code>:t</code>’ glob modifier) of files in the
|
||
directory <code>~/Mail</code>; else</p>
|
||
<p>if the current word begins with <code>-f</code> or the previous word was <code>-f</code>,
|
||
then complete any file; else</p>
|
||
<p>complete user names.</p>
|
||
</blockquote>
|
||
<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>
|
||
<!-- 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="Zsh-Modules.html#22-zsh-modules">22 Zsh Modules</a>
|
||
<ul>
|
||
<li><a href="Zsh-Modules.html#221-description">22.1 Description</a></li>
|
||
<li><a href="Zsh-Modules.html#222-the-zshattr-module">22.2 The zsh/attr Module</a></li>
|
||
<li><a href="Zsh-Modules.html#223-the-zshcap-module">22.3 The zsh/cap Module</a></li>
|
||
<li><a href="Zsh-Modules.html#224-the-zshclone-module">22.4 The zsh/clone Module</a></li>
|
||
<li><a href="Zsh-Modules.html#225-the-zshcompctl-module">22.5 The zsh/compctl Module</a></li>
|
||
<li><a href="Zsh-Modules.html#226-the-zshcomplete-module">22.6 The zsh/complete Module</a></li>
|
||
<li><a href="Zsh-Modules.html#227-the-zshcomplist-module">22.7 The zsh/complist Module</a>
|
||
<ul>
|
||
<li><a href="Zsh-Modules.html#2271-colored-completion-listings">22.7.1 Colored completion listings</a></li>
|
||
<li><a href="Zsh-Modules.html#2272-scrolling-in-completion-listings">22.7.2 Scrolling in completion listings</a></li>
|
||
<li><a href="Zsh-Modules.html#2273-menu-selection">22.7.3 Menu selection</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Zsh-Modules.html#228-the-zshcomputil-module">22.8 The zsh/computil Module</a></li>
|
||
<li><a href="Zsh-Modules.html#229-the-zshcurses-module">22.9 The zsh/curses Module</a>
|
||
<ul>
|
||
<li><a href="Zsh-Modules.html#2291-builtin">22.9.1 Builtin</a></li>
|
||
<li><a href="Zsh-Modules.html#2292-parameters">22.9.2 Parameters</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Zsh-Modules.html#2210-the-zshdatetime-module">22.10 The zsh/datetime Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2211-the-zshdbgdbm-module">22.11 The zsh/db/gdbm Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2212-the-zshdeltochar-module">22.12 The zsh/deltochar Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2213-the-zshexample-module">22.13 The zsh/example Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2214-the-zshfiles-module">22.14 The zsh/files Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2215-the-zshlanginfo-module">22.15 The zsh/langinfo Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2216-the-zshmapfile-module">22.16 The zsh/mapfile Module</a>
|
||
<ul>
|
||
<li><a href="Zsh-Modules.html#22161-limitations">22.16.1 Limitations</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Zsh-Modules.html#2217-the-zshmathfunc-module">22.17 The zsh/mathfunc Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2218-the-zshnearcolor-module">22.18 The zsh/nearcolor Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2219-the-zshnewuser-module">22.19 The zsh/newuser Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2220-the-zshparameter-module">22.20 The zsh/parameter Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2221-the-zshpcre-module">22.21 The zsh/pcre Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2222-the-zshparamprivate-module">22.22 The zsh/param/private Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2223-the-zshregex-module">22.23 The zsh/regex Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2224-the-zshsched-module">22.24 The zsh/sched Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2225-the-zshnetsocket-module">22.25 The zsh/net/socket Module</a>
|
||
<ul>
|
||
<li><a href="Zsh-Modules.html#22251-outbound-connections">22.25.1 Outbound Connections</a></li>
|
||
<li><a href="Zsh-Modules.html#22252-inbound-connections">22.25.2 Inbound Connections</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Zsh-Modules.html#2226-the-zshstat-module">22.26 The zsh/stat Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2227-the-zshsystem-module">22.27 The zsh/system Module</a>
|
||
<ul>
|
||
<li><a href="Zsh-Modules.html#22271-builtins">22.27.1 Builtins</a></li>
|
||
<li><a href="Zsh-Modules.html#22272-math-functions">22.27.2 Math Functions</a></li>
|
||
<li><a href="Zsh-Modules.html#22273-parameters">22.27.3 Parameters</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Zsh-Modules.html#2228-the-zshnettcp-module">22.28 The zsh/net/tcp Module</a>
|
||
<ul>
|
||
<li><a href="Zsh-Modules.html#22281-outbound-connections">22.28.1 Outbound Connections</a></li>
|
||
<li><a href="Zsh-Modules.html#22282-inbound-connections">22.28.2 Inbound Connections</a></li>
|
||
<li><a href="Zsh-Modules.html#22283-closing-connections">22.28.3 Closing Connections</a></li>
|
||
<li><a href="Zsh-Modules.html#22284-example">22.28.4 Example</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Zsh-Modules.html#2229-the-zshtermcap-module">22.29 The zsh/termcap Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2230-the-zshterminfo-module">22.30 The zsh/terminfo Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2231-the-zshzftp-module">22.31 The zsh/zftp Module</a>
|
||
<ul>
|
||
<li><a href="Zsh-Modules.html#22311-subcommands">22.31.1 Subcommands</a></li>
|
||
<li><a href="Zsh-Modules.html#22312-parameters">22.31.2 Parameters</a></li>
|
||
<li><a href="Zsh-Modules.html#22313-functions">22.31.3 Functions</a></li>
|
||
<li><a href="Zsh-Modules.html#22314-problems">22.31.4 Problems</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Zsh-Modules.html#2232-the-zshzle-module">22.32 The zsh/zle Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2233-the-zshzleparameter-module">22.33 The zsh/zleparameter Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2234-the-zshzprof-module">22.34 The zsh/zprof Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2235-the-zshzpty-module">22.35 The zsh/zpty Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2236-the-zshzselect-module">22.36 The zsh/zselect Module</a></li>
|
||
<li><a href="Zsh-Modules.html#2237-the-zshzutil-module">22.37 The zsh/zutil Module</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Zsh-Modules"></span> <span id="Zsh-Modules-1"></span></p>
|
||
<h1 id="22-zsh-modules"><a class="header" href="#22-zsh-modules">22 Zsh Modules</a></h1>
|
||
<p><span id="index-modules"></span></p>
|
||
<hr />
|
||
<p><span id="Description-6"></span></p>
|
||
<h2 id="221-description"><a class="header" href="#221-description">22.1 Description</a></h2>
|
||
<p>Some optional parts of zsh are in modules, separate from the core of the
|
||
shell. Each of these modules may be linked in to the shell at build
|
||
time, or can be dynamically linked while the shell is running if the
|
||
installation supports this feature. Modules are linked at runtime with
|
||
the <code>zmodload</code> command, see <a href="Shell-Builtin-Commands.html#Shell-Builtin-Commands">Shell Builtin
|
||
Commands</a>.</p>
|
||
<p>The modules that are bundled with the zsh distribution are:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>zsh/attr</code><br />
|
||
Builtins for manipulating extended attributes (xattr).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/cap</code><br />
|
||
Builtins for manipulating POSIX.1e (POSIX.6) capability (privilege)
|
||
sets.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/clone</code><br />
|
||
A builtin that can clone a running shell onto another terminal.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/compctl</code><br />
|
||
The <code>compctl</code> builtin for controlling completion.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/complete</code><br />
|
||
The basic completion code.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/complist</code><br />
|
||
Completion listing extensions.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/computil</code><br />
|
||
A module with utility builtins needed for the shell function based
|
||
completion system.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/curses</code><br />
|
||
curses windowing commands</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/datetime</code><br />
|
||
Some date/time commands and parameters.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/db/gdbm</code><br />
|
||
Builtins for managing associative array parameters tied to GDBM
|
||
databases.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/deltochar</code><br />
|
||
A ZLE function duplicating EMACS’ <code>zap-to-char</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/example</code><br />
|
||
An example of how to write a module.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/files</code><br />
|
||
Some basic file manipulation commands as builtins.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/langinfo</code><br />
|
||
Interface to locale information.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/mapfile</code><br />
|
||
Access to external files via a special associative array.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/mathfunc</code><br />
|
||
Standard scientific functions for use in mathematical evaluations.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/nearcolor</code><br />
|
||
Map colours to the nearest colour in the available palette.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/newuser</code><br />
|
||
Arrange for files for new users to be installed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/parameter</code><br />
|
||
<code>zsh/pcre</code><br />
|
||
Interface to the PCRE library.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/param/private</code><br />
|
||
Builtins for managing private-scoped parameters in function context.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/regex</code><br />
|
||
Interface to the POSIX regex library.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/sched</code><br />
|
||
A builtin that provides a timed execution facility within the shell.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/net/socket</code><br />
|
||
Manipulation of Unix domain sockets</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/stat</code><br />
|
||
A builtin command interface to the <code>stat</code> system call.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/system</code><br />
|
||
A builtin interface to various low-level system features.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/net/tcp</code><br />
|
||
Manipulation of TCP sockets</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/termcap</code><br />
|
||
Interface to the termcap database.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/terminfo</code><br />
|
||
Interface to the terminfo database.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/zftp</code><br />
|
||
A builtin FTP client.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/zle</code><br />
|
||
The Zsh Line Editor, including the <code>bindkey</code> and <code>vared</code> builtins.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/zleparameter</code><br />
|
||
Access to internals of the Zsh Line Editor via parameters.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/zprof</code><br />
|
||
A module allowing profiling for shell functions.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/zpty</code><br />
|
||
A builtin for starting a command in a pseudo-terminal.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/zselect</code><br />
|
||
Block and return when file descriptors are ready.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsh/zutil</code><br />
|
||
Some utility builtins, e.g. the one for supporting configuration via
|
||
styles.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="The-zsh_002fattr-Module"></span>
|
||
<span id="The-zsh_002fattr-Module-1"></span></p>
|
||
<h2 id="222-the-zshattr-module"><a class="header" href="#222-the-zshattr-module">22.2 The zsh/attr Module</a></h2>
|
||
<p>The <code>zsh/attr</code> module is used for manipulating extended attributes. The
|
||
<code>-h</code> option causes all commands to operate on symbolic links instead of
|
||
their targets. The builtins in this module are:</p>
|
||
<p><span id="index-zgetattr"></span>
|
||
<span id="index-extended-attributes_002c-xattr_002c-getting-from-files"></span></p>
|
||
<p><code>zgetattr</code> [ <code>-h</code> ] <code>filename</code> <code>attribute</code> [ <code>parameter</code> ]</p>
|
||
<p>Get the extended attribute <code>attribute</code> from the specified <code>filename</code>. If
|
||
the optional argument <code>parameter</code> is given, the attribute is set on that
|
||
parameter instead of being printed to stdout.</p>
|
||
<p><span id="index-zsetattr"></span>
|
||
<span id="index-extended-attributes_002c-xattr_002c-setting-on-files"></span></p>
|
||
<p><code>zsetattr</code> [ <code>-h</code> ] <code>filename</code> <code>attribute</code> <code>value</code></p>
|
||
<p>Set the extended attribute <code>attribute</code> on the specified <code>filename</code> to
|
||
<code>value</code>.</p>
|
||
<p><span id="index-zdelattr"></span>
|
||
<span id="index-extended-attributes_002c-xattr_002c-removing_002c-deleting"></span></p>
|
||
<p><code>zdelattr</code> [ <code>-h</code> ] <code>filename</code> <code>attribute</code></p>
|
||
<p>Remove the extended attribute <code>attribute</code> from the specified <code>filename</code>.</p>
|
||
<p><span id="index-zlistattr"></span>
|
||
<span id="index-extended-attributes_002c-xattr_002c-listing"></span></p>
|
||
<p><code>zlistattr</code> [ <code>-h</code> ] <code>filename</code> [ <code>parameter</code> ]</p>
|
||
<p>List the extended attributes currently set on the specified <code>filename</code>.
|
||
If the optional argument <code>parameter</code> is given, the list of attributes is
|
||
set on that parameter instead of being printed to stdout.</p>
|
||
<p><code>zgetattr</code> and <code>zlistattr</code> allocate memory dynamically. If the attribute
|
||
or list of attributes grows between the allocation and the call to get
|
||
them, they return 2. On all other errors, 1 is returned. This allows the
|
||
calling function to check for this case and retry.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fcap-Module"></span>
|
||
<span id="The-zsh_002fcap-Module-1"></span></p>
|
||
<h2 id="223-the-zshcap-module"><a class="header" href="#223-the-zshcap-module">22.3 The zsh/cap Module</a></h2>
|
||
<p>The <code>zsh/cap</code> module is used for manipulating POSIX.1e (POSIX.6)
|
||
capability sets. If the operating system does not support this
|
||
interface, the builtins defined by this module will do nothing. The
|
||
builtins in this module are:</p>
|
||
<p><span id="index-cap"></span>
|
||
<span id="index-capabilities_002c-setting"></span></p>
|
||
<p><code>cap</code> [ <code>capabilities</code> ]</p>
|
||
<p>Change the shell’s process capability sets to the specified
|
||
<code>capabilities</code>, otherwise display the shell’s current capabilities.</p>
|
||
<p><span id="index-getcap"></span>
|
||
<span id="index-capabilities_002c-getting-from-files"></span></p>
|
||
<p><code>getcap</code> <code>filename</code> ...</p>
|
||
<p>This is a built-in implementation of the POSIX standard utility. It
|
||
displays the capability sets on each specified <code>filename</code>.</p>
|
||
<p><span id="index-setcap"></span>
|
||
<span id="index-capabilities_002c-setting-on-files"></span></p>
|
||
<p><code>setcap</code> <code>capabilities</code> <code>filename</code> ...</p>
|
||
<p>This is a built-in implementation of the POSIX standard utility. It sets
|
||
the capability sets on each specified <code>filename</code> to the specified
|
||
<code>capabilities</code>.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fclone-Module"></span>
|
||
<span id="The-zsh_002fclone-Module-1"></span></p>
|
||
<h2 id="224-the-zshclone-module"><a class="header" href="#224-the-zshclone-module">22.4 The zsh/clone Module</a></h2>
|
||
<p>The <code>zsh/clone</code> module makes available one builtin command:</p>
|
||
<p><span id="index-clone"></span>
|
||
<span id="index-shell_002c-cloning"></span>
|
||
<span id="index-cloning-the-shell"></span>
|
||
<span id="index-terminal"></span></p>
|
||
<p><code>clone</code> <code>tty</code></p>
|
||
<p>Creates a forked instance of the current shell, attached to the
|
||
specified <code>tty</code>. In the new shell, the <code>PID</code>, <code>PPID</code> and <code>TTY</code> special
|
||
parameters are changed appropriately. <code>$!</code> is set to zero in the new
|
||
shell, and to the new shell’s PID in the original shell.</p>
|
||
<p>The return status of the builtin is zero in both shells if successful,
|
||
and non-zero on error.</p>
|
||
<p>The target of <code>clone</code> should be an unused terminal, such as an unused
|
||
virtual console or a virtual terminal created by</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">xterm -e sh -c 'trap : INT QUIT TSTP; tty;
|
||
while :; do sleep 100000000; done'
|
||
</code></pre>
|
||
</div>
|
||
<p>Some words of explanation are warranted about this long xterm command
|
||
line: when doing clone on a pseudo-terminal, some other session
|
||
("session" meant as a unix session group, or SID) is already owning the
|
||
terminal. Hence the cloned zsh cannot acquire the pseudo-terminal as a
|
||
controlling tty. That means two things:</p>
|
||
<ul>
|
||
<li>the job control signals will go to the sh-started-by-xterm process
|
||
group (that’s why we disable INT QUIT and TSTP with trap; otherwise
|
||
the while loop could get suspended or killed)</li>
|
||
<li>the cloned shell will have job control disabled, and the job control
|
||
keys (control-C, control-\ and control-Z) will not work.</li>
|
||
</ul>
|
||
<p>This does not apply when cloning to an <em>unused</em> vc.</p>
|
||
<p>Cloning to a used (and unprepared) terminal will result in two processes
|
||
reading simultaneously from the same terminal, with input bytes going
|
||
randomly to either process.</p>
|
||
<p><code>clone</code> is mostly useful as a shell built-in replacement for openvt.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fcompctl-Module"></span>
|
||
<span id="The-zsh_002fcompctl-Module-1"></span></p>
|
||
<h2 id="225-the-zshcompctl-module"><a class="header" href="#225-the-zshcompctl-module">22.5 The zsh/compctl Module</a></h2>
|
||
<p>The <code>zsh/compctl</code> module makes available two builtin commands.
|
||
<code>compctl</code>, is the old, deprecated way to control completions for ZLE.
|
||
See <a href="Completion-Using-compctl.html#Completion-Using-compctl">Completion Using
|
||
compctl</a>. The
|
||
other builtin command, <code>compcall</code> can be used in user-defined completion
|
||
widgets, see <a href="Completion-Widgets.html#Completion-Widgets">Completion
|
||
Widgets</a>.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fcomplete-Module"></span>
|
||
<span id="The-zsh_002fcomplete-Module-1"></span></p>
|
||
<h2 id="226-the-zshcomplete-module"><a class="header" href="#226-the-zshcomplete-module">22.6 The zsh/complete Module</a></h2>
|
||
<p>The <code>zsh/complete</code> module makes available several builtin commands which
|
||
can be used in user-defined completion widgets, see <a href="Completion-Widgets.html#Completion-Widgets">Completion
|
||
Widgets</a>.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fcomplist-Module"></span>
|
||
<span id="The-zsh_002fcomplist-Module-1"></span></p>
|
||
<h2 id="227-the-zshcomplist-module"><a class="header" href="#227-the-zshcomplist-module">22.7 The zsh/complist Module</a></h2>
|
||
<p><span id="index-completion_002c-listing-1"></span>
|
||
<span id="index-completion_002c-coloured-listings"></span>
|
||
<span id="index-completion_002c-scroll-listings"></span></p>
|
||
<p>The <code>zsh/complist</code> module offers three extensions to completion
|
||
listings: the ability to highlight matches in such a list, the ability
|
||
to scroll through long lists and a different style of menu completion.</p>
|
||
<hr />
|
||
<p><span id="Colored-completion-listings"></span></p>
|
||
<h3 id="2271-colored-completion-listings"><a class="header" href="#2271-colored-completion-listings">22.7.1 Colored completion listings</a></h3>
|
||
<p>Whenever one of the parameters <code>ZLS_COLORS</code> or <code>ZLS_COLOURS</code> is set and
|
||
the <code>zsh/complist</code> module is loaded or linked into the shell, completion
|
||
lists will be colored. Note, however, that <code>complist</code> will not
|
||
automatically be loaded if it is not linked in: on systems with dynamic
|
||
loading, ‘<code>zmodload zsh/complist</code>’ is required.</p>
|
||
<p><span id="index-ZLS_005fCOLORS"></span>
|
||
<span id="index-ZLS_005fCOLOURS"></span></p>
|
||
<p>The parameters <code>ZLS_COLORS</code> and <code>ZLS_COLOURS</code> describe how matches are
|
||
highlighted. To turn on highlighting an empty value suffices, in which
|
||
case all the default values given below will be used. The format of the
|
||
value of these parameters is the same as used by the GNU version of the
|
||
<code>ls</code> command: a colon-separated list of specifications of the form
|
||
‘<code>name``=``value</code>’. The <code>name</code> may be one of the following strings,
|
||
most of which specify file types for which the <code>value</code> will be used. The
|
||
strings and their default values are:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>no 0</code><br />
|
||
for normal text (i.e. when displaying something other than a matched
|
||
file)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>fi 0</code><br />
|
||
for regular files</p>
|
||
</li>
|
||
<li>
|
||
<p><code>di 32</code><br />
|
||
for directories</p>
|
||
</li>
|
||
<li>
|
||
<p><code>ln 36</code><br />
|
||
for symbolic links. If this has the special value <code>target</code>, symbolic
|
||
links are dereferenced and the target file used to determine the
|
||
display format.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>pi 31</code><br />
|
||
for named pipes (FIFOs)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>so 33</code><br />
|
||
for sockets</p>
|
||
</li>
|
||
<li>
|
||
<p><code>bd 44;37</code><br />
|
||
for block devices</p>
|
||
</li>
|
||
<li>
|
||
<p><code>cd 44;37</code><br />
|
||
for character devices</p>
|
||
</li>
|
||
<li>
|
||
<p><code>or</code> <code>none</code><br />
|
||
for a symlink to nonexistent file (default is the value defined for
|
||
<code>ln</code>)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>mi</code> <code>none</code><br />
|
||
for a non-existent file (default is the value defined for <code>fi</code>);
|
||
this code is currently not used</p>
|
||
</li>
|
||
<li>
|
||
<p><code>su 37;41</code><br />
|
||
for files with setuid bit set</p>
|
||
</li>
|
||
<li>
|
||
<p><code>sg 30;43</code><br />
|
||
for files with setgid bit set</p>
|
||
</li>
|
||
<li>
|
||
<p><code>tw 30;42</code><br />
|
||
<code>ow 34;43</code><br />
|
||
<code>sa</code> <code>none</code><br />
|
||
for files with an associated suffix alias; this is only tested after
|
||
specific suffixes, as described below</p>
|
||
</li>
|
||
<li>
|
||
<p><code>st 37;44</code><br />
|
||
<code>ex 35</code><br />
|
||
<code>lc \e[</code><br />
|
||
for the left code (see below)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>rc m</code><br />
|
||
for the right code</p>
|
||
</li>
|
||
<li>
|
||
<p><code>tc 0</code><br />
|
||
for the character indicating the file type printed after filenames
|
||
if the <code>LIST_TYPES</code> option is set</p>
|
||
</li>
|
||
<li>
|
||
<p><code>sp 0</code><br />
|
||
for the spaces printed after matches to align the next column</p>
|
||
</li>
|
||
<li>
|
||
<p><code>ec</code> <code>none</code><br />
|
||
for the end code</p>
|
||
</li>
|
||
</ul>
|
||
<p>Apart from these strings, the <code>name</code> may also be an asterisk (‘<code>*</code>’)
|
||
followed by any string. The <code>value</code> given for such a string will be used
|
||
for all files whose name ends with the string. The <code>name</code> may also be an
|
||
equals sign (‘<code>=</code>’) followed by a pattern; the <code>EXTENDED_GLOB</code> option
|
||
will be turned on for evaluation of the pattern. The <code>value</code> given for
|
||
this pattern will be used for all matches (not just filenames) whose
|
||
display string are matched by the pattern. Definitions for the form with
|
||
the leading equal sign take precedence over the values defined for file
|
||
types, which in turn take precedence over the form with the leading
|
||
asterisk (file extensions).</p>
|
||
<p>The leading-equals form also allows different parts of the displayed
|
||
strings to be colored differently. For this, the pattern has to use the
|
||
‘<code>(#b)</code>’ globbing flag and pairs of parentheses surrounding the parts
|
||
of the strings that are to be colored differently. In this case the
|
||
<code>value</code> may consist of more than one color code separated by equal
|
||
signs. The first code will be used for all parts for which no explicit
|
||
code is specified and the following codes will be used for the parts
|
||
matched by the sub-patterns in parentheses. For example, the
|
||
specification ‘<code>=(#b)(?)*(?)=0=3=7</code>’ will be used for all matches which
|
||
are at least two characters long and will use the code ‘<code>3</code>’ for the
|
||
first character, ‘<code>7</code>’ for the last character and ‘<code>0</code>’ for the rest.</p>
|
||
<p>All three forms of <code>name</code> may be preceded by a pattern in parentheses.
|
||
If this is given, the <code>value</code> will be used only for matches in groups
|
||
whose names are matched by the pattern given in the parentheses. For
|
||
example, ‘<code>(g*)m*=43</code>’ highlights all matches beginning with ‘<code>m</code>’ in
|
||
groups whose names begin with ‘<code>g</code>’ using the color code ‘<code>43</code>’. In case
|
||
of the ‘<code>lc</code>’, ‘<code>rc</code>’, and ‘<code>ec</code>’ codes, the group pattern is ignored.</p>
|
||
<p>Note also that all patterns are tried in the order in which they appear
|
||
in the parameter value until the first one matches which is then used.
|
||
Patterns may be matched against completions, descriptions (possibly with
|
||
spaces appended for padding), or lines consisting of a completion
|
||
followed by a description. For consistent coloring it may be necessary
|
||
to use more than one pattern or a pattern with backreferences.</p>
|
||
<p>When printing a match, the code prints the value of <code>lc</code>, the value for
|
||
the file-type or the last matching specification with a ‘<code>*</code>’, the value
|
||
of <code>rc</code>, the string to display for the match itself, and then the value
|
||
of <code>ec</code> if that is defined or the values of <code>lc</code>, <code>no</code>, and <code>rc</code> if <code>ec</code>
|
||
is not defined.</p>
|
||
<p>The default values are ISO 6429 (ANSI) compliant and can be used on
|
||
vt100 compatible terminals such as <code>xterm</code>s. On monochrome terminals the
|
||
default values will have no visible effect. The <code>colors</code> function from
|
||
the contribution can be used to get associative arrays containing the
|
||
codes for ANSI terminals (see <a href="User-Contributions.html#Other-Functions">Other
|
||
Functions</a>). For example, after
|
||
loading <code>colors</code>, one could use ‘<code>$color[red]</code>’ to get the code for
|
||
foreground color red and ‘<code>$color[bg-green]</code>’ for the code for
|
||
background color green.</p>
|
||
<p>If the completion system invoked by compinit is used, these parameters
|
||
should not be set directly because the system controls them itself.
|
||
Instead, the <code>list-colors</code> style should be used (see <a href="Completion-System.html#Completion-System-Configuration">Completion System
|
||
Configuration</a>).</p>
|
||
<hr />
|
||
<p><span id="Scrolling-in-completion-listings"></span></p>
|
||
<h3 id="2272-scrolling-in-completion-listings"><a class="header" href="#2272-scrolling-in-completion-listings">22.7.2 Scrolling in completion listings</a></h3>
|
||
<p>To enable scrolling through a completion list, the <code>LISTPROMPT</code>
|
||
parameter must be set. Its value will be used as the prompt; if it is
|
||
the empty string, a default prompt will be used. The value may contain
|
||
escapes of the form ‘<code>%x</code>’. It supports the escapes ‘<code>%B</code>’, ‘<code>%b</code>’,
|
||
‘<code>%S</code>’, ‘<code>%s</code>’, ‘<code>%U</code>’, ‘<code>%u</code>’, ‘<code>%F</code>’, ‘<code>%f</code>’, ‘<code>%K</code>’, ‘<code>%k</code>’ and
|
||
‘<code>%{``...``%}</code>’ used also in shell prompts as well as three pairs of
|
||
additional sequences: a ‘<code>%l</code>’ or ‘<code>%L</code>’ is replaced by the number of
|
||
the last line shown and the total number of lines in the form
|
||
‘<code>number``/``total</code>’; a ‘<code>%m</code>’ or ‘<code>%M</code>’ is replaced with the number
|
||
of the last match shown and the total number of matches; and ‘<code>%p</code>’ or
|
||
‘<code>%P</code>’ is replaced with ‘<code>Top</code>’, ‘<code>Bottom</code>’ or the position of the
|
||
first line shown in percent of the total number of lines, respectively.
|
||
In each of these cases the form with the uppercase letter will be
|
||
replaced with a string of fixed width, padded to the right with spaces,
|
||
while the lowercase form will not be padded.</p>
|
||
<p>If the parameter <code>LISTPROMPT</code> is set, the completion code will not ask
|
||
if the list should be shown. Instead it immediately starts displaying
|
||
the list, stopping after the first screenful, showing the prompt at the
|
||
bottom, waiting for a keypress after temporarily switching to the
|
||
<code>listscroll</code> keymap. Some of the zle functions have a special meaning
|
||
while scrolling lists:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>send-break</code><br />
|
||
stops listing discarding the key pressed</p>
|
||
</li>
|
||
<li>
|
||
<p><code>accept-line</code>, <code>down-history</code>, <code>down-line-or-history</code><br />
|
||
<code>down-line-or-search</code>, <code>vi-down-line-or-history</code><br />
|
||
scrolls forward one line</p>
|
||
</li>
|
||
<li>
|
||
<p><code>complete-word</code>, <code>menu-complete</code>, <code>expand-or-complete</code><br />
|
||
<code>expand-or-complete-prefix</code>, <code>menu-complete-or-expand</code><br />
|
||
scrolls forward one screenful</p>
|
||
</li>
|
||
<li>
|
||
<p><code>accept-search</code><br />
|
||
stop listing but take no other action</p>
|
||
</li>
|
||
</ul>
|
||
<p>Every other character stops listing and immediately processes the key as
|
||
usual. Any key that is not bound in the <code>listscroll</code> keymap or that is
|
||
bound to <code>undefined-key</code> is looked up in the keymap currently selected.</p>
|
||
<p>As for the <code>ZLS_COLORS</code> and <code>ZLS_COLOURS</code> parameters, <code>LISTPROMPT</code>
|
||
should not be set directly when using the shell function based
|
||
completion system. Instead, the <code>list-prompt</code> style should be used.</p>
|
||
<hr />
|
||
<p><span id="Menu-selection"></span></p>
|
||
<h3 id="2273-menu-selection"><a class="header" href="#2273-menu-selection">22.7.3 Menu selection</a></h3>
|
||
<p><span id="index-completion_002c-selecting-by-cursor"></span>
|
||
<span id="index-MENUSELECT"></span>
|
||
<span id="index-menu_002dselect"></span></p>
|
||
<p>The <code>zsh/complist</code> module also offers an alternative style of selecting
|
||
matches from a list, called menu selection, which can be used if the
|
||
shell is set up to return to the last prompt after showing a completion
|
||
list (see the <code>ALWAYS_LAST_PROMPT</code> option in
|
||
<a href="Options.html#Options">Options</a>).</p>
|
||
<p>Menu selection can be invoked directly by the widget <code>menu-select</code>
|
||
defined by this module. This is a standard ZLE widget that can be bound
|
||
to a key in the usual way as described in <a href="Zsh-Line-Editor.html#Zsh-Line-Editor">Zsh Line
|
||
Editor</a>.</p>
|
||
<p>Alternatively, the parameter <code>MENUSELECT</code> can be set to an integer,
|
||
which gives the minimum number of matches that must be present before
|
||
menu selection is automatically turned on. This second method requires
|
||
that menu completion be started, either directly from a widget such as
|
||
<code>menu-complete</code>, or due to one of the options <code>MENU_COMPLETE</code> or
|
||
<code>AUTO_MENU</code> being set. If <code>MENUSELECT</code> is set, but is 0, 1 or empty,
|
||
menu selection will always be started during an ambiguous menu
|
||
completion.</p>
|
||
<p>When using the completion system based on shell functions, the
|
||
<code>MENUSELECT</code> parameter should not be used (like the <code>ZLS_COLORS</code> and
|
||
<code>ZLS_COLOURS</code> parameters described above). Instead, the <code>menu</code> style
|
||
should be used with the <code>select=``...</code> keyword.</p>
|
||
<p>After menu selection is started, the matches will be listed. If there
|
||
are more matches than fit on the screen, only the first screenful is
|
||
shown. The matches to insert into the command line can be selected from
|
||
this list. In the list one match is highlighted using the value for <code>ma</code>
|
||
from the <code>ZLS_COLORS</code> or <code>ZLS_COLOURS</code> parameter. The default value for
|
||
this is ‘<code>7</code>’ which forces the selected match to be highlighted using
|
||
standout mode on a vt100-compatible terminal. If neither <code>ZLS_COLORS</code>
|
||
nor <code>ZLS_COLOURS</code> is set, the same terminal control sequence as for the
|
||
‘<code>%S</code>’ escape in prompts is used.</p>
|
||
<p>If there are more matches than fit on the screen and the parameter
|
||
<code>MENUPROMPT</code> is set, its value will be shown below the matches. It
|
||
supports the same escape sequences as <code>LISTPROMPT</code>, but the number of
|
||
the match or line shown will be that of the one where the mark is
|
||
placed. If its value is the empty string, a default prompt will be used.</p>
|
||
<p>The <code>MENUSCROLL</code> parameter can be used to specify how the list is
|
||
scrolled. If the parameter is unset, this is done line by line, if it is
|
||
set to ‘<code>0</code>’ (zero), the list will scroll half the number of lines of
|
||
the screen. If the value is positive, it gives the number of lines to
|
||
scroll and if it is negative, the list will be scrolled the number of
|
||
lines of the screen minus the (absolute) value.</p>
|
||
<p>As for the <code>ZLS_COLORS</code>, <code>ZLS_COLOURS</code> and <code>LISTPROMPT</code> parameters,
|
||
neither <code>MENUPROMPT</code> nor <code>MENUSCROLL</code> should be set directly when using
|
||
the shell function based completion system. Instead, the <code>select-prompt</code>
|
||
and <code>select-scroll</code> styles should be used.</p>
|
||
<p>The completion code sometimes decides not to show all of the matches in
|
||
the list. These hidden matches are either matches for which the
|
||
completion function which added them explicitly requested that they not
|
||
appear in the list (using the <code>-n</code> option of the <code>compadd</code> builtin
|
||
command) or they are matches which duplicate a string already in the
|
||
list (because they differ only in things like prefixes or suffixes that
|
||
are not displayed). In the list used for menu selection, however, even
|
||
these matches are shown so that it is possible to select them. To
|
||
highlight such matches the <code>hi</code> and <code>du</code> capabilities in the
|
||
<code>ZLS_COLORS</code> and <code>ZLS_COLOURS</code> parameters are supported for hidden
|
||
matches of the first and second kind, respectively.</p>
|
||
<p>Selecting matches is done by moving the mark around using the zle
|
||
movement functions. When not all matches can be shown on the screen at
|
||
the same time, the list will scroll up and down when crossing the top or
|
||
bottom line. The following zle functions have special meaning during
|
||
menu selection. Note that the following always perform the same task
|
||
within the menu selection map and cannot be replaced by user defined
|
||
widgets, nor can the set of functions be extended:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>accept-line</code>, <code>accept-search</code><br />
|
||
accept the current match and leave menu selection (but do not cause
|
||
the command line to be accepted)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>send-break</code><br />
|
||
leaves menu selection and restores the previous contents of the
|
||
command line</p>
|
||
</li>
|
||
<li>
|
||
<p><code>redisplay</code>, <code>clear-screen</code><br />
|
||
execute their normal function without leaving menu selection</p>
|
||
</li>
|
||
<li>
|
||
<p><code>accept-and-hold</code>, <code>accept-and-menu-complete</code><br />
|
||
accept the currently inserted match and continue selection allowing
|
||
to select the next match to insert into the line</p>
|
||
</li>
|
||
<li>
|
||
<p><code>accept-and-infer-next-history</code><br />
|
||
accepts the current match and then tries completion with menu
|
||
selection again; in the case of files this allows one to select a
|
||
directory and immediately attempt to complete files in it; if there
|
||
are no matches, a message is shown and one can use <code>undo</code> to go back
|
||
to completion on the previous level, every other key leaves menu
|
||
selection (including the other zle functions which are otherwise
|
||
special during menu selection)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>undo</code><br />
|
||
removes matches inserted during the menu selection by one of the
|
||
three functions before</p>
|
||
</li>
|
||
<li>
|
||
<p><code>down-history</code>, <code>down-line-or-history</code><br />
|
||
<code>vi-down-line-or-history</code>, <code>down-line-or-search</code><br />
|
||
moves the mark one line down</p>
|
||
</li>
|
||
<li>
|
||
<p><code>up-history</code>, <code>up-line-or-history</code><br />
|
||
<code>vi-up-line-or-history</code>, <code>up-line-or-search</code><br />
|
||
moves the mark one line up</p>
|
||
</li>
|
||
<li>
|
||
<p><code>forward-char</code>, <code>vi-forward-char</code><br />
|
||
moves the mark one column right</p>
|
||
</li>
|
||
<li>
|
||
<p><code>backward-char</code>, <code>vi-backward-char</code><br />
|
||
moves the mark one column left</p>
|
||
</li>
|
||
<li>
|
||
<p><code>forward-word</code>, <code>vi-forward-word</code><br />
|
||
<code>vi-forward-word-end</code>, <code>emacs-forward-word</code><br />
|
||
moves the mark one screenful down</p>
|
||
</li>
|
||
<li>
|
||
<p><code>backward-word</code>, <code>vi-backward-word</code>, <code>emacs-backward-word</code><br />
|
||
moves the mark one screenful up</p>
|
||
</li>
|
||
<li>
|
||
<p><code>vi-forward-blank-word</code>, <code>vi-forward-blank-word-end</code><br />
|
||
moves the mark to the first line of the next group of matches</p>
|
||
</li>
|
||
<li>
|
||
<p><code>vi-backward-blank-word</code><br />
|
||
moves the mark to the last line of the previous group of matches</p>
|
||
</li>
|
||
<li>
|
||
<p><code>beginning-of-history</code><br />
|
||
moves the mark to the first line</p>
|
||
</li>
|
||
<li>
|
||
<p><code>end-of-history</code><br />
|
||
moves the mark to the last line</p>
|
||
</li>
|
||
<li>
|
||
<p><code>beginning-of-buffer-or-history</code>, <code>beginning-of-line</code><br />
|
||
<code>beginning-of-line-hist</code>, <code>vi-beginning-of-line</code><br />
|
||
moves the mark to the leftmost column</p>
|
||
</li>
|
||
<li>
|
||
<p><code>end-of-buffer-or-history</code>, <code>end-of-line</code><br />
|
||
<code>end-of-line-hist</code>, <code>vi-end-of-line</code><br />
|
||
moves the mark to the rightmost column</p>
|
||
</li>
|
||
<li>
|
||
<p><code>complete-word</code>, <code>menu-complete</code>, <code>expand-or-complete</code><br />
|
||
<code>expand-or-complete-prefix</code>, <code>menu-expand-or-complete</code><br />
|
||
moves the mark to the next match</p>
|
||
</li>
|
||
<li>
|
||
<p><code>reverse-menu-complete</code><br />
|
||
moves the mark to the previous match</p>
|
||
</li>
|
||
<li>
|
||
<p><code>vi-insert</code><br />
|
||
this toggles between normal and interactive mode; in interactive
|
||
mode the keys bound to <code>self-insert</code> and <code>self-insert-unmeta</code> insert
|
||
into the command line as in normal editing mode but without leaving
|
||
menu selection; after each character completion is tried again and
|
||
the list changes to contain only the new matches; the completion
|
||
widgets make the longest unambiguous string be inserted in the
|
||
command line and <code>undo</code> and <code>backward-delete-char</code> go back to the
|
||
previous set of matches</p>
|
||
</li>
|
||
<li>
|
||
<p><code>history-incremental-search-forward</code><br />
|
||
<code>history-incremental-search-backward</code><br />
|
||
this starts incremental searches in the list of completions
|
||
displayed; in this mode, <code>accept-line</code> only leaves incremental
|
||
search, going back to the normal menu selection mode</p>
|
||
</li>
|
||
</ul>
|
||
<p>All movement functions wrap around at the edges; any other zle function
|
||
not listed leaves menu selection and executes that function. It is
|
||
possible to make widgets in the above list do the same by using the form
|
||
of the widget with a ‘<code>.</code>’ in front. For example, the widget
|
||
‘<code>.accept-line</code>’ has the effect of leaving menu selection and
|
||
accepting the entire command line.</p>
|
||
<p>During this selection the widget uses the keymap <code>menuselect</code>. Any key
|
||
that is not defined in this keymap or that is bound to <code>undefined-key</code>
|
||
is looked up in the keymap currently selected. This is used to ensure
|
||
that the most important keys used during selection (namely the cursor
|
||
keys, return, and TAB) have sensible defaults. However, keys in the
|
||
<code>menuselect</code> keymap can be modified directly using the <code>bindkey</code> builtin
|
||
command (see <a href="Zsh-Modules.html#The-zsh_002fzle-Module">The zsh/zle Module</a>). For
|
||
example, to make the return key leave menu selection without accepting
|
||
the match currently selected one could call</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">bindkey -M menuselect '^M' send-break
|
||
</code></pre>
|
||
</div>
|
||
<p>after loading the <code>zsh/complist</code> module.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fcomputil-Module"></span>
|
||
<span id="The-zsh_002fcomputil-Module-1"></span></p>
|
||
<h2 id="228-the-zshcomputil-module"><a class="header" href="#228-the-zshcomputil-module">22.8 The zsh/computil Module</a></h2>
|
||
<p><span id="index-completion_002c-utility"></span></p>
|
||
<p>The <code>zsh/computil</code> module adds several builtin commands that are used by
|
||
some of the completion functions in the completion system based on shell
|
||
functions (see <a href="Completion-System.html#Completion-System">Completion
|
||
System</a> ). Except for
|
||
<code>compquote</code> these builtin commands are very specialised and thus not
|
||
very interesting when writing your own completion functions. In summary,
|
||
these builtin commands are:</p>
|
||
<p><span id="index-comparguments"></span></p>
|
||
<p><code>comparguments</code></p>
|
||
<p>This is used by the <code>_arguments</code> function to do the argument and command
|
||
line parsing. Like <code>compdescribe</code> it has an option <code>-i</code> to do the
|
||
parsing and initialize some internal state and various options to access
|
||
the state information to decide what should be completed.</p>
|
||
<p><span id="index-compdescribe"></span></p>
|
||
<p><code>compdescribe</code></p>
|
||
<p>This is used by the <code>_describe</code> function to build the displays for the
|
||
matches and to get the strings to add as matches with their options. On
|
||
the first call one of the options <code>-i</code> or <code>-I</code> should be supplied as the
|
||
first argument. In the first case, display strings without the
|
||
descriptions will be generated, in the second case, the string used to
|
||
separate the matches from their descriptions must be given as the second
|
||
argument and the descriptions (if any) will be shown. All other
|
||
arguments are like the definition arguments to <code>_describe</code> itself.</p>
|
||
<p>Once <code>compdescribe</code> has been called with either the <code>-i</code> or the <code>-I</code>
|
||
option, it can be repeatedly called with the <code>-g</code> option and the names
|
||
of four parameters as its arguments. This will step through the
|
||
different sets of matches and store the value of <code>compstate[list]</code> in
|
||
the first scalar, the options for <code>compadd</code> in the second array, the
|
||
matches in the third array, and the strings to be displayed in the
|
||
completion listing in the fourth array. The arrays may then be directly
|
||
given to <code>compadd</code> to register the matches with the completion code.</p>
|
||
<p><span id="index-compfiles"></span></p>
|
||
<p><code>compfiles</code></p>
|
||
<p>Used by the <code>_path_files</code> function to optimize complex recursive
|
||
filename generation (globbing). It does three things. With the <code>-p</code> and
|
||
<code>-P</code> options it builds the glob patterns to use, including the paths
|
||
already handled and trying to optimize the patterns with respect to the
|
||
prefix and suffix from the line and the match specification currently
|
||
used. The <code>-i</code> option does the directory tests for the <code>ignore-parents</code>
|
||
style and the <code>-r</code> option tests if a component for some of the matches
|
||
are equal to the string on the line and removes all other matches if
|
||
that is true.</p>
|
||
<p><span id="index-compgroups"></span></p>
|
||
<p><code>compgroups</code></p>
|
||
<p>Used by the <code>_tags</code> function to implement the internals of the
|
||
<code>group-order</code> style. This only takes its arguments as names of
|
||
completion groups and creates the groups for it (all six types: sorted
|
||
and unsorted, both without removing duplicates, with removing all
|
||
duplicates and with removing consecutive duplicates).</p>
|
||
<p><span id="index-compquote"></span></p>
|
||
<p><code>compquote</code> [ <code>-p</code> ] <code>names</code> ...</p>
|
||
<p>There may be reasons to write completion functions that have to add the
|
||
matches using the <code>-Q</code> option to <code>compadd</code> and perform quoting
|
||
themselves. Instead of interpreting the first character of the
|
||
<code>all_quotes</code> key of the <code>compstate</code> special association and using the
|
||
<code>q</code> flag for parameter expansions, one can use this builtin command. The
|
||
arguments are the names of scalar or array parameters and the values of
|
||
these parameters are quoted as needed for the innermost quoting level.
|
||
If the <code>-p</code> option is given, quoting is done as if there is some prefix
|
||
before the values of the parameters, so that a leading equal sign will
|
||
not be quoted.</p>
|
||
<p>The return status is non-zero in case of an error and zero otherwise.</p>
|
||
<p><span id="index-comptags"></span> <span id="index-comptry"></span></p>
|
||
<p><code>comptags</code></p>
|
||
<p><code>comptry</code></p>
|
||
<p>These implement the internals of the tags mechanism.</p>
|
||
<p><span id="index-compvalues"></span></p>
|
||
<p><code>compvalues</code></p>
|
||
<p>Like <code>comparguments</code>, but for the <code>_values</code> function.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fcurses-Module"></span>
|
||
<span id="The-zsh_002fcurses-Module-1"></span></p>
|
||
<h2 id="229-the-zshcurses-module"><a class="header" href="#229-the-zshcurses-module">22.9 The zsh/curses Module</a></h2>
|
||
<p>The <code>zsh/curses</code> module makes available one builtin command and various
|
||
parameters.</p>
|
||
<hr />
|
||
<p><span id="Builtin"></span></p>
|
||
<h3 id="2291-builtin"><a class="header" href="#2291-builtin">22.9.1 Builtin</a></h3>
|
||
<p><span id="index-zcurses"></span>
|
||
<span id="index-windows_002c-curses"></span></p>
|
||
<p><code>zcurses</code> <code>init</code></p>
|
||
<p><code>zcurses</code> <code>end</code></p>
|
||
<p><code>zcurses</code> <code>addwin</code> <code>targetwin</code> <code>nlines</code> <code>ncols</code> <code>begin_y</code> <code>begin_x</code> [
|
||
<code>parentwin</code> ]</p>
|
||
<p><code>zcurses</code> <code>delwin</code> <code>targetwin</code></p>
|
||
<p><code>zcurses</code> <code>refresh</code> [ <code>targetwin</code> ... ]</p>
|
||
<p><code>zcurses</code> <code>touch</code> <code>targetwin</code> ...</p>
|
||
<p><code>zcurses</code> <code>move</code> <code>targetwin</code> <code>new_y</code> <code>new_x</code></p>
|
||
<p><code>zcurses</code> <code>clear</code> <code>targetwin</code> [ <code>redraw</code> | <code>eol</code> | <code>bot</code> ]</p>
|
||
<p><code>zcurses</code> <code>position</code> <code>targetwin</code> <code>array</code></p>
|
||
<p><code>zcurses</code> <code>char</code> <code>targetwin</code> <code>character</code></p>
|
||
<p><code>zcurses</code> <code>string</code> <code>targetwin</code> <code>string</code></p>
|
||
<p><code>zcurses</code> <code>border</code> <code>targetwin</code> <code>border</code></p>
|
||
<p><code>zcurses</code> <code>attr</code> <code>targetwin</code> [ [<code>+</code>|<code>-</code>]<code>attribute</code> |
|
||
<code>fg_col``/``bg_col</code> ] [...]</p>
|
||
<p><code>zcurses</code> <code>bg</code> <code>targetwin</code> [ [<code>+</code>|<code>-</code>]<code>attribute</code> |
|
||
<code>fg_col``/``bg_col</code> | <code>@``char</code> ] [...]</p>
|
||
<p><code>zcurses</code> <code>scroll</code> <code>targetwin</code> [ <code>on</code> | <code>off</code> | [<code>+</code>|<code>-</code>]<code>lines</code> ]</p>
|
||
<p><code>zcurses</code> <code>input</code> <code>targetwin</code> [ <code>param</code> [ <code>kparam</code> [ <code>mparam</code> ] ]
|
||
]</p>
|
||
<p><code>zcurses</code> <code>mouse</code> [ <code>delay</code> <code>num</code> | [<code>+</code>|<code>-</code>]<code>motion</code> ]</p>
|
||
<p><code>zcurses</code> <code>timeout</code> <code>targetwin</code> <code>intval</code></p>
|
||
<p><code>zcurses</code> <code>querychar</code> <code>targetwin</code> [ <code>param</code> ]</p>
|
||
<p><code>zcurses</code> <code>resize</code> <code>height</code> <code>width</code> [ <code>endwin</code> | <code>nosave</code> |
|
||
<code>endwin_nosave</code> ]</p>
|
||
<p>Manipulate curses windows. All uses of this command should be bracketed
|
||
by ‘<code>zcurses init</code>’ to initialise use of curses, and ‘<code>zcurses end</code>’ to
|
||
end it; omitting ‘<code>zcurses end</code>’ can cause the terminal to be in an
|
||
unwanted state.</p>
|
||
<p>The subcommand <code>addwin</code> creates a window with <code>nlines</code> lines and <code>ncols</code>
|
||
columns. Its upper left corner will be placed at row <code>begin_y</code> and
|
||
column <code>begin_x</code> of the screen. <code>targetwin</code> is a string and refers to
|
||
the name of a window that is not currently assigned. Note in particular
|
||
the curses convention that vertical values appear before horizontal
|
||
values.</p>
|
||
<p>If <code>addwin</code> is given an existing window as the final argument, the new
|
||
window is created as a subwindow of <code>parentwin</code>. This differs from an
|
||
ordinary new window in that the memory of the window contents is shared
|
||
with the parent’s memory. Subwindows must be deleted before their
|
||
parent. Note that the coordinates of subwindows are relative to the
|
||
screen, not the parent, as with other windows.</p>
|
||
<p>Use the subcommand <code>delwin</code> to delete a window created with <code>addwin</code>.
|
||
Note that <code>end</code> does <em>not</em> implicitly delete windows, and that <code>delwin</code>
|
||
does not erase the screen image of the window.</p>
|
||
<p>The window corresponding to the full visible screen is called <code>stdscr</code>;
|
||
it always exists after ‘<code>zcurses init</code>’ and cannot be delete with
|
||
<code>delwin</code>.</p>
|
||
<p>The subcommand <code>refresh</code> will refresh window <code>targetwin</code>; this is
|
||
necessary to make any pending changes (such as characters you have
|
||
prepared for output with <code>char</code>) visible on the screen. <code>refresh</code>
|
||
without an argument causes the screen to be cleared and redrawn. If
|
||
multiple windows are given, the screen is updated once at the end.</p>
|
||
<p>The subcommand <code>touch</code> marks the <code>targetwin</code>s listed as changed. This is
|
||
necessary before <code>refresh</code>ing windows if a window that was in front of
|
||
another window (which may be <code>stdscr</code>) is deleted.</p>
|
||
<p>The subcommand <code>move</code> moves the cursor position in <code>targetwin</code> to new
|
||
coordinates <code>new_y</code> and <code>new_x</code>. Note that the subcommand <code>string</code> (but
|
||
not the subcommand <code>char</code>) advances the cursor position over the
|
||
characters added.</p>
|
||
<p>The subcommand <code>clear</code> erases the contents of <code>targetwin</code>. One (and no
|
||
more than one) of three options may be specified. With the option
|
||
<code>redraw</code>, in addition the next <code>refresh</code> of <code>targetwin</code> will cause the
|
||
screen to be cleared and repainted. With the option <code>eol</code>, <code>targetwin</code>
|
||
is only cleared to the end of the current cursor line. With the option
|
||
<code>bot</code>, <code>targetwin</code> is cleared to the end of the window, i.e everything
|
||
to the right and below the cursor is cleared.</p>
|
||
<p>The subcommand <code>position</code> writes various positions associated with
|
||
<code>targetwin</code> into the array named <code>array</code>. These are, in order:</p>
|
||
<ul>
|
||
<li>
|
||
<p>-<br />
|
||
The y and x coordinates of the cursor relative to the top left of
|
||
<code>targetwin</code></p>
|
||
</li>
|
||
<li>
|
||
<p>-<br />
|
||
The y and x coordinates of the top left of <code>targetwin</code> on the screen</p>
|
||
</li>
|
||
<li>
|
||
<p>-<br />
|
||
The size of <code>targetwin</code> in y and x dimensions.</p>
|
||
</li>
|
||
</ul>
|
||
<p>Outputting characters and strings are achieved by <code>char</code> and <code>string</code>
|
||
respectively.</p>
|
||
<p>To draw a border around window <code>targetwin</code>, use <code>border</code>. Note that the
|
||
border is not subsequently handled specially: in other words, the border
|
||
is simply a set of characters output at the edge of the window. Hence it
|
||
can be overwritten, can scroll off the window, etc.</p>
|
||
<p>The subcommand <code>attr</code> will set <code>targetwin</code>’s attributes or
|
||
foreground/background color pair for any successive character output.
|
||
Each <code>attribute</code> given on the line may be prepended by a <code>+</code> to set or a
|
||
<code>-</code> to unset that attribute; <code>+</code> is assumed if absent. The attributes
|
||
supported are <code>blink</code>, <code>bold</code>, <code>dim</code>, <code>reverse</code>, <code>standout</code>, and
|
||
<code>underline</code>.</p>
|
||
<p>Each <code>fg_col``/``bg_col</code> attribute (to be read as ‘<code>fg_col</code> on
|
||
<code>bg_col</code>’) sets the foreground and background color for character
|
||
output. The color <code>default</code> is sometimes available (in particular if the
|
||
library is ncurses), specifying the foreground or background color with
|
||
which the terminal started. The color pair <code>default/default</code> is always
|
||
available. To use more than the 8 named colors (red, green, etc.)
|
||
construct the <code>fg_col``/``bg_col</code> pairs where <code>fg_col</code> and <code>bg_col</code> are
|
||
decimal integers, e.g <code>128/200</code>. The maximum color value is 254 if the
|
||
terminal supports 256 colors.</p>
|
||
<p><code>bg</code> overrides the color and other attributes of all characters in the
|
||
window. Its usual use is to set the background initially, but it will
|
||
overwrite the attributes of any characters at the time when it is
|
||
called. In addition to the arguments allowed with <code>attr</code>, an argument
|
||
<code>@``char</code> specifies a character to be shown in otherwise blank areas of
|
||
the window. Owing to limitations of curses this cannot be a multibyte
|
||
character (use of ASCII characters only is recommended). As the
|
||
specified set of attributes override the existing background, turning
|
||
attributes off in the arguments is not useful, though this does not
|
||
cause an error.</p>
|
||
<p>The subcommand <code>scroll</code> can be used with <code>on</code> or <code>off</code> to enabled or
|
||
disable scrolling of a window when the cursor would otherwise move below
|
||
the window due to typing or output. It can also be used with a positive
|
||
or negative integer to scroll the window up or down the given number of
|
||
lines without changing the current cursor position (which therefore
|
||
appears to move in the opposite direction relative to the window). In
|
||
the second case, if scrolling is <code>off</code> it is temporarily turned <code>on</code> to
|
||
allow the window to be scrolled.</p>
|
||
<p>The subcommand <code>input</code> reads a single character from the window without
|
||
echoing it back. If <code>param</code> is supplied the character is assigned to the
|
||
parameter <code>param</code>, else it is assigned to the parameter <code>REPLY</code>.</p>
|
||
<p>If both <code>param</code> and <code>kparam</code> are supplied, the key is read in ‘keypad’
|
||
mode. In this mode special keys such as function keys and arrow keys
|
||
return the name of the key in the parameter <code>kparam</code>. The key names are
|
||
the macros defined in the <code>curses.h</code> or <code>ncurses.h</code> with the prefix
|
||
‘<code>KEY_</code>’ removed; see also the description of the parameter
|
||
<code>zcurses_keycodes</code> below. Other keys cause a value to be set in <code>param</code>
|
||
as before. On a successful return only one of <code>param</code> or <code>kparam</code>
|
||
contains a non-empty string; the other is set to an empty string.</p>
|
||
<p>If <code>mparam</code> is also supplied, <code>input</code> attempts to handle mouse input.
|
||
This is only available with the ncurses library; mouse handling can be
|
||
detected by checking for the exit status of ‘<code>zcurses mouse</code>’ with no
|
||
arguments. If a mouse button is clicked (or double- or triple-clicked,
|
||
or pressed or released with a configurable delay from being clicked)
|
||
then <code>kparam</code> is set to the string <code>MOUSE</code>, and <code>mparam</code> is set to an
|
||
array consisting of the following elements:</p>
|
||
<ul>
|
||
<li>
|
||
<p>-<br />
|
||
An identifier to discriminate different input devices; this is only
|
||
rarely useful.</p>
|
||
</li>
|
||
<li>
|
||
<p>-<br />
|
||
The x, y and z coordinates of the mouse click relative to the full
|
||
screen, as three elements in that order (i.e. the y coordinate is,
|
||
unusually, after the x coordinate). The z coordinate is only
|
||
available for a few unusual input devices and is otherwise set to
|
||
zero.</p>
|
||
</li>
|
||
<li>
|
||
<p>-<br />
|
||
Any events that occurred as separate items; usually there will be
|
||
just one. An event consists of <code>PRESSED</code>, <code>RELEASED</code>, <code>CLICKED</code>,
|
||
<code>DOUBLE_CLICKED</code> or <code>TRIPLE_CLICKED</code> followed immediately (in the
|
||
same element) by the number of the button.</p>
|
||
</li>
|
||
<li>
|
||
<p>-<br />
|
||
If the shift key was pressed, the string <code>SHIFT</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p>-<br />
|
||
If the control key was pressed, the string <code>CTRL</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p>-<br />
|
||
If the alt key was pressed, the string <code>ALT</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<p>Not all mouse events may be passed through to the terminal window; most
|
||
terminal emulators handle some mouse events themselves. Note that the
|
||
ncurses manual implies that using input both with and without mouse
|
||
handling may cause the mouse cursor to appear and disappear.</p>
|
||
<p>The subcommand <code>mouse</code> can be used to configure the use of the mouse.
|
||
There is no window argument; mouse options are global. ‘<code>zcurses mouse</code>’
|
||
with no arguments returns status 0 if mouse handling is possible, else
|
||
status 1. Otherwise, the possible arguments (which may be combined on
|
||
the same command line) are as follows. <code>delay</code> <code>num</code> sets the maximum
|
||
delay in milliseconds between press and release events to be considered
|
||
as a click; the value 0 disables click resolution, and the default is
|
||
one sixth of a second. <code>motion</code> proceeded by an optional ‘<code>+</code>’ (the
|
||
default) or <code>-</code> turns on or off reporting of mouse motion in addition to
|
||
clicks, presses and releases, which are always reported. However, it
|
||
appears reports for mouse motion are not currently implemented.</p>
|
||
<p>The subcommand <code>timeout</code> specifies a timeout value for input from
|
||
<code>targetwin</code>. If <code>intval</code> is negative, ‘<code>zcurses input</code>’ waits
|
||
indefinitely for a character to be typed; this is the default. If
|
||
<code>intval</code> is zero, ‘<code>zcurses input</code>’ returns immediately; if there is
|
||
typeahead it is returned, else no input is done and status 1 is
|
||
returned. If <code>intval</code> is positive, ‘<code>zcurses input</code>’ waits <code>intval</code>
|
||
milliseconds for input and if there is none at the end of that period
|
||
returns status 1.</p>
|
||
<p>The subcommand <code>querychar</code> queries the character at the current cursor
|
||
position. The return values are stored in the array named <code>param</code> if
|
||
supplied, else in the array <code>reply</code>. The first value is the character
|
||
(which may be a multibyte character if the system supports them); the
|
||
second is the color pair in the usual <code>fg_col``/``bg_col</code> notation, or
|
||
<code>0</code> if color is not supported. Any attributes other than color that
|
||
apply to the character, as set with the subcommand <code>attr</code>, appear as
|
||
additional elements.</p>
|
||
<p>The subcommand <code>resize</code> resizes <code>stdscr</code> and all windows to given
|
||
dimensions (windows that stick out from the new dimensions are resized
|
||
down). The underlying curses extension (<code>resize_term call</code>) can be
|
||
unavailable. To verify, zeroes can be used for <code>height</code> and <code>width</code>. If
|
||
the result of the subcommand is <code>0</code>, resize_term is available (<code>2</code>
|
||
otherwise). Tests show that resizing can be normally accomplished by
|
||
calling <code>zcurses end</code> and <code>zcurses refresh</code>. The <code>resize</code> subcommand is
|
||
provided for versatility. Multiple system configurations have been
|
||
checked and <code>zcurses end</code> and <code>zcurses refresh</code> are still needed for
|
||
correct terminal state after resize. To invoke them with <code>resize</code>, use
|
||
<code>endwin</code> argument. Using <code>nosave</code> argument will cause new terminal state
|
||
to not be saved internally by <code>zcurses</code>. This is also provided for
|
||
versatility and should normally be not needed.</p>
|
||
<hr />
|
||
<p><span id="Parameters-4"></span></p>
|
||
<h3 id="2292-parameters"><a class="header" href="#2292-parameters">22.9.2 Parameters</a></h3>
|
||
<p><span id="index-ZCURSES_005fCOLORS"></span></p>
|
||
<p><code>ZCURSES_COLORS</code></p>
|
||
<p>Readonly integer. The maximum number of colors the terminal supports.
|
||
This value is initialised by the curses library and is not available
|
||
until the first time <code>zcurses init</code> is run.</p>
|
||
<p><span id="index-ZCURSES_005fCOLOR_005fPAIRS"></span></p>
|
||
<p><code>ZCURSES_COLOR_PAIRS</code></p>
|
||
<p>Readonly integer. The maximum number of color pairs <code>fg_col``/``bg_col</code>
|
||
that may be defined in ‘<code>zcurses attr</code>’ commands; note this limit
|
||
applies to all color pairs that have been used whether or not they are
|
||
currently active. This value is initialised by the curses library and is
|
||
not available until the first time <code>zcurses init</code> is run.</p>
|
||
<p><span id="index-zcurses_005fattrs"></span></p>
|
||
<p><code>zcurses_attrs</code></p>
|
||
<p>Readonly array. The attributes supported by <code>zsh/curses</code>; available as
|
||
soon as the module is loaded.</p>
|
||
<p><span id="index-zcurses_005fcolors"></span></p>
|
||
<p><code>zcurses_colors</code></p>
|
||
<p>Readonly array. The colors supported by <code>zsh/curses</code>; available as soon
|
||
as the module is loaded.</p>
|
||
<p><span id="index-zcurses_005fkeycodes"></span></p>
|
||
<p><code>zcurses_keycodes</code></p>
|
||
<p>Readonly array. The values that may be returned in the second parameter
|
||
supplied to ‘<code>zcurses input</code>’ in the order in which they are defined
|
||
internally by curses. Not all function keys are listed, only <code>F0</code>;
|
||
curses reserves space for <code>F0</code> up to <code>F63</code>.</p>
|
||
<p><span id="index-zcurses_005fwindows"></span></p>
|
||
<p><code>zcurses_windows</code></p>
|
||
<p>Readonly array. The current list of windows, i.e. all windows that have
|
||
been created with ‘<code>zcurses addwin</code>’ and not removed with ‘<code>zcurses delwin</code>’.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fdatetime-Module"></span>
|
||
<span id="The-zsh_002fdatetime-Module-1"></span></p>
|
||
<h2 id="2210-the-zshdatetime-module"><a class="header" href="#2210-the-zshdatetime-module">22.10 The zsh/datetime Module</a></h2>
|
||
<p>The <code>zsh/datetime</code> module makes available one builtin command:</p>
|
||
<p><span id="index-strftime"></span>
|
||
<span id="index-date-string_002c-printing"></span></p>
|
||
<p><code>strftime</code> [ <code>-s</code> <code>scalar</code> ] <code>format</code> [ <code>epochtime</code> [ <code>nanoseconds</code>
|
||
] ]</p>
|
||
<p><code>strftime</code> <code>-r</code> [ <code>-q</code> ] [ <code>-s</code> <code>scalar</code> ] <code>format</code> <code>timestring</code></p>
|
||
<p>Output the date in the <code>format</code> specified. With no <code>epochtime</code>, the
|
||
current system date/time is used; optionally, <code>epochtime</code> may be used to
|
||
specify the number of seconds since the epoch, and <code>nanoseconds</code> may
|
||
additionally be used to specify the number of nanoseconds past the
|
||
second (otherwise that number is assumed to be 0). See man page
|
||
strftime(3) for details. The zsh extensions described in <a href="Prompt-Expansion.html#Prompt-Expansion">Prompt
|
||
Expansion</a> are also available.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-q</code><br />
|
||
Run quietly; suppress printing of all error messages described
|
||
below. Errors for invalid <code>epochtime</code> values are always printed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-r</code><br />
|
||
With the option <code>-r</code> (reverse), use <code>format</code> to parse the input
|
||
string <code>timestring</code> and output the number of seconds since the epoch
|
||
at which the time occurred. The parsing is implemented by the system
|
||
function <code>strptime</code>; see man page strptime(3). This means that zsh
|
||
format extensions are not available, but for reverse lookup they are
|
||
not required.</p>
|
||
<p>In most implementations of <code>strftime</code> any timezone in the
|
||
<code>timestring</code> is ignored and the local timezone declared by the <code>TZ</code>
|
||
environment variable is used; other parameters are set to zero if
|
||
not present.</p>
|
||
<p>If <code>timestring</code> does not match <code>format</code> the command returns status 1
|
||
and prints an error message. If <code>timestring</code> matches <code>format</code> but
|
||
not all characters in <code>timestring</code> were used, the conversion
|
||
succeeds but also prints an error message.</p>
|
||
<p>If either of the system functions <code>strptime</code> or <code>mktime</code> is not
|
||
available, status 2 is returned and an error message is printed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-s</code> <code>scalar</code><br />
|
||
Assign the date string (or epoch time in seconds if <code>-r</code> is given)
|
||
to <code>scalar</code> instead of printing it.</p>
|
||
</li>
|
||
</ul>
|
||
<p>Note that depending on the system’s declared integral time type,
|
||
<code>strftime</code> may produce incorrect results for epoch times greater than
|
||
2147483647 which corresponds to 2038-01-19 03:14:07 +0000.</p>
|
||
<p>The <code>zsh/datetime</code> module makes available several parameters; all are
|
||
readonly:</p>
|
||
<p><span id="index-EPOCHREALTIME"></span></p>
|
||
<p><code>EPOCHREALTIME</code></p>
|
||
<p>A floating point value representing the number of seconds since the
|
||
epoch. The notional accuracy is to nanoseconds if the <code>clock_gettime</code>
|
||
call is available and to microseconds otherwise, but in practice the
|
||
range of double precision floating point and shell scheduling latencies
|
||
may be significant effects.</p>
|
||
<p><span id="index-EPOCHSECONDS"></span></p>
|
||
<p><code>EPOCHSECONDS</code></p>
|
||
<p>An integer value representing the number of seconds since the epoch.</p>
|
||
<p><span id="index-epochtime"></span></p>
|
||
<p><code>epochtime</code></p>
|
||
<p>An array value containing the number of seconds since the epoch in the
|
||
first element and the remainder of the time since the epoch in
|
||
nanoseconds in the second element. To ensure the two elements are
|
||
consistent the array should be copied or otherwise referenced as a
|
||
single substitution before the values are used. The following idiom may
|
||
be used:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">for secs nsecs in $epochtime; do
|
||
...
|
||
done
|
||
</code></pre>
|
||
</div>
|
||
<hr />
|
||
<p><span id="The-zsh_002fdb_002fgdbm-Module"></span>
|
||
<span id="The-zsh_002fdb_002fgdbm-Module-1"></span></p>
|
||
<h2 id="2211-the-zshdbgdbm-module"><a class="header" href="#2211-the-zshdbgdbm-module">22.11 The zsh/db/gdbm Module</a></h2>
|
||
<p>The <code>zsh/db/gdbm</code> module is used to create "tied" associative arrays
|
||
that interface to database files. If the GDBM interface is not
|
||
available, the builtins defined by this module will report an error.
|
||
This module is also intended as a prototype for creating additional
|
||
database interfaces, so the <code>ztie</code> builtin may move to a more generic
|
||
module in the future.</p>
|
||
<p>The builtins in this module are:</p>
|
||
<p><span id="index-ztie"></span>
|
||
<span id="index-database-tied-array_002c-creating"></span></p>
|
||
<p><code>ztie -d db/gdbm -f</code> <code>filename</code> [ <code>-r</code> ] <code>arrayname</code></p>
|
||
<p>Open the GDBM database identified by <code>filename</code> and, if successful,
|
||
create the associative array <code>arrayname</code> linked to the file. To create a
|
||
local tied array, the parameter must first be declared, so commands
|
||
similar to the following would be executed inside a function scope:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">local -A sampledb
|
||
ztie -d db/gdbm -f sample.gdbm sampledb
|
||
</code></pre>
|
||
</div>
|
||
<p>The <code>-r</code> option opens the database file for reading only, creating a
|
||
parameter with the readonly attribute. Without this option, using
|
||
‘<code>ztie</code>’ on a file for which the user does not have write permission
|
||
is changed in <code>arrayname</code> are immediately written to <code>filename</code>.</p>
|
||
<p>Changes to the file modes <code>filename</code> after it has been opened do not
|
||
alter the state of <code>arrayname</code>, but ‘<code>typeset -r</code> <code>arrayname</code>’ works as
|
||
expected.</p>
|
||
<p><span id="index-zuntie"></span>
|
||
<span id="index-database-tied-array_002c-destroying"></span></p>
|
||
<p><code>zuntie</code> [ <code>-u</code> ] <code>arrayname</code> ...</p>
|
||
<p>Close the GDBM database associated with each <code>arrayname</code> and then unset
|
||
the parameter. The <code>-u</code> option forces an unset of parameters made
|
||
readonly with ‘<code>ztie -r</code>’.</p>
|
||
<p>This happens automatically if the parameter is explicitly unset or its
|
||
local scope (function) ends. Note that a readonly parameter may not be
|
||
explicitly unset, so the only way to unset a global parameter created
|
||
with ‘<code>ztie -r</code>’ is to use ‘<code>zuntie -u</code>’.</p>
|
||
<p><span id="index-zgdbmpath"></span>
|
||
<span id="index-database-file-path_002c-reading"></span></p>
|
||
<p><code>zgdbmpath</code> <code>parametername</code></p>
|
||
<p>Put path to database file assigned to <code>parametername</code> into <code>REPLY</code>
|
||
scalar.</p>
|
||
<p><span id="index-zgdbm_005ftied"></span>
|
||
<span id="index-database-tied-arrays_002c-enumerating"></span></p>
|
||
<p><code>zgdbm_tied</code></p>
|
||
<p>Array holding names of all tied parameters.</p>
|
||
<p>The fields of an associative array tied to GDBM are neither cached nor
|
||
otherwise stored in memory, they are read from or written to the
|
||
database on each reference. Thus, for example, the values in a readonly
|
||
array may be changed by a second writer of the same database file.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fdeltochar-Module"></span>
|
||
<span id="The-zsh_002fdeltochar-Module-1"></span></p>
|
||
<h2 id="2212-the-zshdeltochar-module"><a class="header" href="#2212-the-zshdeltochar-module">22.12 The zsh/deltochar Module</a></h2>
|
||
<p>The <code>zsh/deltochar</code> module makes available two ZLE functions:</p>
|
||
<p><span id="index-delete_002dto_002dchar"></span></p>
|
||
<p><code>delete-to-char</code></p>
|
||
<p>Read a character from the keyboard, and delete from the cursor position
|
||
up to and including the next (or, with repeat count <code>n</code>, the <code>n</code>th)
|
||
instance of that character. Negative repeat counts mean delete
|
||
backwards.</p>
|
||
<p><span id="index-zap_002dto_002dchar"></span></p>
|
||
<p><code>zap-to-char</code></p>
|
||
<p>This behaves like <code>delete-to-char</code>, except that the final occurrence of
|
||
the character itself is not deleted.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fexample-Module"></span>
|
||
<span id="The-zsh_002fexample-Module-1"></span></p>
|
||
<h2 id="2213-the-zshexample-module"><a class="header" href="#2213-the-zshexample-module">22.13 The zsh/example Module</a></h2>
|
||
<p>The <code>zsh/example</code> module makes available one builtin command:</p>
|
||
<p><span id="index-example"></span>
|
||
<span id="index-modules_002c-example"></span>
|
||
<span id="index-modules_002c-writing"></span>
|
||
<span id="index-writing-modules"></span></p>
|
||
<p><code>example</code> [ <code>-flags</code> ] [ <code>args</code> ... ]</p>
|
||
<p>Displays the flags and arguments it is invoked with.</p>
|
||
<p>The purpose of the module is to serve as an example of how to write a
|
||
module.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002ffiles-Module"></span>
|
||
<span id="The-zsh_002ffiles-Module-1"></span></p>
|
||
<h2 id="2214-the-zshfiles-module"><a class="header" href="#2214-the-zshfiles-module">22.14 The zsh/files Module</a></h2>
|
||
<p><span id="index-files_002c-manipulating"></span></p>
|
||
<p>The <code>zsh/files</code> module makes available some common commands for file
|
||
manipulation as builtins; these commands are probably not needed for
|
||
many normal situations but can be useful in emergency recovery
|
||
situations with constrained resources. The commands do not implement all
|
||
features now required by relevant standards committees.</p>
|
||
<p>For all commands, a variant beginning <code>zf_</code> is also available and loaded
|
||
automatically. Using the features capability of zmodload will let you
|
||
load only those names you want. Note that it’s possible to load only the
|
||
builtins with zsh-specific names using the following command:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zmodload -m -F zsh/files b:zf_\*
|
||
</code></pre>
|
||
</div>
|
||
<p>The commands loaded by default are:</p>
|
||
<p><span id="index-chgrp"></span></p>
|
||
<p><code>chgrp</code> [ <code>-hRs</code> ] <code>group</code> <code>filename</code> ...</p>
|
||
<p>Changes group of files specified. This is equivalent to <code>chown</code> with a
|
||
<code>user-spec</code> argument of ‘<code>:``group</code>’.</p>
|
||
<p><span id="index-chmod"></span></p>
|
||
<p><code>chmod</code> [ <code>-Rs</code> ] <code>mode</code> <code>filename</code> ...</p>
|
||
<p>Changes mode of files specified.</p>
|
||
<p>The specified <code>mode</code> must be in octal.</p>
|
||
<p>The <code>-R</code> option causes <code>chmod</code> to recursively descend into directories,
|
||
changing the mode of all files in the directory after changing the mode
|
||
of the directory itself.</p>
|
||
<p>The <code>-s</code> option is a zsh extension to <code>chmod</code> functionality. It enables
|
||
paranoid behaviour, intended to avoid security problems involving a
|
||
<code>chmod</code> being tricked into affecting files other than the ones intended.
|
||
It will refuse to follow symbolic links, so that (for example)
|
||
‘‘<code>chmod 600 /tmp/foo/passwd</code>’’ can’t accidentally chmod
|
||
<code>/etc/passwd</code> if <code>/tmp/foo</code> happens to be a link to <code>/etc</code>. It will also
|
||
check where it is after leaving directories, so that a recursive chmod
|
||
of a deep directory tree can’t end up recursively chmoding <code>/usr</code> as a
|
||
result of directories being moved up the tree.</p>
|
||
<p><span id="index-chown"></span></p>
|
||
<p><code>chown</code> [ <code>-hRs</code> ] <code>user-spec</code> <code>filename</code> ...</p>
|
||
<p>Changes ownership and group of files specified.</p>
|
||
<p>The <code>user-spec</code> can be in four forms:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>user</code><br />
|
||
change owner to <code>user</code>; do not change group</p>
|
||
</li>
|
||
<li>
|
||
<p><code>user``::</code><br />
|
||
change owner to <code>user</code>; do not change group</p>
|
||
</li>
|
||
<li>
|
||
<p><code>user``:</code><br />
|
||
change owner to <code>user</code>; change group to <code>user</code>’s primary group</p>
|
||
</li>
|
||
<li>
|
||
<p><code>user``:``group</code><br />
|
||
change owner to <code>user</code>; change group to <code>group</code></p>
|
||
</li>
|
||
<li>
|
||
<p><code>:``group</code><br />
|
||
do not change owner; change group to <code>group</code></p>
|
||
</li>
|
||
</ul>
|
||
<p>In each case, the ‘<code>:</code>’ may instead be a ‘<code>.</code>’. The rule is that if
|
||
there is a ‘<code>:</code>’ then the separator is ‘<code>:</code>’, otherwise if there is a
|
||
‘<code>.</code>’ then the separator is ‘<code>.</code>’, otherwise there is no separator.</p>
|
||
<p>Each of <code>user</code> and <code>group</code> may be either a username (or group name, as
|
||
appropriate) or a decimal user ID (group ID). Interpretation as a name
|
||
takes precedence, if there is an all-numeric username (or group name).</p>
|
||
<p>If the target is a symbolic link, the <code>-h</code> option causes <code>chown</code> to set
|
||
the ownership of the link instead of its target.</p>
|
||
<p>The <code>-R</code> option causes <code>chown</code> to recursively descend into directories,
|
||
changing the ownership of all files in the directory after changing the
|
||
ownership of the directory itself.</p>
|
||
<p>The <code>-s</code> option is a zsh extension to <code>chown</code> functionality. It enables
|
||
paranoid behaviour, intended to avoid security problems involving a
|
||
<code>chown</code> being tricked into affecting files other than the ones intended.
|
||
It will refuse to follow symbolic links, so that (for example) ‘‘<code>chown luser /tmp/foo/passwd</code>’’ can’t accidentally chown <code>/etc/passwd</code> if
|
||
<code>/tmp/foo</code> happens to be a link to <code>/etc</code>. It will also check where it
|
||
is after leaving directories, so that a recursive chown of a deep
|
||
directory tree can’t end up recursively chowning <code>/usr</code> as a result of
|
||
directories being moved up the tree.</p>
|
||
<p><span id="index-ln"></span></p>
|
||
<p><code>ln</code> [ <code>-dfhins</code> ] <code>filename</code> <code>dest</code></p>
|
||
<p><code>ln</code> [ <code>-dfhins</code> ] <code>filename</code> ... <code>dir</code></p>
|
||
<p>Creates hard (or, with <code>-s</code>, symbolic) links. In the first form, the
|
||
specified <code>dest</code>ination is created, as a link to the specified
|
||
<code>filename</code>. In the second form, each of the <code>filename</code>s is taken in
|
||
turn, and linked to a pathname in the specified <code>dir</code>ectory that has the
|
||
same last pathname component.</p>
|
||
<p>Normally, <code>ln</code> will not attempt to create hard links to directories.
|
||
This check can be overridden using the <code>-d</code> option. Typically only the
|
||
super-user can actually succeed in creating hard links to directories.
|
||
This does not apply to symbolic links in any case.</p>
|
||
<p>By default, existing files cannot be replaced by links. The <code>-i</code> option
|
||
causes the user to be queried about replacing existing files. The <code>-f</code>
|
||
option causes existing files to be silently deleted, without querying.
|
||
<code>-f</code> takes precedence.</p>
|
||
<p>The <code>-h</code> and <code>-n</code> options are identical and both exist for
|
||
compatibility; either one indicates that if the target is a symlink then
|
||
it should not be dereferenced. Typically this is used in combination
|
||
with <code>-sf</code> so that if an existing link points to a directory then it
|
||
will be removed, instead of followed. If this option is used with
|
||
multiple filenames and the target is a symbolic link pointing to a
|
||
directory then the result is an error.</p>
|
||
<p><span id="index-mkdir"></span></p>
|
||
<p><code>mkdir</code> [ <code>-p</code> ] [ <code>-m</code> <code>mode</code> ] <code>dir</code> ...</p>
|
||
<p>Creates directories. With the <code>-p</code> option, non-existing parent
|
||
directories are first created if necessary, and there will be no
|
||
complaint if the directory already exists. The <code>-m</code> option can be used
|
||
to specify (in octal) a set of file permissions for the created
|
||
directories, otherwise mode 777 modified by the current <code>umask</code> (see man
|
||
page umask(2)) is used.</p>
|
||
<p><span id="index-mv"></span></p>
|
||
<p><code>mv</code> [ <code>-fi</code> ] <code>filename</code> <code>dest</code></p>
|
||
<p><code>mv</code> [ <code>-fi</code> ] <code>filename</code> ... <code>dir</code></p>
|
||
<p>Moves files. In the first form, the specified <code>filename</code> is moved to the
|
||
specified <code>dest</code>ination. In the second form, each of the <code>filename</code>s is
|
||
taken in turn, and moved to a pathname in the specified <code>dir</code>ectory that
|
||
has the same last pathname component.</p>
|
||
<p>By default, the user will be queried before replacing any file removed.
|
||
The <code>-i</code> option causes the user to be queried about replacing any
|
||
existing files. The <code>-f</code> option causes any existing files to be silently
|
||
deleted, without querying. <code>-f</code> takes precedence.</p>
|
||
<p>Note that this <code>mv</code> will not move files across devices. Historical
|
||
versions of <code>mv</code>, when actual renaming is impossible, fall back on
|
||
copying and removing files; if this behaviour is desired, use <code>cp</code> and
|
||
<code>rm</code> manually. This may change in a future version.</p>
|
||
<p><span id="index-rm"></span></p>
|
||
<p><code>rm</code> [ <code>-dfiRrs</code> ] <code>filename</code> ...</p>
|
||
<p>Removes files and directories specified.</p>
|
||
<p>Normally, <code>rm</code> will not remove directories (except with the <code>-R</code> or <code>-r</code>
|
||
options). The <code>-d</code> option causes <code>rm</code> to try removing directories with
|
||
<code>unlink</code> (see man page unlink(2)), the same method used for files.
|
||
Typically only the super-user can actually succeed in unlinking
|
||
directories in this way. <code>-d</code> takes precedence over <code>-R</code> and <code>-r</code>.</p>
|
||
<p>By default, the user will be queried before removing any file removed.
|
||
The <code>-i</code> option causes the user to be queried about removing any files.
|
||
The <code>-f</code> option causes files to be silently deleted, without querying,
|
||
and suppresses all error indications. <code>-f</code> takes precedence.</p>
|
||
<p>The <code>-R</code> and <code>-r</code> options cause <code>rm</code> to recursively descend into
|
||
directories, deleting all files in the directory before removing the
|
||
directory with the <code>rmdir</code> system call (see man page rmdir(2)).</p>
|
||
<p>The <code>-s</code> option is a zsh extension to <code>rm</code> functionality. It enables
|
||
paranoid behaviour, intended to avoid common security problems involving
|
||
a root-run <code>rm</code> being tricked into removing files other than the ones
|
||
intended. It will refuse to follow symbolic links, so that (for example)
|
||
‘‘<code>rm /tmp/foo/passwd</code>’’ can’t accidentally remove <code>/etc/passwd</code> if
|
||
<code>/tmp/foo</code> happens to be a link to <code>/etc</code>. It will also check where it
|
||
is after leaving directories, so that a recursive removal of a deep
|
||
directory tree can’t end up recursively removing <code>/usr</code> as a result of
|
||
directories being moved up the tree.</p>
|
||
<p><span id="index-rmdir"></span></p>
|
||
<p><code>rmdir</code> <code>dir</code> ...</p>
|
||
<p>Removes empty directories specified.</p>
|
||
<p><span id="index-sync"></span></p>
|
||
<p><code>sync</code></p>
|
||
<p>Calls the system call of the same name (see man page sync(2)), which
|
||
flushes dirty buffers to disk. It might return before the I/O has
|
||
actually been completed.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002flanginfo-Module"></span>
|
||
<span id="The-zsh_002flanginfo-Module-1"></span></p>
|
||
<h2 id="2215-the-zshlanginfo-module"><a class="header" href="#2215-the-zshlanginfo-module">22.15 The zsh/langinfo Module</a></h2>
|
||
<p>The <code>zsh/langinfo</code> module makes available one parameter:</p>
|
||
<p><span id="index-langinfo"></span></p>
|
||
<p><code>langinfo</code></p>
|
||
<p>An associative array that maps langinfo elements to their values.</p>
|
||
<p>Your implementation may support a number of the following keys:</p>
|
||
<p><code>CODESET</code>, <code>D_T_FMT</code>, <code>D_FMT</code>, <code>T_FMT</code>, <code>RADIXCHAR</code>, <code>THOUSEP</code>,
|
||
<code>YESEXPR</code>, <code>NOEXPR</code>, <code>CRNCYSTR</code>, <code>ABDAY_{1..7}</code>, <code>DAY_{1..7}</code>,
|
||
<code>ABMON_{1..12}</code>, <code>MON_{1..12}</code>, <code>T_FMT_AMPM</code>, <code>AM_STR</code>, <code>PM_STR</code>, <code>ERA</code>,
|
||
<code>ERA_D_FMT</code>, <code>ERA_D_T_FMT</code>, <code>ERA_T_FMT</code>, <code>ALT_DIGITS</code></p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fmapfile-Module"></span>
|
||
<span id="The-zsh_002fmapfile-Module-1"></span></p>
|
||
<h2 id="2216-the-zshmapfile-module"><a class="header" href="#2216-the-zshmapfile-module">22.16 The zsh/mapfile Module</a></h2>
|
||
<p><span id="index-parameter_002c-file-access-via"></span></p>
|
||
<p>The <code>zsh/mapfile</code> module provides one special associative array
|
||
parameter of the same name.</p>
|
||
<p><span id="index-mapfile"></span></p>
|
||
<p><code>mapfile</code></p>
|
||
<p>This associative array takes as keys the names of files; the resulting
|
||
value is the content of the file. The value is treated identically to
|
||
any other text coming from a parameter. The value may also be assigned
|
||
to, in which case the file in question is written (whether or not it
|
||
originally existed); or an element may be unset, which will delete the
|
||
file in question. For example, ‘<code>vared mapfile[myfile]</code>’ works as
|
||
expected, editing the file ‘<code>myfile</code>’.</p>
|
||
<p>When the array is accessed as a whole, the keys are the names of files
|
||
in the current directory, and the values are empty (to save a huge
|
||
overhead in memory). Thus <code>${(k)mapfile}</code> has the same effect as the
|
||
glob operator <code>*(D)</code>, since files beginning with a dot are not special.
|
||
Care must be taken with expressions such as <code>rm ${(k)mapfile}</code>, which
|
||
will delete every file in the current directory without the usual ‘<code>rm *</code>’ test.</p>
|
||
<p>The parameter <code>mapfile</code> may be made read-only; in that case, files
|
||
referenced may not be written or deleted.</p>
|
||
<p>A file may conveniently be read into an array as one line per element
|
||
with the form ‘<code>array``=("${(f@)mapfile[``filename``]}")</code>’. The double
|
||
quotes and the ‘<code>@</code>’ are necessary to prevent empty lines from being
|
||
removed. Note that if the file ends with a newline, the shell will split
|
||
on the final newline, generating an additional empty field; this can be
|
||
suppressed by using
|
||
‘<code>array``=("${(f@)${mapfile[``filename``]%$’\n’}}")</code>’.</p>
|
||
<hr />
|
||
<p><span id="Limitations"></span></p>
|
||
<h3 id="22161-limitations"><a class="header" href="#22161-limitations">22.16.1 Limitations</a></h3>
|
||
<p>Although reading and writing of the file in question is efficiently
|
||
handled, zsh’s internal memory management may be arbitrarily baroque;
|
||
however, <code>mapfile</code> is usually very much more efficient than anything
|
||
involving a loop. Note in particular that the whole contents of the file
|
||
will always reside physically in memory when accessed (possibly multiple
|
||
times, due to standard parameter substitution operations). In
|
||
particular, this means handling of sufficiently long files (greater than
|
||
the machine’s swap space, or than the range of the pointer type) will be
|
||
incorrect.</p>
|
||
<p>No errors are printed or flagged for non-existent, unreadable, or
|
||
execution hierarchy to make this convenient.</p>
|
||
<p>It is unfortunate that the mechanism for loading modules does not yet
|
||
allow the user to specify the name of the shell parameter to be given
|
||
the special behaviour.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fmathfunc-Module"></span>
|
||
<span id="The-zsh_002fmathfunc-Module-1"></span></p>
|
||
<h2 id="2217-the-zshmathfunc-module"><a class="header" href="#2217-the-zshmathfunc-module">22.17 The zsh/mathfunc Module</a></h2>
|
||
<p><span id="index-functions_002c-mathematical"></span>
|
||
<span id="index-mathematical-functions"></span></p>
|
||
<p>The <code>zsh/mathfunc</code> module provides standard mathematical functions for
|
||
use when evaluating mathematical formulae. The syntax agrees with normal
|
||
C and FORTRAN conventions, for example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">(( f = sin(0.3) ))
|
||
</code></pre>
|
||
</div>
|
||
<p>assigns the sine of 0.3 to the parameter f.</p>
|
||
<p>Most functions take floating point arguments and return a floating point
|
||
value. However, any necessary conversions from or to integer type will
|
||
be performed automatically by the shell. Apart from <code>atan</code> with a second
|
||
argument and the <code>abs</code>, <code>int</code> and <code>float</code> functions, all functions
|
||
behave as noted in the manual page for the corresponding C function,
|
||
except that any arguments out of range for the function in question will
|
||
be detected by the shell and an error reported.</p>
|
||
<p>The following functions take a single floating point argument: <code>acos</code>,
|
||
<code>acosh</code>, <code>asin</code>, <code>asinh</code>, <code>atan</code>, <code>atanh</code>, <code>cbrt</code>, <code>ceil</code>, <code>cos</code>,
|
||
<code>cosh</code>, <code>erf</code>, <code>erfc</code>, <code>exp</code>, <code>expm1</code>, <code>fabs</code>, <code>floor</code>, <code>gamma</code>, <code>j0</code>,
|
||
<code>j1</code>, <code>lgamma</code>, <code>log</code>, <code>log10</code>, <code>log1p</code>, <code>log2</code>, <code>logb</code>, <code>sin</code>, <code>sinh</code>,
|
||
<code>sqrt</code>, <code>tan</code>, <code>tanh</code>, <code>y0</code>, <code>y1</code>. The <code>atan</code> function can optionally
|
||
take a second argument, in which case it behaves like the C function
|
||
<code>atan2</code>. The <code>ilogb</code> function takes a single floating point argument,
|
||
but returns an integer.</p>
|
||
<p>The function <code>signgam</code> takes no arguments, and returns an integer, which
|
||
is the C variable of the same name, as described in man page gamma(3).
|
||
Note that it is therefore only useful immediately after a call to
|
||
<code>gamma</code> or <code>lgamma</code>. Note also that ‘<code>signgam()</code>’ and ‘<code>signgam</code>’ are
|
||
distinct expressions.</p>
|
||
<p>The functions <code>min</code>, <code>max</code>, and <code>sum</code> are defined not in this module but
|
||
in the <code>zmathfunc</code> autoloadable function, described in <a href="User-Contributions.html#Mathematical-Functions">Mathematical
|
||
Functions</a>.</p>
|
||
<p>The following functions take two floating point arguments: <code>copysign</code>,
|
||
<code>fmod</code>, <code>hypot</code>, <code>nextafter</code>.</p>
|
||
<p>The following take an integer first argument and a floating point second
|
||
argument: <code>jn</code>, <code>yn</code>.</p>
|
||
<p>The following take a floating point first argument and an integer second
|
||
argument: <code>ldexp</code>, <code>scalb</code>.</p>
|
||
<p>The function <code>abs</code> does not convert the type of its single argument; it
|
||
returns the absolute value of either a floating point number or an
|
||
integer. The functions <code>float</code> and <code>int</code> convert their arguments into a
|
||
floating point or integer value (by truncation) respectively.</p>
|
||
<p>Note that the C <code>pow</code> function is available in ordinary math evaluation
|
||
as the ‘<code>**</code>’ operator and is not provided here.</p>
|
||
<p>The function <code>rand48</code> is available if your system’s mathematical library
|
||
has the function <code>erand48(3)</code>. It returns a pseudo-random floating point
|
||
number between 0 and 1. It takes a single string optional argument.</p>
|
||
<p>If the argument is not present, the random number seed is initialised by
|
||
three calls to the <code>rand(3)</code> function — this produces the same random
|
||
numbers as the next three values of <code>$RANDOM</code>.</p>
|
||
<p>If the argument is present, it gives the name of a scalar parameter
|
||
where the current random number seed will be stored. On the first call,
|
||
the value must contain at least twelve hexadecimal digits (the remainder
|
||
of the string is ignored), or the seed will be initialised in the same
|
||
manner as for a call to <code>rand48</code> with no argument. Subsequent calls to
|
||
<code>rand48</code>(<code>param</code>) will then maintain the seed in the parameter <code>param</code>
|
||
as a string of twelve hexadecimal digits, with no base signifier. The
|
||
random number sequences for different parameters are completely
|
||
independent, and are also independent from that used by calls to
|
||
<code>rand48</code> with no argument.</p>
|
||
<p>For example, consider</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">print $(( rand48(seed) ))
|
||
print $(( rand48() ))
|
||
print $(( rand48(seed) ))
|
||
</code></pre>
|
||
</div>
|
||
<p>Assuming <code>$seed</code> does not exist, it will be initialised by the first
|
||
call. In the second call, the default seed is initialised; note,
|
||
however, that because of the properties of <code>rand()</code> there is a
|
||
correlation between the seeds used for the two initialisations, so for
|
||
more secure uses, you should generate your own 12-byte seed. The third
|
||
call returns to the same sequence of random numbers used in the first
|
||
call, unaffected by the intervening <code>rand48()</code>.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fnearcolor-Module"></span>
|
||
<span id="The-zsh_002fnearcolor-Module-1"></span></p>
|
||
<h2 id="2218-the-zshnearcolor-module"><a class="header" href="#2218-the-zshnearcolor-module">22.18 The zsh/nearcolor Module</a></h2>
|
||
<p>The <code>zsh/nearcolor</code> module replaces colours specified as hex triplets
|
||
with the nearest colour in the 88 or 256 colour palettes that are widely
|
||
used by terminal emulators. By default, 24-bit true colour escape codes
|
||
are generated when colours are specified using hex triplets. These are
|
||
not supported by all terminals. The purpose of this module is to make it
|
||
easier to define colour preferences in a form that can work across a
|
||
range of terminal emulators.</p>
|
||
<p>Aside from the default colour, the ANSI standard for terminal escape
|
||
codes provides for eight colours. The bright attribute brings this to
|
||
sixteen. These basic colours are commonly used in terminal applications
|
||
due to being widely supported. Expanded 88 and 256 colour palettes are
|
||
also common and, while the first sixteen colours vary somewhat between
|
||
terminals and configurations, these add a generally consistent and</p>
|
||
<p>In order to use the <code>zsh/nearcolor</code> module, it only needs to be loaded.
|
||
Thereafter, whenever a colour is specified using a hex triplet, it will
|
||
be compared against each of the available colours and the closest will
|
||
be selected. The first sixteen colours are never matched in</p>
|
||
<p>It isn’t possible to reliably detect support for true colour in the
|
||
terminal emulator. It is therefore recommended to be selective in
|
||
loading the <code>zsh/nearcolor</code> module. For example, the following checks
|
||
the <code>COLORTERM</code> environment variable:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">[[ $COLORTERM = *(24bit|truecolor)* ]] || zmodload zsh/nearcolor
|
||
</code></pre>
|
||
</div>
|
||
<p>Note that some terminals accept the true color escape codes but map them
|
||
internally to a more limited palette in a similar manner to the
|
||
<code>zsh/nearcolor</code> module.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fnewuser-Module"></span>
|
||
<span id="The-zsh_002fnewuser-Module-1"></span></p>
|
||
<h2 id="2219-the-zshnewuser-module"><a class="header" href="#2219-the-zshnewuser-module">22.19 The zsh/newuser Module</a></h2>
|
||
<p>The <code>zsh/newuser</code> module is loaded at boot if it is available, the <code>RCS</code>
|
||
option is set, and the <code>PRIVILEGED</code> option is not set (all three are
|
||
true by default). This takes place immediately after commands in the
|
||
global <code>zshenv</code> file (typically <code>/etc/zshenv</code>), if any, have been
|
||
executed. If the module is not available it is silently ignored by the
|
||
shell; the module may safely be removed from <code>$MODULE_PATH</code> by the
|
||
administrator if it is not required.</p>
|
||
<p>On loading, the module tests if any of the start-up files <code>.zshenv</code>,
|
||
<code>.zprofile</code>, <code>.zshrc</code> or <code>.zlogin</code> exist in the directory given by the
|
||
environment variable <code>ZDOTDIR</code>, or the user’s home directory if that is
|
||
not set. The test is not performed and the module halts processing if
|
||
the shell was in an emulation mode (i.e. had been invoked as some other
|
||
shell than zsh).</p>
|
||
<p>If none of the start-up files were found, the module then looks for the
|
||
file <code>newuser</code> first in a sitewide directory, usually the parent
|
||
directory of the <code>site-functions</code> directory, and if that is not found
|
||
the module searches in a version-specific directory, usually the parent
|
||
of the <code>functions</code> directory containing version-specific functions.
|
||
(These directories can be configured when zsh is built using the
|
||
<code>–enable-site-scriptdir=``dir</code> and <code>–enable-scriptdir=``dir</code> flags to
|
||
<code>configure</code>, respectively; the defaults are <code>prefix``/share/zsh</code> and
|
||
<code>prefix``/share/zsh/$ZSH_VERSION</code> where the default <code>prefix</code> is
|
||
<code>/usr/local</code>.)</p>
|
||
<p>If the file <code>newuser</code> is found, it is then sourced in the same manner as
|
||
a start-up file. The file is expected to contain code to install
|
||
start-up files for the user, however any valid shell code will be
|
||
executed.</p>
|
||
<p>The <code>zsh/newuser</code> module is then unconditionally unloaded.</p>
|
||
<p>Note that it is possible to achieve exactly the same effect as the
|
||
<code>zsh/newuser</code> module by adding code to <code>/etc/zshenv</code>. The module exists
|
||
simply to allow the shell to make arrangements for new users without the
|
||
need for intervention by package maintainers and system administrators.</p>
|
||
<p>The script supplied with the module invokes the shell function
|
||
<code>zsh-newuser-install</code>. This may be invoked directly by the user even if
|
||
the <code>zsh/newuser</code> module is disabled. Note, however, that if the module
|
||
is not installed the function will not be installed either. The function
|
||
is documented in <a href="User-Contributions.html#User-Configuration-Functions">User Configuration
|
||
Functions</a>.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fparameter-Module"></span>
|
||
<span id="The-zsh_002fparameter-Module-1"></span></p>
|
||
<h2 id="2220-the-zshparameter-module"><a class="header" href="#2220-the-zshparameter-module">22.20 The zsh/parameter Module</a></h2>
|
||
<p><span id="index-parameters_002c-special-1"></span></p>
|
||
<p>The <code>zsh/parameter</code> module gives access to some of the internal hash</p>
|
||
<p><span id="index-options-1"></span></p>
|
||
<p><code>options</code></p>
|
||
<p>The keys for this associative array are the names of the options that
|
||
can be set and unset using the <code>setopt</code> and <code>unsetopt</code> builtins. The
|
||
value of each key is either the string <code>on</code> if the option is currently
|
||
set, or the string <code>off</code> if the option is unset. Setting a key to one of
|
||
these strings is like setting or unsetting the option, respectively.
|
||
Unsetting a key in this array is like setting it to the value <code>off</code>.</p>
|
||
<p><span id="index-commands"></span></p>
|
||
<p><code>commands</code></p>
|
||
<p>names of external commands, the values are the pathnames of the files
|
||
that would be executed when the command would be invoked. Setting a with
|
||
the <code>hash</code> builtin. Unsetting a key as in ‘<code>unset "commands[foo]"</code>’
|
||
removes the entry for the given key from the command</p>
|
||
<p><span id="index-functions-2"></span></p>
|
||
<p><code>functions</code></p>
|
||
<p>This associative array maps names of enabled functions to their
|
||
definitions. Setting a key in it is like defining a function with the
|
||
name given by the key and the body given by the value. Unsetting a key
|
||
removes the definition for the function named by the key.</p>
|
||
<p><span id="index-dis_005ffunctions"></span></p>
|
||
<p><code>dis_functions</code></p>
|
||
<p>Like <code>functions</code> but for disabled functions.</p>
|
||
<p><span id="index-functions_005fsource"></span></p>
|
||
<p><code>functions_source</code></p>
|
||
<p>This readonly associative array maps names of enabled functions to the
|
||
name of the file containing the source of the function.</p>
|
||
<p>For an autoloaded function that has already been loaded, or marked for
|
||
autoload with an absolute path, or that has had its path resolved with
|
||
‘<code>functions -r</code>’, this is the file found for autoloading, resolved to
|
||
an absolute path.</p>
|
||
<p>For a function defined within the body of a script or sourced file, this
|
||
is the name of that file. In this case, this is the exact path
|
||
originally used to that file, which may be a relative path.</p>
|
||
<p>For any other function, including any defined at an interactive prompt
|
||
or an autoload function whose path has not yet been resolved, this is
|
||
the empty string. However, the hash element is reported as defined just
|
||
so long as the function is present: the keys to this hash are the same
|
||
as those to <code>$functions</code>.</p>
|
||
<p><span id="index-dis_005ffunctions_005fsource"></span></p>
|
||
<p><code>dis_functions_source</code></p>
|
||
<p>Like <code>functions_source</code> but for disabled functions.</p>
|
||
<p><span id="index-builtins"></span></p>
|
||
<p><code>builtins</code></p>
|
||
<p>This associative array gives information about the builtin commands
|
||
currently enabled. The keys are the names of the builtin commands and
|
||
the values are either ‘<code>undefined</code>’ for builtin commands that will
|
||
automatically be loaded from a module if invoked or ‘<code>defined</code>’ for
|
||
builtin commands that are already loaded.</p>
|
||
<p><span id="index-dis_005fbuiltins"></span></p>
|
||
<p><code>dis_builtins</code></p>
|
||
<p>Like <code>builtins</code> but for disabled builtin commands.</p>
|
||
<p><span id="index-reswords"></span></p>
|
||
<p><code>reswords</code></p>
|
||
<p>This array contains the enabled reserved words.</p>
|
||
<p><span id="index-dis_005freswords"></span></p>
|
||
<p><code>dis_reswords</code></p>
|
||
<p>Like <code>reswords</code> but for disabled reserved words.</p>
|
||
<p><span id="index-patchars"></span></p>
|
||
<p><code>patchars</code></p>
|
||
<p>This array contains the enabled pattern characters.</p>
|
||
<p><span id="index-dis_005fpatchars"></span></p>
|
||
<p><code>dis_patchars</code></p>
|
||
<p>Like <code>patchars</code> but for disabled pattern characters.</p>
|
||
<p><span id="index-aliases"></span></p>
|
||
<p><code>aliases</code></p>
|
||
<p>This maps the names of the regular aliases currently enabled to their
|
||
expansions.</p>
|
||
<p><span id="index-dis_005faliases"></span></p>
|
||
<p><code>dis_aliases</code></p>
|
||
<p>Like <code>aliases</code> but for disabled regular aliases.</p>
|
||
<p><span id="index-galiases"></span></p>
|
||
<p><code>galiases</code></p>
|
||
<p>Like <code>aliases</code>, but for global aliases.</p>
|
||
<p><span id="index-dis_005fgaliases"></span></p>
|
||
<p><code>dis_galiases</code></p>
|
||
<p>Like <code>galiases</code> but for disabled global aliases.</p>
|
||
<p><span id="index-saliases"></span></p>
|
||
<p><code>saliases</code></p>
|
||
<p>Like <code>raliases</code>, but for suffix aliases.</p>
|
||
<p><span id="index-dis_005fsaliases"></span></p>
|
||
<p><code>dis_saliases</code></p>
|
||
<p>Like <code>saliases</code> but for disabled suffix aliases.</p>
|
||
<p><span id="index-parameters-1"></span></p>
|
||
<p><code>parameters</code></p>
|
||
<p>The keys in this associative array are the names of the parameters
|
||
currently defined. The values are strings describing the type of the
|
||
parameter, in the same format used by the <code>t</code> parameter flag, see
|
||
<a href="Expansion.html#Parameter-Expansion">Parameter Expansion</a> . Setting or
|
||
unsetting keys in this array is not possible.</p>
|
||
<p><span id="index-modules-1"></span></p>
|
||
<p><code>modules</code></p>
|
||
<p>An associative array giving information about modules. The keys are the
|
||
names of the modules loaded, registered to be autoloaded, or aliased.
|
||
The value says which state the named module is in and is one of the
|
||
strings ‘<code>loaded</code>’, ‘<code>autoloaded</code>’, or ‘<code>alias:``name</code>’, where <code>name</code> is
|
||
the name the module is aliased to.</p>
|
||
<p>Setting or unsetting keys in this array is not possible.</p>
|
||
<p><span id="index-dirstack"></span></p>
|
||
<p><code>dirstack</code></p>
|
||
<p>A normal array holding the elements of the directory stack. Note that
|
||
the output of the <code>dirs</code> builtin command includes one more directory,
|
||
the current working directory.</p>
|
||
<p><span id="index-history-2"></span></p>
|
||
<p><code>history</code></p>
|
||
<p>This associative array maps history event numbers to the full history
|
||
lines. Although it is presented as an associative array, the array of
|
||
all values (<code>${history[@]}</code>) is guaranteed to be returned in order from
|
||
most recent to oldest history event, that is, by decreasing history
|
||
event number.</p>
|
||
<p><span id="index-historywords"></span></p>
|
||
<p><code>historywords</code></p>
|
||
<p>A special array containing the words stored in the history. These also
|
||
appear in most to least recent order.</p>
|
||
<p><span id="index-jobdirs"></span></p>
|
||
<p><code>jobdirs</code></p>
|
||
<p>This associative array maps job numbers to the directories from which
|
||
the job was started (which may not be the current directory of the job).</p>
|
||
<p>The keys of the associative arrays are usually valid job numbers, and
|
||
these are the values output with, for example, <code>${(k)jobdirs}</code>.
|
||
Non-numeric job references may be used when looking up a value; for
|
||
example, <code>${jobdirs[%+]}</code> refers to the current job.</p>
|
||
<p><span id="index-jobtexts"></span></p>
|
||
<p><code>jobtexts</code></p>
|
||
<p>This associative array maps job numbers to the texts of the command
|
||
lines that were used to start the jobs.</p>
|
||
<p>Handling of the keys of the associative array is as described for
|
||
<code>jobdirs</code> above.</p>
|
||
<p><span id="index-jobstates"></span></p>
|
||
<p><code>jobstates</code></p>
|
||
<p>This associative array gives information about the states of the jobs
|
||
currently known. The keys are the job numbers and the values are strings
|
||
of the form ‘<code>job-state``:``mark``:``pid``=``state</code>...’. The <code>job-state</code>
|
||
gives the state the whole job is currently in, one of ‘<code>running</code>’,
|
||
‘<code>suspended</code>’, or ‘<code>done</code>’. The <code>mark</code> is ‘<code>+</code>’ for the current job,
|
||
‘<code>-</code>’ for the previous job and empty otherwise. This is followed by
|
||
one ‘<code>:``pid``=``state</code>’ for every process in the job. The <code>pid</code>s are,
|
||
of course, the process IDs and the <code>state</code> describes the state of that
|
||
process.</p>
|
||
<p>Handling of the keys of the associative array is as described for
|
||
<code>jobdirs</code> above.</p>
|
||
<p><span id="index-nameddirs"></span></p>
|
||
<p><code>nameddirs</code></p>
|
||
<p>This associative array maps the names of named directories to the
|
||
pathnames they stand for.</p>
|
||
<p><span id="index-userdirs"></span></p>
|
||
<p><code>userdirs</code></p>
|
||
<p>This associative array maps user names to the pathnames of their home
|
||
directories.</p>
|
||
<p><span id="index-usergroups"></span></p>
|
||
<p><code>usergroups</code></p>
|
||
<p>This associative array maps names of system groups of which the current
|
||
user is a member to the corresponding group identifiers. The contents
|
||
are the same as the groups output by the <code>id</code> command.</p>
|
||
<p><span id="index-funcfiletrace"></span></p>
|
||
<p><code>funcfiletrace</code></p>
|
||
<p>This array contains the absolute line numbers and corresponding file
|
||
names for the point where the current function, sourced file, or (if
|
||
<code>EVAL_LINENO</code> is set) <code>eval</code> command was called. The array is of the
|
||
same length as <code>funcsourcetrace</code> and <code>functrace</code>, but differs from
|
||
<code>funcsourcetrace</code> in that the line and file are the point of call, not
|
||
the point of definition, and differs from <code>functrace</code> in that all values
|
||
are absolute line numbers in files, rather than relative to the start of
|
||
a function, if any.</p>
|
||
<p><span id="index-funcsourcetrace"></span></p>
|
||
<p><code>funcsourcetrace</code></p>
|
||
<p>This array contains the file names and line numbers of the points where
|
||
the functions, sourced files, and (if <code>EVAL_LINENO</code> is set) <code>eval</code>
|
||
commands currently being executed were defined. The line number is the
|
||
line where the ‘<code>function</code> <code>name</code>’ or ‘<code>name</code> <code>()</code>’ started. In the case
|
||
of an autoloaded function the line number is reported as zero. The
|
||
format of each element is <code>filename``:``lineno</code>.</p>
|
||
<p>For functions autoloaded from a file in native zsh format, where only
|
||
the body of the function occurs in the file, or for files that have been
|
||
executed by the <code>source</code> or ‘<code>.</code>’ builtins, the trace information is
|
||
shown as <code>filename``:``0</code>, since the entire file is the definition. The
|
||
source file name is resolved to an absolute path when the function is
|
||
loaded or the path to it otherwise resolved.</p>
|
||
<p>Most users will be interested in the information in the <code>funcfiletrace</code>
|
||
array instead.</p>
|
||
<p><span id="index-funcstack"></span></p>
|
||
<p><code>funcstack</code></p>
|
||
<p>This array contains the names of the functions, sourced files, and (if
|
||
<code>EVAL_LINENO</code> is set) <code>eval</code> commands. currently being executed. The
|
||
first element is the name of the function using the parameter.</p>
|
||
<p>The standard shell array <code>zsh_eval_context</code> can be used to determine the
|
||
type of shell construct being executed at each depth: note, however,
|
||
that is in the opposite order, with the most recent item last, and it is
|
||
more detailed, for example including an entry for <code>toplevel</code>, the main
|
||
shell code being executed either interactively or from a script, which
|
||
is not present in <code>$funcstack</code>.</p>
|
||
<p><span id="index-functrace"></span></p>
|
||
<p><code>functrace</code></p>
|
||
<p>This array contains the names and line numbers of the callers
|
||
corresponding to the functions currently being executed. The format of
|
||
each element is <code>name``:``lineno</code>. Callers are also shown for sourced
|
||
files; the caller is the point where the <code>source</code> or ‘<code>.</code>’ command was
|
||
executed.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fpcre-Module"></span>
|
||
<span id="The-zsh_002fpcre-Module-1"></span></p>
|
||
<h2 id="2221-the-zshpcre-module"><a class="header" href="#2221-the-zshpcre-module">22.21 The zsh/pcre Module</a></h2>
|
||
<p><span id="index-regular-expressions_002c-perl_002dcompatible"></span></p>
|
||
<p>The <code>zsh/pcre</code> module makes some commands available as builtins:</p>
|
||
<p><span id="index-pcre_005fcompile"></span></p>
|
||
<p><code>pcre_compile</code> [ <code>-aimxs</code> ] <code>PCRE</code></p>
|
||
<p>Compiles a perl-compatible regular expression.</p>
|
||
<p>Option <code>-a</code> will force the pattern to be anchored. Option <code>-i</code> will
|
||
compile a case-insensitive pattern. Option <code>-m</code> will compile a
|
||
multi-line pattern; that is, <code>^</code> and <code>$</code> will match newlines within the
|
||
pattern. Option <code>-x</code> will compile an extended pattern, wherein
|
||
whitespace and <code>#</code> comments are ignored. Option <code>-s</code> makes the dot
|
||
metacharacter match all characters, including those that indicate
|
||
newline.</p>
|
||
<p><span id="index-pcre_005fstudy"></span></p>
|
||
<p><code>pcre_study</code></p>
|
||
<p>Studies the previously-compiled PCRE which may result in faster
|
||
matching.</p>
|
||
<p><span id="index-pcre_005fmatch"></span></p>
|
||
<p><code>pcre_match</code> [ <code>-v</code> <code>var</code> ] [ <code>-a</code> <code>arr</code> ] [ <code>-n</code> <code>offset</code> ] [
|
||
<code>-b</code> ] <code>string</code></p>
|
||
<p>Returns successfully if <code>string</code> matches the previously-compiled PCRE.</p>
|
||
<p>Upon successful match, if the expression captures substrings within
|
||
parentheses, <code>pcre_match</code> will set the array <code>match</code> to those
|
||
substrings, unless the <code>-a</code> option is given, in which case it will set
|
||
the array <code>arr</code>. Similarly, the variable <code>MATCH</code> will be set to the
|
||
entire matched portion of the string, unless the <code>-v</code> option is given,
|
||
in which case the variable <code>var</code> will be set. No variables are altered
|
||
if there is no successful match. A <code>-n</code> option starts searching for a
|
||
match from the byte <code>offset</code> position in <code>string</code>. If the <code>-b</code> option is
|
||
given, the variable <code>ZPCRE_OP</code> will be set to an offset pair string,
|
||
representing the byte offset positions of the entire matched portion
|
||
within the <code>string</code>. For example, a <code>ZPCRE_OP</code> set to "32 45" indicates
|
||
that the matched portion began on byte offset 32 and ended on byte
|
||
offset 44. Here, byte offset position 45 is the position directly after
|
||
the matched portion. Keep in mind that the byte position isn’t
|
||
necessarily the same as the character position when UTF-8 characters are
|
||
involved. Consequently, the byte offset positions are only to be relied
|
||
on in the context of using them for subsequent searches on <code>string</code>,
|
||
using an offset position as an argument to the <code>-n</code> option. This is
|
||
mostly used to implement the "find all non-overlapping matches"
|
||
functionality.</p>
|
||
<p>A simple example of "find all non-overlapping matches":</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">string="The following zip codes: 78884 90210 99513"
|
||
pcre_compile -m "\d{5}"
|
||
accum=()
|
||
pcre_match -b -- $string
|
||
while [[ $? -eq 0 ]] do
|
||
b=($=ZPCRE_OP)
|
||
accum+=$MATCH
|
||
pcre_match -b -n $b[2] -- $string
|
||
done
|
||
print -l $accum
|
||
</code></pre>
|
||
</div>
|
||
<p>The <code>zsh/pcre</code> module makes available the following test condition:</p>
|
||
<p><span id="index-pcre_002dmatch"></span></p>
|
||
<p><code>expr</code> <code>-pcre-match</code> <code>pcre</code></p>
|
||
<p>Matches a string against a perl-compatible regular expression.</p>
|
||
<p>For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">[[ "$text" -pcre-match ^d+$ ]] &&
|
||
print text variable contains only "d's".
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-REMATCH_005fPCRE-1"></span>
|
||
<span id="index-NO_005fCASE_005fMATCH-1"></span></p>
|
||
<p>If the <code>REMATCH_PCRE</code> option is set, the <code>=~</code> operator is equivalent to
|
||
<code>-pcre-match</code>, and the <code>NO_CASE_MATCH</code> option may be used. Note that
|
||
<code>NO_CASE_MATCH</code> never applies to the <code>pcre_match</code> builtin, instead use
|
||
the <code>-i</code> switch of <code>pcre_compile</code>.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fparam_002fprivate-Module"></span>
|
||
<span id="The-zsh_002fparam_002fprivate-Module-1"></span></p>
|
||
<h2 id="2222-the-zshparamprivate-module"><a class="header" href="#2222-the-zshparamprivate-module">22.22 The zsh/param/private Module</a></h2>
|
||
<p>The <code>zsh/param/private</code> module is used to create parameters whose scope
|
||
is limited to the current function body, and <em>not</em> to other functions
|
||
called by the current function.</p>
|
||
<p>This module provides a single autoloaded builtin:</p>
|
||
<p><span id="index-private"></span>
|
||
<span id="index-private-parameter_002c-creating"></span></p>
|
||
<p><code>private</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>The <code>private</code> builtin accepts all the same options and arguments as
|
||
<code>local</code> (<a href="Shell-Builtin-Commands.html#Shell-Builtin-Commands">Shell Builtin
|
||
Commands</a>) except
|
||
for the ‘<code>-``T</code>’ option. Tied parameters may not be made private.</p>
|
||
<p>If used at the top level (outside a function scope), <code>private</code> creates a
|
||
normal parameter in the same manner as <code>declare</code> or <code>typeset</code>. A warning
|
||
about this is printed if <code>WARN_CREATE_GLOBAL</code> is set
|
||
(<a href="Options.html#Options">Options</a>). Used inside a function scope,
|
||
<code>private</code> creates a local parameter similar to one declared with
|
||
<code>local</code>, except having special properties noted below.</p>
|
||
<p>Special parameters which expose or manipulate internal shell state, such
|
||
as <code>ARGC</code>, <code>argv</code>, <code>COLUMNS</code>, <code>LINES</code>, <code>UID</code>, <code>EUID</code>, <code>IFS</code>, <code>PROMPT</code>,
|
||
<code>RANDOM</code>, <code>SECONDS</code>, etc., cannot be made private unless the ‘<code>-``h</code>’
|
||
option is used to hide the special meaning of the parameter. This may
|
||
change in the future.</p>
|
||
<p>As with other <code>typeset</code> equivalents, <code>private</code> is both a builtin and a
|
||
reserved word, so arrays may be assigned with parenthesized word list
|
||
<code>name``=(``value</code>...<code>)</code> syntax. However, the reserved word ‘<code>private</code>’
|
||
is not available until <code>zsh/param/private</code> is loaded, so care must be
|
||
taken with order of execution and parsing for function definitions which
|
||
use <code>private</code>. To compensate for this, the module also adds the option
|
||
‘<code>-P</code>’ to the ‘<code>local</code>’ builtin to declare private parameters.</p>
|
||
<p>For example, this construction fails if <code>zsh/param/private</code> has not yet
|
||
been loaded when ‘<code>bad_declaration</code>’ is defined:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">bad_declaration() {
|
||
zmodload zsh/param/private
|
||
private array=( one two three )
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p>This construction works because <code>local</code> is already a keyword, and the
|
||
module is loaded before the statement is executed:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">good_declaration() {
|
||
zmodload zsh/param/private
|
||
local -P array=( one two three )
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p>The following is usable in scripts but may have trouble with <code>autoload</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zmodload zsh/param/private
|
||
iffy_declaration() {
|
||
private array=( one two three )
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p>The <code>private</code> builtin may always be used with scalar assignments and for
|
||
declarations without assignments.</p>
|
||
<p>Parameters declared with <code>private</code> have the following properties:</p>
|
||
<ul>
|
||
<li>Within the function body where it is declared, the parameter behaves
|
||
as a local, except as noted above for tied or special parameters.</li>
|
||
<li>The type of a parameter declared private cannot be changed in the
|
||
scope where it was declared, even if the parameter is unset. Thus an
|
||
array cannot be assigned to a private scalar, etc.</li>
|
||
<li>Within any other function called by the declaring function, the
|
||
private parameter does <em>NOT</em> hide other parameters of the same name,
|
||
so for example a global parameter of the same name is visible and
|
||
may be assigned or unset. This includes calls to anonymous
|
||
functions, although that may also change in the future.</li>
|
||
<li>An exported private remains in the environment of inner scopes but
|
||
appears unset for the current shell in those scopes. Generally,
|
||
exporting private parameters should be avoided.</li>
|
||
</ul>
|
||
<p>Note that this differs from the static scope defined by compiled
|
||
languages derived from C, in that the a new call to the same function
|
||
creates a new scope, i.e., the parameter is still associated with the
|
||
call stack rather than with the function definition. It differs from ksh
|
||
‘<code>typeset -S</code>’ because the syntax used to define the function has no
|
||
bearing on whether the parameter scope is respected.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fregex-Module"></span>
|
||
<span id="The-zsh_002fregex-Module-1"></span></p>
|
||
<h2 id="2223-the-zshregex-module"><a class="header" href="#2223-the-zshregex-module">22.23 The zsh/regex Module</a></h2>
|
||
<p><span id="index-regular-expressions"></span>
|
||
<span id="index-regex"></span></p>
|
||
<p>The <code>zsh/regex</code> module makes available the following test condition:</p>
|
||
<p><span id="index-regex_002dmatch"></span></p>
|
||
<p><code>expr</code> <code>-regex-match</code> <code>regex</code></p>
|
||
<p>Matches a string against a POSIX extended regular expression. On
|
||
successful match, matched portion of the string will normally be placed
|
||
in the <code>MATCH</code> variable. If there are any capturing parentheses within
|
||
the regex, then the <code>match</code> array variable will contain those. If the
|
||
match is not successful, then the variables will not be altered.</p>
|
||
<p>For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">[[ alphabetical -regex-match ^a([^a]+)a([^a]+)a ]] &&
|
||
print -l $MATCH X $match
|
||
</code></pre>
|
||
</div>
|
||
<p>If the option <code>REMATCH_PCRE</code> is not set, then the <code>=~</code> operator will
|
||
automatically load this module as needed and will invoke the
|
||
<code>-regex-match</code> operator.</p>
|
||
<p>If <code>BASH_REMATCH</code> is set, then the array <code>BASH_REMATCH</code> will be set
|
||
instead of <code>MATCH</code> and <code>match</code>.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fsched-Module"></span>
|
||
<span id="The-zsh_002fsched-Module-1"></span></p>
|
||
<h2 id="2224-the-zshsched-module"><a class="header" href="#2224-the-zshsched-module">22.24 The zsh/sched Module</a></h2>
|
||
<p>The <code>zsh/sched</code> module makes available one builtin command and one
|
||
parameter.</p>
|
||
<p><span id="index-sched"></span> <span id="index-timed-execution"></span>
|
||
<span id="index-execution_002c-timed"></span></p>
|
||
<p><code>sched</code> [<code>-o</code>] [<code>+</code>]<code>hh``:``mm</code>[<code>:``ss</code>] <code>command</code> ...</p>
|
||
<p><code>sched</code> [<code>-o</code>] [<code>+</code>]<code>seconds</code> <code>command</code> ...</p>
|
||
<p><code>sched</code> [ <code>-``item</code> ]</p>
|
||
<p>Make an entry in the scheduled list of commands to execute. The time may
|
||
be specified in either absolute or relative time, and either as hours,
|
||
minutes and (optionally) seconds separated by a colon, or seconds alone.
|
||
An absolute number of seconds indicates the time since the epoch
|
||
(1970/01/01 00:00); this is useful in combination with the features in
|
||
the <code>zsh/datetime</code> module, see <a href="Zsh-Modules.html#The-zsh_002fdatetime-Module">The zsh/datetime
|
||
Module</a>.</p>
|
||
<p>With no arguments, prints the list of scheduled commands. If the
|
||
scheduled command has the <code>-o</code> flag set, this is shown at the start of
|
||
the command.</p>
|
||
<p>With the argument ‘<code>-``item</code>’, removes the given item from the list. The
|
||
numbering of the list is continuous and entries are in time order, so
|
||
the numbering can change when entries are added or deleted.</p>
|
||
<p>Commands are executed either immediately before a prompt, or while the
|
||
shell’s line editor is waiting for input. In the latter case it is
|
||
useful to be able to produce output that does not interfere with the
|
||
line being edited. Providing the option <code>-o</code> causes the shell to clear
|
||
the command line before the event and redraw it afterwards. This should
|
||
be used with any scheduled event that produces visible output to the
|
||
terminal; it is not needed, for example, with output that updates a
|
||
terminal emulator’s title bar.</p>
|
||
<p>To effect changes to the editor buffer when an event executes, use the
|
||
‘<code>zle</code>’ command with no arguments to test whether the editor is
|
||
active, and if it is, then use ‘<code> zle ``widget</code>’ to access the editor
|
||
via the named <code>widget</code>.</p>
|
||
<p>The <code>sched</code> builtin 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/sched b:sched</code>’.</p>
|
||
<p><span id="index-zsh_005fscheduled_005fevents"></span></p>
|
||
<p><code>zsh_scheduled_events</code></p>
|
||
<p>A readonly array corresponding to the events scheduled by the <code>sched</code>
|
||
builtin. The indices of the array correspond to the numbers shown when
|
||
<code>sched</code> is run with no arguments (provided that the <code>KSH_ARRAYS</code> option
|
||
is not set). The value of the array consists of the scheduled time in
|
||
seconds since the epoch (see <a href="Zsh-Modules.html#The-zsh_002fdatetime-Module">The zsh/datetime
|
||
Module</a> for facilities for using this
|
||
number), followed by a colon, followed by any options (which may be
|
||
empty but will be preceded by a ‘<code>-</code>’ otherwise), followed by a colon,
|
||
followed by the command to be executed.</p>
|
||
<p>The <code>sched</code> builtin should be used for manipulating the events. Note
|
||
that this will have an immediate effect on the contents of the array, so
|
||
that indices may become invalid.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fnet_002fsocket-Module"></span>
|
||
<span id="The-zsh_002fnet_002fsocket-Module-1"></span></p>
|
||
<h2 id="2225-the-zshnetsocket-module"><a class="header" href="#2225-the-zshnetsocket-module">22.25 The zsh/net/socket Module</a></h2>
|
||
<p>The <code>zsh/net/socket</code> module makes available one builtin command:</p>
|
||
<p><span id="index-zsocket"></span> <span id="index-sockets"></span>
|
||
<span id="index-sockets_002c-Unix-domain"></span></p>
|
||
<p><code>zsocket</code> [ <code>-altv</code> ] [ <code>-d</code> <code>fd</code> ] [ <code>args</code> ]</p>
|
||
<p><code>zsocket</code> is implemented as a builtin to allow full use of shell command
|
||
line editing, file I/O, and job control mechanisms.</p>
|
||
<hr />
|
||
<p><span id="Outbound-Connections-1"></span></p>
|
||
<h3 id="22251-outbound-connections"><a class="header" href="#22251-outbound-connections">22.25.1 Outbound Connections</a></h3>
|
||
<p><span id="index-sockets_002c-outbound-Unix-domain"></span></p>
|
||
<ul>
|
||
<li>
|
||
<p><code>zsocket</code> [ <code>-v</code> ] [ <code>-d</code> <code>fd</code> ] <code>filename</code><br />
|
||
Open a new Unix domain connection to <code>filename</code>. The shell parameter
|
||
<code>REPLY</code> will be set to the file descriptor associated with that
|
||
connection. Currently, only stream connections are supported.</p>
|
||
<p>If <code>-d</code> is specified, its argument will be taken as the target file
|
||
descriptor for the connection.</p>
|
||
<p>In order to elicit more verbose output, use <code>-v</code>.</p>
|
||
<p>File descriptors can be closed with normal shell syntax when no
|
||
longer needed, for example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">exec {REPLY}>&-
|
||
</code></pre>
|
||
</div>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Inbound-Connections"></span></p>
|
||
<h3 id="22252-inbound-connections"><a class="header" href="#22252-inbound-connections">22.25.2 Inbound Connections</a></h3>
|
||
<p><span id="index-sockets_002c-inbound-Unix-domain"></span></p>
|
||
<ul>
|
||
<li>
|
||
<p><code>zsocket</code> <code>-l</code> [ <code>-v</code> ] [ <code>-d</code> <code>fd</code> ] <code>filename</code><br />
|
||
<code>zsocket -l</code> will open a socket listening on <code>filename</code>. The shell
|
||
parameter <code>REPLY</code> will be set to the file descriptor associated with
|
||
that listener. The file descriptor remains open in subshells</p>
|
||
<p>If <code>-d</code> is specified, its argument will be taken as the target file
|
||
descriptor for the connection.</p>
|
||
<p>In order to elicit more verbose output, use <code>-v</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zsocket</code> <code>-a</code> [ <code>-tv</code> ] [ <code>-d</code> <code>targetfd</code> ] <code>listenfd</code><br />
|
||
<code>zsocket -a</code> will accept an incoming connection to the socket
|
||
associated with <code>listenfd</code>. The shell parameter <code>REPLY</code> will be set
|
||
to the file descriptor associated with the inbound connection. The
|
||
file descriptor remains open in subshells</p>
|
||
<p>If <code>-d</code> is specified, its argument will be taken as the target file
|
||
descriptor for the connection.</p>
|
||
<p>If <code>-t</code> is specified, <code>zsocket</code> will return if no incoming
|
||
connection is pending. Otherwise it will wait for one.</p>
|
||
<p>In order to elicit more verbose output, use <code>-v</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="The-zsh_002fstat-Module"></span>
|
||
<span id="The-zsh_002fstat-Module-1"></span></p>
|
||
<h2 id="2226-the-zshstat-module"><a class="header" href="#2226-the-zshstat-module">22.26 The zsh/stat Module</a></h2>
|
||
<p>The <code>zsh/stat</code> module makes available one builtin command under two
|
||
possible names:</p>
|
||
<p><span id="index-zstat"></span> <span id="index-stat"></span>
|
||
<span id="index-files_002c-listing"></span>
|
||
<span id="index-files_002c-examining"></span></p>
|
||
<p><code>zstat </code>[ <code>-gnNolLtTrs</code> ] [ <code>-f</code> <code>fd</code> ] [ <code>-H</code> <code>hash</code> ] [ <code>-A</code>
|
||
<code>array</code> ] [ <code>-F</code> <code>fmt</code> ]</p>
|
||
<p><code> </code>[ <code>+``element</code> ] [ <code>file</code> ... ]</p>
|
||
<p><code>stat</code> <code>...</code></p>
|
||
<p>The command acts as a front end to the <code>stat</code> system call (see man page
|
||
stat(2)). The same command is provided with two names; as the name
|
||
<code>stat</code> is often used by an external command it is recommended that only
|
||
the <code>zstat</code> form of the command is used. This can be arranged by loading
|
||
the module with the command ‘<code>zmodload -F zsh/stat b:zstat</code>’.</p>
|
||
<p>If the <code>stat</code> call fails, the appropriate system error message printed
|
||
and status 1 is returned. The fields of <code>struct stat</code> give information
|
||
about the files provided as arguments to the command. In addition to
|
||
those available from the <code>stat</code> call, an extra element ‘<code>link</code>’ is
|
||
provided. These elements are:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>device</code><br />
|
||
The number of the device on which the file resides.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>inode</code><br />
|
||
The unique number of the file on this device (‘<em>inode</em>’ number).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>mode</code><br />
|
||
The mode of the file; that is, the file’s type and access
|
||
permissions. With the <code>-s</code> option, this will be returned as a string
|
||
corresponding to the first column in the display of the <code>ls -l</code>
|
||
command.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>nlink</code><br />
|
||
The number of hard links to the file.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>uid</code><br />
|
||
The user ID of the owner of the file. With the <code>-s</code> option, this is
|
||
displayed as a user name.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>gid</code><br />
|
||
The group ID of the file. With the <code>-s</code> option, this is displayed as
|
||
a group name.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>rdev</code><br />
|
||
The raw device number. This is only useful for special devices.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>size</code><br />
|
||
The size of the file in bytes.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>atime</code><br />
|
||
<code>mtime</code><br />
|
||
<code>ctime</code><br />
|
||
The last access, modification and inode change times of the file,
|
||
respectively, as the number of seconds since midnight GMT on 1st
|
||
January, 1970. With the <code>-s</code> option, these are printed as strings
|
||
for the local time zone; the format can be altered with the <code>-F</code>
|
||
option, and with the <code>-g</code> option the times are in GMT.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>blksize</code><br />
|
||
The number of bytes in one allocation block on the device on which
|
||
the file resides.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>block</code><br />
|
||
The number of disk blocks used by the file.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>link</code><br />
|
||
If the file is a link and the <code>-L</code> option is in effect, this
|
||
contains the name of the file linked to, otherwise it is empty. Note
|
||
that if this element is selected (‘‘<code>zstat +link</code>’’) then the <code>-L</code>
|
||
option is automatically used.</p>
|
||
</li>
|
||
</ul>
|
||
<p>A particular element may be selected by including its name preceded by a
|
||
‘<code>+</code>’ in the option list; only one element is allowed. The element may
|
||
be shortened to any unique set of leading characters. Otherwise, all
|
||
elements will be shown for all files.</p>
|
||
<p>Options:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-A</code> <code>array</code><br />
|
||
Instead of displaying the results on standard output, assign them to
|
||
an <code>array</code>, one <code>struct stat</code> element per array element for each
|
||
file in order. In this case neither the name of the element nor the
|
||
name of the files appears in <code>array</code> unless the <code>-t</code> or <code>-n</code> options
|
||
were given, respectively. If <code>-t</code> is given, the element name appears
|
||
as a prefix to the appropriate array element; if <code>-n</code> is given, the
|
||
file name appears as a separate array element preceding all the
|
||
others. Other formatting options are respected.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-H</code> <code>hash</code><br />
|
||
Similar to <code>-A</code>, but instead assign the values to <code>hash</code>. The keys
|
||
are the elements listed above. If the <code>-n</code> option is provided then
|
||
the name of the file is included in the hash with key <code>name</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-f</code> <code>fd</code><br />
|
||
Use the file on file descriptor <code>fd</code> instead of named files; no list
|
||
of file names is allowed in this case.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-F</code> <code>fmt</code><br />
|
||
Supplies a <code>strftime</code> (see man page strftime(3)) string for the
|
||
formatting of the time elements. The format string supports all of
|
||
the zsh extensions described in <a href="Prompt-Expansion.html#Prompt-Expansion">Prompt
|
||
Expansion</a>. The <code>-s</code> option
|
||
is implied.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-g</code><br />
|
||
Show the time elements in the GMT time zone. The <code>-s</code> option is
|
||
implied.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-l</code><br />
|
||
List the names of the type elements (to standard output or an array
|
||
as appropriate) and return immediately; arguments, and options other
|
||
than <code>-A</code>, are ignored.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-L</code><br />
|
||
Perform an <code>lstat</code> (see man page lstat(2)) rather than a <code>stat</code>
|
||
system call. In this case, if the file is a link, information about
|
||
the link itself rather than the target file is returned. This option
|
||
is required to make the <code>link</code> element useful. It’s important to
|
||
note that this is the exact opposite from man page ls(1), etc.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-n</code><br />
|
||
Always show the names of files. Usually these are only shown when
|
||
output is to standard output and there is more than one file in the
|
||
list.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-N</code><br />
|
||
Never show the names of files.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-o</code><br />
|
||
If a raw file mode is printed, show it in octal, which is more
|
||
useful for human consumption than the default of decimal. A leading
|
||
zero will be printed in this case. Note that this does not affect
|
||
whether a raw or formatted file mode is shown, which is controlled
|
||
by the <code>-r</code> and <code>-s</code> options, nor whether a mode is shown at all.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-r</code><br />
|
||
Print raw data (the default format) alongside string data (the <code>-s</code>
|
||
format); the string data appears in parentheses after the raw data.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-s</code><br />
|
||
Print <code>mode</code>, <code>uid</code>, <code>gid</code> and the three time elements as strings
|
||
instead of numbers. In each case the format is like that of <code>ls -l</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-t</code><br />
|
||
Always show the type names for the elements of <code>struct stat</code>.
|
||
Usually these are only shown when output is to standard output and
|
||
no individual element has been selected.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-T</code><br />
|
||
Never show the type names of the <code>struct stat</code> elements.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="The-zsh_002fsystem-Module"></span>
|
||
<span id="The-zsh_002fsystem-Module-1"></span></p>
|
||
<h2 id="2227-the-zshsystem-module"><a class="header" href="#2227-the-zshsystem-module">22.27 The zsh/system Module</a></h2>
|
||
<p>The <code>zsh/system</code> module makes available various builtin commands and
|
||
parameters.</p>
|
||
<hr />
|
||
<p><span id="Builtins"></span></p>
|
||
<h3 id="22271-builtins"><a class="header" href="#22271-builtins">22.27.1 Builtins</a></h3>
|
||
<p><span id="index-syserror"></span></p>
|
||
<p><code>syserror</code> [ <code>-e</code> <code>errvar</code> ] [ <code>-p</code> <code>prefix</code> ] [ <code>errno</code> |
|
||
<code>errname</code> ]</p>
|
||
<p>This command prints out the error message associated with <code>errno</code>, a
|
||
system error number, followed by a newline to standard error.</p>
|
||
<p>Instead of the error number, a name <code>errname</code>, for example <code>ENOENT</code>, may
|
||
be used. The set of names is the same as the contents of the array
|
||
<code>errnos</code>, see below.</p>
|
||
<p>If the string <code>prefix</code> is given, it is printed in front of the error
|
||
message, with no intervening space.</p>
|
||
<p>If <code>errvar</code> is supplied, the entire message, without a newline, is
|
||
assigned to the parameter names <code>errvar</code> and nothing is output.</p>
|
||
<p>A return status of 0 indicates the message was successfully printed
|
||
(although it may not be useful if the error number was out of the
|
||
system’s range), a return status of 1 indicates an error in the
|
||
parameters, and a return status of 2 indicates the error name was not
|
||
recognised (no message is printed for this).</p>
|
||
<p><span id="index-sysopen"></span></p>
|
||
<p><code>sysopen</code> [ <code>-arw</code> ] [ <code>-m</code> <code>permissions</code> ] [ <code>-o</code> <code>options</code> ]</p>
|
||
<p><code> ``-u</code> <code>fd</code> <code>file</code></p>
|
||
<p>This command opens a file. The <code>-r</code>, <code>-w</code> and <code>-a</code> flags indicate
|
||
whether the file should be opened for reading, writing and appending,
|
||
respectively. The <code>-m</code> option allows the initial permissions to use when
|
||
creating a file to be specified in octal form. The file descriptor is
|
||
specified with <code>-u</code>. Either an explicit file descriptor in the range 0
|
||
to 9 can be specified or a variable name can be given to which the file
|
||
descriptor number will be assigned.</p>
|
||
<p>The <code>-o</code> option allows various system specific options to be specified
|
||
as a comma-separated list. The following is a list of possible options.
|
||
Note that, depending on the system, some may not be available.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>cloexec</code><br />
|
||
mark file to be closed when other programs are executed (else the
|
||
file descriptor remains open in subshells and forked external</p>
|
||
</li>
|
||
<li>
|
||
<p><code>create</code><br />
|
||
<code>creat</code><br />
|
||
create file if it does not exist</p>
|
||
</li>
|
||
<li>
|
||
<p><code>excl</code><br />
|
||
create file, error if it already exists</p>
|
||
</li>
|
||
<li>
|
||
<p><code>noatime</code><br />
|
||
suppress updating of the file atime</p>
|
||
</li>
|
||
<li>
|
||
<p><code>nofollow</code><br />
|
||
fail if <code>file</code> is a symbolic link</p>
|
||
</li>
|
||
<li>
|
||
<p><code>sync</code><br />
|
||
request that writes wait until data has been physically written</p>
|
||
</li>
|
||
<li>
|
||
<p><code>truncate</code><br />
|
||
<code>trunc</code><br />
|
||
truncate file to size 0</p>
|
||
</li>
|
||
</ul>
|
||
<p>To close the file, use one of the following:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">exec {fd}<&-
|
||
exec {fd}>&-
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-sysread"></span></p>
|
||
<p><code>sysread </code>[ <code>-c</code> <code>countvar</code> ] [ <code>-i</code> <code>infd</code> ] [ <code>-o</code> <code>outfd</code> ]</p>
|
||
<p><code> </code>[ <code>-s</code> <code>bufsize</code> ] [ <code>-t</code> <code>timeout</code> ] [ <code>param</code> ]</p>
|
||
<p>Perform a single system read from file descriptor <code>infd</code>, or zero if
|
||
that is not given. The result of the read is stored in <code>param</code> or
|
||
<code>REPLY</code> if that is not given. If <code>countvar</code> is given, the number of
|
||
bytes read is assigned to the parameter named by <code>countvar</code>.</p>
|
||
<p>The maximum number of bytes read is <code>bufsize</code> or 8192 if that is not
|
||
given, however the command returns as soon as any number of bytes was
|
||
successfully read.</p>
|
||
<p>If <code>timeout</code> is given, it specifies a timeout in seconds, which may be
|
||
zero to poll the file descriptor. This is handled by the <code>poll</code> system
|
||
call if available, otherwise the <code>select</code> system call if available.</p>
|
||
<p>If <code>outfd</code> is given, an attempt is made to write all the bytes just read
|
||
to the file descriptor <code>outfd</code>. If this fails, because of a system error
|
||
other than <code>EINTR</code> or because of an internal zsh error during an
|
||
interrupt, the bytes read but not written are stored in the parameter
|
||
named by <code>param</code> if supplied (no default is used in this case), and the
|
||
number of bytes read but not written is stored in the parameter named by
|
||
<code>countvar</code> if that is supplied. If it was successful, <code>countvar</code>
|
||
contains the full number of bytes transferred, as usual, and <code>param</code> is
|
||
not set.</p>
|
||
<p>The error <code>EINTR</code> (interrupted system call) is handled internally so
|
||
that shell interrupts are transparent to the caller. Any other error
|
||
causes a return.</p>
|
||
<p>The possible return statuses are</p>
|
||
<ul>
|
||
<li>
|
||
<p>0<br />
|
||
At least one byte of data was successfully read and, if appropriate,
|
||
written.</p>
|
||
</li>
|
||
<li>
|
||
<p>1<br />
|
||
There was an error in the parameters to the command. This is the
|
||
only error for which a message is printed to standard error.</p>
|
||
</li>
|
||
<li>
|
||
<p>2<br />
|
||
There was an error on the read, or on polling the input file
|
||
descriptor for a timeout. The parameter <code>ERRNO</code> gives the error.</p>
|
||
</li>
|
||
<li>
|
||
<p>3<br />
|
||
Data were successfully read, but there was an error writing them to
|
||
<code>outfd</code>. The parameter <code>ERRNO</code> gives the error.</p>
|
||
</li>
|
||
<li>
|
||
<p>4<br />
|
||
The attempt to read timed out. Note this does not set <code>ERRNO</code> as
|
||
this is not a system error.</p>
|
||
</li>
|
||
<li>
|
||
<p>5<br />
|
||
No system error occurred, but zero bytes were read. This usually
|
||
indicates end of file. The parameters are set according to the usual
|
||
rules; no write to <code>outfd</code> is attempted.</p>
|
||
</li>
|
||
</ul>
|
||
<p><code>sysseek</code> [ <code>-u</code> <code>fd</code> ] [ <code>-w</code> <code>start</code>|<code>end</code>|<code>current</code> ] <code>offset</code></p>
|
||
<p>The current file position at which future reads and writes will take
|
||
place is adjusted to the specified byte offset. The <code>offset</code> is
|
||
evaluated as a math expression. The <code>-u</code> option allows the file
|
||
descriptor to be specified. By default the offset is specified relative
|
||
to the start or the file but, with the <code>-w</code> option, it is possible to
|
||
specify that the offset should be relative to the current position or
|
||
the end of the file.</p>
|
||
<p><code>syswrite</code> [ <code>-c</code> <code>countvar</code> ] [ <code>-o</code> <code>outfd</code> ] <code>data</code></p>
|
||
<p>The data (a single string of bytes) are written to the file descriptor
|
||
<code>outfd</code>, or 1 if that is not given, using the <code>write</code> system call.
|
||
Multiple write operations may be used if the first does not write all
|
||
the data.</p>
|
||
<p>If <code>countvar</code> is given, the number of byte written is stored in the
|
||
parameter named by <code>countvar</code>; this may not be the full length of <code>data</code>
|
||
if an error occurred.</p>
|
||
<p>The error <code>EINTR</code> (interrupted system call) is handled internally by
|
||
retrying; otherwise an error causes the command to return. For example,
|
||
if the file descriptor is set to non-blocking output, an error <code>EAGAIN</code>
|
||
(on some systems, <code>EWOULDBLOCK</code>) may result in the command returning
|
||
early.</p>
|
||
<p>The return status may be 0 for success, 1 for an error in the parameters
|
||
to the command, or 2 for an error on the write; no error message is
|
||
printed in the last case, but the parameter <code>ERRNO</code> will reflect the
|
||
error that occurred.</p>
|
||
<p><code>zsystem flock</code> [ <code>-t</code> <code>timeout</code> ] [ <code>-f</code> <code>var</code> ] [<code>-er</code>] <code>file</code></p>
|
||
<p><code>zsystem flock -u</code> <code>fd_expr</code></p>
|
||
<p>The builtin <code>zsystem</code>’s subcommand <code>flock</code> performs advisory file
|
||
locking (via the man page fcntl(2) system call) over the entire contents
|
||
of the given file. This form of locking requires the processes accessing
|
||
the file to cooperate; its most obvious use is between two instances of
|
||
the shell itself.</p>
|
||
<p>In the first form the named <code>file</code>, which must already exist, is locked
|
||
by opening a file descriptor to the file and applying a lock to the file
|
||
descriptor. The lock terminates when the shell process that created the
|
||
lock exits; it is therefore often convenient to create file locks within
|
||
subshells, since the lock is automatically released when the subshell
|
||
exits. Note that use of the <code>print</code> builtin with the <code>-u</code> option will,
|
||
as a side effect, release the lock, as will redirection to the file in
|
||
the shell holding the lock. To work around this use a subshell, e.g.
|
||
‘<code> (print message) >> ``file</code>’. Status 0 is returned if the lock
|
||
succeeds, else status 1.</p>
|
||
<p>In the second form the file descriptor given by the arithmetic
|
||
expression <code>fd_expr</code> is closed, releasing a lock. The file descriptor
|
||
can be queried by using the ‘<code>-f</code> <code>var</code>’ form during the lock; on a
|
||
successful lock, the shell variable <code>var</code> is set to the file descriptor
|
||
used for locking. The lock will be released if the file descriptor is
|
||
closed by any other means, for example using ‘<code>exec {``var``}>&-</code>’;
|
||
however, the form described here performs a safety check that the file
|
||
descriptor is in use for file locking.</p>
|
||
<p>By default the shell waits indefinitely for the lock to succeed. The
|
||
option <code>-t</code> <code>timeout</code> specifies a timeout for the lock in seconds;
|
||
currently this must be an integer. The shell will attempt to lock the
|
||
file once a second during this period. If the attempt times out, status
|
||
2 is returned.</p>
|
||
<p>If the option <code>-e</code> is given, the file descriptor for the lock is
|
||
preserved when the shell uses <code>exec</code> to start a new process; otherwise
|
||
it is closed at that point and the lock released.</p>
|
||
<p>If the option <code>-r</code> is given, the lock is only for reading, otherwise it
|
||
is for reading and writing. The file descriptor is opened accordingly.</p>
|
||
<p><code>zsystem supports</code> <code>subcommand</code></p>
|
||
<p>The builtin <code>zsystem</code>’s subcommand <code>supports</code> tests whether a given
|
||
subcommand is supported. It returns status 0 if so, else status 1. It
|
||
operates silently unless there was a syntax error (i.e. the wrong number
|
||
of arguments), in which case status 255 is returned. Status 1 can
|
||
indicate one of two things: <code>subcommand</code> is known but not supported by
|
||
the current operating system, or <code>subcommand</code> is not known (possibly
|
||
because this is an older version of the shell before it was
|
||
implemented).</p>
|
||
<hr />
|
||
<p><span id="Math-Functions"></span></p>
|
||
<h3 id="22272-math-functions"><a class="header" href="#22272-math-functions">22.27.2 Math Functions</a></h3>
|
||
<ul>
|
||
<li><code>systell(fd)</code><br />
|
||
The systell math function returns the current file position for the
|
||
file descriptor passed as an argument.</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Parameters-3"></span></p>
|
||
<h3 id="22273-parameters"><a class="header" href="#22273-parameters">22.27.3 Parameters</a></h3>
|
||
<p><span id="index-errnos"></span></p>
|
||
<p><code>errnos</code></p>
|
||
<p>A readonly array of the names of errors defined on the system. These are
|
||
typically macros defined in C by including the system header file
|
||
<code>errno.h</code>. The index of each name (assuming the option <code>KSH_ARRAYS</code> is
|
||
unset) corresponds to the error number. Error numbers <code>num</code> before the
|
||
last known error which have no name are given the name <code>E``num</code> in the
|
||
array.</p>
|
||
<p>Note that aliases for errors are not handled; only the canonical name is
|
||
used.</p>
|
||
<p><span id="index-sysparams"></span></p>
|
||
<p><code>sysparams</code></p>
|
||
<p>A readonly associative array. The keys are:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>pid</code><br />
|
||
<span id="index-pid_002c-sysparams"></span></p>
|
||
<p>Returns the process ID of the current process, even in subshells.
|
||
Compare <code>$$</code>, which returns the process ID of the main shell
|
||
process.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>ppid</code><br />
|
||
<span id="index-ppid_002c-sysparams"></span></p>
|
||
<p>Returns the process ID of the parent of the current process, even in
|
||
subshells. Compare <code>$PPID</code>, which returns the process ID of the
|
||
parent of the main shell process.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>procsubstpid</code><br />
|
||
Returns the process ID of the last process started for process
|
||
substitution, i.e. the <code><(``...``)</code> and <code>>(``...``)</code> expansions.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="The-zsh_002fnet_002ftcp-Module"></span>
|
||
<span id="The-zsh_002fnet_002ftcp-Module-1"></span></p>
|
||
<h2 id="2228-the-zshnettcp-module"><a class="header" href="#2228-the-zshnettcp-module">22.28 The zsh/net/tcp Module</a></h2>
|
||
<p>The <code>zsh/net/tcp</code> module makes available one builtin command:</p>
|
||
<p><span id="index-ztcp"></span> <span id="index-TCP"></span>
|
||
<span id="index-sockets_002c-TCP"></span></p>
|
||
<p><code>ztcp</code> [ <code>-acflLtv</code> ] [ <code>-d</code> <code>fd</code> ] [ <code>args</code> ]</p>
|
||
<p><code>ztcp</code> is implemented as a builtin to allow full use of shell command
|
||
line editing, file I/O, and job control mechanisms.</p>
|
||
<p>If <code>ztcp</code> is run with no options, it will output</p>
|
||
<p>If it is run with only the option <code>-L</code>, it will output the contents of
|
||
is ignored if given with a command to open or close a session. The
|
||
output consists of a set of lines, one per session, each containing the
|
||
following elements separated by spaces:</p>
|
||
<ul>
|
||
<li>
|
||
<p>File descriptor<br />
|
||
The file descriptor in use for the connection. For normal inbound
|
||
(<code>I</code>) and outbound (<code>O</code>) connections this may be read and written by
|
||
the usual shell mechanisms. However, it should only be close with
|
||
‘<code>ztcp -c</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p>Connection type<br />
|
||
A letter indicating how the session was created:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>Z</code><br />
|
||
A session created with the <code>zftp</code> command.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>L</code><br />
|
||
A connection opened for listening with ‘<code>ztcp -l</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>I</code><br />
|
||
An inbound connection accepted with ‘<code>ztcp -a</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>O</code><br />
|
||
An outbound connection created with ‘<code>ztcp</code> <code>host</code> <code>...</code>’.</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p>The local host<br />
|
||
This is usually set to an all-zero IP address as the address of the
|
||
localhost is irrelevant.</p>
|
||
</li>
|
||
<li>
|
||
<p>The local port<br />
|
||
This is likely to be zero unless the connection is for listening.</p>
|
||
</li>
|
||
<li>
|
||
<p>The remote host<br />
|
||
This is the fully qualified domain name of the peer, if available,
|
||
else an IP address. It is an all-zero IP address for a session
|
||
opened for listening.</p>
|
||
</li>
|
||
<li>
|
||
<p>The remote port<br />
|
||
This is zero for a connection opened for listening.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Outbound-Connections"></span></p>
|
||
<h3 id="22281-outbound-connections"><a class="header" href="#22281-outbound-connections">22.28.1 Outbound Connections</a></h3>
|
||
<p><span id="index-sockets_002c-outbound-TCP"></span></p>
|
||
<ul>
|
||
<li>
|
||
<p><code>ztcp</code> [ <code>-v</code> ] [ <code>-d</code> <code>fd</code> ] <code>host</code> [ <code>port</code> ]<br />
|
||
Open a new TCP connection to <code>host</code>. If the <code>port</code> is omitted, it
|
||
will default to port 23. The connection will <code>REPLY</code> will be set to
|
||
the file descriptor associated with that connection.</p>
|
||
<p>If <code>-d</code> is specified, its argument will be taken as the target file
|
||
descriptor for the connection.</p>
|
||
<p>In order to elicit more verbose output, use <code>-v</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Inbound-Connections-1"></span></p>
|
||
<h3 id="22282-inbound-connections"><a class="header" href="#22282-inbound-connections">22.28.2 Inbound Connections</a></h3>
|
||
<p><span id="index-sockets_002c-inbound-TCP"></span></p>
|
||
<ul>
|
||
<li>
|
||
<p><code>ztcp</code> <code>-l</code> [ <code>-v</code> ] [ <code>-d</code> <code>fd</code> ] <code>port</code><br />
|
||
<code>ztcp -l</code> will open a socket listening on TCP <code>port</code>. The socket
|
||
will be added to the will be set to the file descriptor associated
|
||
with that listener.</p>
|
||
<p>If <code>-d</code> is specified, its argument will be taken as the target file
|
||
descriptor for the connection.</p>
|
||
<p>In order to elicit more verbose output, use <code>-v</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>ztcp</code> <code>-a</code> [ <code>-tv</code> ] [ <code>-d</code> <code>targetfd</code> ] <code>listenfd</code><br />
|
||
<code>ztcp -a</code> will accept an incoming connection to the port associated
|
||
with <code>listenfd</code>. The connection will be added to the session be set
|
||
to the file descriptor associated with the inbound connection.</p>
|
||
<p>If <code>-d</code> is specified, its argument will be taken as the target file
|
||
descriptor for the connection.</p>
|
||
<p>If <code>-t</code> is specified, <code>ztcp</code> will return if no incoming connection
|
||
is pending. Otherwise it will wait for one.</p>
|
||
<p>In order to elicit more verbose output, use <code>-v</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Closing-Connections"></span></p>
|
||
<h3 id="22283-closing-connections"><a class="header" href="#22283-closing-connections">22.28.3 Closing Connections</a></h3>
|
||
<p><span id="index-sockets_002c-closing-TCP"></span></p>
|
||
<ul>
|
||
<li>
|
||
<p><code>ztcp</code> <code>-cf</code> [ <code>-v</code> ] [ <code>fd</code> ]<br />
|
||
<code>ztcp</code> <code>-c</code> [ <code>-v</code> ] [ <code>fd</code> ]<br />
|
||
<code>ztcp -c</code> will close the socket associated with <code>fd</code>. The socket
|
||
will be removed from the</p>
|
||
<p>Normally, sockets registered by zftp (see <a href="Zsh-Modules.html#The-zsh_002fzftp-Module">The zsh/zftp
|
||
Module</a> ) cannot be closed this way. In
|
||
order to force such a socket closed, use <code>-f</code>.</p>
|
||
<p>In order to elicit more verbose output, use <code>-v</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Example-1"></span></p>
|
||
<h3 id="22284-example"><a class="header" href="#22284-example">22.28.4 Example</a></h3>
|
||
<p><span id="index-TCP_002c-example"></span></p>
|
||
<p>Here is how to create a TCP connection between two instances of zsh. We
|
||
need to pick an unassigned port; here we use the randomly chosen 5123.</p>
|
||
<p>On <code>host1</code>,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zmodload zsh/net/tcp
|
||
ztcp -l 5123
|
||
listenfd=$REPLY
|
||
ztcp -a $listenfd
|
||
fd=$REPLY
|
||
</code></pre>
|
||
</div>
|
||
<p>The second from last command blocks until there is an incoming
|
||
connection.</p>
|
||
<p>Now create a connection from <code>host2</code> (which may, of course, be the same
|
||
machine):</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zmodload zsh/net/tcp
|
||
ztcp host1 5123
|
||
fd=$REPLY
|
||
</code></pre>
|
||
</div>
|
||
<p>Now on each host, <code>$fd</code> contains a file descriptor for talking to the
|
||
other. For example, on <code>host1</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">print This is a message >&$fd
|
||
</code></pre>
|
||
</div>
|
||
<p>and on <code>host2</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">read -r line <&$fd; print -r - $line
|
||
</code></pre>
|
||
</div>
|
||
<p>prints ‘<code>This is a message</code>’.</p>
|
||
<p>To tidy up, on <code>host1</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">ztcp -c $listenfd
|
||
ztcp -c $fd
|
||
</code></pre>
|
||
</div>
|
||
<p>and on <code>host2</code></p>
|
||
<div class="example">
|
||
<pre><code class="language-example">ztcp -c $fd
|
||
</code></pre>
|
||
</div>
|
||
<hr />
|
||
<p><span id="The-zsh_002ftermcap-Module"></span>
|
||
<span id="The-zsh_002ftermcap-Module-1"></span></p>
|
||
<h2 id="2229-the-zshtermcap-module"><a class="header" href="#2229-the-zshtermcap-module">22.29 The zsh/termcap Module</a></h2>
|
||
<p>The <code>zsh/termcap</code> module makes available one builtin command:</p>
|
||
<p><span id="index-echotc"></span>
|
||
<span id="index-termcap-value_002c-printing"></span></p>
|
||
<p><code>echotc</code> <code>cap</code> [ <code>arg</code> ... ]</p>
|
||
<p>Output the termcap value corresponding to the capability <code>cap</code>, with
|
||
optional arguments.</p>
|
||
<p>The <code>zsh/termcap</code> module makes available one parameter:</p>
|
||
<p><span id="index-termcap"></span></p>
|
||
<p><code>termcap</code></p>
|
||
<p>An associative array that maps termcap capability codes to their values.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fterminfo-Module"></span>
|
||
<span id="The-zsh_002fterminfo-Module-1"></span></p>
|
||
<h2 id="2230-the-zshterminfo-module"><a class="header" href="#2230-the-zshterminfo-module">22.30 The zsh/terminfo Module</a></h2>
|
||
<p>The <code>zsh/terminfo</code> module makes available one builtin command:</p>
|
||
<p><span id="index-echoti"></span>
|
||
<span id="index-terminfo-value_002c-printing"></span></p>
|
||
<p><code>echoti</code> <code>cap</code> [ <code>arg</code> ]</p>
|
||
<p>Output the terminfo value corresponding to the capability <code>cap</code>,
|
||
instantiated with <code>arg</code> if applicable.</p>
|
||
<p>The <code>zsh/terminfo</code> module makes available one parameter:</p>
|
||
<p><span id="index-terminfo"></span></p>
|
||
<p><code>terminfo</code></p>
|
||
<p>An associative array that maps terminfo capability names to their
|
||
values.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fzftp-Module"></span>
|
||
<span id="The-zsh_002fzftp-Module-1"></span></p>
|
||
<h2 id="2231-the-zshzftp-module"><a class="header" href="#2231-the-zshzftp-module">22.31 The zsh/zftp Module</a></h2>
|
||
<p>The <code>zsh/zftp</code> module makes available one builtin command:</p>
|
||
<p><span id="index-zftp"></span> <span id="index-FTP"></span>
|
||
<span id="index-files_002c-transferring"></span></p>
|
||
<p><code>zftp</code> <code>subcommand</code> [ <code>args</code> ]</p>
|
||
<p>The <code>zsh/zftp</code> module is a client for FTP (file transfer protocol). It
|
||
is implemented as a builtin to allow full use of shell command line
|
||
editing, file I/O, and job control mechanisms. Often, users will access
|
||
it via shell functions providing a more powerful interface; a set is
|
||
provided with the <code>zsh</code> distribution and is described in <a href="Zftp-Function-System.html#Zftp-Function-System">Zftp Function
|
||
System</a>. However, the
|
||
<code>zftp</code> command is entirely usable in its own right.</p>
|
||
<p>All commands consist of the command name <code>zftp</code> followed by the name of
|
||
a subcommand. These are listed below. The return status of each
|
||
subcommand is supposed to reflect the success or failure of the remote
|
||
operation. See a description of the variable <code>ZFTP_VERBOSE</code> for more
|
||
information on how responses from the server may be printed.</p>
|
||
<hr />
|
||
<p><span id="Subcommands"></span></p>
|
||
<h3 id="22311-subcommands"><a class="header" href="#22311-subcommands">22.31.1 Subcommands</a></h3>
|
||
<p><span id="index-zftp_002c-subcommands"></span></p>
|
||
<p><span id="index-FTP_002c-starting-a-session"></span></p>
|
||
<p><code>open</code> <code>host</code>[<code>:``port</code>] [ <code>user</code> [ <code>password</code> [ <code>account</code> ] ] ]</p>
|
||
<p>Open a new FTP session to <code>host</code>, which may be the name of a TCP/IP
|
||
connected host or an IP number in the standard dot notation. If the
|
||
argument is in the form <code>host``:``port</code>, open a connection to TCP port
|
||
<code>port</code> instead of the standard FTP port 21. This may be the name of a
|
||
TCP service or a number: see the description of <code>ZFTP_PORT</code> below for
|
||
more information.</p>
|
||
<p>If IPv6 addresses in colon format are used, the <code>host</code> should be
|
||
surrounded by quoted square brackets to distinguish it from the <code>port</code>,
|
||
for example <code>’[fe80::203:baff:fe02:8b56]’</code>. For consistency this is
|
||
allowed with all forms of <code>host</code>.</p>
|
||
<p>Remaining arguments are passed to the <code>login</code> subcommand. Note that if
|
||
no arguments beyond <code>host</code> are supplied, <code>open</code> will <em>not</em> automatically
|
||
call <code>login</code>. If no arguments at all are supplied, <code>open</code> will use the
|
||
parameters set by the <code>params</code> subcommand.</p>
|
||
<p>After a successful open, the shell variables <code>ZFTP_HOST</code>, <code>ZFTP_PORT</code>,
|
||
<code>ZFTP_IP</code> and <code>ZFTP_SYSTEM</code> are available; see ‘Variables’ below.</p>
|
||
<p><code>login</code> [ <code>name</code> [ <code>password</code> [ <code>account</code> ] ] ]</p>
|
||
<p><code>user</code> [ <code>name</code> [ <code>password</code> [ <code>account</code> ] ] ]</p>
|
||
<p>Login the user <code>name</code> with parameters <code>password</code> and <code>account</code>. Any of
|
||
the parameters can be omitted, and will be read from standard input if
|
||
needed (<code>name</code> is always needed). If standard input is a terminal, a
|
||
prompt for each one will be printed on standard error and <code>password</code>
|
||
will not be echoed. If any of the parameters are not used, a warning
|
||
message is printed.</p>
|
||
<p>After a successful login, the shell variables <code>ZFTP_USER</code>,
|
||
<code>ZFTP_ACCOUNT</code> and <code>ZFTP_PWD</code> are available; see ‘Variables’ below.</p>
|
||
<p>This command may be re-issued when a user is already logged in, and the
|
||
server will first be reinitialized for a new user.</p>
|
||
<p><code>params</code> [ <code>host</code> [ <code>user</code> [ <code>password</code> [ <code>account</code> ] ] ] ]</p>
|
||
<p><code>params</code> <code>-</code></p>
|
||
<p>Store the given parameters for a later <code>open</code> command with no arguments.
|
||
Only those given on the command line will be remembered. If no arguments
|
||
are given, the parameters currently set are printed, although the
|
||
password will appear as a line of stars; the return status is one if no
|
||
parameters were set, zero otherwise.</p>
|
||
<p>Any of the parameters may be specified as a ‘<code>?</code>’, which may need to be
|
||
quoted to protect it from shell expansion. In this case, the appropriate
|
||
parameter will be read from stdin as with the <code>login</code> subcommand,
|
||
including special handling of <code>password</code>. If the ‘<code>?</code>’ is followed by a
|
||
string, that is used as the prompt for reading the parameter instead of
|
||
the default message (any necessary punctuation and whitespace should be
|
||
included at the end of the prompt). The first letter of the parameter
|
||
(only) may be quoted with a ‘<code>\</code>’; hence an argument <code>"\\$word"</code>
|
||
guarantees that the string from the shell parameter <code>$word</code> will be
|
||
treated literally, whether or not it begins with a ‘<code>?</code>’.</p>
|
||
<p>If instead a single ‘<code>-</code>’ is given, the existing parameters, if any, are
|
||
deleted. In that case, calling <code>open</code> with no arguments will cause an
|
||
error.</p>
|
||
<p>The list of parameters is not deleted after a <code>close</code>, however it will
|
||
be deleted if the <code>zsh/zftp</code> module is unloaded.</p>
|
||
<p>For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zftp params ftp.elsewhere.xx juser '?Password for juser: '
|
||
</code></pre>
|
||
</div>
|
||
<p>will store the host <code>ftp.elsewhere.xx</code> and the user <code>juser</code> and then
|
||
prompt the user for the corresponding password with the given prompt.</p>
|
||
<p><code>test</code></p>
|
||
<p>Test the connection; if the server has reported that it has closed the
|
||
connection (maybe due to a timeout), return status 2; if no connection
|
||
was open anyway, return status 1; else return status 0. The <code>test</code>
|
||
subcommand is silent, apart from messages printed by the <code>$ZFTP_VERBOSE</code>
|
||
mechanism, or error messages if the connection closes. There is no
|
||
network overhead for this test.</p>
|
||
<p>The test is only supported on systems with either the <code>select(2)</code> or
|
||
<code>poll(2)</code> system calls; otherwise the message ‘<code>not supported on this system</code>’ is printed instead.</p>
|
||
<p>The <code>test</code> subcommand will automatically be called at the start of any
|
||
other subcommand for the current session when a connection is open.</p>
|
||
<p><code>cd</code> <code>directory</code></p>
|
||
<p>Change the remote directory to <code>directory</code>. Also alters the shell
|
||
variable <code>ZFTP_PWD</code>.</p>
|
||
<p><code>cdup</code></p>
|
||
<p>Change the remote directory to the one higher in the directory tree.
|
||
Note that <code>cd ..</code> will also work correctly on non-UNIX systems.</p>
|
||
<p><code>dir</code> [ <code>arg</code> ... ]</p>
|
||
<p>Give a (verbose) listing of the remote directory. The <code>arg</code>s are passed
|
||
directly to the server. The command’s behaviour is implementation
|
||
dependent, but a UNIX server will typically interpret <code>arg</code>s as
|
||
arguments to the <code>ls</code> command and with no arguments return the result of
|
||
‘<code>ls -l</code>’. The directory is listed to standard output.</p>
|
||
<p><code>ls</code> [ <code>arg</code> ... ]</p>
|
||
<p>Give a (short) listing of the remote directory. With no <code>arg</code>, produces
|
||
a raw list of the files in the directory, one per line. Otherwise, up to
|
||
vagaries of the server implementation, behaves similar to <code>dir</code>.</p>
|
||
<p><code>type</code> [ <code>type</code> ]</p>
|
||
<p>Change the type for the transfer to <code>type</code>, or print the current type if
|
||
<code>type</code> is absent. The allowed values are ‘<code>A</code>’ (ASCII), ‘<code>I</code>’ (Image,
|
||
i.e. binary), or ‘<code>B</code>’ (a synonym for ‘<code>I</code>’).</p>
|
||
<p>The FTP default for a transfer is ASCII. However, if <code>zftp</code> finds that
|
||
the remote host is a UNIX machine with 8-bit byes, it will automatically
|
||
switch to using binary for file transfers upon <code>open</code>. This can
|
||
subsequently be overridden.</p>
|
||
<p>The transfer type is only passed to the remote host when a data
|
||
connection is established; this command involves no network overhead.</p>
|
||
<p><code>ascii</code></p>
|
||
<p>The same as <code>type A</code>.</p>
|
||
<p><code>binary</code></p>
|
||
<p>The same as <code>type I</code>.</p>
|
||
<p><code>mode</code> [ <code>S</code> | <code>B</code> ]</p>
|
||
<p>Set the mode type to stream (<code>S</code>) or block (<code>B</code>). Stream mode is the
|
||
default; block mode is not widely supported.</p>
|
||
<p><code>remote</code> <code>file</code> ...</p>
|
||
<p><code>local</code> [ <code>file</code> ... ]</p>
|
||
<p>Print the size and last modification time of the remote or local files.
|
||
If there is more than one item on the list, the name of the file is
|
||
printed first. The first number is the file size, the second is the last
|
||
modification time of the file in the format <code>CCYYMMDDhhmmSS</code> consisting
|
||
of year, month, date, hour, minutes and seconds in GMT. Note that this
|
||
format, including the length, is guaranteed, so that time strings can be
|
||
directly compared via the <code>[[</code> builtin’s <code><</code> and <code>></code> operators, even if
|
||
they are too long to be represented as integers.</p>
|
||
<p>Not all servers support the commands for retrieving this information. In
|
||
that case, the <code>remote</code> command will print nothing and return status 2,
|
||
compared with status 1 for a file not found.</p>
|
||
<p>The <code>local</code> command (but not <code>remote</code>) may be used with no arguments, in
|
||
which case the information comes from examining file descriptor zero.
|
||
This is the same file as seen by a <code>put</code> command with no further
|
||
redirection.</p>
|
||
<p><code>get</code> <code>file</code> ...</p>
|
||
<p>Retrieve all <code>file</code>s from the server, concatenating them and sending
|
||
them to standard output.</p>
|
||
<p><code>put</code> <code>file</code> ...</p>
|
||
<p>For each <code>file</code>, read a file from standard input and send that to the
|
||
remote host with the given name.</p>
|
||
<p><code>append</code> <code>file</code> ...</p>
|
||
<p>As <code>put</code>, but if the remote <code>file</code> already exists, data is appended to
|
||
it instead of overwriting it.</p>
|
||
<p><code>getat</code> <code>file</code> <code>point</code></p>
|
||
<p><code>putat</code> <code>file</code> <code>point</code></p>
|
||
<p><code>appendat</code> <code>file</code> <code>point</code></p>
|
||
<p>Versions of <code>get</code>, <code>put</code> and <code>append</code> which will start the transfer at
|
||
the given <code>point</code> in the remote <code>file</code>. This is useful for appending to
|
||
an incomplete local file. However, note that this ability is not
|
||
universally supported by servers (and is not quite the behaviour
|
||
specified by the standard).</p>
|
||
<p><code>delete</code> <code>file</code> ...</p>
|
||
<p>Delete the list of files on the server.</p>
|
||
<p><code>mkdir</code> <code>directory</code></p>
|
||
<p>Create a new directory <code>directory</code> on the server.</p>
|
||
<p><code>rmdir</code> <code>directory</code></p>
|
||
<p>Delete the directory <code>directory</code> on the server.</p>
|
||
<p><code>rename</code> <code>old-name</code> <code>new-name</code></p>
|
||
<p>Rename file <code>old-name</code> to <code>new-name</code> on the server.</p>
|
||
<p><code>site</code> <code>arg</code> ...</p>
|
||
<p>Send a host-specific command to the server. You will probably only need
|
||
this if instructed by the server to use it.</p>
|
||
<p><code>quote</code> <code>arg</code> ...</p>
|
||
<p>Send the raw FTP command sequence to the server. You should be familiar
|
||
with the FTP command set as defined in RFC959 before doing this. Useful
|
||
commands may include <code>STAT</code> and <code>HELP</code>. Note also the mechanism for
|
||
returning messages as described for the variable <code>ZFTP_VERBOSE</code> below,
|
||
in particular that all messages from the control connection are sent to
|
||
standard error.</p>
|
||
<p><code>close</code></p>
|
||
<p><code>quit</code></p>
|
||
<p>Close the current data connection. This unsets the shell parameters
|
||
<code>ZFTP_HOST</code>, <code>ZFTP_PORT</code>, <code>ZFTP_IP</code>, <code>ZFTP_SYSTEM</code>, <code>ZFTP_USER</code>,
|
||
<code>ZFTP_ACCOUNT</code>, <code>ZFTP_PWD</code>, <code>ZFTP_TYPE</code> and <code>ZFTP_MODE</code>.</p>
|
||
<p><code>session</code> [ <code>sessname</code> ]</p>
|
||
<p>Allows multiple FTP sessions to be used at once. The name of the session
|
||
is an arbitrary string of characters; the default session is called
|
||
‘<code>default</code>’. If this command is called without an argument, it will
|
||
list all the current sessions; with an argument, it will either switch
|
||
to the existing session called <code>sessname</code>, or create a new session of
|
||
that name.</p>
|
||
<p>Each session remembers the status of the connection, the set of
|
||
connection-specific shell parameters (the same set as are unset when a
|
||
connection closes, as given in the description of <code>close</code>), and any user
|
||
parameters specified with the <code>params</code> subcommand. Changing to a
|
||
previous session restores those values; changing to a new session
|
||
initialises them in the same way as if <code>zftp</code> had just been loaded. The
|
||
name of the current session is given by the parameter <code>ZFTP_SESSION</code>.</p>
|
||
<p><code>rmsession</code> [ <code>sessname</code> ]</p>
|
||
<p>Delete a session; if a name is not given, the current session is
|
||
deleted. If the current session is deleted, the earliest existing
|
||
session becomes the new current session, otherwise the current session
|
||
is not changed. If the session being deleted is the only one, a new
|
||
session called ‘<code>default</code>’ is created and becomes the current session;
|
||
note that this is a new session even if the session being deleted is
|
||
also called ‘<code>default</code>’. It is recommended that sessions not be deleted
|
||
while background commands which use <code>zftp</code> are still active.</p>
|
||
<hr />
|
||
<p><span id="Parameters-2"></span></p>
|
||
<h3 id="22312-parameters"><a class="header" href="#22312-parameters">22.31.2 Parameters</a></h3>
|
||
<p><span id="index-zftp_002c-parameters"></span></p>
|
||
<p>The following shell parameters are used by <code>zftp</code>. Currently none of
|
||
them are special.</p>
|
||
<p><span id="index-ZFTP_005fTMOUT"></span></p>
|
||
<p><code>ZFTP_TMOUT</code></p>
|
||
<p>Integer. The time in seconds to wait for a network operation to complete
|
||
before returning an error. If this is not set when the module is loaded,
|
||
it will be given the default value 60. A value of zero turns off
|
||
timeouts. If a timeout occurs on the control connection it will be
|
||
closed. Use a larger value if this occurs too frequently.</p>
|
||
<p><span id="index-ZFTP_005fIP"></span></p>
|
||
<p><code>ZFTP_IP</code></p>
|
||
<p>Readonly. The IP address of the current connection in dot notation.</p>
|
||
<p><span id="index-ZFTP_005fHOST"></span></p>
|
||
<p><code>ZFTP_HOST</code></p>
|
||
<p>Readonly. The hostname of the current remote server. If the host was
|
||
opened as an IP number, <code>ZFTP_HOST</code> contains that instead; this saves
|
||
the overhead for a name lookup, as IP numbers are most commonly used
|
||
when a nameserver is unavailable.</p>
|
||
<p><span id="index-ZFTP_005fPORT"></span></p>
|
||
<p><code>ZFTP_PORT</code></p>
|
||
<p>Readonly. The number of the remote TCP port to which the connection is
|
||
open (even if the port was originally specified as a named service).
|
||
Usually this is the standard FTP port, 21.</p>
|
||
<p>In the unlikely event that your system does not have the appropriate
|
||
conversion functions, this appears in network byte order. If your system
|
||
is little-endian, the port then consists of two swapped bytes and the
|
||
standard port will be reported as 5376. In that case, numeric ports
|
||
passed to <code>zftp open</code> will also need to be in this format.</p>
|
||
<p><span id="index-ZFTP_005fSYSTEM"></span></p>
|
||
<p><code>ZFTP_SYSTEM</code></p>
|
||
<p>Readonly. The system type string returned by the server in response to
|
||
an FTP <code>SYST</code> request. The most interesting case is a string beginning
|
||
<code>"UNIX Type: L8"</code>, which ensures maximum compatibility with a local UNIX
|
||
host.</p>
|
||
<p><span id="index-ZFTP_005fTYPE"></span></p>
|
||
<p><code>ZFTP_TYPE</code></p>
|
||
<p>Readonly. The type to be used for data transfers , either ‘<code>A</code>’ or
|
||
‘<code>I</code>’. Use the <code>type</code> subcommand to change this.</p>
|
||
<p><span id="index-ZFTP_005fUSER"></span></p>
|
||
<p><code>ZFTP_USER</code></p>
|
||
<p>Readonly. The username currently logged in, if any.</p>
|
||
<p><span id="index-ZFTP_005fACCOUNT"></span></p>
|
||
<p><code>ZFTP_ACCOUNT</code></p>
|
||
<p>Readonly. The account name of the current user, if any. Most servers do
|
||
not require an account name.</p>
|
||
<p><span id="index-ZFTP_005fPWD"></span></p>
|
||
<p><code>ZFTP_PWD</code></p>
|
||
<p>Readonly. The current directory on the server.</p>
|
||
<p><span id="index-ZFTP_005fCODE"></span></p>
|
||
<p><code>ZFTP_CODE</code></p>
|
||
<p>Readonly. The three digit code of the last FTP reply from the server as
|
||
a string. This can still be read after the connection is closed, and is
|
||
not changed when the current session changes.</p>
|
||
<p><span id="index-ZFTP_005fREPLY"></span></p>
|
||
<p><code>ZFTP_REPLY</code></p>
|
||
<p>Readonly. The last line of the last reply sent by the server. This can
|
||
still be read after the connection is closed, and is not changed when
|
||
the current session changes.</p>
|
||
<p><span id="index-ZFTP_005fSESSION"></span></p>
|
||
<p><code>ZFTP_SESSION</code></p>
|
||
<p>Readonly. The name of the current FTP session; see the description of
|
||
the <code>session</code> subcommand.</p>
|
||
<p><span id="index-ZFTP_005fPREFS"></span></p>
|
||
<p><code>ZFTP_PREFS</code></p>
|
||
<p>A string of preferences for altering aspects of <code>zftp</code>’s behaviour. Each
|
||
preference is a single character. The following are defined:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>P</code><br />
|
||
Passive: attempt to make the remote server initiate data transfers.
|
||
This is slightly more efficient than sendport mode. If the letter
|
||
<code>S</code> occurs later in the string, <code>zftp</code> will use sendport mode if
|
||
passive mode is not available.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>S</code><br />
|
||
Sendport: initiate transfers by the FTP <code>PORT</code> command. If this
|
||
occurs before any <code>P</code> in the string, passive mode will never be
|
||
attempted.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>D</code><br />
|
||
Dumb: use only the bare minimum of FTP commands. This prevents the
|
||
variables <code>ZFTP_SYSTEM</code> and <code>ZFTP_PWD</code> from being set, and will mean
|
||
all connections default to ASCII type. It may prevent <code>ZFTP_SIZE</code>
|
||
from being set during a transfer if the server does not send it
|
||
anyway (many servers do).</p>
|
||
</li>
|
||
</ul>
|
||
<p>If <code>ZFTP_PREFS</code> is not set when <code>zftp</code> is loaded, it will be set to a
|
||
default of ‘<code>PS</code>’, i.e. use passive mode if available, otherwise fall
|
||
back to sendport mode.</p>
|
||
<p><span id="index-ZFTP_005fVERBOSE"></span></p>
|
||
<p><code>ZFTP_VERBOSE</code></p>
|
||
<p>A string of digits between 0 and 5 inclusive, specifying which responses
|
||
from the server should be printed. All responses go to standard error.
|
||
If any of the numbers 1 to 5 appear in the string, raw responses from
|
||
the server with reply codes beginning with that digit will be printed to
|
||
standard error. The first digit of the three digit reply code is defined
|
||
by RFC959 to correspond to:</p>
|
||
<ul>
|
||
<li>
|
||
<p>1.<br />
|
||
A positive preliminary reply.</p>
|
||
</li>
|
||
<li>
|
||
<p>2.<br />
|
||
A positive completion reply.</p>
|
||
</li>
|
||
<li>
|
||
<p>3.<br />
|
||
A positive intermediate reply.</p>
|
||
</li>
|
||
<li>
|
||
<p>4.<br />
|
||
A transient negative completion reply.</p>
|
||
</li>
|
||
<li>
|
||
<p>5.<br />
|
||
A permanent negative completion reply.</p>
|
||
</li>
|
||
</ul>
|
||
<p>It should be noted that, for unknown reasons, the reply ‘Service not
|
||
available’, which forces termination of a connection, is classified as
|
||
421, i.e. ‘transient negative’, an interesting interpretation of the
|
||
word ‘transient’.</p>
|
||
<p>The code 0 is special: it indicates that all but the last line of
|
||
multiline replies read from the server will be printed to standard error
|
||
in a processed format. By convention, servers use this mechanism for
|
||
sending information for the user to read. The appropriate reply code, if
|
||
it matches the same response, takes priority.</p>
|
||
<p>If <code>ZFTP_VERBOSE</code> is not set when <code>zftp</code> is loaded, it will be set to
|
||
the default value <code>450</code>, i.e., messages destined for the user and all
|
||
errors will be printed. A null string is valid and specifies that no
|
||
messages should be printed.</p>
|
||
<hr />
|
||
<p><span id="Functions-1"></span></p>
|
||
<h3 id="22313-functions"><a class="header" href="#22313-functions">22.31.3 Functions</a></h3>
|
||
<p><span id="index-zftp_002c-functions"></span></p>
|
||
<p><span id="index-zftp_005fchpwd_002c-specification"></span></p>
|
||
<p><code>zftp_chpwd</code></p>
|
||
<p>If this function is set by the user, it is called every time the
|
||
directory changes on the server, including when a user is logged in, or
|
||
when a connection is closed. In the last case, <code>$ZFTP_PWD</code> will be
|
||
unset; otherwise it will reflect the new directory.</p>
|
||
<p><span id="index-zftp_005fprogress_002c-specification"></span></p>
|
||
<p><code>zftp_progress</code></p>
|
||
<p>If this function is set by the user, it will be called during a <code>get</code>,
|
||
<code>put</code> or <code>append</code> operation each time sufficient data has been received
|
||
from the host. During a <code>get</code>, the data is sent to standard output, so
|
||
it is vital that this function should write to standard error or
|
||
directly to the terminal, <em>not</em> to standard output.</p>
|
||
<p>When it is called with a transfer in progress, the following additional
|
||
shell parameters are set:</p>
|
||
<p><span id="index-ZFTP_005fFILE"></span></p>
|
||
<p><code>ZFTP_FILE</code></p>
|
||
<p>The name of the remote file being transferred from or to.</p>
|
||
<p><span id="index-ZFTP_005fTRANSFER"></span></p>
|
||
<p><code>ZFTP_TRANSFER</code></p>
|
||
<p>A <code>G</code> for a <code>get</code> operation and a <code>P</code> for a <code>put</code> operation.</p>
|
||
<p><span id="index-ZFTP_005fSIZE"></span></p>
|
||
<p><code>ZFTP_SIZE</code></p>
|
||
<p>The total size of the complete file being transferred: the same as the
|
||
first value provided by the <code>remote</code> and <code>local</code> subcommands for a
|
||
particular file. If the server cannot supply this value for a remote
|
||
file being retrieved, it will not be set. If input is from a pipe the
|
||
value may be incorrect and correspond simply to a full pipe buffer.</p>
|
||
<p><span id="index-ZFTP_005fCOUNT"></span></p>
|
||
<p><code>ZFTP_COUNT</code></p>
|
||
<p>The amount of data so far transferred; a number between zero and
|
||
<code>$ZFTP_SIZE</code>, if that is set. This number is always available.</p>
|
||
<p>The function is initially called with <code>ZFTP_TRANSFER</code> set appropriately
|
||
and <code>ZFTP_COUNT</code> set to zero. After the transfer is finished, the
|
||
function will be called one more time with <code>ZFTP_TRANSFER</code> set to <code>GF</code>
|
||
or <code>PF</code>, in case it wishes to tidy up. It is otherwise never called
|
||
twice with the same value of <code>ZFTP_COUNT</code>.</p>
|
||
<p>Sometimes the progress meter may cause disruption. It is up to the user
|
||
to decide whether the function should be defined and to use <code>unfunction</code>
|
||
when necessary.</p>
|
||
<hr />
|
||
<p><span id="Problems"></span></p>
|
||
<h3 id="22314-problems"><a class="header" href="#22314-problems">22.31.4 Problems</a></h3>
|
||
<p><span id="index-zftp_002c-problems"></span></p>
|
||
<p>A connection may not be opened in the left hand side of a pipe as this
|
||
occurs in a subshell and the file information is not updated in the main
|
||
shell. In the case of type or mode changes or closing the connection in
|
||
a subshell, the information is returned but variables are not updated
|
||
until the next call to <code>zftp</code>. Other status changes in subshells will
|
||
not be reflected by changes to the variables (but should be otherwise
|
||
harmless).</p>
|
||
<p>Deleting sessions while a <code>zftp</code> command is active in the background can
|
||
have unexpected effects, even if it does not use the session being
|
||
deleted. This is because all shell subprocesses share information on the
|
||
state of all connections, and deleting a session changes the ordering of
|
||
that information.</p>
|
||
<p>On some operating systems, the control connection is not valid after a
|
||
fork(), so that operations in subshells, on the left hand side of a
|
||
pipeline, or in the background are not possible, as they should be. This
|
||
is presumably a bug in the operating system.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fzle-Module"></span>
|
||
<span id="The-zsh_002fzle-Module-1"></span></p>
|
||
<h2 id="2232-the-zshzle-module"><a class="header" href="#2232-the-zshzle-module">22.32 The zsh/zle Module</a></h2>
|
||
<p>The <code>zsh/zle</code> module contains the Zsh Line Editor. See <a href="Zsh-Line-Editor.html#Zsh-Line-Editor">Zsh Line
|
||
Editor</a>.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fzleparameter-Module"></span>
|
||
<span id="The-zsh_002fzleparameter-Module-1"></span></p>
|
||
<h2 id="2233-the-zshzleparameter-module"><a class="header" href="#2233-the-zshzleparameter-module">22.33 The zsh/zleparameter Module</a></h2>
|
||
<p><span id="index-parameters_002c-special-2"></span></p>
|
||
<p>The <code>zsh/zleparameter</code> module defines two special parameters that can be
|
||
used to access internal information of the Zsh Line Editor (see <a href="Zsh-Line-Editor.html#Zsh-Line-Editor">Zsh
|
||
Line Editor</a>).</p>
|
||
<p><span id="index-keymaps-2"></span></p>
|
||
<p><code>keymaps</code></p>
|
||
<p>This array contains the names of the keymaps currently defined.</p>
|
||
<p><span id="index-widgets-1"></span></p>
|
||
<p><code>widgets</code></p>
|
||
<p>This associative array contains one entry per widget. The name of the
|
||
widget is the key and the value gives information about the widget. It
|
||
is either the string ‘<code>builtin</code>’ for builtin widgets, a string of the
|
||
form ‘<code>user:``name</code>’ for user-defined widgets, where <code>name</code> is the name
|
||
of the shell function implementing the widget, a string of the form
|
||
‘<code>completion:``type``:``name</code>’ for completion widgets, or a null value
|
||
if the widget is not yet fully defined. In the penultimate case, <code>type</code>
|
||
is the name of the builtin widget the completion widget imitates in its
|
||
behavior and <code>name</code> is the name of the shell function implementing the
|
||
completion widget.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fzprof-Module"></span>
|
||
<span id="The-zsh_002fzprof-Module-1"></span></p>
|
||
<h2 id="2234-the-zshzprof-module"><a class="header" href="#2234-the-zshzprof-module">22.34 The zsh/zprof Module</a></h2>
|
||
<p><span id="index-functions_002c-profiling"></span></p>
|
||
<p>When loaded, the <code>zsh/zprof</code> causes shell functions to be profiled. The
|
||
profiling results can be obtained with the <code>zprof</code> builtin command made
|
||
available by this module. There is no way to turn profiling off other
|
||
than unloading the module.</p>
|
||
<p><span id="index-zprof"></span></p>
|
||
<p><code>zprof</code> [ <code>-c</code> ]</p>
|
||
<p>Without the <code>-c</code> option, <code>zprof</code> lists profiling results to standard
|
||
output. The format is comparable to that of commands like <code>gprof</code>.</p>
|
||
<p>At the top there is a summary listing all functions that were called at
|
||
least once. This summary is sorted in decreasing order of the amount of
|
||
time spent in each. The lines contain the number of the function in
|
||
order, which is used in other parts of the list in suffixes of the form
|
||
‘<code>[``num``]</code>’, then the number of calls made to the function. The next
|
||
three columns list the time in milliseconds spent in the function and
|
||
its descendants, the average time in milliseconds spent in the function
|
||
and its descendants per call and the percentage of time spent in all
|
||
shell functions used in this function and its descendants. The following
|
||
three columns give the same information, but counting only the time
|
||
spent in the function itself. The final column shows the name of the
|
||
function.</p>
|
||
<p>After the summary, detailed information about every function that was
|
||
invoked is listed, sorted in decreasing order of the amount of time
|
||
spent in each function and its descendants. Each of these entries
|
||
consists of descriptions for the functions that called the function
|
||
described, the function itself, and the functions that were called from
|
||
it. The description for the function itself has the same format as in
|
||
the summary (and shows the same information). The other lines don’t show
|
||
the number of the function at the beginning and have their function
|
||
named indented to make it easier to distinguish the line showing the
|
||
function described in the section from the surrounding lines.</p>
|
||
<p>The information shown in this case is almost the same as in the summary,
|
||
but only refers to the call hierarchy being displayed. For example, for
|
||
a calling function the column showing the total running time lists the
|
||
time spent in the described function and its descendants only for the
|
||
times when it was called from that particular calling function.
|
||
Likewise, for a called function, this columns lists the total time spent
|
||
in the called function and its descendants only for the times when it
|
||
was called from the function described.</p>
|
||
<p>Also in this case, the column showing the number of calls to a function
|
||
also shows a slash and then the total number of invocations made to the
|
||
called function.</p>
|
||
<p>As long as the <code>zsh/zprof</code> module is loaded, profiling will be done and
|
||
multiple invocations of the <code>zprof</code> builtin command will show the times
|
||
and numbers of calls since the module was loaded. With the <code>-c</code> option,
|
||
the <code>zprof</code> builtin command will reset its internal counters and will
|
||
not show the listing.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fzpty-Module"></span>
|
||
<span id="The-zsh_002fzpty-Module-1"></span></p>
|
||
<h2 id="2235-the-zshzpty-module"><a class="header" href="#2235-the-zshzpty-module">22.35 The zsh/zpty Module</a></h2>
|
||
<p>The <code>zsh/zpty</code> module offers one builtin:</p>
|
||
<p><span id="index-zpty"></span></p>
|
||
<p><code>zpty</code> [ <code>-e</code> ] [ <code>-b</code> ] <code>name</code> [ <code>arg</code> ... ]</p>
|
||
<p>The arguments following <code>name</code> are concatenated with spaces between,
|
||
then executed as a command, as if passed to the <code>eval</code> builtin. The
|
||
command runs under a newly assigned pseudo-terminal; this is useful for
|
||
running commands non-interactively which expect an interactive
|
||
environment. The <code>name</code> is not part of the command, but is used to refer
|
||
to this command in later calls to <code>zpty</code>.</p>
|
||
<p>With the <code>-e</code> option, the pseudo-terminal is set up so that input
|
||
characters are echoed.</p>
|
||
<p>With the <code>-b</code> option, input to and output from the pseudo-terminal are
|
||
made non-blocking.</p>
|
||
<p>The shell parameter <code>REPLY</code> is set to the file descriptor assigned to
|
||
the master side of the pseudo-terminal. This allows the terminal to be
|
||
monitored with ZLE descriptor handlers (see <a href="Zsh-Line-Editor.html#Zle-Builtins">Zle
|
||
Builtins</a>) or manipulated with
|
||
<code>sysread</code> and <code>syswrite</code> (see <a href="Zsh-Modules.html#The-zsh_002fsystem-Module">The zsh/system
|
||
Module</a>). <em>Warning</em>: Use of <code>sysread</code> and
|
||
<code>syswrite</code> is <em>not</em> recommended; use <code>zpty -r</code> and <code>zpty -w</code> unless you
|
||
know exactly what you are doing.</p>
|
||
<p><code>zpty</code> <code>-d</code> [ <code>name</code> ... ]</p>
|
||
<p>The second form, with the <code>-d</code> option, is used to delete commands
|
||
previously started, by supplying a list of their <code>name</code>s. If no <code>name</code>
|
||
is given, all commands are deleted. Deleting a command causes the HUP
|
||
signal to be sent to the corresponding process.</p>
|
||
<p><code>zpty</code> <code>-w</code> [ <code>-n</code> ] <code>name</code> [ <code>string</code> ... ]</p>
|
||
<p>The <code>-w</code> option can be used to send the to command <code>name</code> the given
|
||
<code>string</code>s as input (separated by spaces). If the <code>-n</code> option is <em>not</em>
|
||
given, a newline is added at the end.</p>
|
||
<p>If no <code>string</code> is provided, the standard input is copied to the
|
||
pseudo-terminal; this may stop before copying the full input if the
|
||
pseudo-terminal is non-blocking. The exact input is always copied: the
|
||
<code>-n</code> option is not applied.</p>
|
||
<p>Note that the command under the pseudo-terminal sees this input as if it
|
||
were typed, so beware when sending special tty driver characters such as
|
||
word-erase, line-kill, and end-of-file.</p>
|
||
<p><code>zpty</code> <code>-r</code> [ <code>-mt</code> ] <code>name</code> [ <code>param</code> [ <code>pattern</code> ] ]</p>
|
||
<p>The <code>-r</code> option can be used to read the output of the command <code>name</code>.
|
||
With only a <code>name</code> argument, the output read is copied to the standard
|
||
output. Unless the pseudo-terminal is non-blocking, copying continues
|
||
until the command under the pseudo-terminal exits; when non-blocking,
|
||
only as much output as is immediately available is copied. The return
|
||
status is zero if any output is copied.</p>
|
||
<p>When also given a <code>param</code> argument, at most one line is read and stored
|
||
in the parameter named <code>param</code>. Less than a full line may be read if the
|
||
pseudo-terminal is non-blocking. The return status is zero if at least
|
||
one character is stored in <code>param</code>.</p>
|
||
<p>If a <code>pattern</code> is given as well, output is read until the whole string
|
||
read matches the <code>pattern</code>, even in the non-blocking case. The return
|
||
status is zero if the string read matches the pattern, or if the command
|
||
has exited but at least one character could still be read. If the option
|
||
<code>-m</code> is present, the return status is zero only if the pattern matches.
|
||
As of this writing, a maximum of one megabyte of output can be consumed
|
||
this way; if a full megabyte is read without matching the pattern, the
|
||
return status is non-zero.</p>
|
||
<p>In all cases, the return status is non-zero if nothing could be read,
|
||
and is <code>2</code> if this is because the command has finished.</p>
|
||
<p>If the <code>-r</code> option is combined with the <code>-t</code> option, <code>zpty</code> tests
|
||
whether output is available before trying to read. If no output is
|
||
available, <code>zpty</code> immediately returns the status <code>1</code>. When used with a
|
||
<code>pattern</code>, the behaviour on a failed poll is similar to when the command
|
||
has exited: the return value is zero if at least one character could
|
||
still be read even if the pattern failed to match.</p>
|
||
<p><code>zpty</code> <code>-t</code> <code>name</code></p>
|
||
<p>The <code>-t</code> option without the <code>-r</code> option can be used to test whether the
|
||
command <code>name</code> is still running. It returns a zero status if the command
|
||
is running and a non-zero value otherwise.</p>
|
||
<p><code>zpty</code> [ <code>-L</code> ]</p>
|
||
<p>The last form, without any arguments, is used to list the commands
|
||
currently defined. If the <code>-L</code> option is given, this is done in the form
|
||
of calls to the <code>zpty</code> builtin.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fzselect-Module"></span>
|
||
<span id="The-zsh_002fzselect-Module-1"></span></p>
|
||
<h2 id="2236-the-zshzselect-module"><a class="header" href="#2236-the-zshzselect-module">22.36 The zsh/zselect Module</a></h2>
|
||
<p>The <code>zsh/zselect</code> module makes available one builtin command:</p>
|
||
<p><span id="index-zselect"></span>
|
||
<span id="index-select_002c-system-call"></span>
|
||
<span id="index-file-descriptors_002c-waiting-for"></span></p>
|
||
<p><code>zselect</code> [ <code>-rwe</code> ] [ <code>-t</code> <code>timeout</code> ] [ <code>-a</code> <code>array</code> ] [ <code>-A</code>
|
||
<code>assoc</code> ] [ <code>fd</code> ... ]</p>
|
||
<p>The <code>zselect</code> builtin is a front-end to the ‘select’ system call, which
|
||
blocks until a file descriptor is ready for reading or writing, or has
|
||
an error condition, with an optional timeout. If this is not available
|
||
on your system, the command prints an error message and returns status 2
|
||
(normal errors return status 1). For more information, see your systems
|
||
documentation for man page select(3). Note there is no connection with
|
||
the shell builtin of the same name.</p>
|
||
<p>Arguments and options may be intermingled in any order. Non-option
|
||
arguments are file descriptors, which must be decimal integers. By
|
||
default, file descriptors are to be tested for reading, i.e. <code>zselect</code>
|
||
will return when data is available to be read from the file descriptor,
|
||
or more precisely, when a read operation from the file descriptor will
|
||
not block. After a <code>-r</code>, <code>-w</code> and <code>-e</code>, the given file descriptors are
|
||
to be tested for reading, writing, or error conditions. These options
|
||
and an arbitrary list of file descriptors may be given in any order.</p>
|
||
<p>(The presence of an ‘error condition’ is not well defined in the
|
||
documentation for many implementations of the select system call.
|
||
According to recent versions of the POSIX specification, it is really an
|
||
<em>exception</em> condition, of which the only standard example is out-of-band
|
||
data received on a socket. So zsh users are unlikely to find the <code>-e</code>
|
||
option useful.)</p>
|
||
<p>The option ‘<code>-t</code> <code>timeout</code>’ specifies a timeout in hundredths of a
|
||
second. This may be zero, in which case the file descriptors will simply
|
||
be polled and <code>zselect</code> will return immediately. It is possible to call
|
||
zselect with no file descriptors and a non-zero timeout for use as a
|
||
finer-grained replacement for ‘sleep’; note, however, the return status
|
||
is always 1 for a timeout.</p>
|
||
<p>The option ‘<code>-a</code> <code>array</code>’ indicates that <code>array</code> should be set to
|
||
indicate the file descriptor(s) which are ready. If the option is not
|
||
given, the array <code>reply</code> will be used for this purpose. The array will
|
||
contain a string similar to the arguments for <code>zselect</code>. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zselect -t 0 -r 0 -w 1
|
||
</code></pre>
|
||
</div>
|
||
<p>might return immediately with status 0 and <code>$reply</code> containing ‘<code>-r 0 -w 1</code>’ to show that both file descriptors are ready for the requested
|
||
operations.</p>
|
||
<p>The option ‘<code>-A</code> <code>assoc</code>’ indicates that the associative array <code>assoc</code>
|
||
should be set to indicate the file descriptor(s) which are ready. This
|
||
option overrides the option <code>-a</code>, nor will <code>reply</code> be modified. The keys
|
||
of <code>assoc</code> are the file descriptors, and the corresponding values are
|
||
any of the characters ‘<code>rwe</code>’ to indicate the condition.</p>
|
||
<p>The command returns status 0 if some file descriptors are ready for
|
||
reading. If the operation timed out, or a timeout of 0 was given and no
|
||
file descriptors were ready, or there was an error, it returns status 1
|
||
and the array will not be set (nor modified in any way). If there was an
|
||
error in the select operation the appropriate error message is printed.</p>
|
||
<hr />
|
||
<p><span id="The-zsh_002fzutil-Module"></span>
|
||
<span id="The-zsh_002fzutil-Module-1"></span></p>
|
||
<h2 id="2237-the-zshzutil-module"><a class="header" href="#2237-the-zshzutil-module">22.37 The zsh/zutil Module</a></h2>
|
||
<p><span id="index-builtins_002c-utility"></span></p>
|
||
<p>The <code>zsh/zutil</code> module only adds some builtins:</p>
|
||
<p><span id="index-zstyle"></span></p>
|
||
<p><code>zstyle</code> [ <code>-L</code> [ <code>metapattern</code> [ <code>style</code> ] ] ]</p>
|
||
<p><code>zstyle</code> [ <code>-e</code> | <code>-</code> | <code>-``-</code> ] <code>pattern</code> <code>style</code> <code>string</code> ...</p>
|
||
<p><code>zstyle -d</code> [ <code>pattern</code> [ <code>style</code> ... ] ]</p>
|
||
<p><code>zstyle -g</code> <code>name</code> [ <code>pattern</code> [ <code>style</code> ] ]</p>
|
||
<p><code>zstyle -</code>{<code>a</code>|<code>b</code>|<code>s</code>} <code>context</code> <code>style</code> <code>name</code> [ <code>sep</code> ]</p>
|
||
<p><code>zstyle -</code>{<code>T</code>|<code>t</code>} <code>context</code> <code>style</code> [ <code>string</code> ... ]</p>
|
||
<p><code>zstyle -m</code> <code>context</code> <code>style</code> <code>pattern</code></p>
|
||
<p>This builtin command is used to define and lookup styles. Styles are
|
||
pairs of names and values, where the values consist of any number of
|
||
strings. They are stored together with patterns and lookup is done by
|
||
giving a string, called the ‘<em>context</em>’, which is matched against the
|
||
patterns. The definition stored for the most specific pattern that
|
||
matches will be returned.</p>
|
||
<p>A pattern is considered to be more specific than another if it contains
|
||
more components (substrings separated by colons) or if the patterns for
|
||
the components are more specific, where simple strings are considered to
|
||
be more specific than patterns and complex patterns are considered to be
|
||
more specific than the pattern ‘<code>*</code>’. A ‘<code>*</code>’ in the pattern will match
|
||
zero or more characters in the context; colons are not treated specially
|
||
in this regard. If two patterns are equally specific, the tie is broken
|
||
in favour of the pattern that was defined first.</p>
|
||
<p><em>Example</em></p>
|
||
<p>For example, to define your preferred form of precipitation depending on
|
||
which city you’re in, you might set the following in your <code>zshrc</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':weather:europe:*' preferred-precipitation rain
|
||
zstyle ':weather:europe:germany:* preferred-precipitation none
|
||
zstyle ':weather:europe:germany:*:munich' preferred-precipitation snow
|
||
</code></pre>
|
||
</div>
|
||
<p>Then, the fictional ‘<code>weather</code>’ plugin might run under the hood a
|
||
command such as</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle -s ":weather:${continent}:${country}:${county}:${city}" preferred-precipitation REPLY
|
||
</code></pre>
|
||
</div>
|
||
<p>in order to retrieve your preference into the scalar variable <code>$REPLY</code>.</p>
|
||
<p><em>Usage</em></p>
|
||
<p>The forms that operate on patterns are the following.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>zstyle</code> [ <code>-L</code> [ <code>metapattern</code> [ <code>style</code> ] ] ]<br />
|
||
Without arguments, lists style definitions. Styles are shown in
|
||
alphabetic order and patterns are shown in the order <code>zstyle</code> will
|
||
test them.</p>
|
||
<p>If the <code>-L</code> option is given, listing is done in the form of calls to
|
||
<code>zstyle</code>. The optional first argument, <code>metapattern</code>, is a pattern
|
||
which will be matched against the string supplied as <code>pattern</code> when
|
||
the style was defined. Note: this means, for example, ‘<code>zstyle -L ":completion:*"</code>’ will match any supplied pattern beginning
|
||
‘<code>:completion:</code>’, not just <code>":completion:*"</code>: use
|
||
<code>’:completion:\*’</code> to match that. The optional second argument
|
||
limits the output to a specific <code>style</code> (not a pattern). <code>-L</code> is not
|
||
compatible with any other options.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zstyle</code> [ <code>-</code> | <code>-``-</code> | <code>-e</code> ] <code>pattern</code> <code>style</code> <code>string</code> ...<br />
|
||
<span id="index-reply_002c-use-of-4"></span></p>
|
||
<p>Defines the given <code>style</code> for the <code>pattern</code> with the <code>string</code>s as
|
||
the value. If the <code>-e</code> option is given, the <code>string</code>s will be
|
||
concatenated (separated by spaces) and the resulting string will be
|
||
evaluated (in the same way as it is done by the <code>eval</code> builtin
|
||
command) when the style is looked up. In this case the parameter
|
||
‘<code>reply</code>’ must be assigned to set the strings returned after the
|
||
evaluation. Before evaluating the value, <code>reply</code> is unset, and if it
|
||
is still unset after the evaluation, the style is treated as if it
|
||
were not set.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zstyle -d</code> [ <code>pattern</code> [ <code>style</code> ... ] ]<br />
|
||
Delete style definitions. Without arguments all definitions are
|
||
deleted, with a <code>pattern</code> all definitions for that pattern are
|
||
deleted and if any <code>style</code>s are given, then only those styles are
|
||
deleted for the <code>pattern</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zstyle -g</code> <code>name</code> [ <code>pattern</code> [ <code>style</code> ] ]<br />
|
||
Retrieve a style definition. The <code>name</code> is used as the name of an
|
||
array in which the results are stored. Without any further
|
||
arguments, all patterns defined are returned. With a <code>pattern</code> the
|
||
styles defined for that pattern are returned and with both a
|
||
<code>pattern</code> and a <code>style</code>, the value strings of that combination is
|
||
returned.</p>
|
||
</li>
|
||
</ul>
|
||
<p>The other forms can be used to look up or test styles for a given
|
||
context.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>zstyle -s</code> <code>context</code> <code>style</code> <code>name</code> [ <code>sep</code> ]<br />
|
||
The parameter <code>name</code> is set to the value of the style interpreted as
|
||
a string. If the value contains several strings they are
|
||
concatenated with spaces (or with the <code>sep</code> string if that is given)
|
||
between them.</p>
|
||
<p>Return <code>0</code> if the style is set, <code>1</code> otherwise.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zstyle -b</code> <code>context</code> <code>style</code> <code>name</code><br />
|
||
The value is stored in <code>name</code> as a boolean, i.e. as the string
|
||
‘<code>yes</code>’ if the value has only one string and that string is equal
|
||
to one of ‘<code>yes</code>’, ‘<code>true</code>’, ‘<code>on</code>’, or ‘<code>1</code>’. If the value is any
|
||
other string or has more than one string, the parameter is set to
|
||
‘<code>no</code>’.</p>
|
||
<p>Return <code>0</code> if <code>name</code> is set to ‘<code>yes</code>’, <code>1</code> otherwise.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zstyle -a</code> <code>context</code> <code>style</code> <code>name</code><br />
|
||
The value is stored in <code>name</code> as an array. If <code>name</code> is declared as
|
||
an associative array, the first, third, etc. strings are used as the
|
||
keys and the other strings are used as the values.</p>
|
||
<p>Return <code>0</code> if the style is set, <code>1</code> otherwise.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zstyle -t</code> <code>context</code> <code>style</code> [ <code>string</code> ... ]<br />
|
||
<code>zstyle -T</code> <code>context</code> <code>style</code> [ <code>string</code> ... ]<br />
|
||
Test the value of a style, i.e. the <code>-t</code> option only returns a
|
||
status (sets <code>$?</code>). Without any <code>string</code> the return status is zero
|
||
if the style is defined for at least one matching pattern, has only
|
||
one string in its value, and that is equal to one of ‘<code>true</code>’,
|
||
‘<code>yes</code>’, ‘<code>on</code>’ or ‘<code>1</code>’. If any <code>string</code>s are given the status is
|
||
zero if and only if at least one of the <code>string</code>s is equal to at
|
||
least one of the strings in the value. If the style is defined but
|
||
doesn’t match, the return status is <code>1</code>. If the style is not
|
||
defined, the status is <code>2</code>.</p>
|
||
<p>The <code>-T</code> option tests the values of the style like <code>-t</code>, but it
|
||
returns status zero (rather than <code>2</code>) if the style is not defined
|
||
for any matching pattern.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zstyle -m</code> <code>context</code> <code>style</code> <code>pattern</code><br />
|
||
Match a value. Returns status zero if the <code>pattern</code> matches at least
|
||
one of the strings in the value.</p>
|
||
</li>
|
||
</ul>
|
||
<p><span id="index-zformat"></span></p>
|
||
<p><code>zformat -f</code> <code>param</code> <code>format</code> <code>spec</code> ...</p>
|
||
<p><code>zformat -a</code> <code>array</code> <code>sep</code> <code>spec</code> ...</p>
|
||
<p>This builtin provides two different forms of formatting. The first form
|
||
is selected with the <code>-f</code> option. In this case the <code>format</code> string will
|
||
be modified by replacing sequences starting with a percent sign in it
|
||
with strings from the <code>spec</code>s. Each <code>spec</code> should be of the form
|
||
‘<code>char``:``string</code>’ which will cause every appearance of the sequence
|
||
‘<code>%``char</code>’ in <code>format</code> to be replaced by the <code>string</code>. The ‘<code>%</code>’
|
||
sequence may also contain optional minimum and maximum field width
|
||
specifications between the ‘<code>%</code>’ and the ‘<code>char</code>’ in the form
|
||
‘<code>%``min``.``max``c</code>’, i.e. the minimum field width is given first and
|
||
if the maximum field width is used, it has to be preceded by a dot.
|
||
Specifying a minimum field width makes the result be padded with spaces
|
||
to the right if the <code>string</code> is shorter than the requested width.
|
||
Padding to the left can be achieved by giving a negative minimum field
|
||
width. If a maximum field width is specified, the <code>string</code> will be
|
||
truncated after that many characters. After all ‘<code>%</code>’ sequences for the
|
||
given <code>spec</code>s have been processed, the resulting string is stored in the
|
||
parameter <code>param</code>.</p>
|
||
<p>The <code>%</code>-escapes also understand ternary expressions in the form used by
|
||
prompts. The <code>%</code> is followed by a ‘<code>(</code>’ and then an ordinary format
|
||
specifier character as described above. There may be a set of digits
|
||
either before or after the ‘<code>(</code>’; these specify a test number, which
|
||
defaults to zero. Negative numbers are also allowed. An arbitrary
|
||
delimiter character follows the format specifier, which is followed by a
|
||
piece of ‘true’ text, the delimiter character again, a piece of ‘false’
|
||
text, and a closing parenthesis. The complete expression (without the
|
||
digits) thus looks like ‘<code>%(``X``.``text1``.``text2``)</code>’, except that
|
||
the ‘<code>.</code>’ character is arbitrary. The value given for the format
|
||
specifier in the <code>char``:``string</code> expressions is evaluated as a
|
||
mathematical expression, and compared with the test number. If they are
|
||
the same, <code>text1</code> is output, else <code>text2</code> is output. A parenthesis may
|
||
be escaped in <code>text2</code> as <code>%)</code>. Either of <code>text1</code> or <code>text2</code> may contain
|
||
nested <code>%</code>-escapes.</p>
|
||
<p>For example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zformat -f REPLY "The answer is '%3(c.yes.no)'." c:3
|
||
</code></pre>
|
||
</div>
|
||
<p>outputs "The answer is ’yes’." to <code>REPLY</code> since the value for the format
|
||
specifier <code>c</code> is 3, agreeing with the digit argument to the ternary
|
||
expression.</p>
|
||
<p>The second form, using the <code>-a</code> option, can be used for aligning
|
||
strings. Here, the <code>spec</code>s are of the form ‘<code>left``:``right</code>’ where
|
||
‘<code>left</code>’ and ‘<code>right</code>’ are arbitrary strings. These strings are
|
||
modified by replacing the colons by the <code>sep</code> string and padding the
|
||
<code>left</code> strings with spaces to the right so that the <code>sep</code> strings in the
|
||
result (and hence the <code>right</code> strings after them) are all aligned if the
|
||
strings are printed below each other. All strings without a colon are
|
||
left unchanged and all strings with an empty <code>right</code> string have the
|
||
trailing colon removed. In both cases the lengths of the strings are not
|
||
used to determine how the other strings are to be aligned. A colon in
|
||
the <code>left</code> string can be escaped with a backslash. The resulting strings
|
||
are stored in the <code>array</code>.</p>
|
||
<p><span id="index-zregexparse"></span></p>
|
||
<p><code>zregexparse</code></p>
|
||
<p>This implements some internals of the <code>_regex_arguments</code> function.</p>
|
||
<p><span id="index-zparseopts"></span></p>
|
||
<p><code>zparseopts</code> [ <code>-D</code> <code>-E</code> <code>-F</code> <code>-K</code> <code>-M</code> ] [ <code>-a</code> <code>array</code> ] [ <code>-A</code>
|
||
<code>assoc</code> ] [ <code>-</code> ] <code>spec</code> ...</p>
|
||
<p>This builtin simplifies the parsing of options in positional parameters,
|
||
i.e. the set of arguments given by <code>$*</code>. Each <code>spec</code> describes one
|
||
option and must be of the form ‘<code>opt</code>[<code>=``array</code>]’. If an option
|
||
described by <code>opt</code> is found in the positional parameters it is copied
|
||
into the <code>array</code> specified with the <code>-a</code> option; if the optional
|
||
‘<code>=``array</code>’ is given, it is instead copied into that array, which
|
||
should be declared as a normal array and never as an associative array.</p>
|
||
<p>Note that it is an error to give any <code>spec</code> without an ‘<code>=``array</code>’
|
||
unless one of the <code>-a</code> or <code>-A</code> options is used.</p>
|
||
<p>Unless the <code>-E</code> option is given, parsing stops at the first string that
|
||
isn’t described by one of the <code>spec</code>s. Even with <code>-E</code>, parsing always
|
||
stops at a positional parameter equal to ‘<code>-</code>’ or ‘<code>-``-</code>’. See also
|
||
<code>-F</code>.</p>
|
||
<p>The <code>opt</code> description must be one of the following. Any of the special
|
||
characters can appear in the option name provided it is preceded by a
|
||
backslash.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>name</code><br />
|
||
<code>name``+</code><br />
|
||
The <code>name</code> is the name of the option without the leading ‘<code>-</code>’. To
|
||
specify a GNU-style long option, one of the usual two leading ‘<code>-</code>’
|
||
must be included in <code>name</code>; for example, a ‘<code>-``-file</code>’ option is
|
||
represented by a <code>name</code> of ‘<code>-file</code>’.</p>
|
||
<p>If a ‘<code>+</code>’ appears after <code>name</code>, the option is appended to <code>array</code>
|
||
each time it is found in the positional parameters; without the
|
||
‘<code>+</code>’ only the <em>last</em> occurrence of the option is preserved.</p>
|
||
<p>If one of these forms is used, the option takes no argument, so
|
||
parsing stops if the next positional parameter does not also begin
|
||
with ‘<code>-</code>’ (unless the <code>-E</code> option is used).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>name``:</code><br />
|
||
<code>name``:-</code><br />
|
||
<code>name``::</code><br />
|
||
If one or two colons are given, the option takes an argument; with
|
||
one colon, the argument is mandatory and with two colons it is
|
||
optional. The argument is appended to the <code>array</code> after the option
|
||
itself.</p>
|
||
<p>An optional argument is put into the same array element as the
|
||
option name (note that this makes empty strings as arguments
|
||
indistinguishable). A mandatory argument is added as a separate
|
||
element unless the ‘<code>:-</code>’ form is used, in which case the argument
|
||
is put into the same element.</p>
|
||
<p>A ‘<code>+</code>’ as described above may appear between the <code>name</code> and the
|
||
first colon.</p>
|
||
</li>
|
||
</ul>
|
||
<p>In all cases, option-arguments must appear either immediately following
|
||
the option in the same positional parameter or in the next one. Even an
|
||
optional argument may appear in the next parameter, unless it begins
|
||
with a ‘<code>-</code>’. There is no special handling of ‘<code>=</code>’ as with GNU-style
|
||
argument parsers; given the <code>spec</code> ‘<code>-foo:</code>’, the positional parameter
|
||
‘<code>-``-foo=bar</code>’ is parsed as ‘<code>-``-foo</code>’ with an argument of ‘<code>=bar</code>’.</p>
|
||
<p>When the names of two options that take no arguments overlap, the
|
||
longest one wins, so that parsing for the <code>spec</code>s ‘<code>-foo -foobar</code>’ (for
|
||
example) is unambiguous. However, due to the aforementioned handling of
|
||
option-arguments, ambiguities may arise when at least one overlapping
|
||
<code>spec</code> takes an argument, as in ‘<code>-foo: -foobar</code>’. In that case, the
|
||
last matching <code>spec</code> wins.</p>
|
||
<p>The options of <code>zparseopts</code> itself cannot be stacked because, for
|
||
example, the stack ‘<code>-DEK</code>’ is indistinguishable from a <code>spec</code> for the
|
||
GNU-style long option ‘<code>-``-DEK</code>’. The options of <code>zparseopts</code> itself
|
||
are:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-a</code> <code>array</code><br />
|
||
As described above, this names the default array in which to store
|
||
the recognised options.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-A</code> <code>assoc</code><br />
|
||
If this is given, the options and their values are also put into an
|
||
associative array with the option names as keys and the arguments
|
||
(if any) as the values.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-D</code><br />
|
||
If this option is given, all options found are removed from the
|
||
positional parameters of the calling shell or shell function, up to
|
||
but not including any not described by the <code>spec</code>s. If the first
|
||
such parameter is ‘<code>-</code>’ or ‘<code>-``-</code>’, it is removed as well. This is
|
||
similar to using the <code>shift</code> builtin.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-E</code><br />
|
||
This changes the parsing rules to <em>not</em> stop at the first string
|
||
that isn’t described by one of the <code>spec</code>s. It can be used to test
|
||
for or (if used together with <code>-D</code>) extract options and their
|
||
arguments, ignoring all other options and arguments that may be in
|
||
the positional parameters. As indicated above, parsing still stops
|
||
at the first ‘<code>-</code>’ or ‘<code>-``-</code>’ not described by a <code>spec</code>, but it is
|
||
not removed when used with <code>-D</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-F</code><br />
|
||
If this option is given, <code>zparseopts</code> immediately stops at the first
|
||
option-like parameter not described by one of the <code>spec</code>s, prints an
|
||
error message, and returns status 1. Removal (<code>-D</code>) and extraction
|
||
(<code>-E</code>) are not performed, and option arrays are not updated. This
|
||
provides basic validation for the given options.</p>
|
||
<p>Note that the appearance in the positional parameters of an option
|
||
without its required argument always aborts parsing and returns an
|
||
error as described above regardless of whether this option is used.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-K</code><br />
|
||
With this option, the arrays specified with the <code>-a</code> option and with
|
||
the ‘<code>=``array</code>’ forms are kept unchanged when none of the <code>spec</code>s
|
||
for them is used. Otherwise the entire array is replaced when any of
|
||
the <code>spec</code>s is used. Individual elements of associative arrays
|
||
specified with the <code>-A</code> option are preserved by <code>-K</code>. This allows
|
||
assignment of default values to arrays before calling <code>zparseopts</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-M</code><br />
|
||
This changes the assignment rules to implement a map among
|
||
equivalent option names. If any <code>spec</code> uses the ‘<code>=``array</code>’ form,
|
||
the string <code>array</code> is interpreted as the name of another <code>spec</code>,
|
||
which is used to choose where to store the values. If no other
|
||
<code>spec</code> is found, the values are stored as usual. This changes only
|
||
the way the values are stored, not the way <code>$*</code> is parsed, so
|
||
results may be</p>
|
||
</li>
|
||
</ul>
|
||
<p>For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">set -- -a -bx -c y -cz baz -cend
|
||
zparseopts a=foo b:=bar c+:=bar
|
||
</code></pre>
|
||
</div>
|
||
<p>will have the effect of</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">foo=(-a)
|
||
bar=(-b x -c y -c z)
|
||
</code></pre>
|
||
</div>
|
||
<p>The arguments from ‘<code>baz</code>’ on will not be used.</p>
|
||
<p>As an example for the <code>-E</code> option, consider:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">set -- -a x -b y -c z arg1 arg2
|
||
zparseopts -E -D b:=bar
|
||
</code></pre>
|
||
</div>
|
||
<p>will have the effect of</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">bar=(-b y)
|
||
set -- -a x -c z arg1 arg2
|
||
</code></pre>
|
||
</div>
|
||
<p>I.e., the option <code>-b</code> and its arguments are taken from the positional
|
||
parameters and put into the array <code>bar</code>.</p>
|
||
<p>The <code>-M</code> option can be used like this:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">set -- -a -bx -c y -cz baz -cend
|
||
zparseopts -A bar -M a=foo b+: c:=b
|
||
</code></pre>
|
||
</div>
|
||
<p>to have the effect of</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">foo=(-a)
|
||
bar=(-a '' -b xyz)
|
||
</code></pre>
|
||
</div>
|
||
<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>
|
||
<!-- 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="Calendar-Function-System.html#23-calendar-function-system">23 Calendar Function System</a>
|
||
<ul>
|
||
<li><a href="Calendar-Function-System.html#231-description">23.1 Description</a></li>
|
||
<li><a href="Calendar-Function-System.html#232-file-and-date-formats">23.2 File and Date Formats</a>
|
||
<ul>
|
||
<li><a href="Calendar-Function-System.html#2321-calendar-file-format">23.2.1 Calendar File Format</a></li>
|
||
<li><a href="Calendar-Function-System.html#2322-date-format">23.2.2 Date Format</a></li>
|
||
<li><a href="Calendar-Function-System.html#2323-relative-time-format">23.2.3 Relative Time Format</a></li>
|
||
<li><a href="Calendar-Function-System.html#2324-example">23.2.4 Example</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Calendar-Function-System.html#233-user-functions">23.3 User Functions</a>
|
||
<ul>
|
||
<li><a href="Calendar-Function-System.html#2331-calendar-system-functions">23.3.1 Calendar system functions</a></li>
|
||
<li><a href="Calendar-Function-System.html#2332-glob-qualifiers">23.3.2 Glob qualifiers</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Calendar-Function-System.html#234-styles">23.4 Styles</a></li>
|
||
<li><a href="Calendar-Function-System.html#235-utility-functions">23.5 Utility functions</a></li>
|
||
<li><a href="Calendar-Function-System.html#236-bugs">23.6 Bugs</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Calendar-Function-System"></span>
|
||
<span id="Calendar-Function-System-1"></span></p>
|
||
<h1 id="23-calendar-function-system"><a class="header" href="#23-calendar-function-system">23 Calendar Function System</a></h1>
|
||
<p><span id="index-calendar-function-system"></span>
|
||
<span id="index-zsh_002fdatetime_002c-function-system-based-on"></span></p>
|
||
<hr />
|
||
<p><span id="Description-8"></span></p>
|
||
<h2 id="231-description"><a class="header" href="#231-description">23.1 Description</a></h2>
|
||
<p>The shell is supplied with a series of functions to replace and enhance
|
||
the traditional Unix <code>calendar</code> programme, which warns the user of
|
||
imminent or future events, details of which are stored in a text file
|
||
(typically <code>calendar</code> in the user’s home directory). The version
|
||
provided here includes a mechanism for alerting the user when an event
|
||
is due.</p>
|
||
<p>In addition functions <code>age</code>, <code>before</code> and <code>after</code> are provided that can
|
||
be used in a glob qualifier; they allow files to be selected based on
|
||
their modification times.</p>
|
||
<p>The format of the <code>calendar</code> file and the dates used there in and in the
|
||
<code>age</code> function are described first, then the functions that can be
|
||
called to examine and modify the <code>calendar</code> file.</p>
|
||
<p>The functions here depend on the availability of the <code>zsh/datetime</code>
|
||
module which is usually installed with the shell. The library function
|
||
<code>strptime()</code> must be available; it is present on most recent operating
|
||
systems.</p>
|
||
<hr />
|
||
<p><span id="Calendar-File-and-Date-Formats"></span>
|
||
<span id="File-and-Date-Formats"></span></p>
|
||
<h2 id="232-file-and-date-formats"><a class="header" href="#232-file-and-date-formats">23.2 File and Date Formats</a></h2>
|
||
<hr />
|
||
<p><span id="Calendar-File-Format"></span></p>
|
||
<h3 id="2321-calendar-file-format"><a class="header" href="#2321-calendar-file-format">23.2.1 Calendar File Format</a></h3>
|
||
<p>The calendar file is by default <code>~/calendar</code>. This can be configured by
|
||
the <code>calendar-file</code> style, see <a href="Calendar-Function-System.html#Calendar-Styles">Styles</a>. The basic
|
||
format consists of a series of separate lines, with no indentation, each
|
||
including a date and time specification followed by a description of the
|
||
event.</p>
|
||
<p>Various enhancements to this format are supported, based on the syntax
|
||
of Emacs calendar mode. An indented line indicates a continuation line
|
||
that continues the description of the event from the preceding line
|
||
(note the date may not be continued in this way). An initial ampersand
|
||
(<code>&</code>) is ignored for compatibility.</p>
|
||
<p>An indented line on which the first non-whitespace character is <code>#</code> is
|
||
not displayed with the calendar entry, but is still scanned for
|
||
information. This can be used to hide information useful to the calendar
|
||
system but not to the user, such as the unique identifier used by
|
||
<code>calendar_add</code>.</p>
|
||
<p>The Emacs extension that a date with no description may refer to a
|
||
number of succeeding events at different times is not supported.</p>
|
||
<p>Unless the <code>done-file</code> style has been altered, any events which have
|
||
been processed are appended to the file with the same name as the
|
||
calendar file with the suffix <code>.done</code>, hence <code>~/calendar.done</code> by
|
||
default.</p>
|
||
<p>An example is shown below.</p>
|
||
<hr />
|
||
<p><span id="Date-Format"></span></p>
|
||
<h3 id="2322-date-format"><a class="header" href="#2322-date-format">23.2.2 Date Format</a></h3>
|
||
<p>The format of the date and time is designed to allow flexibility without
|
||
admitting ambiguity. (The words ‘date’ and ‘time’ are both used in the
|
||
documentation below; except where specifically noted this implies a
|
||
string that may include both a date and a time specification.) Note that
|
||
there is no localization support; month and day names must be in English
|
||
and separator characters are fixed. Matching is case insensitive, and
|
||
only the first three letters of the names are significant, although as a
|
||
special case a form beginning "month" does not match "Monday".
|
||
Furthermore, time zones are not handled; all times are assumed to be
|
||
local.</p>
|
||
<p>It is recommended that, rather than exploring the intricacies of the
|
||
system, users find a date format that is natural to them and stick to
|
||
it. This will avoid unexpected effects. Various key facts should be
|
||
noted.</p>
|
||
<ul>
|
||
<li>In particular, note the confusion between <code>month``/``day``/``year</code>
|
||
and <code>day``/``month``/``year</code> when the month is numeric; these
|
||
formats should be avoided if at all possible. Many alternatives are
|
||
available.</li>
|
||
<li>The year must be given in full to avoid confusion, and only years
|
||
from 1900 to 2099 inclusive are matched.</li>
|
||
</ul>
|
||
<p>The following give some obvious examples; users finding here a format
|
||
they like and not subject to vagaries of style may skip the full
|
||
description. As dates and times are matched separately (even though the
|
||
time may be embedded in the date), any date format may be mixed with any
|
||
format for the time of day provide the separators are clear (whitespace,
|
||
colons, commas).</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">2007/04/03 13:13
|
||
2007/04/03:13:13
|
||
2007/04/03 1:13 pm
|
||
3rd April 2007, 13:13
|
||
April 3rd 2007 1:13 p.m.
|
||
Apr 3, 2007 13:13
|
||
Tue Apr 03 13:13:00 2007
|
||
13:13 2007/apr/3
|
||
</code></pre>
|
||
</div>
|
||
<p>More detailed rules follow.</p>
|
||
<p>Times are parsed and extracted before dates. They must use colons to
|
||
separate hours and minutes, though a dot is allowed before seconds if
|
||
they are present. This limits time formats to the following:</p>
|
||
<ul>
|
||
<li><code>HH``:``MM</code>[<code>:``SS</code>[<code>.``FFFFF</code>]] [<code>am</code>|<code>pm</code>|<code>a.m.</code>|<code>p.m.</code>]</li>
|
||
<li><code>HH``:``MM``.``SS</code>[<code>.``FFFFF</code>] [<code>am</code>|<code>pm</code>|<code>a.m.</code>|<code>p.m.</code>]</li>
|
||
</ul>
|
||
<p>Here, square brackets indicate optional elements, possibly with
|
||
alternatives. Fractions of a second are recognised but ignored. For
|
||
absolute times (the normal format require by the <code>calendar</code> file and the
|
||
<code>age</code>, <code>before</code> and <code>after</code> functions) a date is mandatory but a time of
|
||
day is not; the time returned is at the start of the date. One variation
|
||
is allowed: if <code>a.m.</code> or <code>p.m.</code> or one of their variants is present, an
|
||
hour without a minute is allowed, e.g. <code>3 p.m.</code>.</p>
|
||
<p>Time zones are not handled, though if one is matched following a time
|
||
specification it will be removed to allow a surrounding date to be
|
||
parsed. This only happens if the format of the timezone is not too
|
||
unusual. The following are examples of forms that are understood:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">+0100
|
||
GMT
|
||
GMT-7
|
||
CET+1CDT
|
||
</code></pre>
|
||
</div>
|
||
<p>Any part of the timezone that is not numeric must have exactly three
|
||
capital letters in the name.</p>
|
||
<p>Dates suffer from the ambiguity between <code>DD``/``MM``/``YYYY</code> and
|
||
<code>MM``/``DD``/``YYYY</code>. It is recommended this form is avoided with purely
|
||
numeric dates, but use of ordinals, eg. <code>3rd/04/2007</code>, will resolve the
|
||
ambiguity as the ordinal is always parsed as the day of the month. Years
|
||
must be four digits (and the first two must be <code>19</code> or <code>20</code>); <code>03/04/08</code>
|
||
is not recognised. Other numbers may have leading zeroes, but they are
|
||
not required. The following are handled:</p>
|
||
<ul>
|
||
<li><code>YYYY``/``MM``/``DD</code></li>
|
||
<li><code>YYYY``-``MM``-``DD</code></li>
|
||
<li><code>YYYY``/``MNM``/``DD</code></li>
|
||
<li><code>YYYY``-``MNM``-``DD</code></li>
|
||
<li><code>DD</code>[<code>th</code>|<code>st</code>|<code>rd</code>] <code>MNM</code>[<code>,</code>] [ <code>YYYY</code> ]</li>
|
||
<li><code>MNM</code> <code>DD</code>[<code>th</code>|<code>st</code>|<code>rd</code>][<code>,</code>] [ <code>YYYY</code> ]</li>
|
||
<li><code>DD</code>[<code>th</code>|<code>st</code>|<code>rd</code>]<code>/``MM</code>[<code>,</code>] <code>YYYY</code></li>
|
||
<li><code>DD</code>[<code>th</code>|<code>st</code>|<code>rd</code>]<code>/``MM``/``YYYY</code></li>
|
||
<li><code>MM``/``DD</code>[<code>th</code>|<code>st</code>|<code>rd</code>][<code>,</code>] <code>YYYY</code></li>
|
||
<li><code>MM``/``DD</code>[<code>th</code>|<code>st</code>|<code>rd</code>]<code>/``YYYY</code></li>
|
||
</ul>
|
||
<p>Here, <code>MNM</code> is at least the first three letters of a month name, matched
|
||
case-insensitively. The remainder of the month name may appear but its
|
||
contents are irrelevant, so janissary, febrile, martial, apricot, maybe,
|
||
junta, etc. are happily handled.</p>
|
||
<p>Where the year is shown as optional, the current year is assumed. There
|
||
are only two such cases, the form <code>Jun 20</code> or <code>14 September</code> (the only
|
||
two commonly occurring forms, apart from a "the" in some forms of
|
||
English, which isn’t currently supported). Such dates will of course
|
||
become ambiguous in the future, so should ideally be avoided.</p>
|
||
<p>Times may follow dates with a colon, e.g. <code>1965/07/12:09:45</code>; this is in
|
||
order to provide a format with no whitespace. A comma and whitespace are
|
||
allowed, e.g. <code>1965/07/12, 09:45</code>. Currently the order of these
|
||
separators is not checked, so illogical formats such as <code>1965/07/12, : ,09:45</code> will also be matched. For simplicity such variations are not
|
||
shown in the list above. Otherwise, a time is only recognised as being
|
||
associated with a date if there is only whitespace in between, or if the
|
||
time was embedded in the date.</p>
|
||
<p>Days of the week are not normally scanned, but will be ignored if they
|
||
occur at the start of the date pattern only. However, in contexts where
|
||
it is useful to specify dates relative to today, days of the week with
|
||
no other date specification may be given. The day is assumed to be
|
||
either today or within the past week. Likewise, the words <code>yesterday</code>,
|
||
<code>today</code> and <code>tomorrow</code> are handled. All matches are case-insensitive.
|
||
Hence if today is Monday, then <code>Sunday</code> is equivalent to <code>yesterday</code>,
|
||
<code>Monday</code> is equivalent to <code>today</code>, but <code>Tuesday</code> gives a date six days
|
||
ago. This is not generally useful within the calendar file. Dates in
|
||
this format may be combined with a time specification; for example
|
||
<code>Tomorrow, 8 p.m.</code>.</p>
|
||
<p>For example, the standard date format:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">Fri Aug 18 17:00:48 BST 2006
|
||
</code></pre>
|
||
</div>
|
||
<p>is handled by matching <code>HH``:``MM``:``SS</code> and removing it together with
|
||
the matched (but unused) time zone. This leaves the following:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">Fri Aug 18 2006
|
||
</code></pre>
|
||
</div>
|
||
<p><code>Fri</code> is ignored and the rest is matched according to the standard
|
||
rules.</p>
|
||
<hr />
|
||
<p><span id="Relative-Time-Format"></span></p>
|
||
<h3 id="2323-relative-time-format"><a class="header" href="#2323-relative-time-format">23.2.3 Relative Time Format</a></h3>
|
||
<p>In certain places relative times are handled. Here, a date is not
|
||
allowed; instead a combination of various supported periods are allowed,
|
||
together with an optional time. The periods must be in order from most
|
||
to least significant.</p>
|
||
<p>In some cases, a more accurate calculation is possible when there is an
|
||
anchor date: offsets of months or years pick the correct day, rather
|
||
than being rounded, and it is possible to pick a particular day in a
|
||
month as ‘(1st Friday)’, etc., as described in more detail below.</p>
|
||
<p>Anchors are available in the following cases. If one or two times are
|
||
passed to the function <code>calendar</code>, the start time acts an anchor for the
|
||
end time when the end time is relative (even if the start time is
|
||
implicit). When examining calendar files, the scheduled event being
|
||
examined anchors the warning time when it is given explicitly by means
|
||
of the <code>WARN</code> keyword; likewise, the scheduled event anchors a
|
||
repetition period when given by the <code>RPT</code> keyword, so that
|
||
specifications such as <code>RPT 2 months, 3rd Thursday</code> are handled
|
||
properly. Finally, the <code>-R</code> argument to <code>calendar_scandate</code> directly
|
||
provides an anchor for relative calculations.</p>
|
||
<p>The periods handled, with possible abbreviations are:</p>
|
||
<ul>
|
||
<li>
|
||
<p>Years<br />
|
||
<code>years</code>, <code>yrs</code>, <code>ys</code>, <code>year</code>, <code>yr</code>, <code>y</code>, <code>yearly</code>. A year is 365.25
|
||
days unless there is an anchor.</p>
|
||
</li>
|
||
<li>
|
||
<p>Months<br />
|
||
<code>months</code>, <code>mons</code>, <code>mnths</code>, <code>mths</code>, <code>month</code>, <code>mon</code>, <code>mnth</code>, <code>mth</code>,
|
||
<code>monthly</code>. Note that <code>m</code>, <code>ms</code>, <code>mn</code>, <code>mns</code> are ambiguous and are
|
||
<em>not</em> handled. A month is a period of 30 days rather than a calendar
|
||
month unless there is an anchor.</p>
|
||
</li>
|
||
<li>
|
||
<p>Weeks<br />
|
||
<code>weeks</code>, <code>wks</code>, <code>ws</code>, <code>week</code>, <code>wk</code>, <code>w</code>, <code>weekly</code></p>
|
||
</li>
|
||
<li>
|
||
<p>Days<br />
|
||
<code>days</code>, <code>dys</code>, <code>ds</code>, <code>day</code>, <code>dy</code>, <code>d</code>, <code>daily</code></p>
|
||
</li>
|
||
<li>
|
||
<p>Hours<br />
|
||
<code>hours</code>, <code>hrs</code>, <code>hs</code>, <code>hour</code>, <code>hr</code>, <code>h</code>, <code>hourly</code></p>
|
||
</li>
|
||
<li>
|
||
<p>Minutes<br />
|
||
<code>minutes</code>, <code>mins</code>, <code>minute</code>, <code>min</code>, but <em>not</em> <code>m</code>, <code>ms</code>, <code>mn</code> or
|
||
<code>mns</code></p>
|
||
</li>
|
||
<li>
|
||
<p>Seconds<br />
|
||
<code>seconds</code>, <code>secs</code>, <code>ss</code>, <code>second</code>, <code>sec</code>, <code>s</code></p>
|
||
</li>
|
||
</ul>
|
||
<p>Spaces between the numbers are optional, but are required between items,
|
||
although a comma may be used (with or without spaces).</p>
|
||
<p>The forms <code>yearly</code> to <code>hourly</code> allow the number to be omitted; it is
|
||
assumed to be 1. For example, <code>1 d</code> and <code>daily</code> are equivalent. Note
|
||
that using those forms with plurals is confusing; <code>2 yearly</code> is the same
|
||
as <code>2 years</code>, <em>not</em> twice yearly, so it is recommended they only be used
|
||
without numbers.</p>
|
||
<p>When an anchor time is present, there is an extension to handle regular
|
||
events in the form of the <code>n</code>th <code>some</code>day of the month. Such a
|
||
specification must occur immediately after any year and month
|
||
specification, but before any time of day, and must be in the form
|
||
<code>n</code>(<code>th</code>|<code>st</code>|<code>rd</code>) <code>day</code>, for example <code>1st Tuesday</code> or <code>3rd Monday</code>. As
|
||
in other places, days are matched case insensitively, must be in
|
||
English, and only the first three letters are significant except that a
|
||
form beginning ‘month’ does not match ‘Monday’. No attempt is made to
|
||
sanitize the resulting date; attempts to squeeze too many occurrences
|
||
into a month will push the day into the next month (but in the obvious
|
||
fashion, retaining the correct day of the week).</p>
|
||
<p>Here are some examples:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">30 years 3 months 4 days 3:42:41
|
||
14 days 5 hours
|
||
Monthly, 3rd Thursday
|
||
4d,10hr
|
||
</code></pre>
|
||
</div>
|
||
<hr />
|
||
<p><span id="Example-2"></span></p>
|
||
<h3 id="2324-example"><a class="header" href="#2324-example">23.2.4 Example</a></h3>
|
||
<p>Here is an example calendar file. It uses a consistent date format, as
|
||
recommended above.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">Feb 1, 2006 14:30 Pointless bureaucratic meeting
|
||
Mar 27, 2006 11:00 Mutual recrimination and finger pointing
|
||
Bring water pistol and waterproofs
|
||
Mar 31, 2006 14:00 Very serious managerial pontification
|
||
# UID 12C7878A9A50
|
||
Apr 10, 2006 13:30 Even more pointless blame assignment exercise WARN 30 mins
|
||
May 18, 2006 16:00 Regular moaning session RPT monthly, 3rd Thursday
|
||
</code></pre>
|
||
</div>
|
||
<p>The second entry has a continuation line. The third entry has a
|
||
continuation line that will not be shown when the entry is displayed,
|
||
but the unique identifier will be used by the <code>calendar_add</code> function
|
||
when updating the event. The fourth entry will produce a warning 30
|
||
minutes before the event (to allow you to equip yourself appropriately).
|
||
The fifth entry repeats after a month on the 3rd Thursday, i.e. June 15,
|
||
2006, at the same time.</p>
|
||
<hr />
|
||
<p><span id="Calendar-System-User-Functions"></span>
|
||
<span id="User-Functions"></span></p>
|
||
<h2 id="233-user-functions"><a class="header" href="#233-user-functions">23.3 User Functions</a></h2>
|
||
<p>This section describes functions that are designed to be called directly
|
||
by the user. The first part describes those functions associated with
|
||
the user’s calendar; the second part describes the use in glob
|
||
qualifiers.</p>
|
||
<hr />
|
||
<p><span id="Calendar-system-functions"></span></p>
|
||
<h3 id="2331-calendar-system-functions"><a class="header" href="#2331-calendar-system-functions">23.3.1 Calendar system functions</a></h3>
|
||
<p><span id="index-calendar"></span></p>
|
||
<p><code>calendar </code>[ <code>-abdDsv</code> ] [ <code>-C</code> <code>calfile</code> ] [ <code>-n</code> <code>num</code> ] [
|
||
<code>-S</code> <code>showprog</code> ]</p>
|
||
<p><code> </code>[ [ <code>start</code> ] <code>end</code> ]</p>
|
||
<p><code>calendar -r</code> [ <code>-abdDrsv</code> ] [ <code>-C</code> <code>calfile</code> ] [ <code>-n</code> <code>num</code> ] [
|
||
<code>-S</code> <code>showprog</code> ]</p>
|
||
<p><code> </code>[ <code>start</code> ]</p>
|
||
<p>Show events in the calendar.</p>
|
||
<p>With no arguments, show events from the start of today until the end of
|
||
the next working day after today. In other words, if today is Friday,
|
||
Saturday, or Sunday, show up to the end of the following Monday,
|
||
otherwise show today and tomorrow.</p>
|
||
<p>If <code>end</code> is given, show events from the start of today up to the time
|
||
and date given, which is in the format described in the previous
|
||
section. Note that if this is a date the time is assumed to be midnight
|
||
at the start of the date, so that effectively this shows all events
|
||
before the given date.</p>
|
||
<p><code>end</code> may start with a <code>+</code>, in which case the remainder of the
|
||
specification is a relative time format as described in the previous
|
||
section indicating the range of time from the start time that is to be
|
||
included.</p>
|
||
<p>If <code>start</code> is also given, show events starting from that time and date.
|
||
The word <code>now</code> can be used to indicate the current time.</p>
|
||
<p>To implement an alert when events are due, include <code>calendar -s</code> in your
|
||
<code>~/.zshrc</code> file.</p>
|
||
<p>Options:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-a</code><br />
|
||
Show all items in the calendar, regardless of the <code>start</code> and <code>end</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-b</code><br />
|
||
Brief: don’t display continuation lines (i.e. indented lines
|
||
following the line with the date/time), just the first line.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-B</code> <code>lines</code><br />
|
||
Brief: display at most the first <code>lines</code> lines of the calendar
|
||
entry. ‘<code>-B 1</code>’ is equivalent to ‘<code>-b</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-C</code> <code>calfile</code><br />
|
||
Explicitly specify a calendar file instead of the value of the
|
||
<code>calendar-file</code> style or the default <code>~/calendar</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-d</code><br />
|
||
Move any events that have passed from the calendar file to the
|
||
"done" file, as given by the <code>done-file</code> style or the default which
|
||
is the calendar file with <code>.done</code> appended. This option is implied
|
||
by the <code>-s</code> option.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-D</code><br />
|
||
Turns off the option <code>-d</code>, even if the <code>-s</code> option is also present.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-n</code> <code>num</code>, <code>-``num</code><br />
|
||
Show at least <code>num</code> events, if present in the calendar file,
|
||
regardless of the <code>start</code> and <code>end</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-r</code><br />
|
||
Show all the remaining options in the calendar, ignoring the given
|
||
<code>end</code> time. The <code>start</code> time is respected; any argument given is
|
||
treated as a <code>start</code> time.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-s</code><br />
|
||
Use the shell’s <code>sched</code> command to schedule a timed event that will
|
||
warn the user when an event is due. Note that the <code>sched</code> command
|
||
only runs if the shell is at an interactive prompt; a foreground
|
||
task blocks the scheduled task from running until it is finished.</p>
|
||
<p>The timed event usually runs the programme <code>calendar_show</code> to show
|
||
the event, as described in <a href="Calendar-Function-System.html#Calendar-Utility-Functions">Utility
|
||
functions</a>.</p>
|
||
<p>By default, a warning of the event is shown five minutes before it
|
||
is due. The warning period can be configured by the style
|
||
<code>warn-time</code> or for a single calendar entry by including <code>WARN</code>
|
||
<code>reltime</code> in the first line of the entry, where <code>reltime</code> is one of
|
||
the usual relative time formats.</p>
|
||
<p>A repeated event may be indicated by including <code>RPT</code> <code>reldate</code> in
|
||
the first line of the entry. After the scheduled event has been
|
||
displayed it will be re-entered into the calendar file at a time
|
||
<code>reldate</code> after the existing event. Note that this is currently the
|
||
only use made of the repeat count, so that it is not possible to
|
||
query the schedule for a recurrence of an event in the calendar
|
||
until the previous event has passed.</p>
|
||
<p>If <code>RPT</code> is used, it is also possible to specify that certain
|
||
recurrences of an event are rescheduled or cancelled. This is done
|
||
with the <code>OCCURRENCE</code> keyword, followed by whitespace and the date
|
||
and time of the occurrence in the regular sequence, followed by
|
||
whitespace and either the date and time of the rescheduled event or
|
||
the exact string <code>CANCELLED</code>. In this case the date and time must be
|
||
in exactly the "date with local time" format used by the
|
||
<code>text/calendar</code> MIME type (RFC 2445),
|
||
<code><YYYY><MM><DD>``T``<hh><mm><ss></code> (note the presence of the literal
|
||
character <code>T</code>). The first word (the regular recurrence) may be
|
||
something other than a proper date/time to indicate that the event
|
||
is additional to the normal sequence; a convention that retains the
|
||
formatting appearance is <code>XXXXXXXXTXXXXXX</code>.</p>
|
||
<p>Furthermore, it is useful to record the next regular recurrence (as
|
||
then the displayed date may be for a rescheduled event so cannot be
|
||
used for calculating the regular sequence). This is specified by
|
||
<code>RECURRENCE</code> and a time or date in the same format. <code>calendar_add</code>
|
||
adds such an indication when it encounters a recurring event that
|
||
does not include one, based on the headline date/time.</p>
|
||
<p>If <code>calendar_add</code> is used to update occurrences the <code>UID</code> keyword
|
||
described there should be present in both the existing entry and the
|
||
added occurrence in order to identify recurring event sequences.</p>
|
||
<p>For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">Thu May 6, 2010 11:00 Informal chat RPT 1 week
|
||
# RECURRENCE 20100506T110000
|
||
# OCCURRENCE 20100513T110000 20100513T120000
|
||
# OCCURRENCE 20100520T110000 CANCELLED
|
||
</code></pre>
|
||
</div>
|
||
<p>The event that occurs at 11:00 on 13th May 2010 is rescheduled an
|
||
hour later. The event that occurs a week later is cancelled. The
|
||
occurrences are given on a continuation line starting with a <code>#</code>
|
||
character so will not usually be displayed as part of the event. As
|
||
elsewhere, no account of time zones is taken with the times. After
|
||
the next event occurs the headline date/time will be ‘<code>Thu May 13, 2010 12:00</code>’ while the <code>RECURRENCE</code> date/time will be
|
||
‘<code>20100513T110000</code>’ (note that cancelled and moved events are not
|
||
taken account of in the <code>RECURRENCE</code>, which records what the next
|
||
regular recurrence is, but they are accounted for in the headline
|
||
date/time).</p>
|
||
<p>It is safe to run <code>calendar -s</code> to reschedule an existing event (if
|
||
the calendar file has changed, for example), and also to have it
|
||
running in multiples instances of the shell since the calendar file
|
||
is locked when in use.</p>
|
||
<p>By default, expired events are moved to the "done" file; see the
|
||
<code>-d</code> option. Use <code>-D</code> to prevent this.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-S</code> <code>showprog</code><br />
|
||
Explicitly specify a programme to be used for showing events instead
|
||
of the value of the <code>show-prog</code> style or the default
|
||
<code>calendar_show</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-v</code><br />
|
||
Verbose: show more information about stages of processing. This is
|
||
useful for confirming that the function has successfully parsed the
|
||
dates in the calendar file.</p>
|
||
</li>
|
||
</ul>
|
||
<p><span id="index-calendar_005fadd"></span></p>
|
||
<p><code>calendar_add</code> [ <code>-BL</code> ] <code>event</code> ...</p>
|
||
<p>Adds a single event to the calendar in the appropriate location. The
|
||
event can contain multiple lines, as described in <a href="Calendar-Function-System.html#Calendar-File-and-Date-Formats">File and Date
|
||
Formats</a>. Using this function ensures
|
||
that the calendar file is sorted in date and time order. It also makes
|
||
special arrangements for locking the file while it is altered. The old
|
||
calendar is left in a file with the suffix <code>.old</code>.</p>
|
||
<p>The option <code>-B</code> indicates that backing up the calendar file will be
|
||
handled by the caller and should not be performed by <code>calendar_add</code>. The
|
||
option <code>-L</code> indicates that <code>calendar_add</code> does not need to lock the
|
||
calendar file as it is already locked. These options will not usually be
|
||
needed by users.</p>
|
||
<p>If the style <code>reformat-date</code> is true, the date and time of the new entry
|
||
will be rewritten into the standard date format: see the descriptions of
|
||
this style and the style <code>date-format</code>.</p>
|
||
<p>The function can use a unique identifier stored with each event to
|
||
ensure that updates to existing events are treated correctly. The entry
|
||
should contain the word <code>UID</code>, followed by whitespace, followed by a
|
||
word consisting entirely of hexadecimal digits of arbitrary length (all
|
||
digits are significant, including leading zeroes). As the UID is not
|
||
directly useful to the user, it is convenient to hide it on an indented
|
||
continuation line starting with a <code>#</code>, for example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">Aug 31, 2007 09:30 Celebrate the end of the holidays
|
||
# UID 045B78A0
|
||
</code></pre>
|
||
</div>
|
||
<p>The second line will not be shown by the <code>calendar</code> function.</p>
|
||
<p>It is possible to specify the <code>RPT</code> keyword followed by <code>CANCELLED</code>
|
||
instead of a relative time. This causes any matched event or series of
|
||
events to be cancelled (the original event does not have to be marked as
|
||
recurring in order to be cancelled by this method). A <code>UID</code> is required
|
||
in order to match an existing event in the calendar.</p>
|
||
<p><code>calendar_add</code> will attempt to manage recurrences and occurrences of
|
||
repeating events as described for event scheduling by <code>calendar -s</code>
|
||
above. To reschedule or cancel a single event <code>calendar_add</code> should be
|
||
called with an entry that includes the correct <code>UID</code> but does <em>not</em>
|
||
include the <code>RPT</code> keyword as this is taken to mean the entry applies to
|
||
a series of repeating events and hence replaces all existing
|
||
information. Each rescheduled or cancelled occurrence must have an
|
||
<code>OCCURRENCE</code> keyword in the entry passed to <code>calendar_add</code> which will be
|
||
merged into the calendar file. Any existing reference to the occurrence
|
||
is replaced. An occurrence that does not refer to a valid existing event
|
||
is added as a one-off occurrence to the same calendar entry.</p>
|
||
<p><span id="index-calendar_005fedit"></span></p>
|
||
<p><code>calendar_edit</code></p>
|
||
<p>This calls the user’s editor to edit the calendar file. If there are
|
||
arguments, they are taken as the editor to use (the file name is
|
||
appended to the commands); otherwise, the editor is given by the
|
||
variable <code>VISUAL</code>, if set, else the variable <code>EDITOR</code>.</p>
|
||
<p>If the calendar scheduler was running, then after editing the file
|
||
<code>calendar -s</code> is called to update it.</p>
|
||
<p>This function locks out the calendar system during the edit. Hence it
|
||
should be used to edit the calendar file if there is any possibility of
|
||
a calendar event occurring meanwhile. Note this can lead to another
|
||
shell with calendar functions enabled hanging waiting for a lock, so it
|
||
is necessary to quit the editor as soon as possible.</p>
|
||
<p><span id="index-calendar_005fparse"></span></p>
|
||
<p><code>calendar_parse</code> <code>calendar-entry</code></p>
|
||
<p>This is the internal function that analyses the parts of a calendar
|
||
entry, which is passed as the only argument. The function returns status
|
||
1 if the argument could not be parsed as a calendar entry and status 2
|
||
if the wrong number of arguments were passed; it also sets the parameter
|
||
<code>reply</code> to an empty associative array. Otherwise, it returns status 0
|
||
and sets elements of the associative array <code>reply</code> as follows:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>time</code><br />
|
||
The time as a string of digits in the same units as <code>$EPOCHSECONDS</code></p>
|
||
</li>
|
||
<li>
|
||
<p><code>schedtime</code><br />
|
||
The regularly scheduled time. This may differ from the actual event
|
||
time <code>time</code> if this is a recurring event and the next occurrence has
|
||
been rescheduled. Then <code>time</code> gives the actual time and <code>schedtime</code>
|
||
the time of the regular recurrence before modification.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>text1</code><br />
|
||
The text from the line not including the date and time of the event,
|
||
but including any <code>WARN</code> or <code>RPT</code> keywords and values.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>warntime</code><br />
|
||
Any warning time given by the <code>WARN</code> keyword as a string of digits
|
||
containing the time at which to warn in the same units as
|
||
<code>$EPOCHSECONDS</code>. (Note this is an absolute time, not the relative
|
||
time passed down.) Not set no <code>WARN</code> keyword and value were matched.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>warnstr</code><br />
|
||
The raw string matched after the <code>WARN</code> keyword, else unset.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>rpttime</code><br />
|
||
Any recurrence time given by the <code>RPT</code> keyword as a string of digits
|
||
containing the time of the recurrence in the same units as
|
||
<code>$EPOCHSECONDS</code>. (Note this is an absolute time.) Not set if no
|
||
<code>RPT</code> keyword and value were matched.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>schedrpttime</code><br />
|
||
The next regularly scheduled occurrence of a recurring event before
|
||
modification. This may differ from <code>rpttime</code>, which is the actual
|
||
time of the event that may have been rescheduled from the regular
|
||
time.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>rptstr</code><br />
|
||
The raw string matched after the <code>RPT</code> keyword, else unset.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>text2</code><br />
|
||
The text from the line after removal of the date and any keywords
|
||
and values.</p>
|
||
</li>
|
||
</ul>
|
||
<p><span id="index-calendar_005fshowdate"></span></p>
|
||
<p><code>calendar_showdate</code> [ <code>-r</code> ] [ <code>-f</code> <code>fmt</code> ] <code>date-spec</code> ...</p>
|
||
<p>The given <code>date-spec</code> is interpreted and the corresponding date and time
|
||
printed. If the initial <code>date-spec</code> begins with a <code>+</code> or <code>-</code> it is
|
||
treated as relative to the current time; <code>date-spec</code>s after the first
|
||
are treated as relative to the date calculated so far and a leading <code>+</code>
|
||
is optional in that case. This allows one to use the system as a date
|
||
calculator. For example, <code>calendar_showdate ’+1 month, 1st Friday’</code>
|
||
shows the date of the first Friday of next month.</p>
|
||
<p>With the option <code>-r</code> nothing is printed but the value of the date and
|
||
time in seconds since the epoch is stored in the parameter <code>REPLY</code>.</p>
|
||
<p>With the option <code>-f</code> <code>fmt</code> the given date/time conversion format is
|
||
passed to <code>strftime</code>; see notes on the <code>date-format</code> style below.</p>
|
||
<p>In order to avoid ambiguity with negative relative date specifications,
|
||
options must occur in separate words; in other words, <code>-r</code> and <code>-f</code>
|
||
should not be combined in the same word.</p>
|
||
<p><span id="index-calendar_005fsort"></span></p>
|
||
<p><code>calendar_sort</code></p>
|
||
<p>Sorts the calendar file into date and time order. The old calendar is
|
||
left in a file with the suffix <code>.old</code>.</p>
|
||
<hr />
|
||
<p><span id="Glob-qualifiers"></span></p>
|
||
<h3 id="2332-glob-qualifiers"><a class="header" href="#2332-glob-qualifiers">23.3.2 Glob qualifiers</a></h3>
|
||
<ul>
|
||
<li>
|
||
<p><code>age</code><br />
|
||
<span id="index-age"></span></p>
|
||
<p>The function <code>age</code> can be autoloaded and use separately from the
|
||
calendar system, although it uses the function <code>calendar_scandate</code>
|
||
for date formatting. It requires the <code>zsh/stat</code> builtin, but uses
|
||
only the builtin <code>zstat</code>.</p>
|
||
<p><code>age</code> selects files having a given modification time for use as a
|
||
glob qualifier. The format of the date is the same as that
|
||
understood by the calendar system, described in <a href="Calendar-Function-System.html#Calendar-File-and-Date-Formats">File and Date
|
||
Formats</a>.</p>
|
||
<p>The function can take one or two arguments, which can be supplied
|
||
either directly as command or arguments, or separately as shell
|
||
parameters.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">print *(e:age 2006/10/04 2006/10/09:)
|
||
</code></pre>
|
||
</div>
|
||
<p>The example above matches all files modified between the start of
|
||
those dates. The second argument may alternatively be a relative
|
||
time introduced by a <code>+</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">print *(e:age 2006/10/04 +5d:)
|
||
</code></pre>
|
||
</div>
|
||
<p>The example above is equivalent to the previous example.</p>
|
||
<p>In addition to the special use of days of the week, <code>today</code> and
|
||
<code>yesterday</code>, times with no date may be specified; these apply to
|
||
today. Obviously such uses become problematic around midnight.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">print *(e-age 12:00 13:30-)
|
||
</code></pre>
|
||
</div>
|
||
<p>The example above shows files modified between 12:00 and 13:00
|
||
today.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">print *(e:age 2006/10/04:)
|
||
</code></pre>
|
||
</div>
|
||
<p>The example above matches all files modified on that date. If the
|
||
second argument is omitted it is taken to be exactly 24 hours after
|
||
the first argument (even if the first argument contains a time).</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">print *(e-age 2006/10/04:10:15 2006/10/04:10:45-)
|
||
</code></pre>
|
||
</div>
|
||
<p>The example above supplies times. Note that whitespace within the
|
||
time and date specification must be quoted to ensure <code>age</code> receives
|
||
the correct arguments, hence the use of the additional colon to
|
||
separate the date and time.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">AGEREF=2006/10/04:10:15
|
||
AGEREF2=2006/10/04:10:45
|
||
print *(+age)
|
||
</code></pre>
|
||
</div>
|
||
<p>This shows the same example before using another form of argument
|
||
passing. The dates and times in the parameters <code>AGEREF</code> and
|
||
<code>AGEREF2</code> stay in effect until unset, but will be overridden if any
|
||
argument is passed as an explicit argument to age. Any explicit
|
||
argument causes both parameters to be ignored.</p>
|
||
<p>Instead of an explicit date and time, it’s possible to use the
|
||
modification time of a file as the date and time for either argument
|
||
by introducing the file name with a colon:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">print *(e-age :file1-)
|
||
</code></pre>
|
||
</div>
|
||
<p>matches all files created on the same day (24 hours starting from
|
||
midnight) as <code>file1</code>.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">print *(e-age :file1 :file2-)
|
||
</code></pre>
|
||
</div>
|
||
<p>matches all files modified no earlier than <code>file1</code> and no later than
|
||
<code>file2</code>; precision here is to the nearest second.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>after</code><br />
|
||
<code>before</code><br />
|
||
<span id="index-after"></span> <span id="index-before"></span></p>
|
||
<p>The functions <code>after</code> and <code>before</code> are simpler versions of <code>age</code>
|
||
that take just one argument. The argument is parsed similarly to an
|
||
argument of <code>age</code>; if it is not given the variable <code>AGEREF</code> is
|
||
consulted. As the names of the functions suggest, a file matches if
|
||
its modification time is after or before the time and date
|
||
specified. If a time only is given the date is today.</p>
|
||
<p>The two following examples are therefore equivalent:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">print *(e-after 12:00-)
|
||
print *(e-after today:12:00-)
|
||
</code></pre>
|
||
</div>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Calendar-Styles"></span> <span id="Styles-1"></span></p>
|
||
<h2 id="234-styles"><a class="header" href="#234-styles">23.4 Styles</a></h2>
|
||
<p>The zsh style mechanism using the <code>zstyle</code> command is describe in <a href="Zsh-Modules.html#The-zsh_002fzutil-Module">The
|
||
zsh/zutil Module</a>. This is
|
||
the same mechanism used in the completion system.</p>
|
||
<p>The styles below are all examined in the context
|
||
<code>:datetime:``function``:</code>, for example <code>:datetime:calendar:</code>.</p>
|
||
<p><span id="index-calendar_002dfile"></span></p>
|
||
<p><code>calendar-file</code></p>
|
||
<p>The location of the main calendar. The default is <code>~/calendar</code>.</p>
|
||
<p><span id="index-date_002dformat"></span></p>
|
||
<p><code>date-format</code></p>
|
||
<p>A <code>strftime</code> format string (see man page strftime(3)) with the zsh
|
||
extensions providing various numbers with no leading zero or space if
|
||
the number is a single digit as described for the <code>%D{``string``}</code>
|
||
prompt format in <a href="Prompt-Expansion.html#Prompt-Expansion">Prompt
|
||
Expansion</a>.</p>
|
||
<p>This is used for outputting dates in <code>calendar</code>, both to support the
|
||
<code>-v</code> option and when adding recurring events back to the calendar file,
|
||
and in <code>calendar_showdate</code> as the final output format.</p>
|
||
<p>If the style is not set, the default used is similar the standard system
|
||
format as output by the <code>date</code> command (also known as ‘ctime format’):
|
||
‘<code>%a %b %d %H:%M:%S %Z %Y</code>’.</p>
|
||
<p><span id="index-done_002dfile"></span></p>
|
||
<p><code>done-file</code></p>
|
||
<p>The location of the file to which events which have passed are appended.
|
||
The default is the calendar file location with the suffix <code>.done</code>. The
|
||
style may be set to an empty string in which case a "done" file will not
|
||
be maintained.</p>
|
||
<p><span id="index-reformat_002ddate"></span></p>
|
||
<p><code>reformat-date</code></p>
|
||
<p>Boolean, used by <code>calendar_add</code>. If it is true, the date and time of new
|
||
entries added to the calendar will be reformatted to the format given by
|
||
the style <code>date-format</code> or its default. Only the date and time of the
|
||
event itself is reformatted; any subsidiary dates and times such as
|
||
those associated with repeat and warning times are left alone.</p>
|
||
<p><span id="index-show_002dprog"></span></p>
|
||
<p><code>show-prog</code></p>
|
||
<p>The programme run by <code>calendar</code> for showing events. It will be passed
|
||
the start time and stop time of the events requested in seconds since
|
||
the epoch followed by the event text. Note that <code>calendar -s</code> uses a
|
||
start time and stop time equal to one another to indicate alerts for
|
||
specific events.</p>
|
||
<p>The default is the function <code>calendar_show</code>.</p>
|
||
<p><span id="index-warn_002dtime"></span></p>
|
||
<p><code>warn-time</code></p>
|
||
<p>The time before an event at which a warning will be displayed, if the
|
||
first line of the event does not include the text <code>EVENT</code> <code>reltime</code>. The
|
||
default is 5 minutes.</p>
|
||
<hr />
|
||
<p><span id="Calendar-Utility-Functions"></span>
|
||
<span id="Utility-functions"></span></p>
|
||
<h2 id="235-utility-functions"><a class="header" href="#235-utility-functions">23.5 Utility functions</a></h2>
|
||
<p><span id="index-calendar_005flockfiles"></span></p>
|
||
<p><code>calendar_lockfiles</code></p>
|
||
<p>Attempt to lock the files given in the argument. To prevent problems
|
||
with network file locking this is done in an ad hoc fashion by
|
||
attempting to create a symbolic link to the file with the name
|
||
<code>file``.lockfile</code>. No other system level functions are used for locking,
|
||
i.e. the file can be accessed and modified by any utility that does not
|
||
use this mechanism. In particular, the user is not prevented from
|
||
editing the calendar file at the same time unless <code>calendar_edit</code> is
|
||
used.</p>
|
||
<p>Three attempts are made to lock the file before giving up. If the module
|
||
<code>zsh/zselect</code> is available, the times of the attempts are jittered so
|
||
that multiple instances of the calling function are unlikely to retry at
|
||
the same time.</p>
|
||
<p>The files locked are appended to the array <code>lockfiles</code>, which should be
|
||
local to the caller.</p>
|
||
<p>If all files were successfully locked, status zero is returned, else
|
||
status one.</p>
|
||
<p>This function may be used as a general file locking function, although
|
||
this will only work if only this mechanism is used to lock files.</p>
|
||
<p><span id="index-calendar_005fread"></span></p>
|
||
<p><code>calendar_read</code></p>
|
||
<p>This is a backend used by various other functions to parse the calendar
|
||
file, which is passed as the only argument. The array <code>calendar_entries</code>
|
||
is set to the list of events in the file; no pruning is done except that
|
||
ampersands are removed from the start of the line. Each entry may
|
||
contain multiple lines.</p>
|
||
<p><span id="index-calendar_005fscandate"></span></p>
|
||
<p><code>calendar_scandate</code></p>
|
||
<p>This is a generic function to parse dates and times that may be used
|
||
separately from the calendar system. The argument is a date or time
|
||
specification as described in <a href="Calendar-Function-System.html#Calendar-File-and-Date-Formats">File and Date
|
||
Formats</a>. The parameter <code>REPLY</code> is set
|
||
to the number of seconds since the epoch corresponding to that date or
|
||
time. By default, the date and time may occur anywhere within the given
|
||
argument.</p>
|
||
<p>Returns status zero if the date and time were successfully parsed, else
|
||
one.</p>
|
||
<p>Options:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-a</code><br />
|
||
The date and time are anchored to the start of the argument; they
|
||
will not be matched if there is preceding text.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-A</code><br />
|
||
The date and time are anchored to both the start and end of the
|
||
argument; they will not be matched if the is any other text in the
|
||
argument.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-d</code><br />
|
||
Enable additional debugging output.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-m</code><br />
|
||
Minus. When <code>-R</code> <code>anchor_time</code> is also given the relative time is
|
||
calculated backwards from <code>anchor_time</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-r</code><br />
|
||
The argument passed is to be parsed as a relative time.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-R</code> <code>anchor_time</code><br />
|
||
The argument passed is to be parsed as a relative time. The time is
|
||
relative to <code>anchor_time</code>, a time in seconds since the epoch, and
|
||
the returned value is the absolute time corresponding to advancing
|
||
<code>anchor_time</code> by the relative time given. This allows lengths of
|
||
months to be correctly taken into account. If the final day does not
|
||
exist in the given month, the last day of the final month is given.
|
||
For example, if the anchor time is during 31st January 2007 and the
|
||
relative time is 1 month, the final time is the same time of day
|
||
during 28th February 2007.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-s</code><br />
|
||
In addition to setting <code>REPLY</code>, set <code>REPLY2</code> to the remainder of the
|
||
argument after the date and time have been stripped. This is empty
|
||
if the option <code>-A</code> was given.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-t</code><br />
|
||
Allow a time with no date specification. The date is assumed to be
|
||
today. The behaviour is unspecified if the iron tongue of midnight
|
||
is tolling twelve.</p>
|
||
</li>
|
||
</ul>
|
||
<p><span id="index-calendar_005fshow"></span></p>
|
||
<p><code>calendar_show</code></p>
|
||
<p>The function used by default to display events. It accepts a start time
|
||
and end time for events, both in epoch seconds, and an event
|
||
description.</p>
|
||
<p>The event is always printed to standard output. If the command line
|
||
editor is active (which will usually be the case) the command line will
|
||
be redisplayed after the output.</p>
|
||
<p>If the parameter <code>DISPLAY</code> is set and the start and end times are the
|
||
same (indicating a scheduled event), the function uses the command
|
||
<code>xmessage</code> to display a window with the event details.</p>
|
||
<hr />
|
||
<p><span id="Calendar-Bugs"></span> <span id="Bugs"></span></p>
|
||
<h2 id="236-bugs"><a class="header" href="#236-bugs">23.6 Bugs</a></h2>
|
||
<p>As the system is based entirely on shell functions (with a little
|
||
support from the <code>zsh/datetime</code> module) the mechanisms used are not as
|
||
robust as those provided by a dedicated calendar utility. Consequently
|
||
the user should not rely on the shell for vital alerts.</p>
|
||
<p>There is no <code>calendar_delete</code> function.</p>
|
||
<p>There is no localization support for dates and times, nor any support
|
||
for the use of time zones.</p>
|
||
<p>Relative periods of months and years do not take into account the
|
||
variable number of days.</p>
|
||
<p>The <code>calendar_show</code> function is currently hardwired to use <code>xmessage</code>
|
||
for displaying alerts on X Window System displays. This should be
|
||
configurable and ideally integrate better with the desktop.</p>
|
||
<p><code>calendar_lockfiles</code> hangs the shell while waiting for a lock on a file.
|
||
If called from a scheduled task, it should instead reschedule the event
|
||
that caused it.</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>
|
||
<!-- 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="TCP-Function-System.html#24-tcp-function-system">24 TCP Function System</a>
|
||
<ul>
|
||
<li><a href="TCP-Function-System.html#241-description">24.1 Description</a></li>
|
||
<li><a href="TCP-Function-System.html#242-tcp-user-functions">24.2 TCP User Functions</a>
|
||
<ul>
|
||
<li><a href="TCP-Function-System.html#2421-basic-io">24.2.1 Basic I/O</a></li>
|
||
<li><a href="TCP-Function-System.html#2422-session-management">24.2.2 Session Management</a></li>
|
||
<li><a href="TCP-Function-System.html#2423-advanced-io">24.2.3 Advanced I/O</a></li>
|
||
<li><a href="TCP-Function-System.html#2424-one-shot-file-transfer">24.2.4 ‘One-shot’ file transfer</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="TCP-Function-System.html#243-tcp-user-defined-functions">24.3 TCP User-defined Functions</a></li>
|
||
<li><a href="TCP-Function-System.html#244-tcp-utility-functions">24.4 TCP Utility Functions</a></li>
|
||
<li><a href="TCP-Function-System.html#245-tcp-user-parameters">24.5 TCP User Parameters</a></li>
|
||
<li><a href="TCP-Function-System.html#246-tcp-user-defined-parameters">24.6 TCP User-defined Parameters</a></li>
|
||
<li><a href="TCP-Function-System.html#247-tcp-utility-parameters">24.7 TCP Utility Parameters</a></li>
|
||
<li><a href="TCP-Function-System.html#248-tcp-examples">24.8 TCP Examples</a></li>
|
||
<li><a href="TCP-Function-System.html#249-tcp-bugs">24.9 TCP Bugs</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="TCP-Function-System"></span>
|
||
<span id="TCP-Function-System-1"></span></p>
|
||
<h1 id="24-tcp-function-system"><a class="header" href="#24-tcp-function-system">24 TCP Function System</a></h1>
|
||
<p><span id="index-TCP-function-system"></span>
|
||
<span id="index-ztcp_002c-function-system-based-on"></span></p>
|
||
<hr />
|
||
<p><span id="Description"></span></p>
|
||
<h2 id="241-description"><a class="header" href="#241-description">24.1 Description</a></h2>
|
||
<p>A module <code>zsh/net/tcp</code> is provided to provide network I/O over TCP/IP
|
||
from within the shell; see its description in <a href="Zsh-Modules.html#Zsh-Modules">Zsh
|
||
Modules</a>. This manual page describes a
|
||
function suite based on the module. If the module is installed, the
|
||
functions are usually installed at the same time, in which case they
|
||
will be available for autoloading in the default function search path.
|
||
In addition to the <code>zsh/net/tcp</code> module, the <code>zsh/zselect</code> module is
|
||
used to implement timeouts on read operations. For troubleshooting tips,
|
||
consult the corresponding advice for the <code>zftp</code> functions described in
|
||
<a href="Zftp-Function-System.html#Zftp-Function-System">Zftp Function System</a>.</p>
|
||
<p>There are functions corresponding to the basic I/O operations open,
|
||
close, read and send, named <code>tcp_open</code> etc., as well as a function
|
||
<code>tcp_expect</code> for pattern match analysis of data read as input. The
|
||
system makes it easy to receive data from and send data to multiple
|
||
named sessions at once. In addition, it can be linked with the shell’s
|
||
line editor in such a way that input data is automatically shown at the
|
||
terminal. Other facilities available including logging, filtering and
|
||
configurable output prompts.</p>
|
||
<p>To use the system where it is available, it should be enough to
|
||
‘<code>autoload -U tcp_open</code>’ and run <code>tcp_open</code> as documented below to
|
||
start a session. The <code>tcp_open</code> function will autoload the remaining
|
||
functions.</p>
|
||
<hr />
|
||
<p><span id="TCP-Functions"></span> <span id="TCP-User-Functions"></span></p>
|
||
<h2 id="242-tcp-user-functions"><a class="header" href="#242-tcp-user-functions">24.2 TCP User Functions</a></h2>
|
||
<hr />
|
||
<p><span id="Basic-I_002fO"></span></p>
|
||
<h3 id="2421-basic-io"><a class="header" href="#2421-basic-io">24.2.1 Basic I/O</a></h3>
|
||
<p><span id="index-tcp_005fopen"></span></p>
|
||
<p><code>tcp_open</code> [ <code>-qz</code> ] <code>host port</code> [ <code>sess</code> ]</p>
|
||
<p><code>tcp_open</code> [ <code>-qz</code> ] [ <code>-s</code> <code>sess</code> | <code>-l</code> <code>sess</code>[<code>,</code>...] ] ...</p>
|
||
<p><code>tcp_open</code> [ <code>-qz</code> ] [ <code>-a</code> <code>fd</code> | <code>-f</code> <code>fd</code> ] [ <code>sess</code> ]</p>
|
||
<p>Open a new session. In the first and simplest form, open a TCP
|
||
connection to host <code>host</code> at port <code>port</code>; numeric and symbolic forms are
|
||
understood for both.</p>
|
||
<p>If <code>sess</code> is given, this becomes the name of the session which can be
|
||
used to refer to multiple different TCP connections. If <code>sess</code> is not
|
||
given, the function will invent a numeric name value (note this is <em>not</em>
|
||
the same as the file descriptor to which the session is attached). It is
|
||
recommended that session names not include ‘funny’ characters, where
|
||
funny characters are not well-defined but certainly do not include
|
||
alphanumerics or underscores, and certainly do include whitespace.</p>
|
||
<p>In the second case, one or more sessions to be opened are given by name.
|
||
A single session name is given after <code>-s</code> and a comma-separated list
|
||
after <code>-l</code>; both options may be repeated as many times as necessary. A
|
||
failure to open any session causes <code>tcp_open</code> to abort. The host and
|
||
port are read from the file <code>.ztcp_sessions</code> in the same directory as
|
||
the user’s zsh initialisation files, i.e. usually the home directory,
|
||
but <code>$ZDOTDIR</code> if that is set. The file consists of lines each giving a
|
||
session name and the corresponding host and port, in that order (note
|
||
the session name comes first, not last), separated by whitespace.</p>
|
||
<p>The third form allows passive and fake TCP connections. If the option
|
||
<code>-a</code> is used, its argument is a file descriptor open for listening for
|
||
connections. No function front-end is provided to open such a file
|
||
descriptor, but a call to ‘<code>ztcp -l</code> <code>port</code>’ will create one with the
|
||
file descriptor stored in the parameter <code>$REPLY</code>. The listening port can
|
||
be closed with ‘<code>ztcp -c</code> <code>fd</code>’. A call to ‘<code>tcp_open -a</code> <code>fd</code>’ will
|
||
block until a remote TCP connection is made to <code>port</code> on the local
|
||
machine. At this point, a session is created in the usual way and is
|
||
largely indistinguishable from an active connection created with one of
|
||
the first two forms.</p>
|
||
<p>If the option <code>-f</code> is used, its argument is a file descriptor which is
|
||
used directly as if it were a TCP session. How well the remainder of the
|
||
TCP function system copes with this depends on what actually underlies
|
||
this file descriptor. A regular file is likely to be unusable; a FIFO
|
||
(pipe) of some sort will work better, but note that it is not a good
|
||
idea for two different sessions to attempt to read from the same FIFO at
|
||
once.</p>
|
||
<p>If the option <code>-q</code> is given with any of the three forms, <code>tcp_open</code> will
|
||
not print informational messages, although it will in any case exit with
|
||
an appropriate status.</p>
|
||
<p>If the line editor (zle) is in use, which is typically the case if the
|
||
shell is interactive, <code>tcp_open</code> installs a handler inside zle which
|
||
will check for new data at the same time as it checks for keyboard
|
||
input. This is convenient as the shell consumes no CPU time while
|
||
waiting; the test is performed by the operating system. Giving the
|
||
option <code>-z</code> to any of the forms of <code>tcp_open</code> prevents the handler from
|
||
being installed, so data must be read explicitly. Note, however, this is
|
||
not necessary for executing complete sets of send and read commands from
|
||
a function, as zle is not active at this point. Generally speaking, the
|
||
handler is only active when the shell is waiting for input at a command
|
||
prompt or in the <code>vared</code> builtin. The option has no effect if zle is not
|
||
active; ‘<code>[[ -o zle]]</code>’ will test for this.</p>
|
||
<p>The first session to be opened becomes the current session and
|
||
subsequent calls to <code>tcp_open</code> do not change it. The current session is
|
||
stored in the parameter <code>$TCP_SESS</code>; see below for more detail about the
|
||
parameters used by the system.</p>
|
||
<p>The function <code>tcp_on_open</code>, if defined, is called when a session is
|
||
opened. See the description below.</p>
|
||
<p><span id="index-tcp_005fclose"></span></p>
|
||
<p><code>tcp_close</code> [ <code>-qn</code> ] [ <code>-a</code> | <code>-l</code> <code>sess</code>[<code>,</code>...] | <code>sess</code> ... ]</p>
|
||
<p>Close the named sessions, or the current session if none is given, or
|
||
all open sessions if <code>-a</code> is given. The options <code>-l</code> and <code>-s</code> are both
|
||
handled for consistency with <code>tcp_open</code>, although the latter is
|
||
redundant.</p>
|
||
<p>If the session being closed is the current one, <code>$TCP_SESS</code> is unset,
|
||
leaving no current session, even if there are other sessions still open.</p>
|
||
<p>If the session was opened with <code>tcp_open -f</code>, the file descriptor is
|
||
closed so long as it is in the range 0 to 9 accessible directly from the
|
||
command line. If the option <code>-n</code> is given, no attempt will be made to
|
||
close file descriptors in this case. The <code>-n</code> option is not used for
|
||
genuine <code>ztcp</code> session; the file descriptors are always closed with the
|
||
session.</p>
|
||
<p>If the option <code>-q</code> is given, no informational messages will be printed.</p>
|
||
<p><span id="index-tcp_005fread"></span></p>
|
||
<p><code>tcp_read </code>[ <code>-bdq</code> ] [ <code>-t</code> <code>TO</code> ] [ <code>-T</code> <code>TO</code> ]</p>
|
||
<p><code> </code>[ <code>-a</code> | <code>-u</code> <code>fd</code>[<code>,</code>...] | <code>-l</code> <code>sess</code>[<code>,</code>...] | <code>-s</code>
|
||
<code>sess</code> ... ]</p>
|
||
<p>Perform a read operation on the current session, or on a list of
|
||
sessions if any are given with <code>-u</code>, <code>-l</code> or <code>-s</code>, or all open sessions
|
||
if the option <code>-a</code> is given. Any of the <code>-u</code>, <code>-l</code> or <code>-s</code> options may
|
||
be repeated or mixed together. The <code>-u</code> option specifies a file
|
||
descriptor directly (only those managed by this system are useful), the
|
||
other two specify sessions as described for <code>tcp_open</code> above.</p>
|
||
<p>The function checks for new data available on all the sessions listed.
|
||
Unless the <code>-b</code> option is given, it will not block waiting for new data.
|
||
Any one line of data from any of the available sessions will be read,
|
||
stored in the parameter <code>$TCP_LINE</code>, and displayed to standard output
|
||
unless <code>$TCP_SILENT</code> contains a non-empty string. When printed to
|
||
standard output the string <code>$TCP_PROMPT</code> will be shown at the start of
|
||
the line; the default form for this includes the name of the session
|
||
being read. See below for more information on these parameters. In this
|
||
mode, <code>tcp_read</code> can be called repeatedly until it returns status 2
|
||
which indicates all pending input from all specified sessions has been
|
||
handled.</p>
|
||
<p>With the option <code>-b</code>, equivalent to an infinite timeout, the function
|
||
will block until a line is available to read from one of the specified
|
||
sessions. However, only a single line is returned.</p>
|
||
<p>The option <code>-d</code> indicates that all pending input should be drained. In
|
||
this case <code>tcp_read</code> may process multiple lines in the manner given
|
||
above; only the last is stored in <code>$TCP_LINE</code>, but the complete set is
|
||
stored in the array <code>$tcp_lines</code>. This is cleared at the start of each
|
||
call to <code>tcp_read</code>.</p>
|
||
<p>The options <code>-t</code> and <code>-T</code> specify a timeout in seconds, which may be a
|
||
floating point number for increased accuracy. With <code>-t</code> the timeout is
|
||
applied before each line read. With <code>-T</code>, the timeout applies to the
|
||
overall operation, possibly including multiple read operations if the
|
||
option <code>-d</code> is present; without this option, there is no distinction
|
||
between <code>-t</code> and <code>-T</code>.</p>
|
||
<p>The function does not print informational messages, but if the option
|
||
<code>-q</code> is given, no error message is printed for a non-existent session.</p>
|
||
<p>A return status of 2 indicates a timeout or no data to read. Any other
|
||
non-zero return status indicates some error condition.</p>
|
||
<p>See <code>tcp_log</code> for how to control where data is sent by <code>tcp_read</code>.</p>
|
||
<p><span id="index-tcp_005fsend"></span></p>
|
||
<p><code>tcp_send</code> [ <code>-cnq</code> ] [ <code>-s</code> <code>sess</code> | <code>-l</code> <code>sess</code>[<code>,</code>...] ] <code>data</code>
|
||
...</p>
|
||
<p><code>tcp_send</code> [ <code>-cnq</code> ] <code>-a</code> <code>data</code> ...</p>
|
||
<p>Send the supplied data strings to all the specified sessions in turn.
|
||
The underlying operation differs little from a ‘<code>print -r</code>’ to the
|
||
session’s file descriptor, although it attempts to prevent the shell
|
||
from dying owing to a <code>SIGPIPE</code> caused by an attempt to write to a
|
||
defunct session.</p>
|
||
<p>The option <code>-c</code> causes <code>tcp_send</code> to behave like <code>cat</code>. It reads lines
|
||
from standard input until end of input and sends them in turn to the
|
||
specified session(s) exactly as if they were given as <code>data</code> arguments
|
||
to individual <code>tcp_send</code> commands.</p>
|
||
<p>The option <code>-n</code> prevents <code>tcp_send</code> from putting a newline at the end of
|
||
the data strings.</p>
|
||
<p>The remaining options all behave as for <code>tcp_read</code>.</p>
|
||
<p>The data arguments are not further processed once they have been passed
|
||
to <code>tcp_send</code>; they are simply passed down to <code>print -r</code>.</p>
|
||
<p>If the parameter <code>$TCP_OUTPUT</code> is a non-empty string and logging is
|
||
enabled then the data sent to each session will be echoed to the log
|
||
file(s) with <code>$TCP_OUTPUT</code> in front where appropriate, much in the
|
||
manner of <code>$TCP_PROMPT</code>.</p>
|
||
<hr />
|
||
<p><span id="Session-Management"></span></p>
|
||
<h3 id="2422-session-management"><a class="header" href="#2422-session-management">24.2.2 Session Management</a></h3>
|
||
<p><span id="index-tcp_005falias"></span></p>
|
||
<p><code>tcp_alias</code> [ <code>-q</code> ] <code>alias``=``sess</code> ...</p>
|
||
<p><code>tcp_alias</code> [ <code>-q</code> ] [ <code>alias</code> ... ]</p>
|
||
<p><code>tcp_alias</code> <code>-d</code> [ <code>-q</code> ] <code>alias</code> ...</p>
|
||
<p>This function is not particularly well tested.</p>
|
||
<p>The first form creates an alias for a session name; <code>alias</code> can then be
|
||
used to refer to the existing session <code>sess</code>. As many aliases may be
|
||
listed as required.</p>
|
||
<p>The second form lists any aliases specified, or all aliases if none.</p>
|
||
<p>The third form deletes all the aliases listed. The underlying sessions
|
||
are not affected.</p>
|
||
<p>The option <code>-q</code> suppresses an inconsistently chosen subset of error
|
||
messages.</p>
|
||
<p><span id="index-tcp_005flog"></span></p>
|
||
<p><code>tcp_log</code> [ <code>-asc</code> ] [ <code>-n</code> | <code>-N</code> ] [ <code>logfile</code> ]</p>
|
||
<p>With an argument <code>logfile</code>, all future input from <code>tcp_read</code> will be
|
||
logged to the named file. Unless <code>-a</code> (append) is given, this file will
|
||
first be truncated or created empty. With no arguments, show the current
|
||
status of logging.</p>
|
||
<p>With the option <code>-s</code>, per-session logging is enabled. Input from
|
||
<code>tcp_read</code> is output to the file <code>logfile``.``sess</code>. As the session is
|
||
automatically discriminated by the filename, the contents are raw (no
|
||
<code>$TCP_PROMPT</code>). The option <code>-a</code> applies as above. Per-session logging
|
||
and logging of all data in one file are not mutually exclusive.</p>
|
||
<p>The option <code>-c</code> closes all logging, both complete and per-session logs.</p>
|
||
<p>The options <code>-n</code> and <code>-N</code> respectively turn off or restore output of
|
||
data read by <code>tcp_read</code> to standard output; hence ‘<code>tcp_log -cn</code>’ turns
|
||
off all output by <code>tcp_read</code>.</p>
|
||
<p>The function is purely a convenient front end to setting the parameters
|
||
<code>$TCP_LOG</code>, <code>$TCP_LOG_SESS</code>, <code>$TCP_SILENT</code>, which are described below.</p>
|
||
<p><span id="index-tcp_005frename"></span></p>
|
||
<p><code>tcp_rename</code> <code>old</code> <code>new</code></p>
|
||
<p>Rename session <code>old</code> to session <code>new</code>. The old name becomes invalid.</p>
|
||
<p><span id="index-tcp_005fsess"></span></p>
|
||
<p><code>tcp_sess</code> [ <code>sess</code> [ <code>command</code> [ <code>arg</code> ... ] ] ]</p>
|
||
<p>With no arguments, list all the open sessions and associated file
|
||
descriptors. The current session is marked with a star. For use in
|
||
functions, direct access to the parameters <code>$tcp_by_name</code>, <code>$tcp_by_fd</code>
|
||
and <code>$TCP_SESS</code> is probably more convenient; see below.</p>
|
||
<p>With a <code>sess</code> argument, set the current session to <code>sess</code>. This is
|
||
equivalent to changing <code>$TCP_SESS</code> directly.</p>
|
||
<p>With additional arguments, temporarily set the current session while
|
||
executing ‘<code>command</code> <code>arg</code> ...’. <code>command</code> is re-evaluated so as to
|
||
expand aliases etc., but the remaining <code>arg</code>s are passed through as that
|
||
appear to <code>tcp_sess</code>. The original session is restored when <code>tcp_sess</code>
|
||
exits.</p>
|
||
<hr />
|
||
<p><span id="Advanced-I_002fO"></span></p>
|
||
<h3 id="2423-advanced-io"><a class="header" href="#2423-advanced-io">24.2.3 Advanced I/O</a></h3>
|
||
<p><span id="index-tcp_005fcommand"></span></p>
|
||
<p><code>tcp_command</code> <code>send-option</code> ... <code>send-argument</code> ...</p>
|
||
<p>This is a convenient front-end to <code>tcp_send</code>. All arguments are passed
|
||
to <code>tcp_send</code>, then the function pauses waiting for data. While data is
|
||
arriving at least every <code>$TCP_TIMEOUT</code> (default 0.3) seconds, data is
|
||
handled and printed out according to the current settings. Status 0 is
|
||
always returned.</p>
|
||
<p>This is generally only useful for interactive use, to prevent the
|
||
display becoming fragmented by output returned from the connection.
|
||
Within a programme or function it is generally better to handle reading
|
||
data by a more explicit method.</p>
|
||
<p><span id="index-tcp_005fexpect"></span></p>
|
||
<p><code>tcp_expect </code>[ <code>-q</code> ] [ <code>-p</code> <code>var</code> | <code>-P</code> <code>var</code> ] [ <code>-t</code> <code>TO</code> |
|
||
<code>-T</code> <code>TO</code> ]</p>
|
||
<p><code> </code>[ <code>-a</code> | <code>-s</code> <code>sess</code> | <code>-l</code> <code>sess</code>[<code>,</code>...] ] <code>pattern</code>
|
||
...</p>
|
||
<p>Wait for input matching any of the given <code>pattern</code>s from any of the
|
||
specified sessions. Input is ignored until an input line matches one of
|
||
the given patterns; at this point status zero is returned, the matching
|
||
line is stored in <code>$TCP_LINE</code>, and the full set of lines read during the
|
||
call to <code>tcp_expect</code> is stored in the array <code>$tcp_expect_lines</code>.</p>
|
||
<p>Sessions are specified in the same way as <code>tcp_read</code>: the default is to
|
||
use the current session, otherwise the sessions specified by <code>-a</code>, <code>-s</code>,
|
||
or <code>-l</code> are used.</p>
|
||
<p>Each <code>pattern</code> is a standard zsh extended-globbing pattern; note that it
|
||
needs to be quoted to avoid it being expanded immediately by filename
|
||
generation. It must match the full line, so to match a substring there
|
||
must be a ‘<code>*</code>’ at the start and end. The line matched against includes
|
||
the <code>$TCP_PROMPT</code> added by <code>tcp_read</code>. It is possible to include the
|
||
globbing flags ‘<code>#b</code>’ or ‘<code>#m</code>’ in the patterns to make backreferences
|
||
available in the parameters <code>$MATCH</code>, <code>$match</code>, etc., as described in
|
||
the base zsh documentation on pattern matching.</p>
|
||
<p>Unlike <code>tcp_read</code>, the default behaviour of <code>tcp_expect</code> is to block
|
||
indefinitely until the required input is found. This can be modified by
|
||
specifying a timeout with <code>-t</code> or <code>-T</code>; these function as in <code>tcp_read</code>,
|
||
specifying a per-read or overall timeout, respectively, in seconds, as
|
||
an integer or floating-point number. As <code>tcp_read</code>, the function returns
|
||
status 2 if a timeout occurs.</p>
|
||
<p>The function returns as soon as any one of the patterns given match. If
|
||
the caller needs to know which of the patterns matched, the option <code>-p</code>
|
||
<code>var</code> can be used; on return, <code>$var</code> is set to the number of the pattern
|
||
using ordinary zsh indexing, i.e. the first is 1, and so on. Note the
|
||
absence of a ‘<code>$</code>’ in front of <code>var</code>. To avoid clashes, the parameter
|
||
cannot begin with ‘<code>_expect</code>’. The index -1 is used if there is a
|
||
timeout and 0 if there is no match.</p>
|
||
<p>The option <code>-P</code> <code>var</code> works similarly to <code>-p</code>, but instead of numerical
|
||
indexes the regular arguments must begin with a prefix followed by a
|
||
colon: that prefix is then used as a tag to which <code>var</code> is set when the
|
||
argument matches. The tag <code>timeout</code> is used if there is a timeout and
|
||
the empty string if there is no match. Note it is matches do not need to
|
||
be distinguished.</p>
|
||
<p>The option <code>-q</code> is passed directly down to <code>tcp_read</code>.</p>
|
||
<p>As all input is done via <code>tcp_read</code>, all the usual rules about output of
|
||
lines read apply. One exception is that the parameter <code>$tcp_lines</code> will
|
||
only reflect the line actually matched by <code>tcp_expect</code>; use
|
||
<code>$tcp_expect_lines</code> for the full set of lines read during the function
|
||
call.</p>
|
||
<p><span id="index-tcp_005fproxy"></span></p>
|
||
<p><code>tcp_proxy</code></p>
|
||
<p>This is a simple-minded function to accept a TCP connection and execute
|
||
a command with I/O redirected to the connection. Extreme caution should
|
||
be taken as there is no security whatsoever and this can leave your
|
||
computer open to the world. Ideally, it should only be used behind a
|
||
firewall.</p>
|
||
<p>The first argument is a TCP port on which the function will listen.</p>
|
||
<p>The remaining arguments give a command and its arguments to execute with
|
||
standard input, standard output and standard error redirected to the
|
||
file descriptor on which the TCP session has been accepted. If no
|
||
command is given, a new zsh is started. This gives everyone on your
|
||
network direct access to your account, which in many cases will be a bad
|
||
thing.</p>
|
||
<p>The command is run in the background, so <code>tcp_proxy</code> can then accept new
|
||
connections. It continues to accept new connections until interrupted.</p>
|
||
<p><span id="index-tcp_005fspam"></span></p>
|
||
<p><code>tcp_spam</code> [ <code>-ertv</code> ] [ <code>-a</code> | <code>-s</code> <code>sess</code> | <code>-l</code> <code>sess</code>[<code>,</code>...]
|
||
] <code>cmd</code> [ <code>arg</code> ... ]</p>
|
||
<p>Execute ‘<code>cmd</code> [ <code>arg</code> ... ]’ for each session in turn. Note this
|
||
executes the command and arguments; it does not send the command line as
|
||
data unless the <code>-t</code> (transmit) option is given.</p>
|
||
<p>The sessions may be selected explicitly with the standard <code>-a</code>, <code>-s</code> or
|
||
<code>-l</code> options, or may be chosen implicitly. If none of the three options
|
||
is given the rules are: first, if the array <code>$tcp_spam_list</code> is set,
|
||
this is taken as the list of sessions, otherwise all sessions are taken.
|
||
Second, any sessions given in the array <code>$tcp_no_spam_list</code> are removed
|
||
from the list of sessions.</p>
|
||
<p>Normally, any sessions added by the ‘<code>-a</code>’ flag or when all sessions are
|
||
chosen implicitly are spammed in alphabetic order; sessions given by the
|
||
<code>$tcp_spam_list</code> array or on the command line are spammed in the order
|
||
given. The <code>-r</code> flag reverses the order however it was arrived it.</p>
|
||
<p>The <code>-v</code> flag specifies that a <code>$TCP_PROMPT</code> will be output before each
|
||
session. This is output after any modification to <code>TCP_SESS</code> by the
|
||
user-defined <code>tcp_on_spam</code> function described below. (Obviously that
|
||
function is able to generate its own output.)</p>
|
||
<p>If the option <code>-e</code> is present, the line given as ‘<code>cmd</code> [ <code>arg</code> ... ]’
|
||
is executed using <code>eval</code>, otherwise it is executed without any further
|
||
processing.</p>
|
||
<p><span id="index-tcp_005ftalk"></span></p>
|
||
<p><code>tcp_talk</code></p>
|
||
<p>This is a fairly simple-minded attempt to force input to the line editor
|
||
to go straight to the default <code>TCP_SESS</code>.</p>
|
||
<p>An escape string, <code>$TCP_TALK_ESCAPE</code>, default ‘<code>:</code>’, is used to allow
|
||
access to normal shell operation. If it is on its own at the start of
|
||
the line, or followed only by whitespace, the line editor returns to
|
||
normal operation. Otherwise, the string and any following whitespace are
|
||
skipped and the remainder of the line executed as shell input without
|
||
any change of the line editor’s operating mode.</p>
|
||
<p>The current implementation is somewhat deficient in terms of use of the
|
||
command history. For this reason, many users will prefer to use some
|
||
form of alternative approach for sending data easily to the current
|
||
session. One simple approach is to alias some special character (such as
|
||
‘<code>%</code>’) to ‘<code>tcp_command -``-</code>’.</p>
|
||
<p><span id="index-tcp_005fwait"></span></p>
|
||
<p><code>tcp_wait</code></p>
|
||
<p>The sole argument is an integer or floating point number which gives the
|
||
seconds to delay. The shell will do nothing for that period except wait
|
||
for input on all TCP sessions by calling <code>tcp_read -a</code>. This is similar
|
||
to the interactive behaviour at the command prompt when zle handlers are
|
||
installed.</p>
|
||
<hr />
|
||
<p><span id="g_t_0060One_002dshot_0027-file-transfer"></span></p>
|
||
<h3 id="2424-one-shot-file-transfer"><a class="header" href="#2424-one-shot-file-transfer">24.2.4 ‘One-shot’ file transfer</a></h3>
|
||
<ul>
|
||
<li>
|
||
<p><code>tcp_point</code> <code>port</code><br />
|
||
<code>tcp_shoot</code> <code>host</code> <code>port</code><br />
|
||
This pair of functions provide a simple way to transfer a file
|
||
between two hosts within the shell. Note, however, that bulk data
|
||
transfer is currently done using <code>cat</code>. <code>tcp_point</code> reads any data
|
||
arriving at <code>port</code> and sends it to standard output; <code>tcp_shoot</code>
|
||
connects to <code>port</code> on <code>host</code> and sends its standard input. Any
|
||
unused <code>port</code> may be used; the standard mechanism for picking a port
|
||
is to think of a random four-digit number above 1024 until one
|
||
works.</p>
|
||
<p>To transfer a file from host <code>woodcock</code> to host <code>springes</code>, on
|
||
<code>springes</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">tcp_point 8091 >output_file
|
||
</code></pre>
|
||
</div>
|
||
<p>and on <code>woodcock</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">tcp_shoot springes 8091 <input_file
|
||
</code></pre>
|
||
</div>
|
||
<p>As these two functions do not require <code>tcp_open</code> to set up a TCP
|
||
connection first, they may need to be autoloaded separately.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="TCP-User_002ddefined-Functions"></span></p>
|
||
<h2 id="243-tcp-user-defined-functions"><a class="header" href="#243-tcp-user-defined-functions">24.3 TCP User-defined Functions</a></h2>
|
||
<p>Certain functions, if defined by the user, will be called by the
|
||
function system in certain contexts. This facility depends on the module
|
||
<code>zsh/parameter</code>, which is usually available in interactive shells as the
|
||
completion system depends on it. None of the functions need be defined;
|
||
they simply provide convenient hooks when necessary.</p>
|
||
<p>Typically, these are called after the requested action has been taken,
|
||
so that the various parameters will reflect the new state.</p>
|
||
<p><span id="index-tcp_005fon_005falias"></span></p>
|
||
<p><code>tcp_on_alias</code> <code>alias</code> <code>fd</code></p>
|
||
<p>When an alias is defined, this function will be called with two
|
||
arguments: the name of the alias, and the file descriptor of the
|
||
corresponding session.</p>
|
||
<p><span id="index-tcp_005fon_005fawol"></span></p>
|
||
<p><code>tcp_on_awol</code> <code>sess</code> <code>fd</code></p>
|
||
<p>If the function <code>tcp_fd_handler</code> is handling input from the line editor
|
||
and detects that the file descriptor is no longer reusable, by default
|
||
it removes it from the list of file descriptors handled by this method
|
||
and prints a message. If the function <code>tcp_on_awol</code> is defined it is
|
||
called immediately before this point. It may return status 100, which
|
||
indicates that the normal handling should still be performed; any other
|
||
return status indicates that no further action should be taken and the
|
||
<code>tcp_fd_handler</code> should return immediately with the given status.
|
||
Typically the action of <code>tcp_on_awol</code> will be to close the session.</p>
|
||
<p>The variable <code>TCP_INVALIDATE_ZLE</code> will be a non-empty string if it is
|
||
necessary to invalidate the line editor display using ‘<code>zle -I</code>’ before
|
||
printing output from the function.</p>
|
||
<p>(‘AWOL’ is military jargon for ‘absent without leave’ or some variation.
|
||
It has no pre-existing technical meaning known to the author.)</p>
|
||
<p><span id="index-tcp_005fon_005fclose"></span></p>
|
||
<p><code>tcp_on_close</code> <code>sess</code> <code>fd</code></p>
|
||
<p>This is called with the name of a session being closed and the file
|
||
descriptor which corresponded to that session. Both will be invalid by
|
||
the time the function is called.</p>
|
||
<p><span id="index-tcp_005fon_005fopen"></span></p>
|
||
<p><code>tcp_on_open</code> <code>sess</code> <code>fd</code></p>
|
||
<p>This is called after a new session has been defined with the session
|
||
name and file descriptor as arguments. If it returns a non-zero status,
|
||
opening the session is assumed to fail and the session is closed again;
|
||
however, <code>tcp_open</code> will continue to attempt to open any remaining
|
||
sessions given on the command line.</p>
|
||
<p><span id="index-tcp_005fon_005frename"></span></p>
|
||
<p><code>tcp_on_rename</code> <code>oldsess</code> <code>fd</code> <code>newsess</code></p>
|
||
<p>This is called after a session has been renamed with the three arguments
|
||
old session name, file descriptor, new session name.</p>
|
||
<p><span id="index-tcp_005fon_005fspam"></span></p>
|
||
<p><code>tcp_on_spam</code> <code>sess</code> <code>command ...</code></p>
|
||
<p>This is called once for each session spammed, just <em>before</em> a command is
|
||
executed for a session by <code>tcp_spam</code>. The arguments are the session name
|
||
followed by the command list to be executed. If <code>tcp_spam</code> was called
|
||
with the option <code>-t</code>, the first command will be <code>tcp_send</code>.</p>
|
||
<p>This function is called after <code>$TCP_SESS</code> is set to reflect the session
|
||
to be spammed, but before any use of it is made. Hence it is possible to
|
||
alter the value of <code>$TCP_SESS</code> within this function. For example, the
|
||
session arguments to <code>tcp_spam</code> could include extra information to be
|
||
stripped off and processed in <code>tcp_on_spam</code>.</p>
|
||
<p>If the function sets the parameter <code>$REPLY</code> to ‘<code>done</code>’, the command
|
||
line is not executed; in addition, no prompt is printed for the <code>-v</code>
|
||
option to <code>tcp_spam</code>.</p>
|
||
<p><span id="index-tcp_005fon_005funalias"></span></p>
|
||
<p><code>tcp_on_unalias</code> <code>alias</code> <code>fd</code></p>
|
||
<p>This is called with the name of an alias and the corresponding session’s
|
||
file descriptor after an alias has been deleted.</p>
|
||
<hr />
|
||
<p><span id="TCP-Utility-Functions"></span></p>
|
||
<h2 id="244-tcp-utility-functions"><a class="header" href="#244-tcp-utility-functions">24.4 TCP Utility Functions</a></h2>
|
||
<p>The following functions are used by the TCP function system but will
|
||
rarely if ever need to be called directly.</p>
|
||
<p><span id="index-tcp_005ffd_005fhandler"></span></p>
|
||
<p><code>tcp_fd_handler</code></p>
|
||
<p>This is the function installed by <code>tcp_open</code> for handling input from
|
||
within the line editor, if that is required. It is in the format
|
||
documented for the builtin ‘<code>zle -F</code>’ in <a href="Zsh-Line-Editor.html#Zle-Builtins">Zle
|
||
Builtins</a> .</p>
|
||
<p>While active, the function sets the parameter <code>TCP_HANDLER_ACTIVE</code> to 1.
|
||
This allows shell code called internally (for example, by setting
|
||
<code>tcp_on_read</code>) to tell if is being called when the shell is otherwise
|
||
idle at the editor prompt.</p>
|
||
<p><span id="index-tcp_005foutput"></span></p>
|
||
<p><code>tcp_output</code> [ <code>-q</code> ] <code>-P</code> <code>prompt</code> <code>-F</code> <code>fd</code> <code>-S</code> <code>sess</code></p>
|
||
<p>This function is used for both logging and handling output to standard
|
||
output, from within <code>tcp_read</code> and (if <code>$TCP_OUTPUT</code> is set) <code>tcp_send</code>.</p>
|
||
<p>The <code>prompt</code> to use is specified by <code>-P</code>; the default is the empty
|
||
string. It can contain:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>%c</code><br />
|
||
Expands to 1 if the session is the current session, otherwise 0.
|
||
Used with ternary expressions such as ‘<code>%(c.-.+)</code>’ to output ‘<code>+</code>’
|
||
for the current session and ‘<code>-</code>’ otherwise.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%f</code><br />
|
||
Replaced by the session’s file descriptor.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%s</code><br />
|
||
Replaced by the session name.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%%</code><br />
|
||
Replaced by a single ‘<code>%</code>’.</p>
|
||
</li>
|
||
</ul>
|
||
<p>The option <code>-q</code> suppresses output to standard output, but not to any log
|
||
files which are configured.</p>
|
||
<p>The <code>-S</code> and <code>-F</code> options are used to pass in the session name and file
|
||
descriptor for possible replacement in the prompt.</p>
|
||
<hr />
|
||
<p><span id="TCP-Parameters"></span> <span id="TCP-User-Parameters"></span></p>
|
||
<h2 id="245-tcp-user-parameters"><a class="header" href="#245-tcp-user-parameters">24.5 TCP User Parameters</a></h2>
|
||
<p>Parameters follow the usual convention that uppercase is used for
|
||
scalars and integers, while lowercase is used for normal and associative
|
||
array. It is always safe for user code to read these parameters. Some
|
||
parameters may also be set; these are noted explicitly. Others are
|
||
included in this group as they are set by the function system for the
|
||
user’s benefit, i.e. setting them is typically not useful but is benign.</p>
|
||
<p>For example, ‘<code>local TCP_SILENT=1</code>’ specifies that data read during the
|
||
function call will not be printed to standard output, regardless of the
|
||
setting outside the function. Likewise, ‘<code>local TCP_SESS=``sess</code>’ sets a
|
||
session for the duration of a function, and ‘<code>local TCP_PROMPT=</code>’
|
||
specifies that no prompt is used for input during the function.</p>
|
||
<p><span id="index-tcp_005fexpect_005flines"></span></p>
|
||
<p><code>tcp_expect_lines</code></p>
|
||
<p>Array. The set of lines read during the last call to <code>tcp_expect</code>,
|
||
including the last (<code>$TCP_LINE</code>).</p>
|
||
<p><span id="index-tcp_005ffilter"></span></p>
|
||
<p><code>tcp_filter</code></p>
|
||
<p>Array. May be set directly. A set of extended globbing patterns which,
|
||
if matched in <code>tcp_output</code>, will cause the line not to be printed to
|
||
standard output. The patterns should be defined as described for the
|
||
arguments to <code>tcp_expect</code>. Output of line to log files is not affected.</p>
|
||
<p><span id="index-TCP_005fHANDLER_005fACTIVE"></span></p>
|
||
<p><code>TCP_HANDLER_ACTIVE</code></p>
|
||
<p>Scalar. Set to 1 within <code>tcp_fd_handler</code> to indicate to functions called
|
||
recursively that they have been called during an editor session.
|
||
Otherwise unset.</p>
|
||
<p><span id="index-TCP_005fLINE"></span></p>
|
||
<p><code>TCP_LINE</code></p>
|
||
<p>The last line read by <code>tcp_read</code>, and hence also <code>tcp_expect</code>.</p>
|
||
<p><span id="index-TCP_005fLINE_005fFD"></span></p>
|
||
<p><code>TCP_LINE_FD</code></p>
|
||
<p>The file descriptor from which <code>$TCP_LINE</code> was read.
|
||
<code>${tcp_by_fd[$TCP_LINE_FD]}</code> will give the corresponding session name.</p>
|
||
<p><span id="index-tcp_005flines"></span></p>
|
||
<p><code>tcp_lines</code></p>
|
||
<p>Array. The set of lines read during the last call to <code>tcp_read</code>,
|
||
including the last (<code>$TCP_LINE</code>).</p>
|
||
<p><span id="index-TCP_005fLOG"></span></p>
|
||
<p><code>TCP_LOG</code></p>
|
||
<p>May be set directly, although it is also controlled by <code>tcp_log</code>. The
|
||
name of a file to which output from all sessions will be sent. The
|
||
output is proceeded by the usual <code>$TCP_PROMPT</code>. If it is not an absolute
|
||
path name, it will follow the user’s current directory.</p>
|
||
<p><span id="index-TCP_005fLOG_005fSESS"></span></p>
|
||
<p><code>TCP_LOG_SESS</code></p>
|
||
<p>May be set directly, although it is also controlled by <code>tcp_log</code>. The
|
||
prefix for a set of files to which output from each session separately
|
||
will be sent; the full filename is <code>${TCP_LOG_SESS}.``sess</code>. Output to
|
||
each file is raw; no prompt is added. If it is not an absolute path
|
||
name, it will follow the user’s current directory.</p>
|
||
<p><span id="index-tcp_005fno_005fspam_005flist"></span></p>
|
||
<p><code>tcp_no_spam_list</code></p>
|
||
<p>Array. May be set directly. See <code>tcp_spam</code> for how this is used.</p>
|
||
<p><span id="index-TCP_005fOUTPUT"></span></p>
|
||
<p><code>TCP_OUTPUT</code></p>
|
||
<p>May be set directly. If a non-empty string, any data sent to a session
|
||
by <code>tcp_send</code> will be logged. This parameter gives the prompt to be used
|
||
in a file specified by <code>$TCP_LOG</code> but not in a file generated from
|
||
<code>$TCP_LOG_SESS</code>. The prompt string has the same format as <code>TCP_PROMPT</code>
|
||
and the same rules for its use apply.</p>
|
||
<p><span id="index-TCP_005fPROMPT"></span></p>
|
||
<p><code>TCP_PROMPT</code></p>
|
||
<p>May be set directly. Used as the prefix for data read by <code>tcp_read</code>
|
||
which is printed to standard output or to the log file given by
|
||
<code>$TCP_LOG</code>, if any. Any ‘<code>%s</code>’, ‘<code>%f</code>’ or ‘<code>%%</code>’ occurring in the string
|
||
will be replaced by the name of the session, the session’s underlying
|
||
file descriptor, or a single ‘<code>%</code>’, respectively. The expression ‘<code>%c</code>’
|
||
expands to 1 if the session being read is the current session, else 0;
|
||
this is most useful in ternary expressions such as ‘<code>%(c.-.+)</code>’ which
|
||
outputs ‘<code>+</code>’ if the session is the current one, else ‘<code>-</code>’.</p>
|
||
<p>If the prompt starts with <code>%P</code>, this is stripped and the complete result
|
||
of the previous stage is passed through standard prompt <code>%</code>-style
|
||
formatting before being output.</p>
|
||
<p><span id="index-TCP_005fREAD_005fDEBUG"></span></p>
|
||
<p><code>TCP_READ_DEBUG</code></p>
|
||
<p>May be set directly. If this has non-zero length, <code>tcp_read</code> will give
|
||
some limited diagnostics about data being read.</p>
|
||
<p><span id="index-TCP_005fSECONDS_005fSTART"></span></p>
|
||
<p><code>TCP_SECONDS_START</code></p>
|
||
<p>This value is created and initialised to zero by tcp_open.</p>
|
||
<p>The functions <code>tcp_read</code> and <code>tcp_expect</code> use the shell’s <code>SECONDS</code>
|
||
parameter for their own timing purposes. If that parameter is not of
|
||
floating point type on entry to one of the functions, it will create a
|
||
local parameter <code>SECONDS</code> which is floating point and set the parameter
|
||
<code>TCP_SECONDS_START</code> to the previous value of <code>$SECONDS</code>. If the
|
||
parameter is already floating point, it is used without a local copy
|
||
being created and <code>TCP_SECONDS_START</code> is not set. As the global value is
|
||
zero, the shell elapsed time is guaranteed to be the sum of <code>$SECONDS</code>
|
||
and <code>$TCP_SECONDS_START</code>.</p>
|
||
<p>This can be avoided by setting <code>SECONDS</code> globally to a floating point
|
||
value using ‘<code>typeset -F SECONDS</code>’; then the TCP functions will never
|
||
make a local copy and never set <code>TCP_SECONDS_START</code> to a non-zero value.</p>
|
||
<p><span id="index-TCP_005fSESS"></span></p>
|
||
<p><code>TCP_SESS</code></p>
|
||
<p>May be set directly. The current session; must refer to one of the
|
||
sessions established by <code>tcp_open</code>.</p>
|
||
<p><span id="index-TCP_005fSILENT"></span></p>
|
||
<p><code>TCP_SILENT</code></p>
|
||
<p>May be set directly, although it is also controlled by <code>tcp_log</code>. If of
|
||
non-zero length, data read by <code>tcp_read</code> will not be written to standard
|
||
output, though may still be written to a log file.</p>
|
||
<p><span id="index-tcp_005fspam_005flist"></span></p>
|
||
<p><code>tcp_spam_list</code></p>
|
||
<p>Array. May be set directly. See the description of the function
|
||
<code>tcp_spam</code> for how this is used.</p>
|
||
<p><span id="index-TCP_005fTALK_005fESCAPE"></span></p>
|
||
<p><code>TCP_TALK_ESCAPE</code></p>
|
||
<p>May be set directly. See the description of the function <code>tcp_talk</code> for
|
||
how this is used.</p>
|
||
<p><span id="index-TCP_005fTIMEOUT"></span></p>
|
||
<p><code>TCP_TIMEOUT</code></p>
|
||
<p>May be set directly. Currently this is only used by the function
|
||
<code>tcp_command</code>, see above.</p>
|
||
<hr />
|
||
<p><span id="TCP-User_002ddefined-Parameters"></span></p>
|
||
<h2 id="246-tcp-user-defined-parameters"><a class="header" href="#246-tcp-user-defined-parameters">24.6 TCP User-defined Parameters</a></h2>
|
||
<p>The following parameters are not set by the function system, but have a
|
||
special effect if set by the user.</p>
|
||
<p><span id="index-tcp_005fon_005fread"></span></p>
|
||
<p><code>tcp_on_read</code></p>
|
||
<p>This should be an associative array; if it is not, the behaviour is
|
||
undefined. Each key is the name of a shell function or other command,
|
||
and the corresponding value is a shell pattern (using <code>EXTENDED_GLOB</code>).
|
||
Every line read from a TCP session directly or indirectly using
|
||
<code>tcp_read</code> (which includes lines read by <code>tcp_expect</code>) is compared
|
||
against the pattern. If the line matches, the command given in the key
|
||
is called with two arguments: the name of the session from which the
|
||
line was read, and the line itself.</p>
|
||
<p>If any function called to handle a line returns a non-zero status, the
|
||
line is not output. Thus a <code>tcp_on_read</code> handler containing only the
|
||
instruction ‘<code>return 1</code>’ can be used to suppress output of particular
|
||
lines (see, however, <code>tcp_filter</code> above). However, the line is still
|
||
stored in <code>TCP_LINE</code> and <code>tcp_lines</code>; this occurs after all
|
||
<code>tcp_on_read</code> processing.</p>
|
||
<hr />
|
||
<p><span id="TCP-Utility-Parameters"></span></p>
|
||
<h2 id="247-tcp-utility-parameters"><a class="header" href="#247-tcp-utility-parameters">24.7 TCP Utility Parameters</a></h2>
|
||
<p>These parameters are controlled by the function system; they may be read
|
||
directly, but should not usually be set by user code.</p>
|
||
<p><span id="index-tcp_005faliases"></span></p>
|
||
<p><code>tcp_aliases</code></p>
|
||
<p>Associative array. The keys are the names of sessions established with
|
||
<code>tcp_open</code>; each value is a space-separated list of aliases which refer
|
||
to that session.</p>
|
||
<p><span id="index-tcp_005fby_005ffd"></span></p>
|
||
<p><code>tcp_by_fd</code></p>
|
||
<p>Associative array. The keys are session file descriptors; each value is
|
||
the name of that session.</p>
|
||
<p><span id="index-tcp_005fby_005fname"></span></p>
|
||
<p><code>tcp_by_name</code></p>
|
||
<p>Associative array. The keys are the names of sessions; each value is the
|
||
file descriptor associated with that session.</p>
|
||
<hr />
|
||
<p><span id="TCP-Examples"></span> <span id="TCP-Examples-1"></span></p>
|
||
<h2 id="248-tcp-examples"><a class="header" href="#248-tcp-examples">24.8 TCP Examples</a></h2>
|
||
<p>Here is a trivial example using a remote calculator.</p>
|
||
<p>To create a calculator server on port 7337 (see the <code>dc</code> manual page for
|
||
quite how infuriating the underlying command is):</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">tcp_proxy 7337 dc
|
||
</code></pre>
|
||
</div>
|
||
<p>To connect to this from the same host with a session also named ‘<code>dc</code>’:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">tcp_open localhost 7337 dc
|
||
</code></pre>
|
||
</div>
|
||
<p>To send a command to the remote session and wait a short while for
|
||
output (assuming <code>dc</code> is the current session):</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">tcp_command 2 4 + p
|
||
</code></pre>
|
||
</div>
|
||
<p>To close the session:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">tcp_close
|
||
</code></pre>
|
||
</div>
|
||
<p>The <code>tcp_proxy</code> needs to be killed to be stopped. Note this will not
|
||
usually kill any connections which have already been accepted, and also
|
||
that the port is not immediately available for reuse.</p>
|
||
<p>The following chunk of code puts a list of sessions into an xterm
|
||
header, with the current session followed by a star.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">print -n "\033]2;TCP:" ${(k)tcp_by_name:/$TCP_SESS/$TCP_SESS\*} "\a"
|
||
</code></pre>
|
||
</div>
|
||
<hr />
|
||
<p><span id="TCP-Bugs"></span> <span id="TCP-Bugs-1"></span></p>
|
||
<h2 id="249-tcp-bugs"><a class="header" href="#249-tcp-bugs">24.9 TCP Bugs</a></h2>
|
||
<p>The function <code>tcp_read</code> uses the shell’s normal <code>read</code> builtin. As this
|
||
reads a complete line at once, data arriving without a terminating
|
||
newline can cause the function to block indefinitely.</p>
|
||
<p>Though the function suite works well for interactive use and for data
|
||
arriving in small amounts, the performance when large amounts of data
|
||
are being exchanged is likely to be extremely poor.</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>
|
||
<!-- 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="Zftp-Function-System.html#25-zftp-function-system">25 Zftp Function System</a>
|
||
<ul>
|
||
<li><a href="Zftp-Function-System.html#251-description">25.1 Description</a></li>
|
||
<li><a href="Zftp-Function-System.html#252-installation">25.2 Installation</a></li>
|
||
<li><a href="Zftp-Function-System.html#253-functions">25.3 Functions</a>
|
||
<ul>
|
||
<li><a href="Zftp-Function-System.html#2531-opening-a-connection">25.3.1 Opening a connection</a></li>
|
||
<li><a href="Zftp-Function-System.html#2532-directory-management">25.3.2 Directory management</a></li>
|
||
<li><a href="Zftp-Function-System.html#2533-status-commands">25.3.3 Status commands</a></li>
|
||
<li><a href="Zftp-Function-System.html#2534-retrieving-files">25.3.4 Retrieving files</a></li>
|
||
<li><a href="Zftp-Function-System.html#2535-sending-files">25.3.5 Sending files</a></li>
|
||
<li><a href="Zftp-Function-System.html#2536-closing-the-connection">25.3.6 Closing the connection</a></li>
|
||
<li><a href="Zftp-Function-System.html#2537-session-management">25.3.7 Session management</a></li>
|
||
<li><a href="Zftp-Function-System.html#2538-bookmarks">25.3.8 Bookmarks</a></li>
|
||
<li><a href="Zftp-Function-System.html#2539-other-functions">25.3.9 Other functions</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="Zftp-Function-System.html#254-miscellaneous-features">25.4 Miscellaneous Features</a>
|
||
<ul>
|
||
<li><a href="Zftp-Function-System.html#2541-configuration">25.4.1 Configuration</a></li>
|
||
<li><a href="Zftp-Function-System.html#2542-remote-globbing">25.4.2 Remote globbing</a></li>
|
||
<li><a href="Zftp-Function-System.html#2543-automatic-and-temporary-reopening">25.4.3 Automatic and temporary reopening</a></li>
|
||
<li><a href="Zftp-Function-System.html#2544-completion">25.4.4 Completion</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="Zftp-Function-System"></span>
|
||
<span id="Zftp-Function-System-1"></span></p>
|
||
<h1 id="25-zftp-function-system"><a class="header" href="#25-zftp-function-system">25 Zftp Function System</a></h1>
|
||
<p><span id="index-zftp-function-system"></span>
|
||
<span id="index-FTP_002c-functions-for-using-shell-as-client"></span></p>
|
||
<hr />
|
||
<p><span id="Description-4"></span></p>
|
||
<h2 id="251-description"><a class="header" href="#251-description">25.1 Description</a></h2>
|
||
<p>This describes the set of shell functions supplied with the source
|
||
distribution as an interface to the <code>zftp</code> builtin command, allowing you
|
||
to perform FTP operations from the shell command line or within
|
||
functions or scripts. The interface is similar to a traditional FTP
|
||
client (e.g. the <code>ftp</code> command itself, see man page ftp(1)), but as it
|
||
is entirely done within the shell all the familiar completion, editing
|
||
and globbing features, and so on, are present, and macros are
|
||
particularly simple to write as they are just ordinary shell functions.</p>
|
||
<p>The prerequisite is that the <code>zftp</code> command, as described in <a href="Zsh-Modules.html#The-zsh_002fzftp-Module">The
|
||
zsh/zftp Module</a> , must be
|
||
available in the version of <code>zsh</code> installed at your site. If the shell
|
||
is configured to load new commands at run time, it probably is: typing
|
||
‘<code>zmodload zsh/zftp</code>’ will make sure (if that runs silently, it has
|
||
worked). If this is not the case, it is possible <code>zftp</code> was linked into
|
||
the shell anyway: to test this, type ‘<code>which zftp</code>’ and if <code>zftp</code> is
|
||
available you will get the message ‘<code>zftp: shell built-in command</code>’.</p>
|
||
<p>Commands given directly with <code>zftp</code> builtin may be interspersed between
|
||
the functions in this suite; in a few cases, using <code>zftp</code> directly may
|
||
cause some of the status information stored in shell parameters to
|
||
become invalid. Note in particular the description of the variables
|
||
<code>$ZFTP_TMOUT</code>, <code>$ZFTP_PREFS</code> and <code>$ZFTP_VERBOSE</code> for <code>zftp</code>.</p>
|
||
<hr />
|
||
<p><span id="Installation"></span> <span id="Installation-1"></span></p>
|
||
<h2 id="252-installation"><a class="header" href="#252-installation">25.2 Installation</a></h2>
|
||
<p>You should make sure all the functions from the <code>Functions/Zftp</code>
|
||
directory of the source distribution are available; they all begin with
|
||
the two letters ‘<code>zf</code>’. They may already have been installed on your
|
||
system; otherwise, you will need to find them and copy them. The
|
||
directory should appear as one of the elements of the <code>$fpath</code> array
|
||
(this should already be the case if they were installed), and at least
|
||
the function <code>zfinit</code> should be autoloaded; it will autoload the rest.
|
||
Finally, to initialize the use of the system you need to call the
|
||
<code>zfinit</code> function. The following code in your <code>.zshrc</code> will arrange for
|
||
this; assume the functions are stored in the directory <code>~/myfns</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">fpath=(~/myfns $fpath)
|
||
autoload -U zfinit
|
||
zfinit
|
||
</code></pre>
|
||
</div>
|
||
<p>Note that <code>zfinit</code> assumes you are using the <code>zmodload</code> method to load
|
||
the <code>zftp</code> command. If it is already built into the shell, change
|
||
<code>zfinit</code> to <code>zfinit -n</code>. It is helpful (though not essential) if the
|
||
call to <code>zfinit</code> appears after any code to initialize the new completion
|
||
system, else unnecessary <code>compctl</code> commands will be given.</p>
|
||
<hr />
|
||
<p><span id="Zftp-Functions"></span> <span id="Functions-2"></span></p>
|
||
<h2 id="253-functions"><a class="header" href="#253-functions">25.3 Functions</a></h2>
|
||
<p>The sequence of operations in performing a file transfer is essentially
|
||
the same as that in a standard FTP client. Note that, due to a quirk of
|
||
the shell’s <code>getopts</code> builtin, for those functions that handle options
|
||
you must use ‘<code>-``-</code>’ rather than ‘<code>-</code>’ to ensure the remaining
|
||
arguments are treated literally (a single ‘<code>-</code>’ is treated as an
|
||
argument).</p>
|
||
<hr />
|
||
<p><span id="Opening-a-connection"></span></p>
|
||
<h3 id="2531-opening-a-connection"><a class="header" href="#2531-opening-a-connection">25.3.1 Opening a connection</a></h3>
|
||
<p><span id="index-zfparams"></span></p>
|
||
<p><code>zfparams</code> [ <code>host</code> [ <code>user</code> [ <code>password</code> ... ] ] ]</p>
|
||
<p>Set or show the parameters for a future <code>zfopen</code> with no arguments. If
|
||
no arguments are given, the current parameters are displayed (the
|
||
password will be shown as a line of asterisks). If a <code>host</code> is given,
|
||
and either the <code>user</code> or <code>password</code> is not, they will be prompted for;
|
||
also, any parameter given as ‘<code>?</code>’ will be prompted for, and if the
|
||
‘<code>?</code>’ is followed by a string, that will be used as the prompt. As
|
||
<code>zfopen</code> calls <code>zfparams</code> to store the parameters, this usually need not
|
||
be called directly.</p>
|
||
<p>A single argument ‘<code>-</code>’ will delete the stored parameters. This will
|
||
also cause the memory of the last directory (and so on) on the other
|
||
host to be deleted.</p>
|
||
<p><span id="index-zfopen"></span></p>
|
||
<p><code>zfopen</code> [ <code>-1</code> ] [ <code>host</code> [ <code>user</code> [ <code>password</code> [ <code>account</code> ] ]
|
||
] ]</p>
|
||
<p>If <code>host</code> is present, open a connection to that host under username
|
||
<code>user</code> with password <code>password</code> (and, on the rare occasions when it is
|
||
necessary, account <code>account</code>). If a necessary parameter is missing or
|
||
given as ‘<code>?</code>’ it will be prompted for. If <code>host</code> is not present, use a
|
||
previously stored set of parameters.</p>
|
||
<p>If the command was successful, and the terminal is compatible with
|
||
<code>xterm</code> or is <code>sun-cmd</code>, a summary will appear in the title bar, giving
|
||
the local <code>host:directory</code> and the remote <code>host:directory</code>; this is
|
||
handled by the function <code>zftp_chpwd</code>, described below.</p>
|
||
<p>Normally, the <code>host</code>, <code>user</code> and <code>password</code> are internally recorded for
|
||
later re-opening, either by a <code>zfopen</code> with no arguments, or
|
||
automatically (see below). With the option ‘<code>-1</code>’, no information is
|
||
stored. Also, if an open command with arguments failed, the parameters
|
||
will not be retained (and any previous parameters will also be deleted).
|
||
A <code>zfopen</code> on its own, or a <code>zfopen -1</code>, never alters the stored
|
||
parameters.</p>
|
||
<p>Both <code>zfopen</code> and <code>zfanon</code> (but not <code>zfparams</code>) understand URLs of the
|
||
form <code>ftp://``host</code>/<code>path...</code> as meaning to connect to the <code>host</code>, then
|
||
change directory to <code>path</code> (which must be a directory, not a file). The
|
||
‘<code>ftp://</code>’ can be omitted; the trailing ‘<code>/</code>’ is enough to trigger
|
||
recognition of the <code>path</code>. Note prefixes other than ‘<code>ftp:</code>’ are not
|
||
recognized, and that all characters after the first slash beyond <code>host</code>
|
||
are significant in <code>path</code>.</p>
|
||
<p><span id="index-zfanon"></span></p>
|
||
<p><code>zfanon</code> [ <code>-1</code> ] <code>host</code></p>
|
||
<p>Open a connection <code>host</code> for anonymous FTP. The username used is
|
||
‘<code>anonymous</code>’. The password (which will be reported the first time) is
|
||
generated as <code>user``@``host</code>; this is then stored in the shell parameter
|
||
<code>$EMAIL_ADDR</code> which can alternatively be set manually to a</p>
|
||
<hr />
|
||
<p><span id="Directory-management"></span></p>
|
||
<h3 id="2532-directory-management"><a class="header" href="#2532-directory-management">25.3.2 Directory management</a></h3>
|
||
<p><span id="index-zfcd"></span></p>
|
||
<p><code>zfcd</code> [ <code>dir</code> ]</p>
|
||
<p><code>zfcd -</code></p>
|
||
<p><code>zfcd</code> <code>old</code> <code>new</code></p>
|
||
<p>Change the current directory on the remote server: this is implemented
|
||
to have many of the features of the shell builtin <code>cd</code>.</p>
|
||
<p>In the first form with <code>dir</code> present, change to the directory <code>dir</code>. The
|
||
command ‘<code>zfcd ..</code>’ is treated specially, so is guaranteed to work on
|
||
non-UNIX servers (note this is handled internally by <code>zftp</code>). If <code>dir</code>
|
||
is omitted, has the effect of ‘<code>zfcd ~</code>’.</p>
|
||
<p>The second form changes to the directory previously current.</p>
|
||
<p>The third form attempts to change the current directory by replacing the
|
||
first occurrence of the string <code>old</code> with the string <code>new</code> in the
|
||
current directory.</p>
|
||
<p>Note that in this command, and indeed anywhere a remote filename is
|
||
expected, the string which on the local host corresponds to ‘<code>~</code>’ is
|
||
converted back to a ‘<code>~</code>’ before being passed to the remote machine.
|
||
This is convenient because of the way expansion is performed on the
|
||
command line before <code>zfcd</code> receives a string. For example, suppose the
|
||
command is ‘<code>zfcd ~/foo</code>’. The shell will expand this to a full path
|
||
such as ‘<code>zfcd /home/user2/pws/foo</code>’. At this stage, <code>zfcd</code> recognises
|
||
the initial path as corresponding to ‘<code>~</code>’ and will send the directory
|
||
to the remote host as <code>~/foo</code>, so that the ‘<code>~</code>’ will be expanded by the
|
||
server to the correct remote host directory. Other named directories of
|
||
the form ‘<code>~name</code>’ are not treated in this fashion.</p>
|
||
<p><span id="index-zfhere"></span></p>
|
||
<p><code>zfhere</code></p>
|
||
<p>Change directory on the remote server to the one corresponding to the
|
||
current local directory, with special handling of ‘<code>~</code>’ as in <code>zfcd</code>.
|
||
For example, if the current local directory is <code>~/foo/bar</code>, then
|
||
<code>zfhere</code> performs the effect of ‘<code>zfcd ~/foo/bar</code>’.</p>
|
||
<p><span id="index-zfdir"></span></p>
|
||
<p><code>zfdir</code> [ <code>-rfd</code> ] [ <code>-</code> ] [ <code>dir-options</code> ] [ <code>dir</code> ]</p>
|
||
<p>Produce a long directory listing. The arguments <code>dir-options</code> and <code>dir</code>
|
||
are passed directly to the server and their effect is implementation
|
||
dependent, but specifying a particular remote directory <code>dir</code> is usually
|
||
possible. The output is passed through a pager given by the environment
|
||
variable <code>$PAGER</code>, or ‘<code>more</code>’ if that is not set.</p>
|
||
<p>The directory is usually cached for re-use. In fact, two caches are
|
||
maintained. One is for use when there is no <code>dir-options</code> or <code>dir</code>, i.e.
|
||
a full listing of the current remote directory; it is flushed when the
|
||
current remote directory changes. The other is kept for repeated use of
|
||
<code>zfdir</code> with the same arguments; for example, repeated use of ‘<code>zfdir /pub/gnu</code>’ will only require the directory to be retrieved on the first
|
||
call. Alternatively, this cache can be re-viewed with the <code>-r</code> option.
|
||
As relative directories will confuse <code>zfdir</code>, the <code>-f</code> option can be
|
||
used to force the cache to be flushed before the directory is listed.
|
||
The option <code>-d</code> will delete both caches without showing a directory
|
||
listing; it will also delete the cache of file names in the current
|
||
remote directory, if any.</p>
|
||
<p><span id="index-zfls"></span></p>
|
||
<p><code>zfls</code> [ <code>ls-options</code> ] [ <code>dir</code> ]</p>
|
||
<p>List files on the remote server. With no arguments, this will produce a
|
||
simple list of file names for the current remote directory. Any
|
||
arguments are passed directly to the server. No pager and no caching is
|
||
used.</p>
|
||
<hr />
|
||
<p><span id="Status-commands"></span></p>
|
||
<h3 id="2533-status-commands"><a class="header" href="#2533-status-commands">25.3.3 Status commands</a></h3>
|
||
<p><span id="index-zftype"></span></p>
|
||
<p><code>zftype</code> [ <code>type</code> ]</p>
|
||
<p>With no arguments, show the type of data to be transferred, usually
|
||
ASCII or binary. With an argument, change the type: the types ‘<code>A</code>’ or
|
||
‘<code>ASCII</code>’ for ASCII data and ‘<code>B</code>’ or ‘<code>BINARY</code>’, ‘<code>I</code>’ or ‘<code>IMAGE</code>’
|
||
for binary data are understood case-insensitively.</p>
|
||
<p><span id="index-zfstat"></span></p>
|
||
<p><code>zfstat</code> [ <code>-v</code> ]</p>
|
||
<p>Show the status of the current or last connection, as well as the status
|
||
of some of <code>zftp</code>’s status variables. With the <code>-v</code> option, a more
|
||
verbose listing is produced by querying the server for its version of
|
||
events, too.</p>
|
||
<hr />
|
||
<p><span id="Retrieving-files"></span></p>
|
||
<h3 id="2534-retrieving-files"><a class="header" href="#2534-retrieving-files">25.3.4 Retrieving files</a></h3>
|
||
<p>The commands for retrieving files all take at least two options. <code>-G</code>
|
||
suppresses remote filename expansion which would otherwise be performed
|
||
(see below for a more detailed description of that). <code>-t</code> attempts to
|
||
set the modification time of the local file to that of the remote file:
|
||
see the description of the function <code>zfrtime</code> below for more
|
||
information.</p>
|
||
<p><span id="index-zfget"></span></p>
|
||
<p><code>zfget</code> [ <code>-Gtc</code> ] <code>file1</code> ...</p>
|
||
<p>Retrieve all the listed files <code>file1</code> ... one at a time from the remote
|
||
server. If a file contains a ‘<code>/</code>’, the full name is passed to the
|
||
remote server, but the file is stored locally under the name given by
|
||
the part after the final ‘<code>/</code>’. The option <code>-c</code> (cat) forces all files
|
||
to be sent as a single stream to standard output; in this case the <code>-t</code>
|
||
option has no effect.</p>
|
||
<p><span id="index-zfuget"></span></p>
|
||
<p><code>zfuget</code> [ <code>-Gvst</code> ] <code>file1</code> ...</p>
|
||
<p>As <code>zfget</code>, but only retrieve files where the version on the remote
|
||
server is newer (has a later modification time), or where the local file
|
||
does not exist. If the remote file is older but the files have different
|
||
sizes, or if the sizes are the same but the remote file is newer, the
|
||
user will usually be queried. With the option <code>-s</code>, the command runs
|
||
silently and will always retrieve the file in either of those two cases.
|
||
With the option <code>-v</code>, the command prints more information about the
|
||
files while it is working out whether or not to transfer them.</p>
|
||
<p><span id="index-zfcget"></span></p>
|
||
<p><code>zfcget</code> [ <code>-Gt</code> ] <code>file1</code> ...</p>
|
||
<p>As <code>zfget</code>, but if any of the local files exists, and is shorter than
|
||
the corresponding remote file, the command assumes that it is the result
|
||
of a partially completed transfer and attempts to transfer the rest of
|
||
the file. This is useful on a poor connection which keeps failing.</p>
|
||
<p>Note that this requires a commonly implemented, but non-standard,
|
||
version of the FTP protocol, so is not guaranteed to work on all
|
||
servers.</p>
|
||
<p><span id="index-zfgcp"></span></p>
|
||
<p><code>zfgcp</code> [ <code>-Gt</code> ] <code>remote-file</code> <code>local-file</code></p>
|
||
<p><code>zfgcp</code> [ <code>-Gt</code> ] <code>rfile1</code> ... <code>ldir</code></p>
|
||
<p>This retrieves files from the remote server with arguments behaving
|
||
similarly to the <code>cp</code> command.</p>
|
||
<p>In the first form, copy <code>remote-file</code> from the server to the local file
|
||
<code>local-file</code>.</p>
|
||
<p>In the second form, copy all the remote files <code>rfile1</code> ... into the
|
||
local directory <code>ldir</code> retaining the same basenames. This assumes UNIX
|
||
directory semantics.</p>
|
||
<hr />
|
||
<p><span id="Sending-files"></span></p>
|
||
<h3 id="2535-sending-files"><a class="header" href="#2535-sending-files">25.3.5 Sending files</a></h3>
|
||
<p><span id="index-zfput"></span></p>
|
||
<p><code>zfput</code> [ <code>-r</code> ] <code>file1</code> ...</p>
|
||
<p>Send all the <code>file1</code> ... given separately to the remote server. If a
|
||
filename contains a ‘<code>/</code>’, the full filename is used locally to find the
|
||
file, but only the basename is used for the remote file name.</p>
|
||
<p>With the option <code>-r</code>, if any of the <code>files</code> are directories they are
|
||
sent recursively with all their subdirectories, including files
|
||
beginning with ‘<code>.</code>’. This requires that the remote machine understand
|
||
UNIX file semantics, since ‘<code>/</code>’ is used as a directory separator.</p>
|
||
<p><span id="index-zfuput"></span></p>
|
||
<p><code>zfuput</code> [ <code>-vs</code> ] <code>file1</code> ...</p>
|
||
<p>As <code>zfput</code>, but only send files which are newer than their remote
|
||
equivalents, or if the remote file does not exist. The logic is the same
|
||
as for <code>zfuget</code>, but reversed between local and remote files.</p>
|
||
<p><span id="index-zfcput"></span></p>
|
||
<p><code>zfcput</code> <code>file1</code> ...</p>
|
||
<p>As <code>zfput</code>, but if any remote file already exists and is shorter than
|
||
the local equivalent, assume it is the result of an incomplete transfer
|
||
and send the rest of the file to append to the existing part. As the FTP
|
||
append command is part of the standard set, this is in principle more
|
||
likely to work than <code>zfcget</code>.</p>
|
||
<p><span id="index-zfpcp"></span></p>
|
||
<p><code>zfpcp</code> <code>local-file</code> <code>remote-file</code></p>
|
||
<p><code>zfpcp</code> <code>lfile1</code> ... <code>rdir</code></p>
|
||
<p>This sends files to the remote server with arguments behaving similarly
|
||
to the <code>cp</code> command.</p>
|
||
<p>With two arguments, copy <code>local-file</code> to the server as <code>remote-file</code>.</p>
|
||
<p>With more than two arguments, copy all the local files <code>lfile1</code> ... into
|
||
the existing remote directory <code>rdir</code> retaining the same basenames. This
|
||
assumes UNIX directory semantics.</p>
|
||
<p>A problem arises if you attempt to use <code>zfpcp</code> <code>lfile1</code> <code>rdir</code>, i.e. the
|
||
second form of copying but with two arguments, as the command has no
|
||
simple way of knowing if <code>rdir</code> corresponds to a directory or a
|
||
filename. It attempts to resolve this in various ways. First, if the
|
||
<code>rdir</code> argument is ‘<code>.</code>’ or ‘<code>..</code>’ or ends in a slash, it is assumed to
|
||
be a directory. Secondly, if the operation of copying to a remote file
|
||
in the first form failed, and the remote server sends back the expected
|
||
failure code 553 and a reply including the string ‘<code>Is a directory</code>’,
|
||
then <code>zfpcp</code> will retry using the second form.</p>
|
||
<hr />
|
||
<p><span id="Closing-the-connection"></span></p>
|
||
<h3 id="2536-closing-the-connection"><a class="header" href="#2536-closing-the-connection">25.3.6 Closing the connection</a></h3>
|
||
<p><span id="index-zfclose"></span></p>
|
||
<p><code>zfclose</code></p>
|
||
<p>Close the connection.</p>
|
||
<hr />
|
||
<p><span id="Session-management"></span></p>
|
||
<h3 id="2537-session-management"><a class="header" href="#2537-session-management">25.3.7 Session management</a></h3>
|
||
<p><span id="index-zfsession"></span></p>
|
||
<p><code>zfsession</code> [ <code>-lvod</code> ] [ <code>sessname</code> ]</p>
|
||
<p>Allows you to manage multiple FTP sessions at once. By default,
|
||
connections take place in a session called ‘<code>default</code>’; by giving the
|
||
command ‘<code>zfsession</code> <code>sessname</code>’ you can change to a new or existing
|
||
session with a name of your choice. The new session remembers its own
|
||
connection, as well as associated shell parameters, and also the
|
||
host/user parameters set by <code>zfparams</code>. Hence you can have different
|
||
sessions set up to connect to different hosts, each remembering the
|
||
appropriate host, user and password.</p>
|
||
<p>With no arguments, <code>zfsession</code> prints the name of the current session;
|
||
with the option <code>-l</code> it lists all sessions which currently exist, and
|
||
with the option <code>-v</code> it gives a verbose list showing the host and
|
||
directory for each session, where the current session is marked with an
|
||
asterisk. With <code>-o</code>, it will switch to the most recent previous session.</p>
|
||
<p>With <code>-d</code>, the given session (or else the current one) is removed;
|
||
everything to do with it is completely forgotten. If it was the only
|
||
session, a new session called ‘<code>default</code>’ is created and made current.
|
||
It is safest not to delete sessions while background commands using
|
||
<code>zftp</code> are active.</p>
|
||
<p><span id="index-zftransfer"></span></p>
|
||
<p><code>zftransfer</code> <code>sess1``:``file1</code> <code>sess2``:``file2</code></p>
|
||
<p>Transfer files between two sessions; no local copy is made. The file is
|
||
read from the session <code>sess1</code> as <code>file1</code> and written to session <code>sess2</code>
|
||
as file <code>file2</code>; <code>file1</code> and <code>file2</code> may be relative to the current
|
||
directories of the session. Either <code>sess1</code> or <code>sess2</code> may be omitted
|
||
(though the colon should be retained if there is a possibility of a
|
||
colon appearing in the file name) and defaults to the current session;
|
||
<code>file2</code> may be omitted or may end with a slash, in which case the
|
||
basename of <code>file1</code> will be added. The sessions <code>sess1</code> and <code>sess2</code> must
|
||
be distinct.</p>
|
||
<p>The operation is performed using pipes, so it is required that the
|
||
connections still be valid in a subshell, which is not the case under
|
||
versions of some operating systems, presumably due to a system bug.</p>
|
||
<hr />
|
||
<p><span id="Bookmarks"></span></p>
|
||
<h3 id="2538-bookmarks"><a class="header" href="#2538-bookmarks">25.3.8 Bookmarks</a></h3>
|
||
<p>The two functions <code>zfmark</code> and <code>zfgoto</code> allow you to ‘bookmark’ the
|
||
present location (host, user and directory) of the current FTP
|
||
connection for later use. The file to be used for storing and retrieving
|
||
bookmarks is given by the parameter <code>$ZFTP_BMFILE</code>; if not set when one
|
||
of the two functions is called, it will be set to the file <code>.zfbkmarks</code>
|
||
in the directory where your zsh startup files live (usually <code>~</code>).</p>
|
||
<p><span id="index-zfmark"></span></p>
|
||
<p><code>zfmark</code> [ <code>bookmark</code> ]</p>
|
||
<p>If given an argument, mark the current host, user and directory under
|
||
the name <code>bookmark</code> for later use by <code>zfgoto</code>. If there is no connection
|
||
open, use the values for the last connection immediately before it was
|
||
closed; it is an error if there was none. Any existing bookmark under
|
||
the same name will be silently replaced.</p>
|
||
<p>If not given an argument, list the existing bookmarks and the points to
|
||
which they refer in the form <code>user``@``host``:``directory</code>; this is the
|
||
format in which they are stored, and the file may be edited directly.</p>
|
||
<p><span id="index-zfgoto"></span></p>
|
||
<p><code>zfgoto</code> [ <code>-n</code> ] <code>bookmark</code></p>
|
||
<p>Return to the location given by <code>bookmark</code>, as previously set by
|
||
<code>zfmark</code>. If the location has user ‘<code>ftp</code>’ or ‘<code>anonymous</code>’, open the
|
||
connection with <code>zfanon</code>, so that no password is required. If the user
|
||
and host parameters match those stored for the current session, if any,
|
||
those will be used, and again no password is required. Otherwise a
|
||
password will be prompted for.</p>
|
||
<p>With the option <code>-n</code>, the bookmark is taken to be a nickname stored by
|
||
the <code>ncftp</code> program in its bookmark file, which is assumed to be
|
||
<code>~/.ncftp/bookmarks</code>. The function works identically in other ways. Note
|
||
that there is no mechanism for adding or modifying <code>ncftp</code> bookmarks
|
||
from the zftp functions.</p>
|
||
<hr />
|
||
<p><span id="Other-functions"></span></p>
|
||
<h3 id="2539-other-functions"><a class="header" href="#2539-other-functions">25.3.9 Other functions</a></h3>
|
||
<p>Mostly, these functions will not be called directly (apart from
|
||
<code>zfinit</code>), but are described here for completeness. You may wish to
|
||
alter <code>zftp_chpwd</code> and <code>zftp_progress</code>, in particular.</p>
|
||
<p><span id="index-zfinit"></span></p>
|
||
<p><code>zfinit</code> [ <code>-n</code> ]</p>
|
||
<p>As described above, this is used to initialize the zftp function system.
|
||
The <code>-n</code> option should be used if the zftp command is already built into
|
||
the shell.</p>
|
||
<p><span id="index-zfautocheck"></span></p>
|
||
<p><code>zfautocheck</code> [ <code>-dn</code> ]</p>
|
||
<p>This function is called to implement automatic reopening behaviour, as
|
||
described in more detail below. The options must appear in the first
|
||
argument; <code>-n</code> prevents the command from changing to the old directory,
|
||
while <code>-d</code> prevents it from setting the variable <code>do_close</code>, which it
|
||
otherwise does as a flag for automatically closing the connection after
|
||
a transfer. The host and directory for the last session are stored in
|
||
the variable <code>$zflastsession</code>, but the internal host/user/password
|
||
parameters must also be correctly set.</p>
|
||
<p><span id="index-zfcd_005fmatch"></span></p>
|
||
<p><code>zfcd_match prefix suffix</code></p>
|
||
<p>This performs matching for completion of remote directory names. If the
|
||
remote server is UNIX, it will attempt to persuade the server to list
|
||
the remote directory with subdirectories marked, which usually works but
|
||
is not guaranteed. On other hosts it simply calls <code>zfget_match</code> and
|
||
hence completes all files, not just directories. On some systems,
|
||
directories may not even look like filenames.</p>
|
||
<p><span id="index-zfget_005fmatch"></span></p>
|
||
<p><code>zfget_match prefix suffix</code></p>
|
||
<p>This performs matching for completion of remote filenames. It caches
|
||
files for the current directory (only) in the shell parameter
|
||
<code>$zftp_fcache</code>. It is in the form to be called by the <code>-K</code> option of
|
||
<code>compctl</code>, but also works when called from a widget-style completion
|
||
function with <code>prefix</code> and <code>suffix</code> set appropriately.</p>
|
||
<p><span id="index-zfrglob"></span></p>
|
||
<p><code>zfrglob varname</code></p>
|
||
<p>Perform remote globbing, as describes in more detail below. <code>varname</code> is
|
||
the name of a variable containing the pattern to be expanded; if there
|
||
were any matches, the same variable will be set to the expanded set of
|
||
filenames on return.</p>
|
||
<p><span id="index-zfrtime"></span></p>
|
||
<p><code>zfrtime</code> <code>lfile</code> <code>rfile</code> [ <code>time</code> ]</p>
|
||
<p>Set the local file <code>lfile</code> to have the same modification time as the
|
||
remote file <code>rfile</code>, or the explicit time <code>time</code> in FTP format
|
||
<code>CCYYMMDDhhmmSS</code> for the GMT timezone. This uses the shell’s
|
||
<code>zsh/datetime</code> module to perform the conversion from GMT to local time.</p>
|
||
<p><span id="index-zftp_005fchpwd_002c-supplied-version"></span></p>
|
||
<p><code>zftp_chpwd</code></p>
|
||
<p>This function is called every time a connection is opened, or closed, or
|
||
the remote directory changes. This version alters the title bar of an
|
||
<code>xterm</code>-compatible or <code>sun-cmd</code> terminal emulator to reflect the local
|
||
and remote hostnames and current directories. It works best when
|
||
combined with the function <code>chpwd</code>. In particular, a function of the
|
||
form</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">chpwd() {
|
||
if [[ -n $ZFTP_USER ]]; then
|
||
zftp_chpwd
|
||
else
|
||
# usual chpwd e.g put host:directory in title bar
|
||
fi
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p>fits in well.</p>
|
||
<p><span id="index-zftp_005fprogress_002c-supplied-version"></span></p>
|
||
<p><code>zftp_progress</code></p>
|
||
<p>This function shows the status of the transfer. It will not write
|
||
anything unless the output is going to a terminal; however, if you
|
||
transfer files in the background, you should turn off progress reports
|
||
by hand using ‘<code>zstyle ’:zftp:*’ progress none</code>’. Note also that if you
|
||
alter it, any output <em>must</em> be to standard error, as standard output may
|
||
be a file being received. The form of the progress meter, or whether it
|
||
is used at all, can be configured without altering the function, as
|
||
described in the next section.</p>
|
||
<p><span id="index-zffcache"></span></p>
|
||
<p><code>zffcache</code></p>
|
||
<p>This is used to implement caching of files in the current directory for
|
||
each session separately. It is used by <code>zfget_match</code> and <code>zfrglob</code>.</p>
|
||
<hr />
|
||
<p><span id="Miscellaneous-Features"></span>
|
||
<span id="Miscellaneous-Features-1"></span></p>
|
||
<h2 id="254-miscellaneous-features"><a class="header" href="#254-miscellaneous-features">25.4 Miscellaneous Features</a></h2>
|
||
<hr />
|
||
<p><span id="Configuration-3"></span></p>
|
||
<h3 id="2541-configuration"><a class="header" href="#2541-configuration">25.4.1 Configuration</a></h3>
|
||
<p><span id="index-zftp-function-system_002c-configuration"></span>
|
||
<span id="index-zftp-function-system_002c-styles"></span>
|
||
<span id="index-styles-in-zftp-functions"></span></p>
|
||
<p>Various styles are available using the standard shell style mechanism,
|
||
described in <a href="Zsh-Modules.html#The-zsh_002fzutil-Module">The zsh/zutil
|
||
Module</a>. Briefly, the command
|
||
‘<code>zstyle ’:zftp:*’</code> <code>style</code> <code>value</code> ...’. defines the <code>style</code> to have
|
||
value <code>value</code>; more than one value may be given, although that is not
|
||
useful in the cases described here. These values will then be used
|
||
throughout the zftp function system. For more precise control, the first
|
||
argument, which gives a context in which the style applies, can be
|
||
modified to include a particular function, as for example
|
||
‘<code>:zftp:zfget</code>’: the style will then have the given value only in
|
||
the <code>zfget</code> function. Values for the same style in different contexts
|
||
may be set; the most specific function will be used, where strings are
|
||
held to be more specific than patterns, and longer patterns and shorter
|
||
patterns. Note that only the top level function name, as called by the
|
||
user, is used; calling of lower level functions is transparent to the
|
||
user. Hence modifications to the title bar in <code>zftp_chpwd</code> use the
|
||
contexts <code>:zftp:zfopen</code>, <code>:zftp:zfcd</code>, etc., depending where it was
|
||
called from. The following styles are understood:</p>
|
||
<p><span id="index-progress_002c-zftp-style"></span></p>
|
||
<p><code>progress</code></p>
|
||
<p>Controls the way that <code>zftp_progress</code> reports on the progress of a
|
||
transfer. If empty, unset, or ‘<code>none</code>’, no progress report is made; if
|
||
‘<code>bar</code>’ a growing bar of inverse video is shown; if ‘<code>percent</code>’ (or
|
||
any other string, though this may change in future), the percentage of
|
||
the file transferred is shown. The bar meter requires that the width of
|
||
the terminal be available via the <code>$COLUMNS</code> parameter (normally this is
|
||
set automatically). If the size of the file being transferred is not
|
||
available, <code>bar</code> and <code>percent</code> meters will simply show the number of
|
||
bytes transferred so far.</p>
|
||
<p>When <code>zfinit</code> is run, if this style is not defined for the context
|
||
<code>:zftp:*</code>, it will be set to ‘bar’.</p>
|
||
<p><span id="index-update_002c-zftp-style"></span></p>
|
||
<p><code>update</code></p>
|
||
<p>Specifies the minimum time interval between updates of the progress
|
||
meter in seconds. No update is made unless new data has been received,
|
||
so the actual time interval is limited only by <code>$ZFTP_TIMEOUT</code>.</p>
|
||
<p>As described for <code>progress</code>, <code>zfinit</code> will force this to default to 1.</p>
|
||
<p><span id="index-remote_002dglob_002c-zftp-style"></span></p>
|
||
<p><code>remote-glob</code></p>
|
||
<p>If set to ‘<code>1</code>’, ‘<code>yes</code>’ or ‘<code>true</code>’, filename generation (globbing) is
|
||
performed on the remote machine instead of by zsh itself; see below.</p>
|
||
<p><span id="index-titlebar_002c-zftp-style"></span></p>
|
||
<p><code>titlebar</code></p>
|
||
<p>If set to ‘<code>1</code>’, ‘<code>yes</code>’ or ‘<code>true</code>’, <code>zftp_chpwd</code> will put the remote
|
||
host and remote directory into the titlebar of terminal emulators such
|
||
as xterm or sun-cmd that allow this.</p>
|
||
<p>As described for <code>progress</code>, <code>zfinit</code> will force this to default to 1.</p>
|
||
<p><span id="index-chpwd_002c-zftp-style"></span></p>
|
||
<p><code>chpwd</code></p>
|
||
<p>If set to ‘<code>1</code>’ ‘<code>yes</code>’ or ‘<code>true</code>’, <code>zftp_chpwd</code> will call the function
|
||
<code>chpwd</code> when a connection is closed. This is useful if the remote host
|
||
details were put into the terminal title bar by <code>zftp_chpwd</code> and your
|
||
usual <code>chpwd</code> also modifies the title bar.</p>
|
||
<p>When <code>zfinit</code> is run, it will determine whether <code>chpwd</code> exists and if so
|
||
it will set the default value for the style to 1 if none exists already.</p>
|
||
<p>Note that there is also an associative array <code>zfconfig</code> which contains
|
||
values used by the function system. This should not be modified or
|
||
overwritten.</p>
|
||
<hr />
|
||
<p><span id="Remote-globbing"></span></p>
|
||
<h3 id="2542-remote-globbing"><a class="header" href="#2542-remote-globbing">25.4.2 Remote globbing</a></h3>
|
||
<p><span id="index-zftp-function-system_002c-remote-globbing"></span></p>
|
||
<p>The commands for retrieving files usually perform filename generation
|
||
(globbing) on their arguments; this can be turned off by passing the
|
||
option <code>-G</code> to each of the commands. Normally this operates by
|
||
retrieving a complete list of files for the directory in question, then
|
||
matching these locally against the pattern supplied. This has the
|
||
advantage that the full range of zsh patterns (respecting the setting of
|
||
the option <code>EXTENDED_GLOB</code>) can be used. However, it means that the
|
||
directory part of a filename will not be expanded and must be given
|
||
exactly. If the remote server does not support the UNIX directory
|
||
semantics, directory handling is problematic and it is recommended that
|
||
globbing only be used within the current directory. The list of files in
|
||
the current directory, if retrieved, will be cached, so that subsequent
|
||
globs in the same directory without an intervening <code>zfcd</code> are much
|
||
faster.</p>
|
||
<p>If the <code>remote-glob</code> style (see above) is set, globbing is instead
|
||
performed on the remote host: the server is asked for a list of matching
|
||
files. This is highly dependent on how the server is implemented, though
|
||
typically UNIX servers will provide support for basic glob patterns.
|
||
This may in some cases be faster, as it avoids retrieving the entire
|
||
list of directory contents.</p>
|
||
<hr />
|
||
<p><span id="Automatic-and-temporary-reopening"></span></p>
|
||
<h3 id="2543-automatic-and-temporary-reopening"><a class="header" href="#2543-automatic-and-temporary-reopening">25.4.3 Automatic and temporary reopening</a></h3>
|
||
<p><span id="index-zftp-function-system_002c-automatic-reopening"></span></p>
|
||
<p>As described for the <code>zfopen</code> command, a subsequent <code>zfopen</code> with no
|
||
parameters will reopen the connection to the last host (this includes
|
||
connections made with the <code>zfanon</code> command). Opened in this fashion, the
|
||
connection starts in the default remote directory and will remain open
|
||
until explicitly closed.</p>
|
||
<p>Automatic re-opening is also available. If a connection is not currently
|
||
open and a command requiring a connection is given, the last connection
|
||
is implicitly reopened. In this case the directory which was current
|
||
when the connection was closed again becomes the current directory
|
||
(unless, of course, the command given changes it). Automatic reopening
|
||
will also take place if the connection was close by the remote server
|
||
for whatever reason (e.g. a timeout). It is not available if the <code>-1</code>
|
||
option to <code>zfopen</code> or <code>zfanon</code> was used.</p>
|
||
<p>Furthermore, if the command issued is a file transfer, the connection
|
||
will be closed after the transfer is finished, hence providing a
|
||
one-shot mode for transfers. This does not apply to directory changing
|
||
or listing commands; for example a <code>zfdir</code> may reopen a connection but
|
||
will leave it open. Also, automatic closure will only ever happen in the
|
||
same command as automatic opening, i.e a <code>zfdir</code> directly followed by a
|
||
<code>zfget</code> will never close the connection automatically.</p>
|
||
<p>Information about the previous connection is given by the <code>zfstat</code>
|
||
function. So, for example, if that reports:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">Session: default
|
||
Not connected.
|
||
Last session: ftp.bar.com:/pub/textfiles
|
||
</code></pre>
|
||
</div>
|
||
<p>then the command <code>zfget file.txt</code> will attempt to reopen a connection to
|
||
<code>ftp.bar.com</code>, retrieve the file <code>/pub/textfiles/file.txt</code>, and
|
||
immediately close the connection again. On the other hand, <code>zfcd ..</code>
|
||
will open the connection in the directory <code>/pub</code> and leave it open.</p>
|
||
<p>Note that all the above is local to each session; if you return to a
|
||
previous session, the connection for that session is the one which will
|
||
be reopened.</p>
|
||
<hr />
|
||
<p><span id="Completion-3"></span></p>
|
||
<h3 id="2544-completion"><a class="header" href="#2544-completion">25.4.4 Completion</a></h3>
|
||
<p>Completion of local and remote files, directories, sessions and
|
||
bookmarks is supported. The older, <code>compctl</code>-style completion is defined
|
||
when <code>zfinit</code> is called; support for the new widget-based completion
|
||
system is provided in the function <code>Completion/Zsh/Command/_zftp</code>, which
|
||
should be installed with the other functions of the completion system
|
||
and hence should automatically be available.</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>
|
||
<!-- 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="User-Contributions.html#26-user-contributions">26 User Contributions</a>
|
||
<ul>
|
||
<li><a href="User-Contributions.html#261-description">26.1 Description</a></li>
|
||
<li><a href="User-Contributions.html#262-utilities">26.2 Utilities</a>
|
||
<ul>
|
||
<li><a href="User-Contributions.html#2621-accessing-on-line-help">26.2.1 Accessing On-Line Help</a></li>
|
||
<li><a href="User-Contributions.html#2622-recompiling-functions">26.2.2 Recompiling Functions</a></li>
|
||
<li><a href="User-Contributions.html#2623-keyboard-definition">26.2.3 Keyboard Definition</a></li>
|
||
<li><a href="User-Contributions.html#2624-dumping-shell-state">26.2.4 Dumping Shell State</a></li>
|
||
<li><a href="User-Contributions.html#2625-manipulating-hook-functions">26.2.5 Manipulating Hook Functions</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="User-Contributions.html#263-remembering-recent-directories">26.3 Remembering Recent Directories</a>
|
||
<ul>
|
||
<li><a href="User-Contributions.html#2631-installation">26.3.1 Installation</a></li>
|
||
<li><a href="User-Contributions.html#2632-use">26.3.2 Use</a></li>
|
||
<li><a href="User-Contributions.html#2633-options">26.3.3 Options</a></li>
|
||
<li><a href="User-Contributions.html#2634-configuration">26.3.4 Configuration</a></li>
|
||
<li><a href="User-Contributions.html#2635-use-with-dynamic-directory-naming">26.3.5 Use with dynamic directory naming</a></li>
|
||
<li><a href="User-Contributions.html#2636-details-of-directory-handling">26.3.6 Details of directory handling</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="User-Contributions.html#264-abbreviated-dynamic-references-to-directories">26.4 Abbreviated dynamic references to directories</a>
|
||
<ul>
|
||
<li><a href="User-Contributions.html#2641-usage">26.4.1 Usage</a></li>
|
||
<li><a href="User-Contributions.html#2642-configuration">26.4.2 Configuration</a></li>
|
||
<li><a href="User-Contributions.html#2643-complete-example">26.4.3 Complete example</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="User-Contributions.html#265-gathering-information-from-version-control-systems">26.5 Gathering information from version control systems</a>
|
||
<ul>
|
||
<li><a href="User-Contributions.html#2651-quickstart">26.5.1 Quickstart</a></li>
|
||
<li><a href="User-Contributions.html#2652-configuration">26.5.2 Configuration</a></li>
|
||
<li><a href="User-Contributions.html#2653-oddities">26.5.3 Oddities</a></li>
|
||
<li><a href="User-Contributions.html#2654-quilt-support">26.5.4 Quilt Support</a></li>
|
||
<li><a href="User-Contributions.html#2655-function-descriptions-public-api">26.5.5 Function Descriptions (Public API)</a></li>
|
||
<li><a href="User-Contributions.html#2656-variable-description">26.5.6 Variable Description</a></li>
|
||
<li><a href="User-Contributions.html#2657-hooks-in-vcs%5C_info">26.5.7 Hooks in vcs_info</a></li>
|
||
<li><a href="User-Contributions.html#2658-examples">26.5.8 Examples</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="User-Contributions.html#266-prompt-themes">26.6 Prompt Themes</a>
|
||
<ul>
|
||
<li><a href="User-Contributions.html#2661-installation">26.6.1 Installation</a></li>
|
||
<li><a href="User-Contributions.html#2662-theme-selection">26.6.2 Theme Selection</a></li>
|
||
<li><a href="User-Contributions.html#2663-utility-themes">26.6.3 Utility Themes</a></li>
|
||
<li><a href="User-Contributions.html#2664-writing-themes">26.6.4 Writing Themes</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="User-Contributions.html#267-zle-functions">26.7 ZLE Functions</a>
|
||
<ul>
|
||
<li><a href="User-Contributions.html#2671-widgets">26.7.1 Widgets</a></li>
|
||
<li><a href="User-Contributions.html#2672-utility-functions">26.7.2 Utility Functions</a></li>
|
||
<li><a href="User-Contributions.html#2673-styles">26.7.3 Styles</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="User-Contributions.html#268-exception-handling">26.8 Exception Handling</a></li>
|
||
<li><a href="User-Contributions.html#269-mime-functions">26.9 MIME Functions</a></li>
|
||
<li><a href="User-Contributions.html#2610-mathematical-functions">26.10 Mathematical Functions</a></li>
|
||
<li><a href="User-Contributions.html#2611-user-configuration-functions">26.11 User Configuration Functions</a></li>
|
||
<li><a href="User-Contributions.html#2612-other-functions">26.12 Other Functions</a>
|
||
<ul>
|
||
<li><a href="User-Contributions.html#26121-descriptions">26.12.1 Descriptions</a></li>
|
||
<li><a href="User-Contributions.html#26122-styles">26.12.2 Styles</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
|
||
<p><span id="User-Contributions"></span>
|
||
<span id="User-Contributions-1"></span></p>
|
||
<h1 id="26-user-contributions"><a class="header" href="#26-user-contributions">26 User Contributions</a></h1>
|
||
<p><span id="index-user-contributions"></span></p>
|
||
<hr />
|
||
<p><span id="Description-2"></span></p>
|
||
<h2 id="261-description"><a class="header" href="#261-description">26.1 Description</a></h2>
|
||
<p>The Zsh source distribution includes a number of items contributed by
|
||
the user community. These are not inherently a part of the shell, and
|
||
some may not be available in every zsh installation. The most
|
||
significant of these are documented here. For documentation on other
|
||
contributed items such as shell functions, look for comments in the
|
||
function source files.</p>
|
||
<hr />
|
||
<p><span id="Utilities"></span> <span id="Utilities-1"></span></p>
|
||
<h2 id="262-utilities"><a class="header" href="#262-utilities">26.2 Utilities</a></h2>
|
||
<hr />
|
||
<p><span id="Accessing-On_002dLine-Help"></span></p>
|
||
<h3 id="2621-accessing-on-line-help"><a class="header" href="#2621-accessing-on-line-help">26.2.1 Accessing On-Line Help</a></h3>
|
||
<p><span id="index-helpfiles-utility"></span></p>
|
||
<p>The key sequence <code>ESC h</code> is normally bound by ZLE to execute the
|
||
<code>run-help</code> widget (see <a href="Zsh-Line-Editor.html#Zsh-Line-Editor">Zsh Line
|
||
Editor</a>). This invokes the
|
||
<code>run-help</code> command with the command word from the current input line as
|
||
its argument. By default, <code>run-help</code> is an alias for the <code>man</code> command,
|
||
so this often fails when the command word is a shell builtin or a
|
||
user-defined function. By redefining the <code>run-help</code> alias, one can
|
||
improve the on-line help provided by the shell.</p>
|
||
<p>The <code>helpfiles</code> utility, found in the <code>Util</code> directory of the
|
||
distribution, is a Perl program that can be used to process the zsh
|
||
manual to produce a separate help file for each shell builtin and for
|
||
many other shell features as well. The autoloadable <code>run-help</code> function,
|
||
found in <code>Functions/Misc</code>, searches for these helpfiles and performs
|
||
several other tests to produce the most complete help possible for the
|
||
command.</p>
|
||
<p>Help files are installed by default to a subdirectory of
|
||
<code>/usr/share/zsh</code> or <code>/usr/local/share/zsh</code>.</p>
|
||
<p>To create your own help files with <code>helpfiles</code>, choose or create a
|
||
directory where the individual command help files will reside. For
|
||
example, you might choose <code>~/zsh_help</code>. If you unpacked the zsh
|
||
distribution in your home directory, you would use the commands:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">mkdir ~/zsh_help
|
||
perl ~/zsh-5.8/Util/helpfiles ~/zsh_help
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-HELPDIR"></span></p>
|
||
<p>The <code>HELPDIR</code> parameter tells <code>run-help</code> where to look for the help
|
||
files. When unset, it uses the default installation path. To use your
|
||
own set of help files, set this to the appropriate path in one of your
|
||
startup files:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">HELPDIR=~/zsh_help
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-run_002dhelp_002c-use-of"></span></p>
|
||
<p>To use the <code>run-help</code> function, you need to add lines something like the
|
||
following to your <code>.zshrc</code> or equivalent startup file:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">unalias run-help
|
||
autoload run-help
|
||
</code></pre>
|
||
</div>
|
||
<p>Note that in order for ‘<code>autoload run-help</code>’ to work, the <code>run-help</code>
|
||
file must be in one of the directories named in your <code>fpath</code> array (see
|
||
<a href="Parameters.html#Parameters-Used-By-The-Shell">Parameters Used By The
|
||
Shell</a>). This should
|
||
already be the case if you have a standard zsh installation; if it is
|
||
not, copy <code>Functions/Misc/run-help</code> to an appropriate directory.</p>
|
||
<hr />
|
||
<p><span id="Recompiling-Functions"></span></p>
|
||
<h3 id="2622-recompiling-functions"><a class="header" href="#2622-recompiling-functions">26.2.2 Recompiling Functions</a></h3>
|
||
<p><span id="index-functions_002c-recompiling"></span>
|
||
<span id="index-zrecompile-utility"></span></p>
|
||
<p>If you frequently edit your zsh functions, or periodically update your
|
||
zsh installation to track the latest developments, you may find that
|
||
function digests compiled with the <code>zcompile</code> builtin are frequently out
|
||
of date with respect to the function source files. This is not usually a
|
||
problem, because zsh always looks for the newest file when loading a
|
||
function, but it may cause slower shell startup and function loading.
|
||
Also, if a digest file is explicitly used as an element of <code>fpath</code>, zsh
|
||
won’t check whether any of its source files has changed.</p>
|
||
<p>The <code>zrecompile</code> autoloadable function, found in <code>Functions/Misc</code>, can
|
||
be used to keep function digests up to date.</p>
|
||
<p><span id="index-zrecompile"></span></p>
|
||
<p><code>zrecompile</code> [ <code>-qt</code> ] [ <code>name</code> ... ]</p>
|
||
<p><code>zrecompile</code> [ <code>-qt</code> ] <code>-p</code> <code>arg</code> ... [ <code>-``-</code> <code>arg</code> ... ]</p>
|
||
<p>This tries to find <code>*.zwc</code> files and automatically re-compile them if at
|
||
least one of the original files is newer than the compiled file. This
|
||
works only if the names stored in the compiled files are full paths or
|
||
are relative to the directory that contains the <code>.zwc</code> file.</p>
|
||
<p>In the first form, each <code>name</code> is the name of a compiled file or a
|
||
directory containing <code>*.zwc</code> files that should be checked. If no
|
||
arguments are given, the directories and <code>*.zwc</code> files in <code>fpath</code> are
|
||
used.</p>
|
||
<p>When <code>-t</code> is given, no compilation is performed, but a return status of
|
||
zero (true) is set if there are files that need to be re-compiled and
|
||
non-zero (false) otherwise. The <code>-q</code> option quiets the chatty output
|
||
that describes what <code>zrecompile</code> is doing.</p>
|
||
<p>Without the <code>-t</code> option, the return status is zero if all files that
|
||
needed re-compilation could be compiled and non-zero if compilation for
|
||
at least one of the files failed.</p>
|
||
<p>If the <code>-p</code> option is given, the <code>arg</code>s are interpreted as one or more
|
||
sets of arguments for <code>zcompile</code>, separated by ‘<code>-``-</code>’. For example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zrecompile -p \
|
||
-R ~/.zshrc -- \
|
||
-M ~/.zcompdump -- \
|
||
~/zsh/comp.zwc ~/zsh/Completion/*/_*
|
||
</code></pre>
|
||
</div>
|
||
<p>This compiles <code>~/.zshrc</code> into <code>~/.zshrc.zwc</code> if that doesn’t exist or if
|
||
it is older than <code>~/.zshrc</code>. The compiled file will be marked for
|
||
reading instead of mapping. The same is done for <code>~/.zcompdump</code> and
|
||
<code>~/.zcompdump.zwc</code>, but this compiled file is marked for mapping. The
|
||
last line re-creates the file <code>~/zsh/comp.zwc</code> if any of the files
|
||
matching the given pattern is newer than it.</p>
|
||
<p>Without the <code>-p</code> option, <code>zrecompile</code> does not create function digests
|
||
that do not already exist, nor does it add new functions to the digest.</p>
|
||
<p>The following shell loop is an example of a method for creating function
|
||
digests for all functions in your <code>fpath</code>, assuming that you have write
|
||
permission to the directories:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">for ((i=1; i <= $#fpath; ++i)); do
|
||
dir=$fpath[i]
|
||
zwc=${dir:t}.zwc
|
||
if [[ $dir == (.|..) || $dir == (.|..)/* ]]; then
|
||
continue
|
||
fi
|
||
files=($dir/*(N-.))
|
||
if [[ -w $dir:h && -n $files ]]; then
|
||
files=(${${(M)files%/*/*}#/})
|
||
if ( cd $dir:h &&
|
||
zrecompile -p -U -z $zwc $files ); then
|
||
fpath[i]=$fpath[i].zwc
|
||
fi
|
||
fi
|
||
done
|
||
</code></pre>
|
||
</div>
|
||
<p>The <code>-U</code> and <code>-z</code> options are appropriate for functions in the default
|
||
zsh installation <code>fpath</code>; you may need to use different options for your
|
||
personal function directories.</p>
|
||
<p>Once the digests have been created and your <code>fpath</code> modified to refer to
|
||
them, you can keep them up to date by running <code>zrecompile</code> with no
|
||
arguments.</p>
|
||
<hr />
|
||
<p><span id="Keyboard-Definition"></span></p>
|
||
<h3 id="2623-keyboard-definition"><a class="header" href="#2623-keyboard-definition">26.2.3 Keyboard Definition</a></h3>
|
||
<p><span id="index-keyboard-definition"></span>
|
||
<span id="index-zkbd"></span></p>
|
||
<p>The large number of possible combinations of keyboards, workstations,
|
||
terminals, emulators, and window systems makes it impossible for zsh to
|
||
have built-in key bindings for every situation. The <code>zkbd</code> utility,
|
||
found in <code>Functions/Misc</code>, can help you quickly create key bindings for
|
||
your configuration.</p>
|
||
<p>Run <code>zkbd</code> either as an autoloaded function, or as a shell script:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zsh -f ~/zsh-5.8/Functions/Misc/zkbd
|
||
</code></pre>
|
||
</div>
|
||
<p>When you run <code>zkbd</code>, it first asks you to enter your terminal type; if
|
||
the default it offers is correct, just press return. It then asks you to
|
||
press a number of different keys to determine characteristics of your
|
||
keyboard and terminal; <code>zkbd</code> warns you if it finds anything out of the
|
||
ordinary, such as a Delete key that sends neither <code>^H</code> nor <code>^?</code>.</p>
|
||
<p>The keystrokes read by <code>zkbd</code> are recorded as a definition for an
|
||
associative array named <code>key</code>, written to a file in the subdirectory
|
||
<code>.zkbd</code> within either your <code>HOME</code> or <code>ZDOTDIR</code> directory. The name of
|
||
the file is composed from the <code>TERM</code>, <code>VENDOR</code> and <code>OSTYPE</code> parameters,
|
||
joined by hyphens.</p>
|
||
<p>You may read this file into your <code>.zshrc</code> or another startup file with
|
||
the ‘<code>source</code>’ or ‘<code>.</code>’ commands, then reference the <code>key</code> parameter in
|
||
bindkey commands, like this:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">source ${ZDOTDIR:-$HOME}/.zkbd/$TERM-$VENDOR-$OSTYPE
|
||
[[ -n ${key[Left]} ]] && bindkey "${key[Left]}" backward-char
|
||
[[ -n ${key[Right]} ]] && bindkey "${key[Right]}" forward-char
|
||
# etc.
|
||
</code></pre>
|
||
</div>
|
||
<p>Note that in order for ‘<code>autoload zkbd</code>’ to work, the <code>zkdb</code> file must
|
||
be in one of the directories named in your <code>fpath</code> array (see
|
||
<a href="Parameters.html#Parameters-Used-By-The-Shell">Parameters Used By The
|
||
Shell</a>). This should
|
||
already be the case if you have a standard zsh installation; if it is
|
||
not, copy <code>Functions/Misc/zkbd</code> to an appropriate directory.</p>
|
||
<hr />
|
||
<p><span id="Dumping-Shell-State"></span></p>
|
||
<h3 id="2624-dumping-shell-state"><a class="header" href="#2624-dumping-shell-state">26.2.4 Dumping Shell State</a></h3>
|
||
<p><span id="index-reporter-utility"></span></p>
|
||
<p>Occasionally you may encounter what appears to be a bug in the shell,
|
||
particularly if you are using a beta version of zsh or a development
|
||
release. Usually it is sufficient to send a description of the problem
|
||
to one of the zsh mailing lists (see <a href="Introduction.html#Mailing-Lists">Mailing
|
||
Lists</a>), but sometimes one of the zsh
|
||
developers will need to recreate your environment in order to track the
|
||
problem down.</p>
|
||
<p>The script named <code>reporter</code>, found in the <code>Util</code> directory of the
|
||
distribution, is provided for this purpose. (It is also possible to
|
||
<code>autoload reporter</code>, but <code>reporter</code> is not installed in <code>fpath</code> by
|
||
default.) This script outputs a detailed dump of the shell state, in the
|
||
form of another script that can be read with ‘<code>zsh -f</code>’ to recreate that
|
||
state.</p>
|
||
<p>To use <code>reporter</code>, read the script into your shell with the ‘<code>.</code>’
|
||
command and redirect the output into a file:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">. ~/zsh-5.8/Util/reporter > zsh.report
|
||
</code></pre>
|
||
</div>
|
||
<p>You should check the <code>zsh.report</code> file for any sensitive information
|
||
such as passwords and delete them by hand before sending the script to
|
||
the developers. Also, as the output can be voluminous, it’s best to wait
|
||
for the developers to ask for this information before sending it.</p>
|
||
<p>You can also use <code>reporter</code> to dump only a subset of the shell state.
|
||
This is sometimes useful for creating startup files for the first time.
|
||
Most of the output from reporter is far more detailed than usually is
|
||
necessary for a startup file, but the <code>aliases</code>, <code>options</code>, and
|
||
<code>zstyles</code> states may be useful because they include only changes from
|
||
the defaults. The <code>bindings</code> state may be useful if you have created any
|
||
of your own keymaps, because <code>reporter</code> arranges to dump the keymap
|
||
creation commands as well as the bindings for every keymap.</p>
|
||
<p>As is usual with automated tools, if you create a startup file with
|
||
<code>reporter</code>, you should edit the results to remove unnecessary commands.
|
||
Note that if you’re using the new completion system, you should <em>not</em>
|
||
dump the <code>functions</code> state to your startup files with <code>reporter</code>; use
|
||
the <code>compdump</code> function instead (see <a href="Completion-System.html#Completion-System">Completion
|
||
System</a>).</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>reporter</code> [ <code>state</code> ... ]<br />
|
||
<span id="index-reporter"></span></p>
|
||
<p>Print to standard output the indicated subset of the current shell
|
||
state. The <code>state</code> arguments may be one or more of:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>all</code><br />
|
||
Output everything listed below.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>aliases</code><br />
|
||
Output alias definitions.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>bindings</code><br />
|
||
Output ZLE key maps and bindings.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>completion</code><br />
|
||
Output old-style <code>compctl</code> commands. New completion is covered
|
||
by <code>functions</code> and <code>zstyles</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>functions</code><br />
|
||
Output autoloads and function definitions.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>limits</code><br />
|
||
Output <code>limit</code> commands.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>options</code><br />
|
||
Output <code>setopt</code> commands.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>styles</code><br />
|
||
Same as <code>zstyles</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>variables</code><br />
|
||
Output shell parameter assignments, plus <code>export</code> commands for
|
||
any environment variables.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>zstyles</code><br />
|
||
Output <code>zstyle</code> commands.</p>
|
||
</li>
|
||
</ul>
|
||
<p>If the <code>state</code> is omitted, <code>all</code> is assumed.</p>
|
||
<p>With the exception of ‘<code>all</code>’, every <code>state</code> can be abbreviated by
|
||
any prefix, even a single letter; thus <code>a</code> is the same as <code>aliases</code>,
|
||
<code>z</code> is the same as <code>zstyles</code>, etc.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Manipulating-Hook-Functions"></span></p>
|
||
<h3 id="2625-manipulating-hook-functions"><a class="header" href="#2625-manipulating-hook-functions">26.2.5 Manipulating Hook Functions</a></h3>
|
||
<p><span id="index-hook-function-utility"></span></p>
|
||
<p><span id="index-add_002dzsh_002dhook"></span></p>
|
||
<p><code>add-zsh-hook</code> [ <code>-L</code> | <code>-dD</code> ] [ <code>-Uzk</code> ] <code>hook</code> <code>function</code></p>
|
||
<p>Several functions are special to the shell, as described in the section
|
||
Special Functions, <a href="Functions.html#Functions">Functions</a>, in that they
|
||
are automatically called at specific points during shell execution. Each
|
||
has an associated array consisting of names of functions to be called at
|
||
the same point; these are so-called ‘hook functions’. The shell function
|
||
<code>add-zsh-hook</code> provides a simple way of adding or removing functions
|
||
from the array.</p>
|
||
<p><code>hook</code> is one of <code>chpwd</code>, <code>periodic</code>, <code>precmd</code>, <code>preexec</code>,
|
||
<code>zshaddhistory</code>, <code>zshexit</code>, or <code>zsh_directory_name</code>, the special
|
||
functions in question. Note that <code>zsh_directory_name</code> is called in a
|
||
different way from the other functions, but may still be manipulated as
|
||
a hook.</p>
|
||
<p><code>function</code> is name of an ordinary shell function. If no options are
|
||
given this will be added to the array of functions to be executed in the
|
||
given context. Functions are invoked in the order they were added.</p>
|
||
<p>If the option <code>-L</code> is given, the current values for the hook arrays are
|
||
listed with <code>typeset</code>.</p>
|
||
<p>If the option <code>-d</code> is given, the <code>function</code> is removed from the array of
|
||
functions to be executed.</p>
|
||
<p>If the option <code>-D</code> is given, the <code>function</code> is treated as a pattern and
|
||
any matching names of functions are removed from the array of functions
|
||
to be executed.</p>
|
||
<p>The options <code>-U</code>, <code>-z</code> and <code>-k</code> are passed as arguments to <code>autoload</code>
|
||
for <code>function</code>. For functions contributed with zsh, the options <code>-Uz</code>
|
||
are appropriate.</p>
|
||
<p><span id="index-add_002dzle_002dhook_002dwidget"></span></p>
|
||
<p><code>add-zle-hook-widget</code> [ <code>-L</code> | <code>-dD</code> ] [ <code>-Uzk</code> ] <code>hook</code>
|
||
<code>widgetname</code></p>
|
||
<p>Several widget names are special to the line editor, as described in the
|
||
section Special Widgets, <a href="Zsh-Line-Editor.html#Zle-Widgets">Widgets</a>, in
|
||
that they are automatically called at specific points during editing.
|
||
Unlike function hooks, these do not use a predefined array of other
|
||
names to call at the same point; the shell function
|
||
<code>add-zle-hook-widget</code> maintains a similar array and arranges for the
|
||
special widget to invoke those additional widgets.</p>
|
||
<p><code>hook</code> is one of <code>isearch-exit</code>, <code>isearch-update</code>, <code>line-pre-redraw</code>,
|
||
<code>line-init</code>, <code>line-finish</code>, <code>history-line-set</code>, or <code>keymap-select</code>,
|
||
corresponding to each of the special widgets <code>zle-isearch-exit</code>, etc.
|
||
The special widget names are also accepted as the <code>hook</code> argument.</p>
|
||
<p><code>widgetname</code> is the name of a ZLE widget. If no options are given this
|
||
is added to the array of widgets to be invoked in the given hook
|
||
context. Widgets are invoked in the order they were added, with</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle widgetname -Nw -- "$@"
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-WIDGET_002c-in-hooks"></span></p>
|
||
<p>Note that this means that the ‘<code>WIDGET</code>’ special parameter tracks the
|
||
<code>widgetname</code> when the widget function is called, rather than tracking
|
||
the name of the corresponding special hook widget.</p>
|
||
<p>If the option <code>-d</code> is given, the <code>widgetname</code> is removed from the array
|
||
of widgets to be executed.</p>
|
||
<p>If the option <code>-D</code> is given, the <code>widgetname</code> is treated as a pattern
|
||
and any matching names of widgets are removed from the array.</p>
|
||
<p>If <code>widgetname</code> does not name an existing widget when added to the
|
||
array, it is assumed that a shell function also named <code>widgetname</code> is
|
||
meant to provide the implementation of the widget. This name is
|
||
therefore marked for autoloading, and the options <code>-U</code>, <code>-z</code> and <code>-k</code>
|
||
are passed as arguments to <code>autoload</code> as with <code>add-zsh-hook</code>. The widget
|
||
is also created with ‘<code> zle -N ``widgetname</code>’ to cause the
|
||
corresponding function to be loaded the first time the hook is called.</p>
|
||
<p>The arrays of <code>widgetname</code> are currently maintained in <code>zstyle</code>
|
||
contexts, one for each <code>hook</code> context, with a style of ‘<code>widgets</code>’. If
|
||
the <code>-L</code> option is given, this set of styles is listed with ‘<code>zstyle -L</code>’. This implementation may change, and the special widgets that
|
||
refer to the styles are created only if <code>add-zle-hook-widget</code> is called
|
||
to add at least one widget, so if this function is used for any hooks,
|
||
then all hooks should be managed only via this function.</p>
|
||
<hr />
|
||
<p><span id="Recent-Directories"></span>
|
||
<span id="index-recent-directories_002c-maintaining-list-of"></span>
|
||
<span id="index-directories_002c-maintaining-list-of-recent"></span>
|
||
<span id="index-cdr"></span> <span id="index-_005fcdr"></span>
|
||
<span id="index-chpwd_005frecent_005fadd"></span>
|
||
<span id="index-chpwd_005frecent_005fdirs"></span>
|
||
<span id="index-chpwd_005frecent_005ffilehandler"></span>
|
||
<span id="Remembering-Recent-Directories"></span></p>
|
||
<h2 id="263-remembering-recent-directories"><a class="header" href="#263-remembering-recent-directories">26.3 Remembering Recent Directories</a></h2>
|
||
<p>The function <code>cdr</code> allows you to change the working directory to a
|
||
previous working directory from a list maintained automatically. It is
|
||
similar in concept to the directory stack controlled by the <code>pushd</code>,
|
||
<code>popd</code> and <code>dirs</code> builtins, but is more configurable, and as it stores
|
||
all entries in files it is maintained across sessions and (by default)
|
||
between terminal emulators in the current session. Duplicates are
|
||
automatically removed, so that the list reflects the single most recent
|
||
use of each directory.</p>
|
||
<p>Note that the <code>pushd</code> directory stack is not actually modified or used
|
||
by <code>cdr</code> unless you configure it to do so as described in the
|
||
configuration section below.</p>
|
||
<hr />
|
||
<p><span id="Installation-3"></span></p>
|
||
<h3 id="2631-installation"><a class="header" href="#2631-installation">26.3.1 Installation</a></h3>
|
||
<p>The system works by means of a hook function that is called every time
|
||
the directory changes. To install the system, autoload the required
|
||
functions and use the <code>add-zsh-hook</code> function described above:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">autoload -Uz chpwd_recent_dirs cdr add-zsh-hook
|
||
add-zsh-hook chpwd chpwd_recent_dirs
|
||
</code></pre>
|
||
</div>
|
||
<p>Now every time you change directly interactively, no matter which
|
||
command you use, the directory to which you change will be remembered in
|
||
most-recent-first order.</p>
|
||
<hr />
|
||
<p><span id="Use"></span></p>
|
||
<h3 id="2632-use"><a class="header" href="#2632-use">26.3.2 Use</a></h3>
|
||
<p>All direct user interaction is via the <code>cdr</code> function.</p>
|
||
<p>The argument to cdr is a number <code>N</code> corresponding to the <code>N</code>th most
|
||
recently changed-to directory. 1 is the immediately preceding directory;
|
||
the current directory is remembered but is not offered as a destination.
|
||
Note that if you have multiple windows open 1 may refer to a directory
|
||
changed to in another window; you can avoid this by having per-terminal
|
||
files for storing directory as described for the <code>recent-dirs-file</code>
|
||
style below.</p>
|
||
<p>If you set the <code>recent-dirs-default</code> style described below <code>cdr</code> will
|
||
behave the same as <code>cd</code> if given a non-numeric argument, or more than
|
||
one argument. The recent directory list is updated just the same however
|
||
you change directory.</p>
|
||
<p>If the argument is omitted, 1 is assumed. This is similar to <code>pushd</code>’s
|
||
behaviour of swapping the two most recent directories on the stack.</p>
|
||
<p>Completion for the argument to <code>cdr</code> is available if compinit has been
|
||
run; menu selection is recommended, using:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*:*:cdr:*:*' menu selection
|
||
</code></pre>
|
||
</div>
|
||
<p>to allow you to cycle through recent directories; the order is
|
||
preserved, so the first choice is the most recent directory before the
|
||
current one. The verbose style is also recommended to ensure the
|
||
directory is shown; this style is on by default so no action is required
|
||
unless you have changed it.</p>
|
||
<hr />
|
||
<p><span id="Options-2"></span></p>
|
||
<h3 id="2633-options"><a class="header" href="#2633-options">26.3.3 Options</a></h3>
|
||
<p>The behaviour of <code>cdr</code> may be modified by the following options.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-l</code><br />
|
||
lists the numbers and the corresponding directories in abbreviated
|
||
form (i.e. with <code>~</code> substitution reapplied), one per line. The
|
||
directories here are not quoted (this would only be an issue if a
|
||
directory name contained a newline). This is used by the completion
|
||
system.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-r</code><br />
|
||
sets the variable <code>reply</code> to the current set of directories. Nothing
|
||
is printed and the directory is not changed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-e</code><br />
|
||
allows you to edit the list of directories, one per line. The list
|
||
can be edited to any extent you like; no sanity checking is
|
||
performed. Completion is available. No quoting is necessary (except
|
||
for newlines, where I have in any case no sympathy); directories are
|
||
in unabbreviated from and contain an absolute path, i.e. they start
|
||
with <code>/</code>. Usually the first entry should be left as the current
|
||
directory.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-p ’``pattern``’</code><br />
|
||
Prunes any items in the directory list that match the given extended
|
||
glob pattern; the pattern needs to be quoted from immediate
|
||
expansion on the command line. The pattern is matched against each
|
||
completely expanded file name in the list; the full string must
|
||
match, so wildcards at the end (e.g. <code>’*removeme*’</code>) are needed to
|
||
remove entries with a given substring.</p>
|
||
<p>If output is to a terminal, then the function will print the new
|
||
list after pruning and prompt for confirmation by the user. This
|
||
output and confirmation step can be skipped by using <code>-P</code> instead of
|
||
<code>-p</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Configuration-2"></span></p>
|
||
<h3 id="2634-configuration"><a class="header" href="#2634-configuration">26.3.4 Configuration</a></h3>
|
||
<p>Configuration is by means of the styles mechanism that should be
|
||
familiar from completion; if not, see the description of the <code>zstyle</code>
|
||
command in <a href="Zsh-Modules.html#The-zsh_002fzutil-Module">The zsh/zutil
|
||
Module</a>. The context for
|
||
setting styles should be <code>’:chpwd:*’</code> in case the meaning of the context
|
||
is extended in future, for example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':chpwd:*' recent-dirs-max 0
|
||
</code></pre>
|
||
</div>
|
||
<p>sets the value of the <code>recent-dirs-max</code> style to 0. In practice the
|
||
style name is specific enough that a context of ’*’ should be fine.</p>
|
||
<p>An exception is <code>recent-dirs-insert</code>, which is used exclusively by the
|
||
completion system and so has the usual completion system context
|
||
(<code>’:completion:*’</code> if nothing more specific is needed), though again
|
||
<code>’*’</code> should be fine in practice.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>recent-dirs-default</code><br />
|
||
If true, and the command is expecting a recent directory index, and
|
||
either there is more than one argument or the argument is not an
|
||
integer, then fall through to "cd". This allows the lazy to use only
|
||
one command for directory changing. Completion recognises this, too;
|
||
see recent-dirs-insert for how to control completion when this
|
||
option is in use.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>recent-dirs-file</code><br />
|
||
The file where the list of directories is saved. The default is
|
||
<code>${ZDOTDIR:-$HOME}/.chpwd-recent-dirs</code>, i.e. this is in your home
|
||
directory unless you have set the variable <code>ZDOTDIR</code> to point
|
||
somewhere else. Directory names are saved in <code>$’``...``’</code> quoted
|
||
form, so each line in the file can be supplied directly to the shell
|
||
as an argument.</p>
|
||
<p>The value of this style may be an array. In this case, the first
|
||
file in the list will always be used for saving directories while
|
||
any other files are left untouched. When reading the recent
|
||
directory list, if there are fewer than the maximum number of
|
||
entries in the first file, the contents of later files in the array
|
||
will be appended with duplicates removed from the list shown. The
|
||
contents of the two files are not sorted together, i.e. all the
|
||
entries in the first file are shown first. The special value <code>+</code> can
|
||
appear in the list to indicate the default file should be read at
|
||
that point. This allows effects like the following:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':chpwd:*' recent-dirs-file \
|
||
~/.chpwd-recent-dirs-${TTY##*/} +
|
||
</code></pre>
|
||
</div>
|
||
<p>Recent directories are read from a file numbered according to the
|
||
terminal. If there are insufficient entries the list is supplemented
|
||
from the default file.</p>
|
||
<p>It is possible to use <code>zstyle -e</code> to make the directory configurable
|
||
at run time:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle -e ':chpwd:*' recent-dirs-file pick-recent-dirs-file
|
||
pick-recent-dirs-file() {
|
||
if [[ $PWD = ~/text/writing(|/*) ]]; then
|
||
reply=(~/.chpwd-recent-dirs-writing)
|
||
else
|
||
reply=(+)
|
||
fi
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p>In this example, if the current directory is <code>~/text/writing</code> or a
|
||
directory under it, then use a special file for saving recent
|
||
directories, else use the default.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>recent-dirs-insert</code><br />
|
||
Used by completion. If <code>recent-dirs-default</code> is true, then setting
|
||
this to <code>true</code> causes the actual directory, rather than its index,
|
||
to be inserted on the command line; this has the same effect as
|
||
using the corresponding index, but makes the history clearer and the
|
||
line easier to edit. With this setting, if part of an argument was
|
||
already typed, normal directory completion rather than recent
|
||
directory completion is done; this is because recent directory
|
||
completion is expected to be done by cycling through entries menu
|
||
fashion.</p>
|
||
<p>If the value of the style is <code>always</code>, then only recent directories
|
||
will be completed; in that case, use the <code>cd</code> command when you want
|
||
to complete other directories.</p>
|
||
<p>If the value is <code>fallback</code>, recent directories will be tried first,
|
||
then normal directory completion is performed if recent directory
|
||
completion failed to find a match.</p>
|
||
<p>Finally, if the value is <code>both</code> then both sets of completions are
|
||
presented; the usual tag mechanism can be used to distinguish
|
||
results, with recent directories tagged as <code>recent-dirs</code>. Note that
|
||
the recent directories inserted are abbreviated with directory names
|
||
where appropriate.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>recent-dirs-max</code><br />
|
||
The maximum number of directories to save to the file. If this is
|
||
zero or negative there is no maximum. The default is 20. Note this
|
||
includes the current directory, which isn’t offered, so the highest
|
||
number of directories you will be offered is one less than the
|
||
maximum.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>recent-dirs-prune</code><br />
|
||
This style is an array determining what directories should (or
|
||
should not) be added to the recent list. Elements of the array can
|
||
include:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>parent</code><br />
|
||
Prune parents (more accurately, ancestors) from the recent list.
|
||
If present, changing directly down by any number of directories
|
||
causes the current directory to be overwritten. For example,
|
||
changing from ~pws to ~pws/some/other/dir causes ~pws not to
|
||
be left on the recent directory stack. This only applies to
|
||
direct changes to descendant directories; earlier directories on
|
||
the list are not pruned. For example, changing from
|
||
~pws/yet/another to ~pws/some/other/dir does not cause ~pws
|
||
to be pruned.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>pattern:pattern</code><br />
|
||
Gives a zsh pattern for directories that should not be added to
|
||
the recent list (if not already there). This element can be
|
||
repeated to add different patterns. For example,
|
||
<code>’pattern:/tmp(|/*)’</code> stops <code>/tmp</code> or its descendants from
|
||
being added. The <code>EXTENDED_GLOB</code> option is always turned on for
|
||
these patterns.</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p><code>recent-dirs-pushd</code><br />
|
||
If set to true, <code>cdr</code> will use <code>pushd</code> instead of <code>cd</code> to change the
|
||
directory, so the directory is saved on the directory stack. As the
|
||
directory stack is completely separate from the list of files saved
|
||
by the mechanism used in this file there is no obvious reason to do
|
||
this.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Use-with-dynamic-directory-naming"></span></p>
|
||
<h3 id="2635-use-with-dynamic-directory-naming"><a class="header" href="#2635-use-with-dynamic-directory-naming">26.3.5 Use with dynamic directory naming</a></h3>
|
||
<p>It is possible to refer to recent directories using the dynamic
|
||
directory name syntax by using the supplied function
|
||
<code>zsh_directory_name_cdr</code> a hook:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">autoload -Uz add-zsh-hook
|
||
add-zsh-hook -Uz zsh_directory_name zsh_directory_name_cdr
|
||
</code></pre>
|
||
</div>
|
||
<p>When this is done, <code>~[1]</code> will refer to the most recent directory other
|
||
than $PWD, and so on. Completion after <code>~[``...</code> also works.</p>
|
||
<hr />
|
||
<p><span id="Details-of-directory-handling"></span></p>
|
||
<h3 id="2636-details-of-directory-handling"><a class="header" href="#2636-details-of-directory-handling">26.3.6 Details of directory handling</a></h3>
|
||
<p>This section is for the curious or confused; most users will not need to
|
||
know this information.</p>
|
||
<p>Recent directories are saved to a file immediately and hence are
|
||
preserved across sessions. Note currently no file locking is applied:
|
||
the list is updated immediately on interactive commands and nowhere else
|
||
(unlike history), and it is assumed you are only going to change
|
||
directory in one window at once. This is not safe on shared accounts,
|
||
but in any case the system has limited utility when someone else is
|
||
changing to a different set of directories behind your back.</p>
|
||
<p>To make this a little safer, only directory changes instituted from the
|
||
command line, either directly or indirectly through shell function calls
|
||
(but not through subshells, evals, traps, completion functions and the
|
||
like) are saved. Shell functions should use <code>cd -q</code> or <code>pushd -q</code> to
|
||
avoid side effects if the change to the directory is to be invisible at
|
||
the command line. See the contents of the function <code>chpwd_recent_dirs</code>
|
||
for more details.</p>
|
||
<hr />
|
||
<p><span id="Other-Directory-Functions"></span>
|
||
<span id="index-directories_002c-named_002c-dynamic_002c-helper-function"></span>
|
||
<span id="index-dynamic-directory-naming_002c-helper-function"></span>
|
||
<span id="index-named-directories_002c-dynamic_002c-helper-function"></span>
|
||
<span id="index-zsh_005fdirectory_005fname_005fgeneric"></span>
|
||
<span id="Abbreviated-dynamic-references-to-directories"></span></p>
|
||
<h2 id="264-abbreviated-dynamic-references-to-directories"><a class="header" href="#264-abbreviated-dynamic-references-to-directories">26.4 Abbreviated dynamic references to directories</a></h2>
|
||
<p>The dynamic directory naming system is described in the subsection
|
||
<em>Dynamic named directories</em> of <a href="Expansion.html#Filename-Expansion">Filename
|
||
Expansion</a>. In this, a reference to
|
||
<code>~[``...``]</code> is expanded by a function found by the hooks mechanism.</p>
|
||
<p>The contributed function <code>zsh_directory_name_generic</code> provides a system
|
||
allowing the user to refer to directories with only a limited amount of
|
||
new code. It supports all three of the standard interfaces for directory
|
||
naming: converting from a name to a directory, converting in the reverse
|
||
direction to find a short name, and completion of names.</p>
|
||
<p>The main feature of this function is a path-like syntax, combining
|
||
abbreviations at multiple levels separated by ":". As an example,
|
||
~[g:p:s] might specify:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>g</code><br />
|
||
The top level directory for your git area. This first component has
|
||
to match, or the function will return indicating another directory
|
||
name hook function should be tried.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>p</code><br />
|
||
The name of a project within your git area.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>s</code><br />
|
||
The source area within that project.</p>
|
||
</li>
|
||
</ul>
|
||
<p>This allows you to collapse references to long hierarchies to a very
|
||
compact form, particularly if the hierarchies are similar across
|
||
different areas of the disk.</p>
|
||
<p>Name components may be completed: if a description is shown at the top
|
||
of the list of completions, it includes the path to which previous
|
||
components expand, while the description for an individual completion
|
||
shows the path segment it would add. No additional configuration is
|
||
needed for this as the completion system is aware of the dynamic
|
||
directory name mechanism.</p>
|
||
<hr />
|
||
<p><span id="Usage"></span></p>
|
||
<h3 id="2641-usage"><a class="header" href="#2641-usage">26.4.1 Usage</a></h3>
|
||
<p>To use the function, first define a wrapper function for your specific
|
||
case. We’ll assume it’s to be autoloaded. This can have any name but
|
||
we’ll refer to it as zdn_mywrapper. This wrapper function will define
|
||
various variables and then call this function with the same arguments
|
||
that the wrapper function gets. This configuration is described below.</p>
|
||
<p>Then arrange for the wrapper to be run as a zsh_directory_name hook:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">autoload -Uz add-zsh-hook zsh_diretory_name_generic zdn_mywrapper
|
||
add-zsh-hook -U zsh_directory_name zdn_mywrapper
|
||
</code></pre>
|
||
</div>
|
||
<hr />
|
||
<p><span id="Configuration"></span></p>
|
||
<h3 id="2642-configuration"><a class="header" href="#2642-configuration">26.4.2 Configuration</a></h3>
|
||
<p>The wrapper function should define a local associative array zdn_top.
|
||
Alternatively, this can be set with a style called <code>mapping</code>. The
|
||
context for the style is <code>:zdn:``wrapper-name</code> where <code>wrapper-name</code> is
|
||
the function calling zsh_directory_name_generic; for example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle :zdn:zdn_mywrapper: mapping zdn_mywrapper_top
|
||
</code></pre>
|
||
</div>
|
||
<p>The keys in this associative array correspond to the first component of
|
||
the name. The values are matching directories. They may have an optional
|
||
suffix with a slash followed by a colon and the name of a variable in
|
||
the same format to give the next component. (The slash before the colon
|
||
is to disambiguate the case where a colon is needed in the path for a
|
||
drive. There is otherwise no syntax for escaping this, so path
|
||
components whose names start with a colon are not supported.) A special
|
||
component <code>:default:</code> specifies a variable in the form <code>/:``var</code> (the
|
||
path section is ignored and so is usually empty) that will be used for
|
||
the next component if no variable is given for the path. Variables
|
||
referred to within <code>zdn_top</code> have the same format as <code>zdn_top</code> itself,
|
||
but contain relative paths.</p>
|
||
<p>For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">local -A zdn_top=(
|
||
g ~/git
|
||
ga ~/alternate/git
|
||
gs /scratch/$USER/git/:second2
|
||
:default: /:second1
|
||
)
|
||
</code></pre>
|
||
</div>
|
||
<p>This specifies the behaviour of a directory referred to as <code>~[g:...]</code> or
|
||
<code>~[ga:...]</code> or <code>~[gs:...]</code>. Later path components are optional; in that
|
||
case <code>~[g]</code> expands to <code>~/git</code>, and so on. <code>gs</code> expands to
|
||
<code>/scratch/$USER/git</code> and uses the associative array <code>second2</code> to match
|
||
the second component; <code>g</code> and <code>ga</code> use the associative array <code>second1</code>
|
||
to match the second component.</p>
|
||
<p>When expanding a name to a directory, if the first component is not <code>g</code>
|
||
or <code>ga</code> or <code>gs</code>, it is not an error; the function simply returns 1 so
|
||
that a later hook function can be tried. However, matching the first
|
||
component commits the function, so if a later component does not match,
|
||
an error is printed (though this still does not stop later hooks from
|
||
being executed).</p>
|
||
<p>For components after the first, a relative path is expected, but note
|
||
that multiple levels may still appear. Here is an example of <code>second1</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">local -A second1=(
|
||
p myproject
|
||
s somproject
|
||
os otherproject/subproject/:third
|
||
)
|
||
</code></pre>
|
||
</div>
|
||
<p>The path as found from <code>zdn_top</code> is extended with the matching
|
||
directory, so <code>~[g:p]</code> becomes <code>~/git/myproject</code>. The slash between is
|
||
added automatically (it’s not possible to have a later component modify
|
||
the name of a directory already matched). Only <code>os</code> specifies a variable
|
||
for a third component, and there’s no <code>:default:</code>, so it’s an error to
|
||
use a name like <code>~[g:p:x]</code> or <code>~[ga:s:y]</code> because there’s nowhere to
|
||
look up the <code>x</code> or <code>y</code>.</p>
|
||
<p>The associative arrays need to be visible within this function; the
|
||
generic function therefore uses internal variable names beginning
|
||
<code>_zdn_</code> in order to avoid clashes. Note that the variable <code>reply</code> needs
|
||
to be passed back to the shell, so should not be local in the calling
|
||
function.</p>
|
||
<p>The function does not test whether directories assembled by component
|
||
actually exist; this allows the system to work across automounted file
|
||
systems. The error from the command trying to use a non-existent
|
||
directory should be sufficient to indicate the problem.</p>
|
||
<hr />
|
||
<p><span id="Complete-example"></span></p>
|
||
<h3 id="2643-complete-example"><a class="header" href="#2643-complete-example">26.4.3 Complete example</a></h3>
|
||
<p>Here is a full fictitious but usable autoloadable definition of the
|
||
example function defined by the code above. So <code>~[gs:p:s]</code> expands to
|
||
<code>/scratch/$USER/git/myscratchproject/top/srcdir</code> (with <code>$USER</code> also
|
||
expanded).</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">local -A zdn_top=(
|
||
g ~/git
|
||
ga ~/alternate/git
|
||
gs /scratch/$USER/git/:second2
|
||
:default: /:second1
|
||
)
|
||
|
||
local -A second1=(
|
||
p myproject
|
||
s somproject
|
||
os otherproject/subproject/:third
|
||
)
|
||
|
||
local -A second2=(
|
||
p myscratchproject
|
||
s somescratchproject
|
||
)
|
||
|
||
local -A third=(
|
||
s top/srcdir
|
||
d top/documentation
|
||
)
|
||
|
||
# autoload not needed if you did this at initialisation...
|
||
autoload -Uz zsh_directory_name_generic
|
||
zsh_directory_name_generic "$@
|
||
</code></pre>
|
||
</div>
|
||
<p>It is also possible to use global associative arrays, suitably named,
|
||
and set the style for the context of your wrapper function to refer to
|
||
this. Then your set up code would contain the following:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">typeset -A zdn_mywrapper_top=(...)
|
||
# ... and so on for other associative arrays ...
|
||
zstyle ':zdn:zdn_mywrapper:' mapping zdn_mywrapper_top
|
||
autoload -Uz add-zsh-hook zsh_directory_name_generic zdn_mywrapper
|
||
add-zsh-hook -U zsh_directory_name zdn_mywrapper
|
||
</code></pre>
|
||
</div>
|
||
<p>and the function <code>zdn_mywrapper</code> would contain only the following:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zsh_directory_name_generic "$@"
|
||
</code></pre>
|
||
</div>
|
||
<hr />
|
||
<p><span id="Version-Control-Information"></span>
|
||
<span id="Gathering-information-from-version-control-systems"></span></p>
|
||
<h2 id="265-gathering-information-from-version-control-systems"><a class="header" href="#265-gathering-information-from-version-control-systems">26.5 Gathering information from version control systems</a></h2>
|
||
<p><span id="index-version-control-utility"></span></p>
|
||
<p>In a lot of cases, it is nice to automatically retrieve information from
|
||
version control systems (VCSs), such as subversion, CVS or git, to be
|
||
able to provide it to the user; possibly in the user’s prompt. So that
|
||
you can instantly tell which branch you are currently on, for example.</p>
|
||
<p>In order to do that, you may use the <code>vcs_info</code> function.</p>
|
||
<p>The following VCSs are supported, showing the abbreviated name by which
|
||
they are referred to within the system:</p>
|
||
<ul>
|
||
<li>
|
||
<p>Bazaar (<code>bzr</code>)<br />
|
||
<code>https://bazaar.canonical.com/</code></p>
|
||
</li>
|
||
<li>
|
||
<p>Codeville (<code>cdv</code>)<br />
|
||
<code>http://freecode.com/projects/codeville/</code></p>
|
||
</li>
|
||
<li>
|
||
<p>Concurrent Versioning System (<code>cvs</code>)<br />
|
||
<code>https://www.nongnu.org/cvs/</code></p>
|
||
</li>
|
||
<li>
|
||
<p>Darcs (<code>darcs</code>)<br />
|
||
<code>http://darcs.net/</code></p>
|
||
</li>
|
||
<li>
|
||
<p>Fossil (<code>fossil</code>)<br />
|
||
<code>https://fossil-scm.org/</code></p>
|
||
</li>
|
||
<li>
|
||
<p>Git (<code>git</code>)<br />
|
||
<code>https://git-scm.com/</code></p>
|
||
</li>
|
||
<li>
|
||
<p>GNU arch (<code>tla</code>)<br />
|
||
<code>https://www.gnu.org/software/gnu-arch/</code></p>
|
||
</li>
|
||
<li>
|
||
<p>Mercurial (<code>hg</code>)<br />
|
||
<code>https://www.mercurial-scm.org/</code></p>
|
||
</li>
|
||
<li>
|
||
<p>Monotone (<code>mtn</code>)<br />
|
||
<code>https://monotone.ca/</code></p>
|
||
</li>
|
||
<li>
|
||
<p>Perforce (<code>p4</code>)<br />
|
||
<code>https://www.perforce.com/</code></p>
|
||
</li>
|
||
<li>
|
||
<p>Subversion (<code>svn</code>)<br />
|
||
<code>https://subversion.apache.org/</code></p>
|
||
</li>
|
||
<li>
|
||
<p>SVK (<code>svk</code>)<br />
|
||
<code>https://svk.bestpractical.com/</code></p>
|
||
</li>
|
||
</ul>
|
||
<p>There is also support for the patch management system <code>quilt</code>
|
||
(<code>https://savannah.nongnu.org/projects/quilt</code>). See <a href="User-Contributions.html#vcs_005finfo-Quilt-Support">Quilt
|
||
Support</a> below for details.</p>
|
||
<p>To load <code>vcs_info</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">autoload -Uz vcs_info
|
||
</code></pre>
|
||
</div>
|
||
<p>It can be used in any existing prompt, because it does not require any
|
||
specific <code>$psvar</code> entries to be available.</p>
|
||
<hr />
|
||
<p><span id="vcs_005finfo-Quickstart"></span> <span id="Quickstart"></span></p>
|
||
<h3 id="2651-quickstart"><a class="header" href="#2651-quickstart">26.5.1 Quickstart</a></h3>
|
||
<p>To get this feature working quickly (including colors), you can do the
|
||
following (assuming, you loaded <code>vcs_info</code> properly - see above):</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':vcs_info:*' actionformats \
|
||
'%F{5}(%f%s%F{5})%F{3}-%F{5}[%F{2}%b%F{3}|%F{1}%a%F{5}]%f '
|
||
zstyle ':vcs_info:*' formats \
|
||
'%F{5}(%f%s%F{5})%F{3}-%F{5}[%F{2}%b%F{5}]%f '
|
||
zstyle ':vcs_info:(sv[nk]|bzr):*' branchformat '%b%F{1}:%F{3}%r'
|
||
precmd () { vcs_info }
|
||
PS1='%F{5}[%F{2}%n%F{5}] %F{3}%3~ ${vcs_info_msg_0_}%f%# '
|
||
</code></pre>
|
||
</div>
|
||
<p>Obviously, the last two lines are there for demonstration. You need to
|
||
call <code>vcs_info</code> from your <code>precmd</code> function. Once that is done you need
|
||
a <em>single quoted</em> <code>’${vcs_info_msg_0_}’</code> in your prompt.</p>
|
||
<p>To be able to use <code>’${vcs_info_msg_0_}’</code> directly in your prompt like
|
||
this, you will need to have the <code>PROMPT_SUBST</code> option enabled.</p>
|
||
<p>Now call the <code>vcs_info_printsys</code> utility from the command line:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">% vcs_info_printsys
|
||
## list of supported version control backends:
|
||
## disabled systems are prefixed by a hash sign (#)
|
||
bzr
|
||
cdv
|
||
cvs
|
||
darcs
|
||
fossil
|
||
git
|
||
hg
|
||
mtn
|
||
p4
|
||
svk
|
||
svn
|
||
tla
|
||
## flavours (cannot be used in the enable or disable styles; they
|
||
## are enabled and disabled with their master [git-svn -> git])
|
||
## they *can* be used in contexts: ':vcs_info:git-svn:*'.
|
||
git-p4
|
||
git-svn
|
||
hg-git
|
||
hg-hgsubversion
|
||
hg-hgsvn
|
||
</code></pre>
|
||
</div>
|
||
<p>You may not want all of these because there is no point in running the
|
||
code to detect systems you do not use. So there is a way to disable some
|
||
backends altogether:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':vcs_info:*' disable bzr cdv darcs mtn svk tla
|
||
</code></pre>
|
||
</div>
|
||
<p>You may also pick a few from that list and enable only those:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':vcs_info:*' enable git cvs svn
|
||
</code></pre>
|
||
</div>
|
||
<p>If you rerun <code>vcs_info_printsys</code> after one of these commands, you will
|
||
see the backends listed in the <code>disable</code> style (or backends not in the
|
||
<code>enable</code> style - if you used that) marked as disabled by a hash sign.
|
||
That means the detection of these systems is skipped <em>completely</em>. No
|
||
wasted time there.</p>
|
||
<hr />
|
||
<p><span id="vcs_005finfo-Configuration"></span>
|
||
<span id="Configuration-1"></span></p>
|
||
<h3 id="2652-configuration"><a class="header" href="#2652-configuration">26.5.2 Configuration</a></h3>
|
||
<p>The <code>vcs_info</code> feature can be configured via <code>zstyle</code>.</p>
|
||
<p>First, the context in which we are working:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">:vcs_info:vcs-string:user-context:repo-root-name
|
||
</code></pre>
|
||
</div>
|
||
<ul>
|
||
<li>
|
||
<p><code>vcs-string</code><br />
|
||
is one of: <code>git</code>, <code>git-svn</code>, <code>git-p4</code>, <code>hg</code>, <code>hg-git</code>,
|
||
<code>hg-hgsubversion</code>, <code>hg-hgsvn</code>, <code>darcs</code>, <code>bzr</code>, <code>cdv</code>, <code>mtn</code>, <code>svn</code>,
|
||
<code>cvs</code>, <code>svk</code>, <code>tla</code>, <code>p4</code> or <code>fossil</code>. This is followed by
|
||
‘<code>.quilt-``quilt-mode</code>’ in Quilt mode (see <a href="User-Contributions.html#vcs_005finfo-Quilt-Support">Quilt
|
||
Support</a> for details) and by
|
||
‘<code>+``hook-name</code>’ while hooks are active (see <a href="User-Contributions.html#vcs_005finfo-Hooks">Hooks in
|
||
vcs_info</a> for details).</p>
|
||
<p>Currently, hooks in quilt mode don’t add the ‘<code>.quilt-``quilt-mode</code>’
|
||
information. This may change in the future.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>user-context</code><br />
|
||
is a freely configurable string, assignable by the user as the first
|
||
argument to <code>vcs_info</code> (see its description below).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>repo-root-name</code><br />
|
||
is the name of a repository in which you want a style to match. So,
|
||
if you want a setting specific to <code>/usr/src/zsh</code>, with that being a
|
||
CVS checkout, you can set <code>repo-root-name</code> to <code>zsh</code> to make it so.</p>
|
||
</li>
|
||
</ul>
|
||
<p>There are three special values for <code>vcs-string</code>: The first is named
|
||
<code>-init-</code>, that is in effect as long as there was no decision what VCS
|
||
backend to use. The second is <code>-preinit-</code>; it is used <em>before</em>
|
||
<code>vcs_info</code> is run, when initializing the data exporting variables. The
|
||
third special value is <code>formats</code> and is used by the <code>vcs_info_lastmsg</code>
|
||
for looking up its styles.</p>
|
||
<p>The initial value of <code>repo-root-name</code> is <code>-all-</code> and it is replaced with
|
||
the actual name, as soon as it is known. Only use this part of the
|
||
context for defining the <code>formats</code>, <code>actionformats</code> or <code>branchformat</code>
|
||
styles, as it is guaranteed that <code>repo-root-name</code> is set up correctly
|
||
for these only. For all other styles, just use <code>’*’</code> instead.</p>
|
||
<p>There are two pre-defined values for <code>user-context</code>:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>default</code><br />
|
||
the one used if none is specified</p>
|
||
</li>
|
||
<li>
|
||
<p><code>command</code><br />
|
||
used by vcs_info_lastmsg to lookup its styles</p>
|
||
</li>
|
||
</ul>
|
||
<p>You can of course use <code>’:vcs_info:*’</code> to match all VCSs in all
|
||
user-contexts at once.</p>
|
||
<p>This is a description of all styles that are looked up.</p>
|
||
<p><span id="index-formats"></span></p>
|
||
<p><code>formats</code></p>
|
||
<p>A list of formats, used when actionformats is not used (which is most of
|
||
the time).</p>
|
||
<p><span id="index-actionformats"></span></p>
|
||
<p><code>actionformats</code></p>
|
||
<p>A list of formats, used if there is a special action going on in your
|
||
current repository; like an interactive rebase or a merge conflict.</p>
|
||
<p><span id="index-branchformat"></span></p>
|
||
<p><code>branchformat</code></p>
|
||
<p>Some backends replace <code>%b</code> in the formats and actionformats styles
|
||
above, not only by a branch name but also by a revision number. This
|
||
style lets you modify how that string should look.</p>
|
||
<p><span id="index-nvcsformats"></span></p>
|
||
<p><code>nvcsformats</code></p>
|
||
<p>These "formats" are set when we didn’t detect a version control system
|
||
for the current directory or <code>vcs_info</code> was disabled. This is useful if
|
||
you want <code>vcs_info</code> to completely take over the generation of your
|
||
prompt. You would do something like <code>PS1=’${vcs_info_msg_0_}’</code> to
|
||
accomplish that.</p>
|
||
<p><span id="index-hgrevformat"></span></p>
|
||
<p><code>hgrevformat</code></p>
|
||
<p><code>hg</code> uses both a hash and a revision number to reference a specific
|
||
changeset in a repository. With this style you can format the revision
|
||
string (see <code>branchformat</code>) to include either or both. It’s only useful
|
||
when <code>get-revision</code> is true. Note, the full 40-character revision id is
|
||
not available (except when using the <code>use-simple</code> option) because
|
||
executing hg more than once per prompt is too slow; you may customize
|
||
this behavior using hooks.</p>
|
||
<p><span id="index-max_002dexports"></span></p>
|
||
<p><code>max-exports</code></p>
|
||
<p>Defines the maximum number of <code>vcs_info_msg_*_</code> variables <code>vcs_info</code>
|
||
will set.</p>
|
||
<p><span id="index-enable-1"></span></p>
|
||
<p><code>enable</code></p>
|
||
<p>A list of backends you want to use. Checked in the <code>-init-</code> context. If
|
||
this list contains an item called <code>NONE</code> no backend is used at all and
|
||
<code>vcs_info</code> will do nothing. If this list contains <code>ALL</code>, <code>vcs_info</code> will
|
||
use all known backends. Only with <code>ALL</code> in <code>enable</code> will the <code>disable</code>
|
||
style have any effect. <code>ALL</code> and <code>NONE</code> are case insensitive.</p>
|
||
<p><span id="index-disable-1"></span></p>
|
||
<p><code>disable</code></p>
|
||
<p>A list of VCSs you don’t want <code>vcs_info</code> to test for repositories
|
||
(checked in the <code>-init-</code> context, too). Only used if <code>enable</code> contains
|
||
<code>ALL</code>.</p>
|
||
<p><span id="index-disable_002dpatterns"></span></p>
|
||
<p><code>disable-patterns</code></p>
|
||
<p>A list of patterns that are checked against <code>$PWD</code>. If a pattern
|
||
matches, <code>vcs_info</code> will be disabled. This style is checked in the
|
||
<code>:vcs_info:-init-:*:-all-</code> context.</p>
|
||
<p>Say, <code>~/.zsh</code> is a directory under version control, in which you do not
|
||
want <code>vcs_info</code> to be active, do:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':vcs_info:*' disable-patterns "${(b)HOME}/.zsh(|/*)"
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-use_002dquilt"></span></p>
|
||
<p><code>use-quilt</code></p>
|
||
<p>If enabled, the <code>quilt</code> support code is active in ‘addon’ mode. See
|
||
<a href="User-Contributions.html#vcs_005finfo-Quilt-Support">Quilt Support</a> for details.</p>
|
||
<p><span id="index-quilt_002dstandalone"></span></p>
|
||
<p><code>quilt-standalone</code></p>
|
||
<p>If enabled, ‘standalone’ mode detection is attempted if no VCS is active
|
||
in a given directory. See <a href="User-Contributions.html#vcs_005finfo-Quilt-Support">Quilt Support</a>
|
||
for details.</p>
|
||
<p><span id="index-quilt_002dpatch_002ddir"></span></p>
|
||
<p><code>quilt-patch-dir</code></p>
|
||
<p>Overwrite the value of the <code>$QUILT_PATCHES</code> environment variable. See
|
||
<a href="User-Contributions.html#vcs_005finfo-Quilt-Support">Quilt Support</a> for details.</p>
|
||
<p><span id="index-quiltcommand"></span></p>
|
||
<p><code>quiltcommand</code></p>
|
||
<p>When <code>quilt</code> itself is called in quilt support, the value of this style
|
||
is used as the command name.</p>
|
||
<p><span id="index-check_002dfor_002dchanges"></span></p>
|
||
<p><code>check-for-changes</code></p>
|
||
<p>If enabled, this style causes the <code>%c</code> and <code>%u</code> format escapes to show
|
||
when the working directory has uncommitted changes. The strings
|
||
displayed by these escapes can be controlled via the <code>stagedstr</code> and
|
||
<code>unstagedstr</code> styles. The only backends that currently support this
|
||
option are <code>git</code>, <code>hg</code>, and <code>bzr</code> (the latter two only support
|
||
unstaged).</p>
|
||
<p>For this style to be evaluated with the <code>hg</code> backend, the <code>get-revision</code>
|
||
style needs to be set and the <code>use-simple</code> style needs to be unset. The
|
||
latter is the default; the former is not.</p>
|
||
<p>With the <code>bzr</code> backend, <em>lightweight checkouts</em> only honor this style if
|
||
the <code>use-server</code> style is set.</p>
|
||
<p>Note, the actions taken if this style is enabled are potentially
|
||
expensive (read: they may be slow, depending on how big the current
|
||
repository is). Therefore, it is disabled by default.</p>
|
||
<p><span id="index-check_002dfor_002dstaged_002dchanges"></span></p>
|
||
<p><code>check-for-staged-changes</code></p>
|
||
<p>This style is like <code>check-for-changes</code>, but it never checks the worktree
|
||
files, only the metadata in the <code>.${vcs}</code> dir. Therefore, this style
|
||
initializes only the <code>%c</code> escape (with <code>stagedstr</code>) but not the <code>%u</code>
|
||
escape. This style is faster than <code>check-for-changes</code>.</p>
|
||
<p>In the <code>git</code> backend, this style checks for changes in the index. Other
|
||
backends do not currently implement this style.</p>
|
||
<p>This style is disabled by default.</p>
|
||
<p><span id="index-stagedstr"></span></p>
|
||
<p><code>stagedstr</code></p>
|
||
<p>This string will be used in the <code>%c</code> escape if there are staged changes
|
||
in the repository.</p>
|
||
<p><span id="index-unstagedstr"></span></p>
|
||
<p><code>unstagedstr</code></p>
|
||
<p>This string will be used in the <code>%u</code> escape if there are unstaged
|
||
changes in the repository.</p>
|
||
<p><span id="index-command-2"></span></p>
|
||
<p><code>command</code></p>
|
||
<p>This style causes <code>vcs_info</code> to use the supplied string as the command
|
||
to use as the VCS’s binary. Note, that setting this in ’<code>:vcs_info:*</code>’
|
||
is not a good idea.</p>
|
||
<p>If the value of this style is empty (which is the default), the used
|
||
binary name is the name of the backend in use (e.g. <code>svn</code> is used in an
|
||
<code>svn</code> repository).</p>
|
||
<p>The <code>repo-root-name</code> part in the context is always the default <code>-all-</code>
|
||
when this style is looked up.</p>
|
||
<p>For example, this style can be used to use binaries from non-default
|
||
installation directories. Assume, <code>git</code> is installed in /usr/bin but
|
||
your sysadmin installed a newer version in /usr/local/bin. Instead of
|
||
changing the order of your <code>$PATH</code> parameter, you can do this:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':vcs_info:git:*:-all-' command /usr/local/bin/git
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-use_002dserver"></span></p>
|
||
<p><code>use-server</code></p>
|
||
<p>This is used by the Perforce backend (<code>p4</code>) to decide if it should
|
||
contact the Perforce server to find out if a directory is managed by
|
||
Perforce. This is the only reliable way of doing this, but runs the risk
|
||
of a delay if the server name cannot be found. If the server (more
|
||
specifically, the <code>host``:``port</code> pair describing the server) cannot be
|
||
contacted, its name is put into the associative array
|
||
<code>vcs_info_p4_dead_servers</code> and is not contacted again during the session
|
||
until it is removed by hand. If you do not set this style, the <code>p4</code>
|
||
backend is only usable if you have set the environment variable
|
||
<code>P4CONFIG</code> to a file name and have corresponding files in the root
|
||
directories of each Perforce client. See comments in the function
|
||
<code>VCS_INFO_detect_p4</code> for more detail.</p>
|
||
<p>The Bazaar backend (<code>bzr</code>) uses this to permit contacting the server
|
||
about lightweight checkouts, see the <code>check-for-changes</code> style.</p>
|
||
<p><span id="index-use_002dsimple"></span></p>
|
||
<p><code>use-simple</code></p>
|
||
<p>If there are two different ways of gathering information, you can select
|
||
the simpler one by setting this style to true; the default is to use the
|
||
not-that-simple code, which is potentially a lot slower but might be
|
||
more accurate in all possible cases. This style is used by the <code>bzr</code> and
|
||
<code>hg</code> backends. In the case of <code>hg</code> it will invoke the external hexdump
|
||
program to parse the binary dirstate cache file; this method will not
|
||
return the local revision number.</p>
|
||
<p><span id="index-get_002drevision"></span></p>
|
||
<p><code>get-revision</code></p>
|
||
<p>If set to true, vcs_info goes the extra mile to figure out the revision
|
||
of a repository’s work tree (currently for the <code>git</code> and <code>hg</code> backends,
|
||
where this kind of information is not always vital). For <code>git</code>, the hash
|
||
value of the currently checked out commit is available via the <code>%i</code>
|
||
expansion. With <code>hg</code>, the local revision number and the corresponding
|
||
global hash are available via <code>%i</code>.</p>
|
||
<p><span id="index-get_002dmq"></span></p>
|
||
<p><code>get-mq</code></p>
|
||
<p>If set to true, the <code>hg</code> backend will look for a Mercurial Queue (<code>mq</code>)
|
||
patch directory. Information will be available via the ‘<code>%m</code>’
|
||
replacement.</p>
|
||
<p><span id="index-get_002dbookmarks"></span></p>
|
||
<p><code>get-bookmarks</code></p>
|
||
<p>If set to true, the <code>hg</code> backend will try to get a list of current
|
||
bookmarks. They will be available via the ‘<code>%m</code>’ replacement.</p>
|
||
<p>The default is to generate a comma-separated list of all bookmark names
|
||
that refer to the currently checked out revision. If a bookmark is
|
||
active, its name is suffixed an asterisk and placed first in the list.</p>
|
||
<p><span id="index-use_002dprompt_002descapes"></span></p>
|
||
<p><code>use-prompt-escapes</code></p>
|
||
<p>Determines if we assume that the assembled string from <code>vcs_info</code>
|
||
includes prompt escapes. (Used by <code>vcs_info_lastmsg</code>.)</p>
|
||
<p><span id="index-debug"></span></p>
|
||
<p><code>debug</code></p>
|
||
<p>Enable debugging output to track possible problems. Currently this style
|
||
is only used by <code>vcs_info</code>’s hooks system.</p>
|
||
<p><span id="index-hooks"></span></p>
|
||
<p><code>hooks</code></p>
|
||
<p>A list style that defines hook-function names. See <a href="User-Contributions.html#vcs_005finfo-Hooks">Hooks in
|
||
vcs_info</a> below for details.</p>
|
||
<p><span id="index-patch_002dformat"></span>
|
||
<span id="index-nopatch_002dformat"></span></p>
|
||
<p><code>patch-format</code></p>
|
||
<p><code>nopatch-format</code></p>
|
||
<p>This pair of styles format the patch information used by the <code>%m</code>
|
||
expando in formats and actionformats for the <code>git</code> and <code>hg</code> backends.
|
||
The value is subject to certain <code>%</code>-expansions described below. The
|
||
expanded value is made available in the global <code>backend_misc</code> array as
|
||
<code>${backend_misc[patches]}</code> (also if a <code>set-patch-format</code> hook is used).</p>
|
||
<p><span id="index-get_002dunapplied"></span></p>
|
||
<p><code>get-unapplied</code></p>
|
||
<p>This boolean style controls whether a backend should attempt to gather a
|
||
list of unapplied patches (for example with Mercurial Queue patches).</p>
|
||
<p>Used by the <code>quilt</code> and <code>hg</code> backends.</p>
|
||
<p>The default values for these styles in all contexts are:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>formats</code><br />
|
||
" (%s)-[%b]%u%c-"</p>
|
||
</li>
|
||
<li>
|
||
<p><code>actionformats</code><br />
|
||
" (%s)-[%b|%a]%u%c-"</p>
|
||
</li>
|
||
<li>
|
||
<p><code>branchformat</code><br />
|
||
"%b:%r" (for bzr, svn, svk and hg)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>nvcsformats</code><br />
|
||
""</p>
|
||
</li>
|
||
<li>
|
||
<p><code>hgrevformat</code><br />
|
||
"%r:%h"</p>
|
||
</li>
|
||
<li>
|
||
<p><code>max-exports</code><br />
|
||
2</p>
|
||
</li>
|
||
<li>
|
||
<p><code>enable</code><br />
|
||
ALL</p>
|
||
</li>
|
||
<li>
|
||
<p><code>disable</code><br />
|
||
(empty list)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>disable-patterns</code><br />
|
||
(empty list)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>check-for-changes</code><br />
|
||
false</p>
|
||
</li>
|
||
<li>
|
||
<p><code>check-for-staged-changes</code><br />
|
||
false</p>
|
||
</li>
|
||
<li>
|
||
<p><code>stagedstr</code><br />
|
||
(string: "S")</p>
|
||
</li>
|
||
<li>
|
||
<p><code>unstagedstr</code><br />
|
||
(string: "U")</p>
|
||
</li>
|
||
<li>
|
||
<p><code>command</code><br />
|
||
(empty string)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>use-server</code><br />
|
||
false</p>
|
||
</li>
|
||
<li>
|
||
<p><code>use-simple</code><br />
|
||
false</p>
|
||
</li>
|
||
<li>
|
||
<p><code>get-revision</code><br />
|
||
false</p>
|
||
</li>
|
||
<li>
|
||
<p><code>get-mq</code><br />
|
||
true</p>
|
||
</li>
|
||
<li>
|
||
<p><code>get-bookmarks</code><br />
|
||
false</p>
|
||
</li>
|
||
<li>
|
||
<p><code>use-prompt-escapes</code><br />
|
||
true</p>
|
||
</li>
|
||
<li>
|
||
<p><code>debug</code><br />
|
||
false</p>
|
||
</li>
|
||
<li>
|
||
<p><code>hooks</code><br />
|
||
(empty list)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>use-quilt</code><br />
|
||
false</p>
|
||
</li>
|
||
<li>
|
||
<p><code>quilt-standalone</code><br />
|
||
false</p>
|
||
</li>
|
||
<li>
|
||
<p><code>quilt-patch-dir</code><br />
|
||
empty - use <code>$QUILT_PATCHES</code></p>
|
||
</li>
|
||
<li>
|
||
<p><code>quiltcommand</code><br />
|
||
quilt</p>
|
||
</li>
|
||
<li>
|
||
<p><code>patch-format</code><br />
|
||
<code>backend dependent</code></p>
|
||
</li>
|
||
<li>
|
||
<p><code>nopatch-format</code><br />
|
||
<code>backend dependent</code></p>
|
||
</li>
|
||
<li>
|
||
<p><code>get-unapplied</code><br />
|
||
false</p>
|
||
</li>
|
||
</ul>
|
||
<p>In normal <code>formats</code> and <code>actionformats</code> the following replacements are
|
||
done:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>%s</code><br />
|
||
The VCS in use (git, hg, svn, etc.).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%b</code><br />
|
||
Information about the current branch.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%a</code><br />
|
||
An identifier that describes the action. Only makes sense in
|
||
<code>actionformats</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%i</code><br />
|
||
The current revision number or identifier. For <code>hg</code> the
|
||
<code>hgrevformat</code> style may be used to customize the output.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%c</code><br />
|
||
The string from the <code>stagedstr</code> style if there are staged changes in
|
||
the repository.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%u</code><br />
|
||
The string from the <code>unstagedstr</code> style if there are unstaged
|
||
changes in the repository.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%R</code><br />
|
||
The base directory of the repository.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%r</code><br />
|
||
The repository name. If <code>%R</code> is <code>/foo/bar/repoXY</code>, <code>%r</code> is <code>repoXY</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%S</code><br />
|
||
A subdirectory within a repository. If <code>$PWD</code> is
|
||
<code>/foo/bar/repoXY/beer/tasty</code>, <code>%S</code> is <code>beer/tasty</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<!-- end list -->
|
||
<ul>
|
||
<li>
|
||
<p><code>%m</code><br />
|
||
A "misc" replacement. It is at the discretion of the backend to
|
||
decide what this replacement expands to.</p>
|
||
<p>The <code>hg</code> and <code>git</code> backends use this expando to display patch
|
||
information. <code>hg</code> sources patch information from the <code>mq</code>
|
||
extensions; <code>git</code> from in-progress <code>rebase</code> and <code>cherry-pick</code>
|
||
operations and from the <code>stgit</code> extension. The <code>patch-format</code> and
|
||
<code>nopatch-format</code> styles control the generated string. The former is
|
||
used when at least one patch from the patch queue has been applied,
|
||
and the latter otherwise.</p>
|
||
<p>The <code>hg</code> backend displays bookmark information in this expando (in
|
||
addition to <code>mq</code> information). See the <code>get-mq</code> and <code>get-bookmarks</code>
|
||
styles. Both of these styles may be enabled at the same time. If
|
||
both are enabled, both resulting strings will be shown separated by
|
||
a semicolon (that cannot currently be customized).</p>
|
||
<p>The <code>quilt</code> ‘standalone’ backend sets this expando to the same value
|
||
as the <code>%Q</code> expando.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%Q</code><br />
|
||
Quilt series information. When quilt is used (either in ‘addon’ mode
|
||
or as a ‘standalone’ backend), this expando is set to quilt series’
|
||
<code>patch-format</code> string. The <code>set-patch-format</code> hook and
|
||
<code>nopatch-format</code> style are honoured.</p>
|
||
<p>See <a href="User-Contributions.html#vcs_005finfo-Quilt-Support">Quilt Support</a> below for details.</p>
|
||
</li>
|
||
</ul>
|
||
<p>In <code>branchformat</code> these replacements are done:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>%b</code><br />
|
||
The branch name.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%r</code><br />
|
||
The current revision number or the <code>hgrevformat</code> style for <code>hg</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<p>In <code>hgrevformat</code> these replacements are done:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>%r</code><br />
|
||
The current local revision number.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%h</code><br />
|
||
The current global revision identifier.</p>
|
||
</li>
|
||
</ul>
|
||
<p>In <code>patch-format</code> and <code>nopatch-format</code> these replacements are done:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>%p</code><br />
|
||
The name of the top-most applied patch; may be overridden by the
|
||
<code>applied-string</code> hook.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%u</code><br />
|
||
The number of unapplied patches; may be overridden by the
|
||
<code>unapplied-string</code> hook.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%n</code><br />
|
||
The number of applied patches.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%c</code><br />
|
||
The number of unapplied patches.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%a</code><br />
|
||
The number of all patches (<code>%a = %n + %c</code>).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%g</code><br />
|
||
The names of active <code>mq</code> guards (<code>hg</code> backend).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%G</code><br />
|
||
The number of active <code>mq</code> guards (<code>hg</code> backend).</p>
|
||
</li>
|
||
</ul>
|
||
<p>Not all VCS backends have to support all replacements. For <code>nvcsformats</code>
|
||
no replacements are performed at all, it is just a string.</p>
|
||
<hr />
|
||
<p><span id="vcs_005finfo-Oddities"></span> <span id="Oddities"></span></p>
|
||
<h3 id="2653-oddities"><a class="header" href="#2653-oddities">26.5.3 Oddities</a></h3>
|
||
<p>If you want to use the <code>%b</code> (bold off) prompt expansion in <code>formats</code>,
|
||
which expands <code>%b</code> itself, use <code>%%b</code>. That will cause the <code>vcs_info</code>
|
||
expansion to replace <code>%%b</code> with <code>%b</code>, so that zsh’s prompt expansion
|
||
mechanism can handle it. Similarly, to hand down <code>%b</code> from
|
||
<code>branchformat</code>, use <code>%%%%b</code>. Sorry for this inconvenience, but it cannot
|
||
be easily avoided. Luckily we do not clash with a lot of prompt
|
||
expansions and this only needs to be done for those.</p>
|
||
<p>When one of the <code>gen-applied-string</code>, <code>gen-unapplied-string</code>, and
|
||
<code>set-patch-format</code> hooks is defined, applying <code>%</code>-escaping
|
||
(‘<code>foo=${foo//’%’/%%}</code>’) to the interpolated values for use in the
|
||
prompt is the responsibility of those hooks (jointly); when neither of
|
||
those hooks is defined, <code>vcs_info</code> handles escaping by itself. We regret
|
||
this coupling, but it was required for backwards compatibility.</p>
|
||
<hr />
|
||
<p><span id="vcs_005finfo-Quilt-Support"></span>
|
||
<span id="Quilt-Support"></span></p>
|
||
<h3 id="2654-quilt-support"><a class="header" href="#2654-quilt-support">26.5.4 Quilt Support</a></h3>
|
||
<p>Quilt is not a version control system, therefore this is not implemented
|
||
as a backend. It can help keeping track of a series of patches. People
|
||
use it to keep a set of changes they want to use on top of software
|
||
packages (which is tightly integrated into the package build process -
|
||
the Debian project does this for a large number of packages). Quilt can
|
||
also help individual developers keep track of their own patches on top
|
||
of real version control systems.</p>
|
||
<p>The <code>vcs_info</code> integration tries to support both ways of using quilt by
|
||
having two slightly different modes of operation: ‘addon’ mode and
|
||
‘standalone’ mode).</p>
|
||
<p>Quilt integration is off by default; to enable it, set the <code>use-quilt</code>
|
||
style, and add <code>%Q</code> to your <code>formats</code> or <code>actionformats</code> style:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':vcs_info:*' use-quilt true
|
||
</code></pre>
|
||
</div>
|
||
<p>Styles looked up from the Quilt support code include
|
||
‘<code>.quilt-``quilt-mode</code>’ in the <code>vcs-string</code> part of the context, where
|
||
<code>quilt-mode</code> is either <code>addon</code> or <code>standalone</code>. Example:
|
||
<code>:vcs_info:git.quilt-addon:default:``repo-root-name</code>.</p>
|
||
<p>For ‘addon’ mode to become active <code>vcs_info</code> must have already detected
|
||
a real version control system controlling the directory. If that is the
|
||
case, a directory that holds quilt’s patches needs to be found. That
|
||
directory is configurable via the ‘<code>QUILT_PATCHES</code>’ environment
|
||
variable. If that variable exists its value is used, otherwise the value
|
||
‘<code>patches</code>’ is assumed. The value from <code>$QUILT_PATCHES</code> can be
|
||
overwritten using the ‘<code>quilt-patches</code>’ style. (Note: you can use
|
||
<code>vcs_info</code> to keep the value of <code>$QUILT_PATCHES</code> correct all the time
|
||
via the <code>post-quilt</code> hook).</p>
|
||
<p>When the directory in question is found, quilt is assumed to be active.
|
||
To gather more information, <code>vcs_info</code> looks for a directory called
|
||
‘.pc’; Quilt uses that directory to track its current state. If this
|
||
directory does not exist we know that quilt has not done anything to the
|
||
working directory (read: no patches have been applied yet).</p>
|
||
<p>If patches are applied, <code>vcs_info</code> will try to find out which. If you
|
||
want to know which patches of a series are not yet applied, you need to
|
||
activate the <code>get-unapplied</code> style in the appropriate context.</p>
|
||
<p><code>vcs_info</code> allows for very detailed control over how the gathered
|
||
information is presented (see
|
||
<a href="User-Contributions.html#vcs_005finfo-Configuration">Configuration</a> and <a href="User-Contributions.html#vcs_005finfo-Hooks">Hooks in
|
||
vcs_info</a>), all of which are documented below.
|
||
Note there are a number of other patch tracking systems that work on top
|
||
of a certain version control system (like <code>stgit</code> for git, or <code>mq</code> for
|
||
hg); the configuration for systems like that are generally configured
|
||
the same way as the quilt support.</p>
|
||
<p>If the quilt support is working in ‘addon’ mode, the produced string is
|
||
available as a simple format replacement (<code>%Q</code> to be precise), which can
|
||
be used in <code>formats</code> and <code>actionformats</code>; see below for details).</p>
|
||
<p>If, on the other hand, the support code is working in ‘standalone’ mode,
|
||
<code>vcs_info</code> will pretend as if <code>quilt</code> were an actual version control
|
||
system. That means that the version control system identifier (which
|
||
otherwise would be something like ‘svn’ or ‘cvs’) will be set to
|
||
‘<code>-quilt-</code>’. This has implications on the used style context where
|
||
this identifier is the second element. <code>vcs_info</code> will have filled in a
|
||
proper value for the "repository’s" root directory and the string
|
||
containing the information about quilt’s state will be available as the
|
||
‘misc’ replacement (and <code>%Q</code> for compatibility with ‘addon’ mode).</p>
|
||
<p>What is left to discuss is how ‘standalone’ mode is detected. The
|
||
detection itself is a series of searches for directories. You can have
|
||
this detection enabled all the time in every directory that is not
|
||
otherwise under version control. If you know there is only a limited set
|
||
of trees where you would like <code>vcs_info</code> to try and look for Quilt in
|
||
‘standalone’ mode to minimise the amount of searching on every call to
|
||
<code>vcs_info</code>, there are a number of ways to do that:</p>
|
||
<p>Essentially, ‘standalone’ mode detection is controlled by a style called
|
||
‘<code>quilt-standalone</code>’. It is a string style and its value can have
|
||
different effects. The simplest values are: ‘<code>always</code>’ to run detection
|
||
every time <code>vcs_info</code> is run, and ‘<code>never</code>’ to turn the detection off
|
||
entirely.</p>
|
||
<p>If the value of <code>quilt-standalone</code> is something else, it is interpreted
|
||
differently. If the value is the name of a scalar variable the value of
|
||
that variable is checked and that value is used in the same
|
||
‘always’/‘never’ way as described above.</p>
|
||
<p>If the value of <code>quilt-standalone</code> is an array, the elements of that
|
||
array are used as directory names under which you want the detection to
|
||
be active.</p>
|
||
<p>If <code>quilt-standalone</code> is an associative array, the keys are taken as
|
||
directory names under which you want the detection to be active, but
|
||
only if the corresponding value is the string ‘<code>true</code>’.</p>
|
||
<p>Last, but not least, if the value of <code>quilt-standalone</code> is the name of a
|
||
function, the function is called without arguments and the return value
|
||
decides whether detection should be active. A ‘0’ return value is true;
|
||
a non-zero return value is interpreted as false.</p>
|
||
<p>Note, if there is both a function and a variable by the name of
|
||
<code>quilt-standalone</code>, the function will take precedence.</p>
|
||
<hr />
|
||
<p><span id="vcs_005finfo-API"></span>
|
||
<span id="Function-Descriptions-_0028Public-API_0029"></span></p>
|
||
<h3 id="2655-function-descriptions-public-api"><a class="header" href="#2655-function-descriptions-public-api">26.5.5 Function Descriptions (Public API)</a></h3>
|
||
<p><span id="index-vcs_005finfo"></span></p>
|
||
<p><code>vcs_info</code> [<code>user-context</code>]</p>
|
||
<p>The main function, that runs all backends and assembles all data into
|
||
<code>${vcs_info_msg_*_}</code>. This is the function you want to call from
|
||
<code>precmd</code> if you want to include up-to-date information in your prompt
|
||
(see <a href="User-Contributions.html#vcs_005finfo-Variables">Variable Description</a> below). If an
|
||
argument is given, that string will be used instead of <code>default</code> in the
|
||
<code>user-context</code> field of the style context.</p>
|
||
<p><span id="index-vcs_005finfo_005fhookadd"></span></p>
|
||
<p><code>vcs_info_hookadd</code></p>
|
||
<p>Statically registers a number of functions to a given hook. The hook
|
||
needs to be given as the first argument; what follows is a list of
|
||
hook-function names to register to the hook. The ‘<code>+vi-</code>’ prefix needs
|
||
to be left out here. See <a href="User-Contributions.html#vcs_005finfo-Hooks">Hooks in vcs_info</a> below
|
||
for details.</p>
|
||
<p><span id="index-vcs_005finfo_005fhookdel"></span></p>
|
||
<p><code>vcs_info_hookdel</code></p>
|
||
<p>Remove hook-functions from a given hook. The hook needs to be given as
|
||
the first non-option argument; what follows is a list of hook-function
|
||
names to un-register from the hook. If ‘<code>-a</code>’ is used as the first
|
||
argument, <code>all</code> occurrences of the functions are unregistered. Otherwise
|
||
only the last occurrence is removed (if a function was registered to a
|
||
hook more than once). The ‘<code>+vi-</code>’ prefix needs to be left out here. See
|
||
<a href="User-Contributions.html#vcs_005finfo-Hooks">Hooks in vcs_info</a> below for details.</p>
|
||
<p><span id="index-vcs_005finfo_005flastmsg"></span></p>
|
||
<p><code>vcs_info_lastmsg</code></p>
|
||
<p>Outputs the last <code>${vcs_info_msg_*_}</code> value. Takes into account the
|
||
value of the <code>use-prompt-escapes</code> style in
|
||
<code>’:vcs_info:formats:command:-all-’</code>. It also only prints <code>max-exports</code>
|
||
values.</p>
|
||
<p><span id="index-vcs_005finfo_005fprintsys"></span></p>
|
||
<p><code>vcs_info_printsys</code> [<code>user-context</code>]</p>
|
||
<p>Prints a list of all supported version control systems. Useful to find
|
||
out possible contexts (and which of them are enabled) or values for the
|
||
<code>disable</code> style.</p>
|
||
<p><span id="index-vcs_005finfo_005fsetsys"></span></p>
|
||
<p><code>vcs_info_setsys</code></p>
|
||
<p>Initializes <code>vcs_info</code>’s internal list of available backends. With this
|
||
function, you can add support for new VCSs without restarting the shell.</p>
|
||
<p>All functions named <code>VCS_INFO_*</code> are for internal use only.</p>
|
||
<hr />
|
||
<p><span id="vcs_005finfo-Variables"></span>
|
||
<span id="Variable-Description"></span></p>
|
||
<h3 id="2656-variable-description"><a class="header" href="#2656-variable-description">26.5.6 Variable Description</a></h3>
|
||
<ul>
|
||
<li><code>${vcs_info_msg_``N``_}</code> (Note the trailing underscore)<br />
|
||
Where <code>N</code> is an integer, e.g., <code>vcs_info_msg_0_</code>. These variables
|
||
are the storage for the informational message the last <code>vcs_info</code>
|
||
call has assembled. These are strongly connected to the <code>formats</code>,
|
||
<code>actionformats</code> and <code>nvcsformats</code> styles described above. Those
|
||
styles are lists. The first member of that list gets expanded into
|
||
<code>${vcs_info_msg_0_}</code>, the second into <code>${vcs_info_msg_1_}</code> and the
|
||
Nth into <code>${vcs_info_msg_N-1_}</code>. (See the <code>max-exports</code> style
|
||
above.)</li>
|
||
</ul>
|
||
<p>All variables named <code>VCS_INFO_*</code> are for internal use only.</p>
|
||
<hr />
|
||
<p><span id="vcs_005finfo-Hooks"></span>
|
||
<span id="Hooks-in-vcs_005finfo"></span></p>
|
||
<h3 id="2657-hooks-in-vcs_info"><a class="header" href="#2657-hooks-in-vcs_info">26.5.7 Hooks in vcs_info</a></h3>
|
||
<p>Hooks are places in <code>vcs_info</code> where you can run your own code. That
|
||
code can communicate with the code that called it and through that,
|
||
change the system’s behaviour.</p>
|
||
<p>For configuration, hooks change the style context:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">:vcs_info:vcs-string+hook-name:user-context:repo-root-name
|
||
</code></pre>
|
||
</div>
|
||
<p>To register functions to a hook, you need to list them in the <code>hooks</code>
|
||
style in the appropriate context.</p>
|
||
<p>Example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':vcs_info:*+foo:*' hooks bar baz
|
||
</code></pre>
|
||
</div>
|
||
<p>This registers functions to the hook ‘foo’ for all backends. In order to
|
||
avoid namespace problems, all registered function names are prepended by
|
||
a ‘<code>+vi-</code>’, so the actual functions called for the ‘foo’ hook are
|
||
‘<code>+vi-bar</code>’ and ‘<code>+vi-baz</code>’.</p>
|
||
<p>If you would like to register a function to a hook regardless of the
|
||
current context, you may use the <code>vcs_info_hookadd</code> function. To remove
|
||
a function that was added like that, the <code>vcs_info_hookdel</code> function can
|
||
be used.</p>
|
||
<p>If something seems weird, you can enable the ‘debug’ boolean style in
|
||
the proper context and the hook-calling code will print what it tried to
|
||
execute and whether the function in question existed.</p>
|
||
<p>When you register more than one function to a hook, all functions are
|
||
executed one after another until one function returns non-zero or until
|
||
all functions have been called. Context-sensitive hook functions are
|
||
executed <code>before</code> statically registered ones (the ones added by
|
||
<code>vcs_info_hookadd</code>).</p>
|
||
<p>You may pass data between functions via an associative array,
|
||
<code>user_data</code>. For example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">+vi-git-myfirsthook(){
|
||
user_data[myval]=$myval
|
||
}
|
||
+vi-git-mysecondhook(){
|
||
# do something with ${user_data[myval]}
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p>There are a number of variables that are special in hook contexts:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>ret</code><br />
|
||
The return value that the hooks system will return to the caller.
|
||
The default is an integer ‘zero’. If and how a changed <code>ret</code> value
|
||
changes the execution of the caller depends on the specific hook.
|
||
See the hook documentation below for details.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>hook_com</code><br />
|
||
An associated array which is used for bidirectional communication
|
||
from the caller to hook functions. The used keys depend on the
|
||
specific hook.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>context</code><br />
|
||
The active context of the hook. Functions that wish to change this
|
||
variable should make it local scope first.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>vcs</code><br />
|
||
The current VCS after it was detected. The same values as in the
|
||
enable/disable style are used. Available in all hooks except
|
||
<code>start-up</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<p>Finally, the full list of currently available hooks:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>start-up</code><br />
|
||
Called after starting <code>vcs_info</code> but before the VCS in this
|
||
directory is determined. It can be used to deactivate <code>vcs_info</code>
|
||
temporarily if necessary. When <code>ret</code> is set to <code>1</code>, <code>vcs_info</code>
|
||
aborts and does nothing; when set to <code>2</code>, <code>vcs_info</code> sets up
|
||
everything as if no version control were active and exits.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>pre-get-data</code><br />
|
||
Same as <code>start-up</code> but after the VCS was detected.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>gen-hg-bookmark-string</code><br />
|
||
Called in the Mercurial backend when a bookmark string is generated;
|
||
the <code>get-revision</code> and <code>get-bookmarks</code> styles must be true.</p>
|
||
<p>This hook gets the names of the Mercurial bookmarks that <code>vcs_info</code>
|
||
collected from ‘hg’.</p>
|
||
<p>If a bookmark is active, the key <code>${hook_com[hg-active-bookmark]}</code>
|
||
is set to its name. The key is otherwise unset.</p>
|
||
<p>When setting <code>ret</code> to non-zero, the string in
|
||
<code>${hook_com[hg-bookmark-string]}</code> will be used in the <code>%m</code> escape in
|
||
<code>formats</code> and <code>actionformats</code> and will be available in the global
|
||
<code>backend_misc</code> array as <code>${backend_misc[bookmarks]}</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>gen-applied-string</code><br />
|
||
Called in the <code>git</code> (with <code>stgit</code> or during rebase or merge), and
|
||
<code>hg</code> (with <code>mq</code>) backends and in <code>quilt</code> support when the
|
||
<code>applied-string</code> is generated; the <code>use-quilt</code> zstyle must be true
|
||
for <code>quilt</code> (the <code>mq</code> and <code>stgit</code> backends are active by default).</p>
|
||
<p>This hook gets the names of all applied patches which <code>vcs_info</code>
|
||
collected so far in the opposite order, which means that the first
|
||
argument is the top-most patch and so forth.</p>
|
||
<p>When setting <code>ret</code> to non-zero, the string in
|
||
<code>${hook_com[applied-string]}</code> will be available as <code>%p</code> in the
|
||
<code>patch-format</code> and <code>nopatch-format</code> styles. This hook is, in concert
|
||
with <code>set-patch-format</code>, responsible for <code>%</code>-escaping that value for
|
||
use in the prompt. (See <a href="User-Contributions.html#vcs_005finfo-Oddities">Oddities</a>.)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>gen-unapplied-string</code><br />
|
||
Called in the <code>git</code> (with <code>stgit</code> or during rebase), and <code>hg</code> (with
|
||
<code>mq</code>) backend and in <code>quilt</code> support when the <code>unapplied-string</code> is
|
||
generated; the <code>get-unapplied</code> style must be true.</p>
|
||
<p>This hook gets the names of all unapplied patches which <code>vcs_info</code>
|
||
collected so far in order, which means that the first argument is
|
||
the patch next-in-line to be applied and so forth.</p>
|
||
<p>When setting <code>ret</code> to non-zero, the string in
|
||
<code>${hook_com[unapplied-string]}</code> will be available as <code>%u</code> in the
|
||
<code>patch-format</code> and <code>nopatch-format</code> styles. This hook is, in concert
|
||
with <code>set-patch-format</code>, responsible for <code>%</code>-escaping that value for
|
||
use in the prompt. (See <a href="User-Contributions.html#vcs_005finfo-Oddities">Oddities</a>.)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>gen-mqguards-string</code><br />
|
||
Called in the <code>hg</code> backend when <code>guards-string</code> is generated; the
|
||
<code>get-mq</code> style must be true (default).</p>
|
||
<p>This hook gets the names of any active <code>mq</code> guards.</p>
|
||
<p>When setting <code>ret</code> to non-zero, the string in
|
||
<code>${hook_com[guards-string]}</code> will be used in the <code>%g</code> escape in the
|
||
<code>patch-format</code> and <code>nopatch-format</code> styles.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>no-vcs</code><br />
|
||
This hooks is called when no version control system was detected.</p>
|
||
<p>The ‘<code>hook_com</code>’ parameter is not used.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>post-backend</code><br />
|
||
Called as soon as the backend has finished collecting information.</p>
|
||
<p>The ‘<code>hook_com</code>’ keys available are as for the <code>set-message</code> hook.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>post-quilt</code><br />
|
||
Called after the <code>quilt</code> support is done. The following information
|
||
is passed as arguments to the hook: 1. the quilt-support mode
|
||
(‘addon’ or ‘standalone’); 2. the directory that contains the
|
||
patch series; 3. the directory that holds quilt’s status information
|
||
(the ‘.pc’ directory) or the string <code>"-nopc-"</code> if that directory
|
||
wasn’t found.</p>
|
||
<p>The ‘hook_com’ parameter is not used.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>set-branch-format</code><br />
|
||
Called before ‘<code>branchformat</code>’ is set. The only argument to the hook
|
||
is the format that is configured at this point.</p>
|
||
<p>The ‘<code>hook_com</code>’ keys considered are ‘<code>branch</code>’ and ‘<code>revision</code>’.
|
||
They are set to the values figured out so far by <code>vcs_info</code> and any
|
||
change will be used directly when the actual replacement is done.</p>
|
||
<p>If <code>ret</code> is set to non-zero, the string in
|
||
<code>${hook_com[branch-replace]}</code> will be used unchanged as the ‘<code>%b</code>’
|
||
replacement in the variables set by <code>vcs_info</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>set-hgrev-format</code><br />
|
||
Called before a ‘<code>hgrevformat</code>’ is set. The only argument to the
|
||
hook is the format that is configured at this point.</p>
|
||
<p>The ‘<code>hook_com</code>’ keys considered are ‘<code>hash</code>’ and ‘<code>localrev</code>’. They
|
||
are set to the values figured out so far by <code>vcs_info</code> and any
|
||
change will be used directly when the actual replacement is done.</p>
|
||
<p>If <code>ret</code> is set to non-zero, the string in
|
||
<code>${hook_com[rev-replace]}</code> will be used unchanged as the ‘<code>%i</code>’
|
||
replacement in the variables set by <code>vcs_info</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>pre-addon-quilt</code><br />
|
||
This hook is used when <code>vcs_info</code>’s quilt functionality is active in
|
||
"addon" mode (quilt used on top of a real version control system).
|
||
It is activated right before any quilt specific action is taken.</p>
|
||
<p>Setting the ‘<code>ret</code>’ variable in this hook to a non-zero value avoids
|
||
any quilt specific actions from being run at all.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>set-patch-format</code><br />
|
||
This hook is used to control some of the possible expansions in
|
||
<code>patch-format</code> and <code>nopatch-format</code> styles with patch queue systems
|
||
such as quilt, mqueue and the like.</p>
|
||
<p>This hook is used in the <code>git</code>, <code>hg</code> and <code>quilt</code> backends.</p>
|
||
<p>The hook allows the control of the <code>%p</code> (<code>${hook_com[applied]}</code>) and
|
||
<code>%u</code> (<code>${hook_com[unapplied]}</code>) expansion in all backends that use
|
||
the hook. With the mercurial backend, the <code>%g</code>
|
||
(<code>${hook_com[guards]}</code>) expansion is controllable in addition to
|
||
that.</p>
|
||
<p>If <code>ret</code> is set to non-zero, the string in
|
||
<code>${hook_com[patch-replace]}</code> will be used unchanged instead of an
|
||
expanded format from <code>patch-format</code> or <code>nopatch-format</code>.</p>
|
||
<p>This hook is, in concert with the <code>gen-applied-string</code> or
|
||
<code>gen-unapplied-string</code> hooks if they are defined, responsible for
|
||
<code>%</code>-escaping the final <code>patch-format</code> value for use in the prompt.
|
||
(See <a href="User-Contributions.html#vcs_005finfo-Oddities">Oddities</a>.)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>set-message</code><br />
|
||
Called each time before a ‘<code>vcs_info_msg_``N``_</code>’ message is set. It
|
||
takes two arguments; the first being the ‘<code>N</code>’ in the message
|
||
variable name, the second is the currently configured <code>formats</code> or
|
||
<code>actionformats</code>.</p>
|
||
<p>There are a number of ‘<code>hook_com</code>’ keys, that are used here:
|
||
‘<code>action</code>’, ‘<code>branch</code>’, ‘<code>base</code>’, ‘<code>base-name</code>’, ‘<code>subdir</code>’,
|
||
‘<code>staged</code>’, ‘<code>unstaged</code>’, ‘<code>revision</code>’, ‘<code>misc</code>’, ‘<code>vcs</code>’ and one
|
||
‘<code>miscN</code>’ entry for each backend-specific data field (<code>N</code> starting
|
||
at zero). They are set to the values figured out so far by
|
||
<code>vcs_info</code> and any change will be used directly when the actual
|
||
replacement is done.</p>
|
||
<p>Since this hook is triggered multiple times (once for each
|
||
configured <code>formats</code> or <code>actionformats</code>), each of the ‘<code>hook_com</code>’
|
||
keys mentioned above (except for the <code>miscN</code> entries) has an
|
||
‘<code>_orig</code>’ counterpart, so even if you changed a value to your
|
||
liking you can still get the original value in the next run.
|
||
Changing the ‘<code>_orig</code>’ values is probably not a good idea.</p>
|
||
<p>If <code>ret</code> is set to non-zero, the string in <code>${hook_com[message]}</code>
|
||
will be used unchanged as the message by <code>vcs_info</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<p>If all of this sounds rather confusing, take a look at
|
||
<a href="User-Contributions.html#vcs_005finfo-Examples">Examples</a> and also in the
|
||
<code>Misc/vcs_info-examples</code> file in the Zsh source. They contain some
|
||
explanatory code.</p>
|
||
<hr />
|
||
<p><span id="vcs_005finfo-Examples"></span> <span id="Examples"></span></p>
|
||
<h3 id="2658-examples"><a class="header" href="#2658-examples">26.5.8 Examples</a></h3>
|
||
<p>Don’t use <code>vcs_info</code> at all (even though it’s in your prompt):</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':vcs_info:*' enable NONE
|
||
</code></pre>
|
||
</div>
|
||
<p>Disable the backends for <code>bzr</code> and <code>svk</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':vcs_info:*' disable bzr svk
|
||
</code></pre>
|
||
</div>
|
||
<p>Disable everything <em>but</em> <code>bzr</code> and <code>svk</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':vcs_info:*' enable bzr svk
|
||
</code></pre>
|
||
</div>
|
||
<p>Provide a special formats for <code>git</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':vcs_info:git:*' formats ' GIT, BABY! [%b]'
|
||
zstyle ':vcs_info:git:*' actionformats ' GIT ACTION! [%b|%a]'
|
||
</code></pre>
|
||
</div>
|
||
<p>All <code>%x</code> expansion in all sorts of formats (<code>formats</code>, <code>actionformats</code>,
|
||
<code>branchformat</code>, you name it) are done using the ‘<code>zformat</code>’ builtin from
|
||
the ‘<code>zsh/zutil</code>’ module. That means you can do everything with these
|
||
<code>%x</code> items what zformat supports. In particular, if you want something
|
||
that is really long to have a fixed width, like a hash in a mercurial
|
||
branchformat, you can do this: <code>%12.12i</code>. That’ll shrink the 40
|
||
character hash to its 12 leading characters. The form is actually
|
||
‘<code>%``min``.``max``x</code>’. More is possible. See <a href="Zsh-Modules.html#The-zsh_002fzutil-Module">The zsh/zutil
|
||
Module</a> for details.</p>
|
||
<p>Use the quicker <code>bzr</code> backend</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':vcs_info:bzr:*' use-simple true
|
||
</code></pre>
|
||
</div>
|
||
<p>If you do use <code>use-simple</code>, please report if it does
|
||
‘the-right-thing[tm]’.</p>
|
||
<p>Display the revision number in yellow for <code>bzr</code> and <code>svn</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':vcs_info:(svn|bzr):*' \
|
||
branchformat '%b%{'${fg[yellow]}'%}:%r'
|
||
</code></pre>
|
||
</div>
|
||
<p>If you want colors, make sure you enclose the color codes in
|
||
<code>%{``...``%}</code> if you want to use the string provided by <code>vcs_info</code> in
|
||
prompts.</p>
|
||
<p>Here is how to print the VCS information as a command (not in a prompt):</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">alias vcsi='vcs_info command; vcs_info_lastmsg'
|
||
</code></pre>
|
||
</div>
|
||
<p>This way, you can even define different formats for output via
|
||
<code>vcs_info_lastmsg</code> in the ’<code>:vcs_info:*:command:*</code>’ namespace.</p>
|
||
<p>Now as promised, some code that uses hooks: say, you’d like to replace
|
||
the string ‘svn’ by ‘subversion’ in <code>vcs_info</code>’s <code>%s</code> <code>formats</code>
|
||
replacement.</p>
|
||
<p>First, we will tell <code>vcs_info</code> to call a function when populating the
|
||
message variables with the gathered information:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':vcs_info:*+set-message:*' hooks svn2subversion
|
||
</code></pre>
|
||
</div>
|
||
<p>Nothing happens. Which is reasonable, since we didn’t define the actual
|
||
function yet. To see what the hooks subsystem is trying to do, enable
|
||
the ‘<code>debug</code>’ style:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':vcs_info:*+*:*' debug true
|
||
</code></pre>
|
||
</div>
|
||
<p>That should give you an idea what is going on. Specifically, the
|
||
function that we are looking for is ‘<code>+vi-svn2subversion</code>’. Note, the
|
||
‘<code>+vi-</code>’ prefix. So, everything is in order, just as documented. When
|
||
you are done checking out the debugging output, disable it again:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':vcs_info:*+*:*' debug false
|
||
</code></pre>
|
||
</div>
|
||
<p>Now, let’s define the function:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">function +vi-svn2subversion() {
|
||
[[ ${hook_com[vcs_orig]} == svn ]] && hook_com[vcs]=subversion
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p>Simple enough. And it could have even been simpler, if only we had
|
||
registered our function in a less generic context. If we do it only in
|
||
the ‘<code>svn</code>’ backend’s context, we don’t need to test which the active
|
||
backend is:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':vcs_info:svn+set-message:*' hooks svn2subversion
|
||
</code></pre>
|
||
</div>
|
||
<div class="example">
|
||
<pre><code class="language-example">function +vi-svn2subversion() {
|
||
hook_com[vcs]=subversion
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p>And finally a little more elaborate example, that uses a hook to create
|
||
a customised bookmark string for the <code>hg</code> backend.</p>
|
||
<p>Again, we start off by registering a function:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':vcs_info:hg+gen-hg-bookmark-string:*' hooks hgbookmarks
|
||
</code></pre>
|
||
</div>
|
||
<p>And then we define the ‘<code>+vi-hgbookmarks</code>’ function:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">function +vi-hgbookmarks() {
|
||
# The default is to connect all bookmark names by
|
||
# commas. This mixes things up a little.
|
||
# Imagine, there's one type of bookmarks that is
|
||
# special to you. Say, because it's *your* work.
|
||
# Those bookmarks look always like this: "sh/*"
|
||
# (because your initials are sh, for example).
|
||
# This makes the bookmarks string use only those
|
||
# bookmarks. If there's more than one, it
|
||
# concatenates them using commas.
|
||
# The bookmarks returned by `hg' are available in
|
||
# the function's positional parameters.
|
||
local s="${(Mj:,:)@:#sh/*}"
|
||
# Now, the communication with the code that calls
|
||
# the hook functions is done via the hook_com[]
|
||
# hash. The key at which the `gen-hg-bookmark-string'
|
||
# hook looks is `hg-bookmark-string'. So:
|
||
hook_com[hg-bookmark-string]=$s
|
||
# And to signal that we want to use the string we
|
||
# just generated, set the special variable `ret' to
|
||
# something other than the default zero:
|
||
ret=1
|
||
return 0
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p>Some longer examples and code snippets which might be useful are
|
||
available in the examples file located at Misc/vcs_info-examples in the
|
||
Zsh source directory.</p>
|
||
<p>This concludes our guided tour through zsh’s <code>vcs_info</code>.</p>
|
||
<hr />
|
||
<p><span id="Prompt-Themes"></span> <span id="Prompt-Themes-1"></span></p>
|
||
<h2 id="266-prompt-themes"><a class="header" href="#266-prompt-themes">26.6 Prompt Themes</a></h2>
|
||
<hr />
|
||
<p><span id="Installation-2"></span></p>
|
||
<h3 id="2661-installation"><a class="header" href="#2661-installation">26.6.1 Installation</a></h3>
|
||
<p>You should make sure all the functions from the <code>Functions/Prompts</code>
|
||
directory of the source distribution are available; they all begin with
|
||
the string ‘<code>prompt_</code>’ except for the special function‘<code>promptinit</code>’.
|
||
You also need the ‘<code>colors</code>’ and ‘<code>add-zsh-hook</code>’ functions from
|
||
<code>Functions/Misc</code>. All these functions may already be installed on your
|
||
system; if not, you will need to find them and copy them. The directory
|
||
should appear as one of the elements of the <code>fpath</code> array (this should
|
||
already be the case if they were installed), and at least the function
|
||
<code>promptinit</code> should be autoloaded; it will autoload the rest. Finally,
|
||
to initialize the use of the system you need to call the <code>promptinit</code>
|
||
function. The following code in your <code>.zshrc</code> will arrange for this;
|
||
assume the functions are stored in the directory <code>~/myfns</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">fpath=(~/myfns $fpath)
|
||
autoload -U promptinit
|
||
promptinit
|
||
</code></pre>
|
||
</div>
|
||
<hr />
|
||
<p><span id="Theme-Selection"></span></p>
|
||
<h3 id="2662-theme-selection"><a class="header" href="#2662-theme-selection">26.6.2 Theme Selection</a></h3>
|
||
<p>Use the <code>prompt</code> command to select your preferred theme. This command
|
||
may be added to your <code>.zshrc</code> following the call to <code>promptinit</code> in
|
||
order to start zsh with a theme already selected.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>prompt</code> [ <code>-c</code> | <code>-l</code> ]<br />
|
||
<code>prompt</code> [ <code>-p</code> | <code>-h</code> ] [ <code>theme</code> ... ]<br />
|
||
<code>prompt</code> [ <code>-s</code> ] <code>theme</code> [ <code>arg</code> ... ]<br />
|
||
Set or examine the prompt theme. With no options and a <code>theme</code>
|
||
argument, the theme with that name is set as the current theme. The
|
||
available themes are determined at run time; use the <code>-l</code> option to
|
||
see a list. The special <code>theme</code> ‘<code>random</code>’ selects at random one of
|
||
the available themes and sets your prompt to that.</p>
|
||
<p>In some cases the <code>theme</code> may be modified by one or more arguments,
|
||
which should be given after the theme name. See the help for each
|
||
theme for descriptions of these arguments.</p>
|
||
<p>Options are:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-c</code><br />
|
||
Show the currently selected theme and its parameters, if any.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-l</code><br />
|
||
List all available prompt themes.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-p</code><br />
|
||
Preview the theme named by <code>theme</code>, or all themes if no <code>theme</code>
|
||
is given.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-h</code><br />
|
||
Show help for the theme named by <code>theme</code>, or for the <code>prompt</code>
|
||
function if no <code>theme</code> is given.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-s</code><br />
|
||
Set <code>theme</code> as the current theme and save state.</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p><code>prompt_``theme``_setup</code><br />
|
||
Each available <code>theme</code> has a setup function which is called by the
|
||
<code>prompt</code> function to install that theme. This function may define
|
||
other functions as necessary to maintain the prompt, including
|
||
functions used to preview the prompt or provide help for its use.
|
||
You should not normally call a theme’s setup function directly.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Utility-Themes"></span></p>
|
||
<h3 id="2663-utility-themes"><a class="header" href="#2663-utility-themes">26.6.3 Utility Themes</a></h3>
|
||
<ul>
|
||
<li>
|
||
<p><code>prompt off</code><br />
|
||
The theme ‘<code>off</code>’ sets all the prompt variables to minimal values
|
||
with no special effects.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>prompt default</code><br />
|
||
The theme ‘<code>default</code>’ sets all prompt variables to the same state as
|
||
if an interactive zsh was started with no initialization files.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>prompt restore</code><br />
|
||
The special theme ‘<code>restore</code>’ erases all theme settings and sets
|
||
prompt variables to their state before the first time the ‘<code>prompt</code>’
|
||
function was run, provided each theme has properly defined its
|
||
cleanup (see below).</p>
|
||
<p>Note that you can undo ‘<code>prompt off</code>’ and ‘<code>prompt default</code>’ with
|
||
‘<code>prompt restore</code>’, but a second restore does not undo the first.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Writing-Themes"></span></p>
|
||
<h3 id="2664-writing-themes"><a class="header" href="#2664-writing-themes">26.6.4 Writing Themes</a></h3>
|
||
<p>The first step for adding your own theme is to choose a name for it, and
|
||
create a file ‘<code>prompt_name_setup</code>’ in a directory in your <code>fpath</code>, such
|
||
as <code>~/myfns</code> in the example above. The file should at minimum contain
|
||
assignments for the prompt variables that your theme wishes to modify.
|
||
By convention, themes use <code>PS1</code>, <code>PS2</code>, <code>RPS1</code>, etc., rather than the
|
||
longer <code>PROMPT</code> and <code>RPROMPT</code>.</p>
|
||
<p>The file is autoloaded as a function in the current shell context, so it
|
||
may contain any necessary commands to customize your theme, including
|
||
defining additional functions. To make some complex tasks easier, your
|
||
setup function may also do any of the following:</p>
|
||
<ul>
|
||
<li>
|
||
<p>Assign <code>prompt_opts</code><br />
|
||
The array <code>prompt_opts</code> may be assigned any of <code>"bang"</code>, <code>"cr"</code>,
|
||
<code>"percent"</code>, <code>"sp"</code>, and/or <code>"subst"</code> as values. The corresponding
|
||
setopts (<code>promptbang</code>, etc.) are turned on, all other prompt-related
|
||
options are turned off. The <code>prompt_opts</code> array preserves setopts
|
||
even beyond the scope of <code>localoptions</code>, should your function need
|
||
that.</p>
|
||
</li>
|
||
<li>
|
||
<p>Modify precmd and preexec<br />
|
||
Use of <code>add-zsh-hook</code> is recommended. The <code>precmd</code> and <code>preexec</code>
|
||
hooks are automatically adjusted if the prompt theme changes or is
|
||
disabled.</p>
|
||
</li>
|
||
<li>
|
||
<p>Declare cleanup<br />
|
||
If your function makes any other changes that should be undone when
|
||
the theme is disabled, your setup function may call</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">prompt_cleanup command
|
||
</code></pre>
|
||
</div>
|
||
<p>where <code>command</code> should be suitably quoted. If your theme is ever
|
||
disabled or replaced by another, <code>command</code> is executed with <code>eval</code>.
|
||
You may declare more than one such cleanup hook.</p>
|
||
</li>
|
||
<li>
|
||
<p>Define preview<br />
|
||
Define or autoload a function <code>prompt_name_preview</code> to display a
|
||
simulated version of your prompt. A simple default previewer is
|
||
defined by <code>promptinit</code> for themes that do not define their own.
|
||
This preview function is called by ‘<code>prompt -p</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p>Provide help<br />
|
||
Define or autoload a function <code>prompt_name_help</code> to display
|
||
documentation or help text for your theme. This help function is
|
||
called by ‘<code>prompt -h</code>’.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="ZLE-Functions"></span> <span id="ZLE-Functions-1"></span></p>
|
||
<h2 id="267-zle-functions"><a class="header" href="#267-zle-functions">26.7 ZLE Functions</a></h2>
|
||
<hr />
|
||
<p><span id="Widgets"></span></p>
|
||
<h3 id="2671-widgets"><a class="header" href="#2671-widgets">26.7.1 Widgets</a></h3>
|
||
<p>These functions all implement user-defined ZLE widgets (see <a href="Zsh-Line-Editor.html#Zsh-Line-Editor">Zsh Line
|
||
Editor</a>) which can be bound to
|
||
keystrokes in interactive shells. To use them, your <code>.zshrc</code> should
|
||
contain lines of the form</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">autoload function
|
||
zle -N function
|
||
</code></pre>
|
||
</div>
|
||
<p>followed by an appropriate <code>bindkey</code> command to associate the function
|
||
with a key sequence. Suggested bindings are described below.</p>
|
||
<ul>
|
||
<li>
|
||
<p>bash-style word functions<br />
|
||
If you are looking for functions to implement moving over and
|
||
editing words in the manner of bash, where only alphanumeric
|
||
characters are considered word characters, you can use the functions
|
||
described in the next section. The following is sufficient:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">autoload -U select-word-style
|
||
select-word-style bash
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-forward_002dword_002dmatch"></span>
|
||
<span id="index-backward_002dword_002dmatch"></span>
|
||
<span id="index-kill_002dword_002dmatch"></span>
|
||
<span id="index-backward_002dkill_002dword_002dmatch"></span>
|
||
<span id="index-transpose_002dwords_002dmatch"></span>
|
||
<span id="index-capitalize_002dword_002dmatch"></span>
|
||
<span id="index-up_002dcase_002dword_002dmatch"></span>
|
||
<span id="index-down_002dcase_002dword_002dmatch"></span>
|
||
<span id="index-delete_002dwhole_002dword_002dmatch"></span>
|
||
<span id="index-select_002dword_002dmatch"></span>
|
||
<span id="index-select_002dword_002dstyle"></span>
|
||
<span id="index-match_002dword_002dcontext"></span>
|
||
<span id="index-match_002dwords_002dby_002dstyle"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>forward-word-match</code>, <code>backward-word-match</code><br />
|
||
<code>kill-word-match</code>, <code>backward-kill-word-match</code><br />
|
||
<code>transpose-words-match</code>, <code>capitalize-word-match</code><br />
|
||
<code>up-case-word-match</code>, <code>down-case-word-match</code><br />
|
||
<code>delete-whole-word-match</code>, <code>select-word-match</code><br />
|
||
<code>select-word-style</code>, <code>match-word-context</code>, <code>match-words-by-style</code><br />
|
||
The first eight ‘<code>-match</code>’ functions are drop-in replacements for
|
||
the builtin widgets without the suffix. By default they behave in a
|
||
similar way. However, by the use of styles and the function
|
||
<code>select-word-style</code>, the way words are matched can be altered.
|
||
<code>select-word-match</code> is intended to be used as a text object in vi
|
||
mode but with custom word styles. For comparison, the widgets
|
||
described in <a href="Zsh-Line-Editor.html#Text-Objects">Text Objects</a> use
|
||
fixed definitions of words, compatible with the <code>vim</code> editor.</p>
|
||
<p>The simplest way of configuring the functions is to use
|
||
<code>select-word-style</code>, which can either be called as a normal function
|
||
with the appropriate argument, or invoked as a user-defined widget
|
||
that will prompt for the first character of the word style to be
|
||
used. The first time it is invoked, the first eight <code>-match</code>
|
||
functions will automatically replace the builtin versions, so they
|
||
do not need to be loaded explicitly.</p>
|
||
<p>The word styles available are as follows. Only the first character
|
||
is examined.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>bash</code><br />
|
||
Word characters are alphanumeric characters only.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>normal</code><br />
|
||
As in normal shell operation: word characters are alphanumeric
|
||
characters plus any characters present in the string given by
|
||
the parameter <code>$WORDCHARS</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>shell</code><br />
|
||
Words are complete shell command arguments, possibly including
|
||
complete quoted strings, or any tokens special to the shell.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>whitespace</code><br />
|
||
Words are any set of characters delimited by whitespace.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>default</code><br />
|
||
Restore the default settings; this is usually the same as
|
||
‘<code>normal</code>’.</p>
|
||
</li>
|
||
</ul>
|
||
<p>All but ‘<code>default</code>’ can be input as an upper case character, which
|
||
has the same effect but with subword matching turned on. In this
|
||
case, words with upper case characters are treated specially: each
|
||
separate run of upper case characters, or an upper case character
|
||
followed by any number of other characters, is considered a word.
|
||
The style <code>subword-range</code> can supply an alternative character range
|
||
to the default ‘<code>[:upper:]</code>’; the value of the style is treated as
|
||
the contents of a ‘<code>[``...``]</code>’ pattern (note that the outer
|
||
brackets should not be supplied, only those surrounding named
|
||
ranges).</p>
|
||
<p>More control can be obtained using the <code>zstyle</code> command, as
|
||
described in <a href="Zsh-Modules.html#The-zsh_002fzutil-Module">The zsh/zutil
|
||
Module</a>. Each style is
|
||
looked up in the context <code>:zle:``widget</code> where <code>widget</code> is the name
|
||
of the user-defined widget, not the name of the function
|
||
implementing it, so in the case of the definitions supplied by
|
||
<code>select-word-style</code> the appropriate contexts are
|
||
<code>:zle:forward-word</code>, and so on. The function <code>select-word-style</code>
|
||
itself always defines styles for the context ‘<code>:zle:*</code>’ which can be
|
||
overridden by more specific (longer) patterns as well as explicit
|
||
contexts.</p>
|
||
<p>The style <code>word-style</code> specifies the rules to use. This may have the
|
||
following values.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>normal</code><br />
|
||
Use the standard shell rules, i.e. alphanumerics and
|
||
<code>$WORDCHARS</code>, unless overridden by the styles <code>word-chars</code> or
|
||
<code>word-class</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>specified</code><br />
|
||
Similar to <code>normal</code>, but <em>only</em> the specified characters, and
|
||
not also alphanumerics, are considered word characters.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>unspecified</code><br />
|
||
The negation of specified. The given characters are those which
|
||
will <em>not</em> be considered part of a word.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>shell</code><br />
|
||
Words are obtained by using the syntactic rules for generating
|
||
shell command arguments. In addition, special tokens which are
|
||
never command arguments such as ‘<code>()</code>’ are also treated as
|
||
words.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>whitespace</code><br />
|
||
Words are whitespace-delimited strings of characters.</p>
|
||
</li>
|
||
</ul>
|
||
<p>The first three of those rules usually use <code>$WORDCHARS</code>, but the
|
||
value in the parameter can be overridden by the style <code>word-chars</code>,
|
||
which works in exactly the same way as <code>$WORDCHARS</code>. In addition,
|
||
the style <code>word-class</code> uses character class syntax to group
|
||
characters and takes precedence over <code>word-chars</code> if both are set.
|
||
The <code>word-class</code> style does not include the surrounding brackets of
|
||
the character class; for example, ‘<code>-:[:alnum:]</code>’ is a valid
|
||
<code>word-class</code> to include all alphanumerics plus the characters ‘<code>-</code>’
|
||
and ‘<code>:</code>’. Be careful including ‘<code>]</code>’, ‘<code>^</code>’ and ‘<code>-</code>’ as these are
|
||
special inside character classes.</p>
|
||
<p><code>word-style</code> may also have ‘<code>-subword</code>’ appended to its value to
|
||
turn on subword matching, as described above.</p>
|
||
<p>The style <code>skip-chars</code> is mostly useful for <code>transpose-words</code> and
|
||
similar functions. If set, it gives a count of characters starting
|
||
at the cursor position which will not be considered part of the word
|
||
and are treated as space, regardless of what they actually are. For
|
||
example, if</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':zle:transpose-words' skip-chars 1
|
||
</code></pre>
|
||
</div>
|
||
<p>has been set, and <code>transpose-words-match</code> is called with the cursor
|
||
on the <code>X</code> of <code>foo``X``bar</code>, where <code>X</code> can be any character, then
|
||
the resulting expression is <code>bar``X``foo</code>.</p>
|
||
<p>Finer grained control can be obtained by setting the style
|
||
<code>word-context</code> to an array of pairs of entries. Each pair of entries
|
||
consists of a <code>pattern</code> and a <code>subcontext</code>. The shell argument the
|
||
cursor is on is matched against each <code>pattern</code> in turn until one
|
||
matches; if it does, the context is extended by a colon and the
|
||
corresponding <code>subcontext</code>. Note that the test is made against the
|
||
original word on the line, with no stripping of quotes. Special
|
||
handling is done between words: the current context is examined and
|
||
if it contains the string <code>between</code> the word is set to a single
|
||
space; else if it is contains the string <code>back</code>, the word before the
|
||
cursor is considered, else the word after cursor is considered. Some
|
||
examples are given below.</p>
|
||
<p>The style <code>skip-whitespace-first</code> is only used with the
|
||
<code>forward-word</code> widget. If it is set to true, then <code>forward-word</code>
|
||
skips any non-word-characters, followed by any non-word-characters:
|
||
this is similar to the behaviour of other word-orientated widgets,
|
||
and also that used by other editors, however it differs from the
|
||
standard zsh behaviour. When using <code>select-word-style</code> the widget is
|
||
set in the context <code>:zle:*</code> to <code>true</code> if the word style is <code>bash</code>
|
||
and <code>false</code> otherwise. It may be overridden by setting it in the
|
||
more specific context <code>:zle:forward-word*</code>.</p>
|
||
<p>It is possible to create widgets with specific behaviour by defining
|
||
a new widget implemented by the appropriate generic function, then
|
||
setting a style for the context of the specific widget. For example,
|
||
the following defines a widget <code>backward-kill-space-word</code> using
|
||
<code>backward-kill-word-match</code>, the generic widget implementing
|
||
<code>backward-kill-word</code> behaviour, and ensures that the new widget
|
||
always implements space-delimited behaviour.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle -N backward-kill-space-word backward-kill-word-match
|
||
zstyle :zle:backward-kill-space-word word-style space
|
||
</code></pre>
|
||
</div>
|
||
<p>The widget <code>backward-kill-space-word</code> can now be bound to a key.</p>
|
||
<p>Here are some further examples of use of the styles, actually taken
|
||
from the simplified interface in <code>select-word-style</code>:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':zle:*' word-style standard
|
||
zstyle ':zle:*' word-chars ''
|
||
</code></pre>
|
||
</div>
|
||
<p>Implements bash-style word handling for all widgets, i.e. only
|
||
alphanumerics are word characters; equivalent to setting the
|
||
parameter <code>WORDCHARS</code> empty for the given context.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">style ':zle:*kill*' word-style space
|
||
</code></pre>
|
||
</div>
|
||
<p>Uses space-delimited words for widgets with the word ‘kill’ in the
|
||
name. Neither of the styles <code>word-chars</code> nor <code>word-class</code> is used in
|
||
this case.</p>
|
||
<p>Here are some examples of use of the <code>word-context</code> style to extend
|
||
the context.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':zle:*' word-context \
|
||
"*/*" filename "[[:space:]]" whitespace
|
||
zstyle ':zle:transpose-words:whitespace' word-style shell
|
||
zstyle ':zle:transpose-words:filename' word-style normal
|
||
zstyle ':zle:transpose-words:filename' word-chars ''
|
||
</code></pre>
|
||
</div>
|
||
<p>This provides two different ways of using <code>transpose-words</code>
|
||
depending on whether the cursor is on whitespace between words or on
|
||
a filename, here any word containing a <code>/</code>. On whitespace, complete
|
||
arguments as defined by standard shell rules will be transposed. In
|
||
a filename, only alphanumerics will be transposed. Elsewhere, words
|
||
will be transposed using the default style for
|
||
<code>:zle:transpose-words</code>.</p>
|
||
<p>The word matching and all the handling of <code>zstyle</code> settings is
|
||
actually implemented by the function <code>match-words-by-style</code>. This
|
||
can be used to create new user-defined widgets. The calling function
|
||
should set the local parameter <code>curcontext</code> to <code>:zle:``widget</code>,
|
||
create the local parameter <code>matched_words</code> and call
|
||
<code>match-words-by-style</code> with no arguments. On return, <code>matched_words</code>
|
||
will be set to an array with the elements: (1) the start of the line
|
||
(2) the word before the cursor (3) any non-word characters between
|
||
that word and the cursor (4) any non-word character at the cursor
|
||
position plus any remaining non-word characters before the next
|
||
word, including all characters specified by the <code>skip-chars</code> style,
|
||
(5) the word at or following the cursor (6) any non-word characters
|
||
following that word (7) the remainder of the line. Any of the
|
||
elements may be an empty string; the calling function should test
|
||
for this to decide whether it can perform its function.</p>
|
||
<p>If the variable <code>matched_words</code> is defined by the caller to
|
||
<code>match-words-by-style</code> as an associative array (<code>local -A matched_words</code>), then the seven values given above should be
|
||
retrieved from it as elements named <code>start</code>, <code>word-before-cursor</code>,
|
||
<code>ws-before-cursor</code>, <code>ws-after-cursor</code>, <code>word-after-cursor</code>,
|
||
<code>ws-after-word</code>, and <code>end</code>. In addition the element <code>is-word-start</code>
|
||
is 1 if the cursor is on the start of a word or subword, or on white
|
||
space before it (the cases can be distinguished by testing the
|
||
<code>ws-after-cursor</code> element) and 0 otherwise. This form is recommended
|
||
for future compatibility.</p>
|
||
<p>It is possible to pass options with arguments to
|
||
<code>match-words-by-style</code> to override the use of styles. The options
|
||
are:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-w</code><br />
|
||
<code>word-style</code></p>
|
||
</li>
|
||
<li>
|
||
<p><code>-s</code><br />
|
||
<code>skip-chars</code></p>
|
||
</li>
|
||
<li>
|
||
<p><code>-c</code><br />
|
||
<code>word-class</code></p>
|
||
</li>
|
||
<li>
|
||
<p><code>-C</code><br />
|
||
<code>word-chars</code></p>
|
||
</li>
|
||
<li>
|
||
<p><code>-r</code><br />
|
||
<code>subword-range</code></p>
|
||
</li>
|
||
</ul>
|
||
<p>For example, <code>match-words-by-style -w shell -c 0</code> may be used to
|
||
extract the command argument around the cursor.</p>
|
||
<p>The <code>word-context</code> style is implemented by the function
|
||
<code>match-word-context</code>. This should not usually need to be called
|
||
directly.</p>
|
||
<p><span id="index-bracketed_002dpaste_002dmagic"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>bracketed-paste-magic</code><br />
|
||
The <code>bracketed-paste</code> widget (see
|
||
<a href="Zsh-Line-Editor.html#Miscellaneous">Miscellaneous</a> in
|
||
<a href="Zsh-Line-Editor.html#Zle-Widgets">Widgets</a>) inserts pasted text
|
||
literally into the editor buffer rather than interpret it as
|
||
keystrokes. This disables some common usages where the self-insert
|
||
widget is replaced in order to accomplish some extra processing. An
|
||
example is the contributed <code>url-quote-magic</code> widget described below.</p>
|
||
<p>The <code>bracketed-paste-magic</code> widget is meant to replace
|
||
<code>bracketed-paste</code> with a wrapper that re-enables these self-insert
|
||
actions, and other actions as selected by zstyles. Therefore this
|
||
widget is installed with</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">autoload -Uz bracketed-paste-magic
|
||
zle -N bracketed-paste bracketed-paste-magic
|
||
</code></pre>
|
||
</div>
|
||
<p>Other than enabling some widget processing, <code>bracketed-paste-magic</code>
|
||
attempts to replicate <code>bracketed-paste</code> as faithfully as possible.</p>
|
||
<p>The following zstyles may be set to control processing of pasted
|
||
text. All are looked up in the context ‘<code>:bracketed-paste-magic</code>’.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>active-widgets</code><br />
|
||
A list of patterns matching widget names that should be
|
||
activated during the paste. All other key sequences are
|
||
processed as self-insert-unmeta. The default is ‘<code>self-*</code>’ so
|
||
any user-defined widgets named with that prefix are active along
|
||
with the builtin self-insert.</p>
|
||
<p>If this style is not set (explicitly deleted) or set to an empty
|
||
value, no widgets are active and the pasted text is inserted
|
||
literally. If the value includes ‘<code>undefined-key</code>’, any unknown
|
||
sequences are discarded from the pasted text.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>inactive-keys</code><br />
|
||
The inverse of <code>active-widgets</code>, a list of key sequences that
|
||
always use <code>self-insert-unmeta</code> even when bound to an active
|
||
widget. Note that this is a list of literal key sequences, not
|
||
patterns.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>paste-init</code><br />
|
||
A list of function names, called in widget context (but not as
|
||
widgets). The functions are called in order until one of them
|
||
returns a non-zero status. The parameter ‘<code>PASTED</code>’ contains the
|
||
initial state of the pasted text. All other ZLE parameters such
|
||
as ‘<code>BUFFER</code>’ have their normal values and side-effects, and
|
||
full history is available, so for example <code>paste-init</code> functions
|
||
may move words from <code>BUFFER</code> into <code>PASTED</code> to make those words
|
||
visible to the <code>active-widgets</code>.</p>
|
||
<p>A non-zero return from a <code>paste-init</code> function does <em>not</em>
|
||
prevent the paste itself from proceeding.</p>
|
||
<p>Loading <code>bracketed-paste-magic</code> defines <code>backward-extend-paste</code>,
|
||
a helper function for use in <code>paste-init</code>.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle :bracketed-paste-magic paste-init \
|
||
backward-extend-paste
|
||
</code></pre>
|
||
</div>
|
||
<p>When a paste would insert into the middle of a word or append
|
||
text to a word already on the line, <code>backward-extend-paste</code>
|
||
moves the prefix from <code>LBUFFER</code> into <code>PASTED</code> so that the
|
||
<code>active-widgets</code> see the full word so far. This may be useful
|
||
with <code>url-quote-magic</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>paste-finish</code><br />
|
||
Another list of function names called in order until one returns
|
||
non-zero. These functions are called <em>after</em> the pasted text has
|
||
been processed by the <code>active-widgets</code>, but <em>before</em> it is
|
||
inserted into ‘<code>BUFFER</code>’. ZLE parameters have their normal
|
||
values and side-effects.</p>
|
||
<p>A non-zero return from a <code>paste-finish</code> function does <em>not</em>
|
||
prevent the paste itself from proceeding.</p>
|
||
<p>Loading <code>bracketed-paste-magic</code> also defines <code>quote-paste</code>, a
|
||
helper function for use in <code>paste-finish</code>.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle :bracketed-paste-magic paste-finish \
|
||
quote-paste
|
||
zstyle :bracketed-paste-magic:finish quote-style \
|
||
qqq
|
||
</code></pre>
|
||
</div>
|
||
<p>When the pasted text is inserted into <code>BUFFER</code>, it is quoted per
|
||
the <code>quote-style</code> value. To forcibly turn off the built-in
|
||
numeric prefix quoting of <code>bracketed-paste</code>, use:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle :bracketed-paste-magic:finish quote-style \
|
||
none
|
||
</code></pre>
|
||
</div>
|
||
</li>
|
||
</ul>
|
||
<p><em>Important:</em> During <code>active-widgets</code> processing of the paste (after
|
||
<code>paste-init</code> and before <code>paste-finish</code>), <code>BUFFER</code> starts empty and
|
||
history is restricted, so cursor motions, etc., may not pass outside
|
||
of the pasted content. Text assigned to <code>BUFFER</code> by the active
|
||
widgets is copied back into <code>PASTED</code> before <code>paste-finish</code>.</p>
|
||
<p><span id="index-copy_002dearlier_002dword"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>copy-earlier-word</code><br />
|
||
This widget works like a combination of <code>insert-last-word</code> and
|
||
<code>copy-prev-shell-word</code>. Repeated invocations of the widget retrieve
|
||
earlier words on the relevant history line. With a numeric argument
|
||
<code>N</code>, insert the <code>N</code>th word from the history line; <code>N</code> may be
|
||
negative to count from the end of the line.</p>
|
||
<p>If <code>insert-last-word</code> has been used to retrieve the last word on a
|
||
previous history line, repeated invocations will replace that word
|
||
with earlier words from the same line.</p>
|
||
<p>Otherwise, the widget applies to words on the line currently being
|
||
edited. The <code>widget</code> style can be set to the name of another widget
|
||
that should be called to retrieve words. This widget must accept the
|
||
same three arguments as <code>insert-last-word</code>.</p>
|
||
<p><span id="index-cycle_002dcompletion_002dpositions"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>cycle-completion-positions</code><br />
|
||
After inserting an unambiguous string into the command line, the new
|
||
function based completion system may know about multiple places in
|
||
this string where characters are missing or differ from at least one
|
||
of the possible matches. It will then place the cursor on the
|
||
position it considers to be the most interesting one, i.e. the one
|
||
where one can disambiguate between as many matches as possible with
|
||
as little typing as possible.</p>
|
||
<p>This widget allows the cursor to be easily moved to the other
|
||
interesting spots. It can be invoked repeatedly to cycle between all
|
||
positions reported by the completion system.</p>
|
||
<p><span id="index-delete_002dwhole_002dword_002dmatch-1"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>delete-whole-word-match</code><br />
|
||
This is another function which works like the <code>-match</code> functions
|
||
described immediately above, i.e. using styles to decide the word
|
||
boundaries. However, it is not a replacement for any existing
|
||
function.</p>
|
||
<p>The basic behaviour is to delete the word around the cursor. There
|
||
is no numeric argument handling; only the single word around the
|
||
cursor is considered. If the widget contains the string <code>kill</code>, the
|
||
removed text will be placed in the cutbuffer for future yanking.
|
||
This can be obtained by defining <code>kill-whole-word-match</code> as follows:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle -N kill-whole-word-match delete-whole-word-match
|
||
</code></pre>
|
||
</div>
|
||
<p>and then binding the widget <code>kill-whole-word-match</code>.</p>
|
||
<p><span id="index-down_002dline_002dor_002dbeginning_002dsearch"></span>
|
||
<span id="index-up_002dline_002dor_002dbeginning_002dsearch"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>up-line-or-beginning-search</code>, <code>down-line-or-beginning-search</code><br />
|
||
These widgets are similar to the builtin functions
|
||
<code>up-line-or-search</code> and <code>down-line-or-search</code>: if in a multiline
|
||
buffer they move up or down within the buffer, otherwise they search
|
||
for a history line matching the start of the current line. In this
|
||
case, however, they search for a line which matches the current line
|
||
up to the current cursor position, in the manner of
|
||
<code>history-beginning-search-backward</code> and <code>-forward</code>, rather than the
|
||
first word on the line.</p>
|
||
<p><span id="index-edit_002dcommand_002dline"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>edit-command-line</code><br />
|
||
Edit the command line using your visual editor, as in <code>ksh</code>.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">bindkey -M vicmd v edit-command-line
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-expand_002dabsolute_002dpath"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>expand-absolute-path</code><br />
|
||
Expand the file name under the cursor to an absolute path, resolving
|
||
symbolic links. Where possible, the initial path segment is turned
|
||
into a named directory or reference to a user’s home directory.</p>
|
||
<p><span id="index-history_002dbeginning_002dsearch_002dbackward_002dend"></span>
|
||
<span id="index-history_002dbeginning_002dsearch_002dforward_002dend"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>history-search-end</code><br />
|
||
This function implements the widgets
|
||
<code>history-beginning-search-backward-end</code> and
|
||
<code>history-beginning-search-forward-end</code>. These commands work by first
|
||
calling the corresponding builtin widget (see <a href="Zsh-Line-Editor.html#History-Control">History
|
||
Control</a>) and then moving the
|
||
cursor to the end of the line. The original cursor position is
|
||
remembered and restored before calling the builtin widget a second
|
||
time, so that the same search is repeated to look farther through
|
||
the history.</p>
|
||
<p>Although you <code>autoload</code> only one function, the commands to use it
|
||
are slightly different because it implements two widgets.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle -N history-beginning-search-backward-end \
|
||
history-search-end
|
||
zle -N history-beginning-search-forward-end \
|
||
history-search-end
|
||
bindkey '\e^P' history-beginning-search-backward-end
|
||
bindkey '\e^N' history-beginning-search-forward-end
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-history_002dbeginning_002dsearch_002dmenu"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>history-beginning-search-menu</code><br />
|
||
This function implements yet another form of history searching. The
|
||
text before the cursor is used to select lines from the history, as
|
||
for <code>history-beginning-search-backward</code> except that all matches are
|
||
shown in a numbered menu. Typing the appropriate digits inserts the
|
||
full history line. Note that leading zeroes must be typed (they are
|
||
only shown when necessary for removing ambiguity). The entire
|
||
history is searched; there is no distinction between forwards and
|
||
backwards.</p>
|
||
<p>With a numeric argument, the search is not anchored to the start of
|
||
the line; the string typed by the use may appear anywhere in the
|
||
line in the history.</p>
|
||
<p>If the widget name contains ‘<code>-end</code>’ the cursor is moved to the end
|
||
of the line inserted. If the widget name contains ‘<code>-space</code>’ any
|
||
space in the text typed is treated as a wildcard and can match
|
||
anything (hence a leading space is equivalent to giving a numeric
|
||
argument). Both forms can be combined, for example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle -N history-beginning-search-menu-space-end \
|
||
history-beginning-search-menu
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-history_002dpattern_002dsearch"></span>
|
||
<span id="index-history_002dpattern_002dsearch_002dbackward"></span>
|
||
<span id="index-history_002dpattern_002dsearch_002dforward"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>history-pattern-search</code><br />
|
||
The function <code>history-pattern-search</code> implements widgets which
|
||
prompt for a pattern with which to search the history backwards or
|
||
forwards. The pattern is in the usual zsh format, however the first
|
||
character may be <code>^</code> to anchor the search to the start of the line,
|
||
and the last character may be <code>$</code> to anchor the search to the end of
|
||
the line. If the search was not anchored to the end of the line the
|
||
cursor is positioned just after the pattern found.</p>
|
||
<p>The commands to create bindable widgets are similar to those in the
|
||
example immediately above:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">autoload -U history-pattern-search
|
||
zle -N history-pattern-search-backward history-pattern-search
|
||
zle -N history-pattern-search-forward history-pattern-search
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-incarg"></span>
|
||
<span id="index-incarg_002c-use-of"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>incarg</code><br />
|
||
Typing the keystrokes for this widget with the cursor placed on or
|
||
to the left of an integer causes that integer to be incremented by
|
||
one. With a numeric argument, the number is incremented by the
|
||
amount of the argument (decremented if the numeric argument is
|
||
negative). The shell parameter <code>incarg</code> may be set to change the
|
||
default increment to something other than one.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">bindkey '^X+' incarg
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-incremental_002dcomplete_002dword"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>incremental-complete-word</code><br />
|
||
This allows incremental completion of a word. After starting this
|
||
command, a list of completion choices can be shown after every
|
||
character you type, which you can delete with <code>^H</code> or <code>DEL</code>.
|
||
Pressing return accepts the completion so far and returns you to
|
||
normal editing (that is, the command line is <em>not</em> immediately
|
||
executed). You can hit <code>TAB</code> to do normal completion, <code>^G</code> to abort
|
||
back to the state when you started, and <code>^D</code> to list the matches.</p>
|
||
<p>This works only with the new function based completion system.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">bindkey '^Xi' incremental-complete-word
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-insert_002dcomposed_002dchar"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>insert-composed-char</code><br />
|
||
This function allows you to compose characters that don’t appear on
|
||
the keyboard to be inserted into the command line. The command is
|
||
followed by two keys corresponding to ASCII characters (there is no
|
||
prompt). For accented characters, the two keys are a base character
|
||
followed by a code for the accent, while for other special
|
||
characters the two characters together form a mnemonic for the
|
||
character to be inserted. The two-character codes are a subset of
|
||
those given by RFC 1345 (see for example
|
||
<code>http://www.faqs.org/rfcs/rfc1345.html</code>).</p>
|
||
<p>The function may optionally be followed by up to two characters
|
||
which replace one or both of the characters read from the keyboard;
|
||
if both characters are supplied, no input is read. For example,
|
||
<code>insert-composed-char a:</code> can be used within a widget to insert an a
|
||
with umlaut into the command line. This has the advantages over use
|
||
of a</p>
|
||
<p>For best results zsh should have been built with support for
|
||
multibyte characters (configured with <code>–enable-multibyte</code>); however,
|
||
the function works for the limited range of characters available in
|
||
single-byte character sets such as ISO-8859-1.</p>
|
||
<p>The character is converted into the local representation and
|
||
inserted into the command line at the cursor position. (The
|
||
conversion is done within the shell, using whatever facilities the C
|
||
library provides.) With a numeric argument, the character and its
|
||
code are previewed in the status line</p>
|
||
<p>The function may be run outside zle in which case it prints the
|
||
character (together with a newline) to standard output. Input is
|
||
still read from keystrokes.</p>
|
||
<p>See <code>insert-unicode-char</code> for an alternative way of inserting
|
||
Unicode characters using their hexadecimal character number.</p>
|
||
<p>The set of accented characters is reasonably complete up to Unicode
|
||
character U+0180, the set of special characters less so. However, it
|
||
is very sporadic from that point. Adding new characters is easy,
|
||
however; see the function <code>define-composed-chars</code>. Please send any
|
||
additions to <code>zsh-workers@zsh.org</code>.</p>
|
||
<p>The codes for the second character when used to accent the first are
|
||
as follows. Note that not every character can take every accent.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>!</code><br />
|
||
Grave.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>’</code><br />
|
||
Acute.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>></code><br />
|
||
Circumflex.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>?</code><br />
|
||
Tilde. (This is not <code>~</code> as RFC 1345 does not assume that
|
||
character is present on the keyboard.)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-</code><br />
|
||
Macron. (A horizontal bar over the base character.)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>(</code><br />
|
||
Breve. (A shallow dish shape over the base character.)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>.</code><br />
|
||
Dot above the base character, or in the case of <code>i</code> no dot, or
|
||
in the case of <code>L</code> and <code>l</code> a centered dot.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>:</code><br />
|
||
Diaeresis (Umlaut).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>c</code><br />
|
||
Cedilla.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>_</code><br />
|
||
Underline, however there are currently no underlined characters.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>/</code><br />
|
||
Stroke through the base character.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>"</code><br />
|
||
Double acute (only supported on a few letters).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>;</code><br />
|
||
Ogonek. (A little forward facing hook at the bottom right of the
|
||
character.)</p>
|
||
</li>
|
||
<li>
|
||
<p><code><</code><br />
|
||
Caron. (A little v over the letter.)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>0</code><br />
|
||
Circle over the base character.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>2</code><br />
|
||
Hook over the base character.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>9</code><br />
|
||
Horn over the base character.</p>
|
||
</li>
|
||
</ul>
|
||
<p>The most common characters from the Arabic, Cyrillic, Greek and
|
||
Hebrew alphabets are available; consult RFC 1345 for the appropriate
|
||
sequences. In addition, a set of two letter codes not in RFC 1345
|
||
are available for the double-width characters corresponding to ASCII
|
||
characters from <code>!</code> to <code>~</code> (0x21 to 0x7e) by preceding the character
|
||
with <code>^</code>, for example <code>^A</code> for a double-width <code>A</code>.</p>
|
||
<p>The following other two-character sequences are understood.</p>
|
||
<ul>
|
||
<li>
|
||
<p>ASCII characters<br />
|
||
These are already present on most keyboards:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code><(</code><br />
|
||
Left square bracket</p>
|
||
</li>
|
||
<li>
|
||
<p><code>//</code><br />
|
||
Backslash (solidus)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>)></code><br />
|
||
Right square bracket</p>
|
||
</li>
|
||
<li>
|
||
<p><code>(!</code><br />
|
||
Left brace (curly bracket)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>!!</code><br />
|
||
Vertical bar (pipe symbol)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>!)</code><br />
|
||
Right brace (curly bracket)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>’?</code><br />
|
||
Tilde</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p>Special letters<br />
|
||
Characters found in various variants of the Latin alphabet:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>ss</code><br />
|
||
Eszett (scharfes S)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>D-</code>, <code>d-</code><br />
|
||
Eth</p>
|
||
</li>
|
||
<li>
|
||
<p><code>TH</code>, <code>th</code><br />
|
||
Thorn</p>
|
||
</li>
|
||
<li>
|
||
<p><code>kk</code><br />
|
||
Kra</p>
|
||
</li>
|
||
<li>
|
||
<p><code>’n</code><br />
|
||
’n</p>
|
||
</li>
|
||
<li>
|
||
<p><code>NG</code>, <code>ng</code><br />
|
||
Ng</p>
|
||
</li>
|
||
<li>
|
||
<p><code>OI</code>, <code>oi</code><br />
|
||
Oi</p>
|
||
</li>
|
||
<li>
|
||
<p><code>yr</code><br />
|
||
yr</p>
|
||
</li>
|
||
<li>
|
||
<p><code>ED</code><br />
|
||
ezh</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p>Currency symbols</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>Ct</code><br />
|
||
Cent</p>
|
||
</li>
|
||
<li>
|
||
<p><code>Pd</code><br />
|
||
Pound sterling (also lira and others)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>Cu</code><br />
|
||
Currency</p>
|
||
</li>
|
||
<li>
|
||
<p><code>Ye</code><br />
|
||
Yen</p>
|
||
</li>
|
||
<li>
|
||
<p><code>Eu</code><br />
|
||
Euro (N.B. not in RFC 1345)</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p>Punctuation characters<br />
|
||
References to "right" quotes indicate the shape (like a 9 rather
|
||
than 6) rather than their grammatical use. (For example, a
|
||
"right" low double quote is used to open quotations in German.)</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>!I</code><br />
|
||
Inverted exclamation mark</p>
|
||
</li>
|
||
<li>
|
||
<p><code>BB</code><br />
|
||
Broken vertical bar</p>
|
||
</li>
|
||
<li>
|
||
<p><code>SE</code><br />
|
||
Section</p>
|
||
</li>
|
||
<li>
|
||
<p><code>Co</code><br />
|
||
Copyright</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-a</code><br />
|
||
Spanish feminine ordinal indicator</p>
|
||
</li>
|
||
<li>
|
||
<p><code><<</code><br />
|
||
Left guillemet</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-``-</code><br />
|
||
Soft hyphen</p>
|
||
</li>
|
||
<li>
|
||
<p><code>Rg</code><br />
|
||
Registered trade mark</p>
|
||
</li>
|
||
<li>
|
||
<p><code>PI</code><br />
|
||
Pilcrow (paragraph)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-o</code><br />
|
||
Spanish masculine ordinal indicator</p>
|
||
</li>
|
||
<li>
|
||
<p><code>>></code><br />
|
||
Right guillemet</p>
|
||
</li>
|
||
<li>
|
||
<p><code>?I</code><br />
|
||
Inverted question mark</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-1</code><br />
|
||
Hyphen</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-N</code><br />
|
||
En dash</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-M</code><br />
|
||
Em dash</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-3</code><br />
|
||
Horizontal bar</p>
|
||
</li>
|
||
<li>
|
||
<p><code>:3</code><br />
|
||
Vertical ellipsis</p>
|
||
</li>
|
||
<li>
|
||
<p><code>.3</code><br />
|
||
Horizontal midline ellipsis</p>
|
||
</li>
|
||
<li>
|
||
<p><code>!2</code><br />
|
||
Double vertical line</p>
|
||
</li>
|
||
<li>
|
||
<p><code>=2</code><br />
|
||
Double low line</p>
|
||
</li>
|
||
<li>
|
||
<p><code>’6</code><br />
|
||
Left single quote</p>
|
||
</li>
|
||
<li>
|
||
<p><code>’9</code><br />
|
||
Right single quote</p>
|
||
</li>
|
||
<li>
|
||
<p><code>.9</code><br />
|
||
"Right" low quote</p>
|
||
</li>
|
||
<li>
|
||
<p><code>9’</code><br />
|
||
Reversed "right" quote</p>
|
||
</li>
|
||
<li>
|
||
<p><code>"6</code><br />
|
||
Left double quote</p>
|
||
</li>
|
||
<li>
|
||
<p><code>"9</code><br />
|
||
Right double quote</p>
|
||
</li>
|
||
<li>
|
||
<p><code>:9</code><br />
|
||
"Right" low double quote</p>
|
||
</li>
|
||
<li>
|
||
<p><code>9"</code><br />
|
||
Reversed "right" double quote</p>
|
||
</li>
|
||
<li>
|
||
<p><code>/-</code><br />
|
||
Dagger</p>
|
||
</li>
|
||
<li>
|
||
<p><code>/=</code><br />
|
||
Double dagger</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p>Mathematical symbols</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>DG</code><br />
|
||
Degree</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-2</code>, <code>+-</code>, <code>-+</code><br />
|
||
- sign, +/- sign, -/+ sign</p>
|
||
</li>
|
||
<li>
|
||
<p><code>2S</code><br />
|
||
Superscript 2</p>
|
||
</li>
|
||
<li>
|
||
<p><code>3S</code><br />
|
||
Superscript 3</p>
|
||
</li>
|
||
<li>
|
||
<p><code>1S</code><br />
|
||
Superscript 1</p>
|
||
</li>
|
||
<li>
|
||
<p><code>My</code><br />
|
||
Micro</p>
|
||
</li>
|
||
<li>
|
||
<p><code>.M</code><br />
|
||
Middle dot</p>
|
||
</li>
|
||
<li>
|
||
<p><code>14</code><br />
|
||
Quarter</p>
|
||
</li>
|
||
<li>
|
||
<p><code>12</code><br />
|
||
Half</p>
|
||
</li>
|
||
<li>
|
||
<p><code>34</code><br />
|
||
Three quarters</p>
|
||
</li>
|
||
<li>
|
||
<p><code>*X</code><br />
|
||
Multiplication</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-:</code><br />
|
||
Division</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%0</code><br />
|
||
Per mille</p>
|
||
</li>
|
||
<li>
|
||
<p><code>FA</code>, <code>TE</code>, <code>/0</code><br />
|
||
For all, there exists, empty set</p>
|
||
</li>
|
||
<li>
|
||
<p><code>dP</code>, <code>DE</code>, <code>NB</code><br />
|
||
Partial derivative, delta (increment), del (nabla)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>(-</code>, <code>-)</code><br />
|
||
Element of, contains</p>
|
||
</li>
|
||
<li>
|
||
<p><code>*P</code>, <code>+Z</code><br />
|
||
Product, sum</p>
|
||
</li>
|
||
<li>
|
||
<p><code>*-</code>, <code>Ob</code>, <code>Sb</code><br />
|
||
Asterisk, ring, bullet</p>
|
||
</li>
|
||
<li>
|
||
<p><code>RT</code>, <code>0(</code>, <code>00</code><br />
|
||
Root sign, proportional to, infinity</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p>Other symbols</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>cS</code>, <code>cH</code>, <code>cD</code>, <code>cC</code><br />
|
||
Card suits: spades, hearts, diamonds, clubs</p>
|
||
</li>
|
||
<li>
|
||
<p><code>Md</code>, <code>M8</code>, <code>M2</code>, <code>Mb</code>, <code>Mx</code>, <code>MX</code><br />
|
||
Musical notation: crotchet (quarter note), quaver (eighth
|
||
note), semiquavers (sixteenth notes), flag sign, natural
|
||
sign, sharp sign</p>
|
||
</li>
|
||
<li>
|
||
<p><code>Fm</code>, <code>Ml</code><br />
|
||
Female, male</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>
|
||
<p>Accents on their own</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>’></code><br />
|
||
Circumflex (same as caret, <code>^</code>)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>’!</code><br />
|
||
Grave (same as backtick, <code>‘</code>)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>’,</code><br />
|
||
Cedilla</p>
|
||
</li>
|
||
<li>
|
||
<p><code>’:</code><br />
|
||
Diaeresis (Umlaut)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>’m</code><br />
|
||
Macron</p>
|
||
</li>
|
||
<li>
|
||
<p><code>”</code><br />
|
||
Acute</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<p><span id="index-insert_002dfiles"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>insert-files</code><br />
|
||
This function allows you type a file pattern, and see the results of
|
||
the expansion at each step. When you hit return, all expansions are
|
||
inserted into the command line.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">bindkey '^Xf' insert-files
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-insert_002dunicode_002dchar"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>insert-unicode-char</code><br />
|
||
When first executed, the user inputs a set of hexadecimal digits.
|
||
This is terminated with another call to <code>insert-unicode-char</code>. The
|
||
digits are then turned into the corresponding Unicode character. For
|
||
example, if the widget is bound to <code>^XU</code>, the character sequence
|
||
‘<code>^XU 4 c ^XU</code>’ inserts <code>L</code> (Unicode U+004c).</p>
|
||
<p>See <code>insert-composed-char</code> for a way of inserting characters using a
|
||
two-character mnemonic.</p>
|
||
<p><span id="index-narrow_002dto_002dregion"></span>
|
||
<span id="index-narrow_002dto_002dregion_002dinvisible"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>narrow-to-region </code>[ <code>-p</code> <code>pre</code> ] [ <code>-P</code> <code>post</code> ]<br />
|
||
<code> </code>[ <code>-S</code> <code>statepm</code> | <code>-R</code> <code>statepm</code> | [ <code>-l</code>
|
||
<code>lbufvar</code> ] [ <code>-r</code> <code>rbufvar</code> ] ]<br />
|
||
<code> </code>[ <code>-n</code> ] [ <code>start</code> <code>end</code> ]<br />
|
||
<code>narrow-to-region-invisible</code><br />
|
||
<code>predict-on</code><br />
|
||
This set of functions implements predictive typing using history
|
||
search. After <code>predict-on</code>, typing characters causes the editor to
|
||
look backward in the history for the first line beginning with what
|
||
you have typed so far. After <code>predict-off</code>, editing returns to
|
||
normal for the line found. In fact, you often don’t even need to use
|
||
<code>predict-off</code>, because if the line doesn’t match something in the
|
||
history, adding a key performs standard completion, and then inserts
|
||
itself if no completions were found. However, editing in the middle
|
||
of a line is liable to confuse prediction; see the <code>toggle</code> style
|
||
below.</p>
|
||
<p>With the function based completion system (which is needed for
|
||
this), you should be able to type <code>TAB</code> at almost any point to
|
||
advance the cursor to the next ‘‘interesting’’ character position
|
||
(usually the end of the current word, but sometimes somewhere in the
|
||
middle of the word). And of course as soon as the entire line is
|
||
what you want, you can accept with return, without needing to move
|
||
the cursor to the end first.</p>
|
||
<p>The first time <code>predict-on</code> is used, it creates several additional
|
||
widget functions:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>delete-backward-and-predict</code><br />
|
||
Replaces the <code>backward-delete-char</code> widget. You do not need to
|
||
bind this yourself.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>insert-and-predict</code><br />
|
||
Implements predictive typing by replacing the <code>self-insert</code>
|
||
widget. You do not need to bind this yourself.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>predict-off</code><br />
|
||
Turns off predictive typing.</p>
|
||
</li>
|
||
</ul>
|
||
<p>Although you <code>autoload</code> only the <code>predict-on</code> function, it is
|
||
necessary to create a keybinding for <code>predict-off</code> as well.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle -N predict-on
|
||
zle -N predict-off
|
||
bindkey '^X^Z' predict-on
|
||
bindkey '^Z' predict-off
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-read_002dfrom_002dminibuffer"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>read-from-minibuffer</code><br />
|
||
This is most useful when called as a function from inside a widget,
|
||
but will work correctly as a widget in its own right. It prompts for
|
||
a value below the current command line; a value may be input using
|
||
all of the standard zle operations (and not merely the restricted
|
||
set available when executing, for example, <code>execute-named-cmd</code>). The
|
||
value is then returned to the calling function in the parameter
|
||
<code>$REPLY</code> and the editing buffer restored to its previous state. If
|
||
the read was aborted by a keyboard break (typically <code>^G</code>), the
|
||
function returns status 1 and <code>$REPLY</code> is not set.</p>
|
||
<p>If one argument is supplied to the function it is taken as a prompt,
|
||
otherwise ‘<code>? </code>’ is used. If two arguments are supplied, they are
|
||
the prompt and the initial value of <code>$LBUFFER</code>, and if a third
|
||
argument is given it is the initial value of <code>$RBUFFER</code>. This
|
||
provides a default value and starting cursor placement. Upon return
|
||
the entire buffer is the value of <code>$REPLY</code>.</p>
|
||
<p>One option is available: ‘<code>-k</code> <code>num</code>’ specifies that <code>num</code>
|
||
characters are to be read instead of a whole line. The line editor
|
||
is not invoked recursively in this case, so depending on the
|
||
terminal settings the input may not be visible, and only the input
|
||
keys are placed in <code>$REPLY</code>, not the entire buffer. Note that unlike
|
||
the <code>read</code> builtin <code>num</code> must be given; there is no default.</p>
|
||
<p>The name is a slight misnomer, as in fact the shell’s own minibuffer
|
||
is not used. Hence it is still possible to call <code>executed-named-cmd</code>
|
||
and similar functions while reading a value.</p>
|
||
<p><span id="index-replace_002dargument"></span>
|
||
<span id="index-replace_002dargument_002dedit"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>replace-argument</code>, <code>replace-argument-edit</code><br />
|
||
The function <code>replace-argument</code> can be used to replace a command
|
||
line argument in the current command line or, if the current command
|
||
line is empty, in the last command line executed (the new command
|
||
line is not executed). Arguments are as delimited by standard shell
|
||
syntax,</p>
|
||
<p>If a numeric argument is given, that specifies the argument to be
|
||
replaced. 0 means the command name, as in history expansion. A
|
||
negative numeric argument counts backward from the last word.</p>
|
||
<p>If no numeric argument is given, the current argument is replaced;
|
||
this is the last argument if the previous history line is being
|
||
used.</p>
|
||
<p>The function prompts for a replacement argument.</p>
|
||
<p>If the widget contains the string <code>edit</code>, for example is defined as</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle -N replace-argument-edit replace-argument
|
||
</code></pre>
|
||
</div>
|
||
<p>then the function presents the current value of the argument for
|
||
editing, otherwise the editing buffer for the replacement is
|
||
initially empty.</p>
|
||
<p><span id="index-replace_002dstring"></span>
|
||
<span id="index-replace_002dstring_002dagain"></span>
|
||
<span id="index-replace_002dpattern"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>replace-string</code>, <code>replace-pattern</code><br />
|
||
<code>replace-string-again</code>, <code>replace-pattern-again</code><br />
|
||
The function <code>replace-string</code> implements three widgets. If defined
|
||
under the same name as the function, it prompts for two strings; the
|
||
first (source) string will be replaced by the second everywhere it
|
||
occurs in the line editing buffer.</p>
|
||
<p>If the widget name contains the word ‘<code>pattern</code>’, for example by
|
||
defining the widget using the command ‘<code>zle -N replace-pattern replace-string</code>’, then the matching is performed using zsh patterns.
|
||
All zsh extended globbing patterns can be used in the source string;
|
||
note that unlike filename generation the pattern does not need to
|
||
match an entire word, nor do glob qualifiers have any effect. In
|
||
addition, the replacement string can contain parameter or command
|
||
substitutions. Furthermore, a ‘<code>&</code>’ in the replacement string will
|
||
be replaced with the matched source string, and a backquoted digit
|
||
‘<code>\``N</code>’ will be replaced by the <code>N</code>th parenthesised expression
|
||
matched. The form ‘<code>\{``N``}</code>’ may be used to protect the digit from
|
||
following digits.</p>
|
||
<p>If the widget instead contains the word ‘<code>regex</code>’ (or ‘<code>regexp</code>’),
|
||
then the matching is performed using regular expressions, respecting
|
||
the setting of the option <code>RE_MATCH_PCRE</code> (see the description of
|
||
the function <code>regexp-replace</code> below). The special replacement
|
||
facilities described above for pattern matching are available.</p>
|
||
<p>By default the previous source or replacement string will not be
|
||
offered for editing. However, this feature can be activated by
|
||
setting the style <code>edit-previous</code> in the context <code>:zle:``widget</code>
|
||
(for example, <code>:zle:replace-string</code>) to <code>true</code>. In addition, a
|
||
positive numeric argument forces the previous values to be offered,
|
||
a negative or zero argument forces them not to be.</p>
|
||
<p>The function <code>replace-string-again</code> can be used to repeat the
|
||
previous replacement; no prompting is done. As with
|
||
<code>replace-string</code>, if the name of the widget contains the word
|
||
‘<code>pattern</code>’ or ‘<code>regex</code>’, pattern or regular expression matching
|
||
is performed, else a literal string replacement. Note that the
|
||
previous source and replacement text are the same whether pattern,
|
||
regular expression or string matching is used.</p>
|
||
<p>In addition, <code>replace-string</code> shows the previous replacement above
|
||
the prompt, so long as there was one during the current session; if
|
||
the source string is empty, that replacement will be repeated
|
||
without the widget prompting for a replacement string.</p>
|
||
<p>For example, starting from the line:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">print This line contains fan and fond
|
||
</code></pre>
|
||
</div>
|
||
<p>and invoking <code>replace-pattern</code> with the source string ‘<code>f(?)n</code>’ and
|
||
the replacement string ‘<code>c\1r</code>’ produces the not very useful line:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">print This line contains car and cord
|
||
</code></pre>
|
||
</div>
|
||
<p>The range of the replacement string can be limited by using the
|
||
<code>narrow-to-region-invisible</code> widget. One limitation of the current
|
||
version is that <code>undo</code> will cycle through changes to the replacement
|
||
and source strings before undoing the replacement itself.</p>
|
||
<p><span id="index-send_002dinvisible"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>send-invisible</code><br />
|
||
This is similar to read-from-minibuffer in that it may be called as
|
||
a function from a widget or as a widget of its own, and
|
||
interactively reads input from the keyboard. However, the input
|
||
being typed is concealed and a string of asterisks (‘<code>*</code>’) is shown
|
||
instead. The value is saved in the parameter <code>$INVISIBLE</code> to which a
|
||
reference is inserted into the editing buffer at the restored cursor
|
||
position. If the read was aborted by a keyboard break (typically
|
||
<code>^G</code>) or another escape from editing such as <code>push-line</code>,
|
||
<code>$INVISIBLE</code> is set to empty and the original buffer is restored
|
||
unchanged.</p>
|
||
<p>If one argument is supplied to the function it is taken as a prompt,
|
||
otherwise ‘<code>Non-echoed text: </code>’ is used (as in emacs). If a second
|
||
and third argument are supplied they are used to begin and end the
|
||
reference to <code>$INVISIBLE</code> that is inserted into the buffer. The
|
||
default is to open with <code>${</code>, then <code>INVISIBLE</code>, and close with <code>}</code>,
|
||
but many other effects are possible.</p>
|
||
<p><span id="index-smart_002dinsert_002dlast_002dword"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>smart-insert-last-word</code><br />
|
||
This function may replace the <code>insert-last-word</code> widget, like so:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle -N insert-last-word smart-insert-last-word
|
||
</code></pre>
|
||
</div>
|
||
<p>With a numeric argument, or when passed command line arguments in a
|
||
call from another widget, it behaves like <code>insert-last-word</code>, except
|
||
that words in comments are ignored when <code>INTERACTIVE_COMMENTS</code> is
|
||
set.</p>
|
||
<p>Otherwise, the rightmost ‘‘interesting’’ word from the previous
|
||
command is found and inserted. The default definition of
|
||
‘‘interesting’’ is that the word contains at least one
|
||
alphabetic character, slash, or backslash. This definition may be
|
||
overridden by use of the <code>match</code> style. The context used to look up
|
||
the style is the widget name, so usually the context is
|
||
<code>:insert-last-word</code>. However, you can bind this function to
|
||
different widgets to use different patterns:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zle -N insert-last-assignment smart-insert-last-word
|
||
zstyle :insert-last-assignment match '[[:alpha:]][][[:alnum:]]#=*'
|
||
bindkey '\e=' insert-last-assignment
|
||
</code></pre>
|
||
</div>
|
||
<p>If no interesting word is found and the <code>auto-previous</code> style is set
|
||
to a true value, the search continues upward through the history.
|
||
When <code>auto-previous</code> is unset or false (the default), the widget
|
||
must be invoked repeatedly in order to search earlier history lines.</p>
|
||
<p><span id="index-transpose_002dlines"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>transpose-lines</code><br />
|
||
Only useful with a multi-line editing buffer; the lines here are
|
||
lines within the current on-screen buffer, not history lines. The
|
||
effect is similar to the function of the same name in Emacs.</p>
|
||
<p>Transpose the current line with the previous line and move the
|
||
cursor to the start of the next line. Repeating this (which can be
|
||
done by providing a positive numeric argument) has the effect of
|
||
moving the line above the cursor down by a number of lines.</p>
|
||
<p>With a negative numeric argument, requires two lines above the
|
||
cursor. These two lines are transposed and the cursor moved to the
|
||
start of the previous line. Using a numeric argument less than -1
|
||
has the effect of moving the line above the cursor up by minus that
|
||
number of lines.</p>
|
||
<p><span id="index-url_002dquote_002dmagic"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>url-quote-magic</code><br />
|
||
This widget replaces the built-in <code>self-insert</code> to make it easier to
|
||
type URLs as command line arguments. As you type, the input
|
||
character is analyzed and, if it may need quoting, the current word
|
||
is checked for a URI scheme. If one is found and the current word is
|
||
not already in quotes, a backslash is inserted before the input
|
||
character.</p>
|
||
<p>Styles to control quoting behavior:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>url-metas</code><br />
|
||
This style is looked up in the context
|
||
‘<code>:url-quote-magic:``scheme</code>’ (where <code>scheme</code> is that of the
|
||
current URL, e.g. "<code>ftp</code>"). The value is a string listing the
|
||
characters to be treated as globbing metacharacters when
|
||
appearing in a URL using that scheme. The default is to quote
|
||
all zsh extended globbing characters, excluding ’<code><</code>’ and ’<code>></code>’
|
||
but including braces (as in brace expansion). See also
|
||
<code>url-seps</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>url-seps</code><br />
|
||
Like <code>url-metas</code>, but lists characters that should be considered
|
||
command separators, redirections, history references, etc. The
|
||
default is to quote the standard set of shell separators,
|
||
excluding those that overlap with the extended globbing
|
||
characters, but including ’<code><</code>’ and ’<code>></code>’ and the first
|
||
character of <code>$histchars</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>url-globbers</code><br />
|
||
This style is looked up in the context ‘<code>:url-quote-magic</code>’. The
|
||
values form a list of command names that are expected to do
|
||
their own globbing on the URL string. This implies that they are
|
||
aliased to use the ‘<code>noglob</code>’ modifier. When the first word on
|
||
the line matches one of the values <em>and</em> the URL refers to a
|
||
local file (see <code>url-local-schema</code>), only the <code>url-seps</code>
|
||
characters are quoted; the <code>url-metas</code> are left alone, allowing
|
||
them to affect command-line parsing, completion, etc. The
|
||
default values are a literal ‘<code>noglob</code>’ plus (when the
|
||
<code>zsh/parameter</code> module is available) any commands aliased to the
|
||
helper function ‘<code>urlglobber</code>’ or its alias ‘<code>globurl</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>url-local-schema</code><br />
|
||
This style is always looked up in the context ‘<code>:urlglobber</code>’,
|
||
even though it is used by both url-quote-magic and urlglobber.
|
||
The values form a list of URI schema that should be treated as
|
||
referring to local files by their real local path names, as
|
||
opposed to files which are specified relative to a
|
||
web-server-defined document root. The defaults are "<code>ftp</code>" and
|
||
"<code>file</code>".</p>
|
||
</li>
|
||
<li>
|
||
<p><code>url-other-schema</code><br />
|
||
Like <code>url-local-schema</code>, but lists all other URI schema upon
|
||
which <code>urlglobber</code> and <code>url-quote-magic</code> should act. If the URI
|
||
on the command line does not have a scheme appearing either in
|
||
this list or in <code>url-local-schema</code>, it is not magically quoted.
|
||
The default values are "<code>http</code>", "<code>https</code>", and "<code>ftp</code>". When a
|
||
scheme appears both here and in <code>url-local-schema</code>, it is quoted
|
||
differently depending on whether the command name appears in
|
||
<code>url-globbers</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<p>Loading <code>url-quote-magic</code> also defines a helper function
|
||
‘<code>urlglobber</code>’ and aliases ‘<code>globurl</code>’ to ‘<code>noglob urlglobber</code>’.
|
||
This function takes a local URL apart, attempts to pattern-match the
|
||
local file portion of the URL path, and then puts the results back
|
||
into URL format again.</p>
|
||
<p><span id="index-vi_002dpipe"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>vi-pipe</code><br />
|
||
This function reads a movement command from the keyboard and then
|
||
prompts for an external command. The part of the buffer covered by
|
||
the movement is piped to the external command and then replaced by
|
||
the command’s output. If the movement command is bound to vi-pipe,
|
||
the current line is used.</p>
|
||
<p>The function serves as an example for reading a vi movement command
|
||
from within a user-defined widget.</p>
|
||
<p><span id="index-which_002dcommand-1"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>which-command</code><br />
|
||
This function is a drop-in replacement for the builtin widget
|
||
<code>which-command</code>. It has enhanced behaviour, in that it correctly
|
||
detects whether or not the command word needs to be expanded as an
|
||
alias; if so, it continues tracing the command word from the
|
||
expanded alias until it reaches the command that will be executed.</p>
|
||
<p>The style <code>whence</code> is available in the context <code>:zle:$WIDGET</code>; this
|
||
may be set to an array to give the command and options that will be
|
||
used to investigate the command word found. The default is <code>whence -c</code>.</p>
|
||
<p><span id="index-zcalc_002dauto_002dinsert"></span></p>
|
||
</li>
|
||
<li>
|
||
<p><code>zcalc-auto-insert</code><br />
|
||
This function is useful together with the <code>zcalc</code> function described
|
||
in <a href="User-Contributions.html#Mathematical-Functions">Mathematical Functions</a>. It should be
|
||
bound to a key representing a binary operator such as ‘<code>+</code>’, ‘<code>-</code>’,
|
||
‘<code>*</code>’ or ‘<code>/</code>’. When running in zcalc, if the key occurs at the
|
||
start of the line or immediately following an open parenthesis, the
|
||
text <code>"ans "</code> is inserted before the representation of the key
|
||
itself. This allows easy use of the answer from the previous
|
||
calculation in the current line. The text to be inserted before the
|
||
symbol typed can be modified by setting the variable
|
||
<code>ZCALC_AUTO_INSERT_PREFIX</code>.</p>
|
||
<p>Hence, for example, typing ‘<code>+12</code>’ followed by return adds 12 to the
|
||
previous result.</p>
|
||
<p>If zcalc is in RPN mode (<code>-r</code> option) the effect of this binding is
|
||
automatically suppressed as operators alone on a line are
|
||
meaningful.</p>
|
||
<p>When not in zcalc, the key simply inserts the symbol itself.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Utility-Functions"></span></p>
|
||
<h3 id="2672-utility-functions"><a class="header" href="#2672-utility-functions">26.7.2 Utility Functions</a></h3>
|
||
<p>These functions are useful in constructing widgets. They should be
|
||
loaded with ‘<code>autoload -U</code> <code>function</code>’ and called as indicated from
|
||
user-defined widgets.</p>
|
||
<p><span id="index-split_002dshell_002darguments"></span></p>
|
||
<p><code>split-shell-arguments</code></p>
|
||
<p>This function splits the line currently being edited into shell
|
||
arguments and whitespace. The result is stored in the array <code>reply</code>. The
|
||
array contains all the parts of the line in order, starting with any
|
||
whitespace before the first argument, and finishing with any whitespace
|
||
after the last argument. Hence (so long as the option <code>KSH_ARRAYS</code> is
|
||
not set) whitespace is given by odd indices in the array and arguments
|
||
by even indices. Note that no stripping of quotes is done; joining
|
||
together all the elements of <code>reply</code> in order is guaranteed to produce
|
||
the original line.</p>
|
||
<p>The parameter <code>REPLY</code> is set to the index of the word in <code>reply</code> which
|
||
contains the character after the cursor, where the first element has
|
||
index 1. The parameter <code>REPLY2</code> is set to the index of the character
|
||
under the cursor in that word, where the first character has index 1.</p>
|
||
<p>Hence <code>reply</code>, <code>REPLY</code> and <code>REPLY2</code> should all be made local to the
|
||
enclosing function.</p>
|
||
<p>See the function <code>modify-current-argument</code>, described below, for an
|
||
example of how to call this function.</p>
|
||
<p><span id="index-modify_002dcurrent_002dargument"></span></p>
|
||
<p><code>modify-current-argument</code> [ <code>expr-using-``$ARG</code> | <code>func</code> ]</p>
|
||
<p>This function provides a simple method of allowing user-defined widgets
|
||
to modify the command line argument under the cursor (or immediately to
|
||
the left of the cursor if the cursor is between arguments).</p>
|
||
<p>The argument can be an expression which when evaluated operates on the
|
||
shell parameter <code>ARG</code>, which will have been set to the command line
|
||
argument under the cursor. The expression should be suitably quoted to
|
||
prevent it being evaluated too early.</p>
|
||
<p>Alternatively, if the argument does not contain the string <code>ARG</code>, it is
|
||
assumed to be a shell function, to which the current command line
|
||
argument is passed as the only argument. The function should set the
|
||
variable <code>REPLY</code> to the new value for the command line argument. If the
|
||
function returns non-zero status, so does the calling function.</p>
|
||
<p>For example, a user-defined widget containing the following code
|
||
converts the characters in the argument under the cursor into all upper
|
||
case:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">modify-current-argument '${(U)ARG}'
|
||
</code></pre>
|
||
</div>
|
||
<p>The following strips any quoting from the current word (whether
|
||
backslashes or one of the styles of quotes), and replaces it with single
|
||
quoting throughout:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">modify-current-argument '${(qq)${(Q)ARG}}'
|
||
</code></pre>
|
||
</div>
|
||
<p>The following performs directory expansion on the command line argument
|
||
and replaces it by the absolute path:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">expand-dir() {
|
||
REPLY=${~1}
|
||
REPLY=${REPLY:a}
|
||
}
|
||
modify-current-argument expand-dir
|
||
</code></pre>
|
||
</div>
|
||
<p>In practice the function <code>expand-dir</code> would probably not be defined
|
||
within the widget where <code>modify-current-argument</code> is called.</p>
|
||
<hr />
|
||
<p><span id="Styles"></span></p>
|
||
<h3 id="2673-styles"><a class="header" href="#2673-styles">26.7.3 Styles</a></h3>
|
||
<p>The behavior of several of the above widgets can be controlled by the
|
||
use of the <code>zstyle</code> mechanism. In particular, widgets that interact with
|
||
the completion system pass along their context to any completions that
|
||
they invoke.</p>
|
||
<p><span id="index-break_002dkeys_002c-widget-style"></span></p>
|
||
<p><code>break-keys</code></p>
|
||
<p>This style is used by the <code>incremental-complete-word</code> widget. Its value
|
||
should be a pattern, and all keys matching this pattern will cause the
|
||
widget to stop incremental completion without the key having any further
|
||
effect. Like all styles used directly by <code>incremental-complete-word</code>,
|
||
this style is looked up using the context ‘<code>:incremental</code>’.</p>
|
||
<p><span id="index-completer_002c-completion-style-1"></span></p>
|
||
<p><code>completer</code></p>
|
||
<p>The <code>incremental-complete-word</code> and <code>insert-and-predict</code> widgets set up
|
||
their top-level context name before calling completion. This allows one
|
||
to define different sets of completer functions for normal completion
|
||
and for these widgets. For example, to use completion, approximation and
|
||
correction for normal completion, completion and correction for
|
||
incremental completion and only completion for prediction one could use:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':completion:*' completer \
|
||
_complete _correct _approximate
|
||
zstyle ':completion:incremental:*' completer \
|
||
_complete _correct
|
||
zstyle ':completion:predict:*' completer \
|
||
_complete
|
||
</code></pre>
|
||
</div>
|
||
<p>It is a good idea to restrict the completers used in prediction, because
|
||
they may be automatically invoked as you type. The <code>_list</code> and <code>_menu</code>
|
||
completers should never be used with prediction. The <code>_approximate</code>,
|
||
<code>_correct</code>, <code>_expand</code>, and <code>_match</code> completers may be used, but be aware
|
||
that they may change characters anywhere in the word behind the cursor,
|
||
so you need to watch carefully that the result is what you intended.</p>
|
||
<p><span id="index-cursor_002c-completion-style"></span></p>
|
||
<p><code>cursor</code></p>
|
||
<p>The <code>insert-and-predict</code> widget uses this style, in the context
|
||
‘<code>:predict</code>’, to decide where to place the cursor after completion has
|
||
been tried. Values are:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>complete</code><br />
|
||
The cursor is left where it was when completion finished, but only
|
||
if it is after a character equal to the one just inserted by the
|
||
user. If it is after another character, this value is the same as
|
||
‘<code>key</code>’.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>key</code><br />
|
||
The cursor is left after the <code>n</code>th occurrence of the character just
|
||
inserted, where <code>n</code> is the number of times that character appeared
|
||
in the word before completion was attempted. In short, this has the
|
||
effect of leaving the cursor after the character just typed even if
|
||
the completion code found out that no other characters need to be
|
||
inserted at that position.</p>
|
||
</li>
|
||
</ul>
|
||
<p>Any other value for this style unconditionally leaves the cursor at the
|
||
position where the completion code left it.</p>
|
||
<p><span id="index-list_002c-widget-style"></span></p>
|
||
<p><code>list</code></p>
|
||
<p>When using the <code>incremental-complete-word</code> widget, this style says if
|
||
the matches should be listed on every key press (if they fit on the
|
||
screen). Use the context prefix ‘<code>:completion:incremental</code>’.</p>
|
||
<p>The <code>insert-and-predict</code> widget uses this style to decide if the
|
||
completion should be shown even if there is only one possible
|
||
completion. This is done if the value of this style is the string
|
||
<code>always</code>. In this case the context is ‘<code>:predict</code>’ (<em>not</em>
|
||
‘<code>:completion:predict</code>’).</p>
|
||
<p><span id="index-match_002c-widget-style"></span></p>
|
||
<p><code>match</code></p>
|
||
<p>This style is used by <code>smart-insert-last-word</code> to provide a pattern
|
||
(using full <code>EXTENDED_GLOB</code> syntax) that matches an interesting word.
|
||
The context is the name of the widget to which <code>smart-insert-last-word</code>
|
||
is bound (see above). The default behavior of <code>smart-insert-last-word</code>
|
||
is equivalent to:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle :insert-last-word match '*[[:alpha:]/\\]*'
|
||
</code></pre>
|
||
</div>
|
||
<p>However, you might want to include words that contain spaces:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle :insert-last-word match '*[[:alpha:][:space:]/\\]*'
|
||
</code></pre>
|
||
</div>
|
||
<p>Or include numbers as long as the word is at least two characters long:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle :insert-last-word match '*([[:digit:]]?|[[:alpha:]/\\])*'
|
||
</code></pre>
|
||
</div>
|
||
<p>The above example causes redirections like "2>" to be included.</p>
|
||
<p><span id="index-prompt_002c-widget-style"></span></p>
|
||
<p><code>prompt</code></p>
|
||
<p>The <code>incremental-complete-word</code> widget shows the value of this style in
|
||
the status line during incremental completion. The string value may
|
||
contain any of the following substrings in the manner of the <code>PS1</code> and
|
||
other prompt parameters:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>%c</code><br />
|
||
Replaced by the name of the completer function that generated the
|
||
matches (without the leading underscore).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%l</code><br />
|
||
When the <code>list</code> style is set, replaced by ‘<code>...</code>’ if the list of
|
||
matches is too long to fit on the screen and with an empty string
|
||
otherwise. If the <code>list</code> style is ‘false’ or not set, ‘<code>%l</code>’ is
|
||
always removed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%n</code><br />
|
||
Replaced by the number of matches generated.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%s</code><br />
|
||
Replaced by ‘<code>-no match-</code>’, ‘<code>-no prefix-</code>’, or an empty string if
|
||
there is no completion matching the word on the line, if the matches
|
||
have no common prefix different from the word on the line, or if
|
||
there is such a common prefix, respectively.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>%u</code><br />
|
||
Replaced by the unambiguous part of all matches, if there is any,
|
||
and if it is different from the word on the line.</p>
|
||
</li>
|
||
</ul>
|
||
<p>Like ‘<code>break-keys</code>’, this uses the ‘<code>:incremental</code>’ context.</p>
|
||
<p><span id="index-stop_002dkeys_002c-widget-style"></span></p>
|
||
<p><code>stop-keys</code></p>
|
||
<p>This style is used by the <code>incremental-complete-word</code> widget. Its value
|
||
is treated similarly to the one for the <code>break-keys</code> style (and uses the
|
||
same context: ‘<code>:incremental</code>’). However, in this case all keys matching
|
||
the pattern given as its value will stop incremental completion and will
|
||
then execute their usual function.</p>
|
||
<p><span id="index-toggle_002c-widget-style"></span></p>
|
||
<p><code>toggle</code></p>
|
||
<p>This boolean style is used by <code>predict-on</code> and its related widgets in
|
||
the context ‘<code>:predict</code>’. If set to one of the standard ‘true’ values,
|
||
predictive typing is automatically toggled off in situations where it is
|
||
unlikely to be useful, such as when editing a multi-line buffer or after
|
||
moving into the middle of a line and then deleting a character. The
|
||
default is to leave prediction turned on until an explicit call to
|
||
<code>predict-off</code>.</p>
|
||
<p><span id="index-verbose_002c-widget-style"></span></p>
|
||
<p><code>verbose</code></p>
|
||
<p>This boolean style is used by <code>predict-on</code> and its related widgets in
|
||
the context ‘<code>:predict</code>’. If set to one of the standard ‘true’ values,
|
||
these widgets display a message below the prompt when the predictive
|
||
state is toggled. This is most useful in combination with the <code>toggle</code>
|
||
style. The default does not display these messages.</p>
|
||
<p><span id="index-widget_002c-widget-style"></span></p>
|
||
<p><code>widget</code></p>
|
||
<p>This style is similar to the <code>command</code> style: For widget functions that
|
||
use <code>zle</code> to call other widgets, this style can sometimes be used to
|
||
override the widget which is called. The context for this style is the
|
||
name of the calling widget (<em>not</em> the name of the calling function,
|
||
because one function may be bound to multiple widget names).</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle :copy-earlier-word widget smart-insert-last-word
|
||
</code></pre>
|
||
</div>
|
||
<p>Check the documentation for the calling widget or function to determine
|
||
whether the <code>widget</code> style is used.</p>
|
||
<hr />
|
||
<p><span id="Exception-Handling"></span>
|
||
<span id="Exception-Handling-1"></span></p>
|
||
<h2 id="268-exception-handling"><a class="header" href="#268-exception-handling">26.8 Exception Handling</a></h2>
|
||
<p>Two functions are provided to enable zsh to provide exception handling
|
||
in a form that should be familiar from other languages.</p>
|
||
<p><span id="index-throw"></span></p>
|
||
<p><code>throw</code> <code>exception</code></p>
|
||
<p>The function <code>throw</code> throws the named <code>exception</code>. The name is an
|
||
arbitrary string and is only used by the <code>throw</code> and <code>catch</code> functions.
|
||
An exception is for the most part treated the same as a shell error,
|
||
i.e. an unhandled exception will cause the shell to abort all processing
|
||
in a function or script and to return to the top level in an interactive
|
||
shell.</p>
|
||
<p><code>catch</code> <code>exception-pattern</code></p>
|
||
<p>The function <code>catch</code> returns status zero if an exception was thrown and
|
||
the pattern <code>exception-pattern</code> matches its name. Otherwise it returns
|
||
status 1. <code>exception-pattern</code> is a standard shell pattern, respecting
|
||
the current setting of the <code>EXTENDED_GLOB</code> option. An alias <code>catch</code> is
|
||
also defined to prevent the argument to the function from matching
|
||
filenames, so patterns may be used unquoted. Note that as exceptions are
|
||
not fundamentally different from other shell errors it is possible to
|
||
catch shell errors by using an empty string as the exception name. The
|
||
shell variable <code>CAUGHT</code> is set by <code>catch</code> to the name of the exception
|
||
caught. It is possible to rethrow an exception by calling the <code>throw</code>
|
||
function again once an exception has been caught.
|
||
<span id="index-catch"></span></p>
|
||
<p>The functions are designed to be used together with the <code>always</code>
|
||
construct described in <a href="Shell-Grammar.html#Complex-Commands">Complex
|
||
Commands</a>. This is important as
|
||
only this construct provides the required support for exceptions. A
|
||
typical example is as follows.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">{
|
||
# "try" block
|
||
# ... nested code here calls "throw MyExcept"
|
||
} always {
|
||
# "always" block
|
||
if catch MyExcept; then
|
||
print "Caught exception MyExcept"
|
||
elif catch ''; then
|
||
print "Caught a shell error. Propagating..."
|
||
throw ''
|
||
fi
|
||
# Other exceptions are not handled but may be caught further
|
||
# up the call stack.
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p>If all exceptions should be caught, the following idiom might be
|
||
preferable.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">{
|
||
# ... nested code here throws an exception
|
||
} always {
|
||
if catch *; then
|
||
case $CAUGHT in
|
||
(MyExcept)
|
||
print "Caught my own exception"
|
||
;;
|
||
(*)
|
||
print "Caught some other exception"
|
||
;;
|
||
esac
|
||
fi
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p>In common with exception handling in other languages, the exception may
|
||
be thrown by code deeply nested inside the ‘try’ block. However, note
|
||
that it must be thrown inside the current shell, not in a subshell
|
||
forked for a pipeline, parenthesised current-shell construct, or some
|
||
form of command or process substitution.</p>
|
||
<p>The system internally uses the shell variable <code>EXCEPTION</code> to record the
|
||
name of the exception between throwing and catching. One drawback of
|
||
this scheme is that if the exception is not handled the variable
|
||
<code>EXCEPTION</code> remains set and may be incorrectly recognised as the name of
|
||
an exception if a shell error subsequently occurs. Adding <code>unset EXCEPTION</code> at the start of the outermost layer of any code that uses
|
||
exception handling will eliminate this problem.</p>
|
||
<hr />
|
||
<p><span id="MIME-Functions"></span> <span id="MIME-Functions-1"></span></p>
|
||
<h2 id="269-mime-functions"><a class="header" href="#269-mime-functions">26.9 MIME Functions</a></h2>
|
||
<p>Three functions are available to provide handling of files recognised by
|
||
extension, for example to dispatch a file <code>text.ps</code> when executed as a
|
||
command to an appropriate viewer.</p>
|
||
<p><span id="index-zsh_002dmime_002dsetup"></span>
|
||
<span id="index-zsh_002dmime_002dhandler"></span></p>
|
||
<p><code>zsh-mime-setup</code> [ <code>-fv</code> ] [ <code>-l</code> [ <code>suffix</code> ... ] ]</p>
|
||
<p><code>zsh-mime-handler</code> [ <code>-l</code> ] <code>command argument</code> ...</p>
|
||
<p>These two functions use the files <code>~/.mime.types</code> and <code>/etc/mime.types</code>,
|
||
which associate types and extensions, as well as <code>~/.mailcap</code> and
|
||
<code>/etc/mailcap</code> files, which associate types and the programs that handle
|
||
them. These are provided on many systems with the Multimedia Internet
|
||
Mail Extensions.</p>
|
||
<p>To enable the system, the function <code>zsh-mime-setup</code> should be autoloaded
|
||
and run. This allows files with extensions to be treated The function
|
||
<code>zsh-mime-handler</code> should not need to be called by the user.</p>
|
||
<p>The system works by setting up suffix aliases with ‘<code>alias -s</code>’. Suffix
|
||
aliases already installed by the user will not be overwritten.</p>
|
||
<p>For suffixes defined in lower case, upper case variants will also
|
||
automatically be handled (e.g. <code>PDF</code> is automatically handled if
|
||
handling for the suffix <code>pdf</code> is defined), but not vice versa.</p>
|
||
<p>Repeated calls to <code>zsh-mime-setup</code> do not override the existing is
|
||
given. Note, however, that this does not override existing suffix
|
||
aliases assigned to handlers other than <code>zsh-mime-handler</code>.</p>
|
||
<p>Calling <code>zsh-mime-setup</code> with the option <code>-l</code> lists the existing
|
||
mappings without altering them. Suffixes to list (which may contain
|
||
pattern characters that should be quoted from immediate interpretation
|
||
on the command line) may be given as additional arguments, otherwise all
|
||
suffixes are listed.</p>
|
||
<p>Calling <code>zsh-mime-setup</code> with the option <code>-v</code> causes verbose output to
|
||
be shown during the setup operation.</p>
|
||
<p>The system respects the <code>mailcap</code> flags <code>needsterminal</code> and
|
||
<code>copiousoutput</code>, see man page mailcap(4).</p>
|
||
<p>The functions use the following styles, which are defined with the
|
||
<code>zstyle</code> builtin command (<a href="Zsh-Modules.html#The-zsh_002fzutil-Module">The zsh/zutil
|
||
Module</a>). They should be
|
||
defined before <code>zsh-mime-setup</code> is run. The contexts used all start with
|
||
<code>:mime:</code>, with additional components in some cases. It is recommended
|
||
that a trailing <code>*</code> (suitably quoted) be appended to style patterns in
|
||
case the system is extended in future. Some examples are given below.</p>
|
||
<p>For files that have multiple suffixes, e.g. <code>.pdf.gz</code>, where the context
|
||
includes the suffix it will be looked up starting with the longest
|
||
possible suffix until a match for the style is found. For example, if
|
||
<code>.pdf.gz</code> produces a match for the handler, that will be used; otherwise
|
||
the handler for <code>.gz</code> will be used. Note that, owing to the way suffix
|
||
aliases work, it is always required that there be a handler for the
|
||
shortest possible suffix, so in this example <code>.pdf.gz</code> can only be
|
||
handled if <code>.gz</code> is also handled (though not necessarily in the same
|
||
way). Alternatively, if no handling for <code>.gz</code> on its own is needed,
|
||
simply adding the command</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">alias -s gz=zsh-mime-handler
|
||
</code></pre>
|
||
</div>
|
||
<p>to the initialisation code is sufficient; <code>.gz</code> will not be handled on
|
||
its own, but may be in combination with other suffixes.</p>
|
||
<p><span id="index-current_002dshell_002c-MIME-style"></span></p>
|
||
<p><code>current-shell</code></p>
|
||
<p>If this boolean style is true, the mailcap handler for the context in
|
||
question is run using the <code>eval</code> builtin instead of by starting a new
|
||
<code>sh</code> process. This is more efficient, but may not work in the occasional
|
||
cases where the mailcap handler uses strict POSIX syntax.</p>
|
||
<p><span id="index-disown_002c-MIME-style"></span></p>
|
||
<p><code>disown</code></p>
|
||
<p>If this boolean style is true, mailcap handlers started in the
|
||
background will be disowned, i.e. not subject to job control within the
|
||
parent shell. Such handlers nearly always produce their own windows, so
|
||
the only likely harmful side effect of setting the style is that it
|
||
becomes harder to kill jobs from within the shell.</p>
|
||
<p><span id="index-execute_002das_002dis_002c-MIME-style"></span></p>
|
||
<p><code>execute-as-is</code></p>
|
||
<p>This style gives a list of patterns to be matched against files passed
|
||
for execution with a handler program. If the file matches the pattern,
|
||
the entire command line is executed in its current form, with no
|
||
handler. This is useful for files which might have suffixes is not set,
|
||
the pattern <code>*(*) *(/)</code> is used; handler, and the option <code>AUTO_CD</code> may
|
||
be used to change to directories that happen to have MIME suffixes.</p>
|
||
<p><span id="index-execute_002dnever_002c-MIME-style"></span></p>
|
||
<p><code>execute-never</code></p>
|
||
<p>This style is useful in combination with <code>execute-as-is</code>. It is set to
|
||
an array of patterns corresponding to full paths to files that the MIME
|
||
handler matches <code>execute-as-is</code>. This is useful for file from another
|
||
operating system. For example, if <code>/mnt/windows</code> is a Windows mount,
|
||
then</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':mime:*' execute-never '/mnt/windows/*'
|
||
</code></pre>
|
||
</div>
|
||
<p>will ensure that any files found in that area will be executed as MIME
|
||
file name is matched against the pattern, regardless of how the file was
|
||
passed to the handler. The file is resolved to a full path using the
|
||
<code>:P</code> modifier described in <a href="Expansion.html#Modifiers">Modifiers</a>; this
|
||
means that symbolic links are resolved where possible, so that links
|
||
into other file systems behave in the correct fashion.</p>
|
||
<p><span id="index-file_002dpath_002c-MIME-style"></span></p>
|
||
<p><code>file-path</code></p>
|
||
<p>Used if the style <code>find-file-in-path</code> is true for the same context. Set
|
||
to an array of directories that are used for searching for the file to
|
||
be handled; the default is the command path given by the special
|
||
parameter <code>path</code>. The shell option <code>PATH_DIRS</code> is respected; if that is
|
||
set, the appropriate path will be searched even if the name of the file
|
||
to be handled as it appears on the command line contains a ‘<code>/</code>’. The
|
||
full context is <code>:mime:.``suffix``:</code>, as described for the style
|
||
<code>handler</code>.</p>
|
||
<p><span id="index-find_002dfile_002din_002dpath_002c-MIME-style"></span></p>
|
||
<p><code>find-file-in-path</code></p>
|
||
<p>If set, allows files whose names do not contain absolute paths to be
|
||
searched for in the command path or the path specified by the
|
||
<code>file-path</code> style. If the file is not found in the path, it is looked
|
||
for locally (whether or not the current directory is in the path); if it
|
||
is not found locally, the handler will abort unless the
|
||
<code>handle-nonexistent</code> style is set. Files found in the path are tested as
|
||
described for the style <code>execute-as-is</code>. The full context is
|
||
<code>:mime:.``suffix``:</code>, as described for the style <code>handler</code>.</p>
|
||
<p><span id="index-flags_002c-MIME-style"></span></p>
|
||
<p><code>flags</code></p>
|
||
<p>Defines flags to go with a handler; the context is as for the <code>handler</code>
|
||
style, and the format is as for the flags in <code>mailcap</code>.</p>
|
||
<p><span id="index-handle_002dnonexistent_002c-MIME-style"></span></p>
|
||
<p><code>handle-nonexistent</code></p>
|
||
<p>By default, arguments that don’t correspond to files are not passed to
|
||
the MIME handler in order to prevent it from intercepting commands found
|
||
in the path that happen to have suffixes. This style may be set to an
|
||
array of extended glob patterns for arguments that will be passed to the
|
||
handler even if they don’t exist. If it is not explicitly set it
|
||
defaults to <code>[[:alpha:]]#:/*</code> which allows URLs to be passed to the MIME
|
||
handler even though they don’t exist in that format in the file system.
|
||
The full context is <code>:mime:.``suffix``:</code>, as described for the style
|
||
<code>handler</code>.</p>
|
||
<p><span id="index-handler_002c-MIME-style"></span></p>
|
||
<p><code>handler</code></p>
|
||
<p>Specifies a handler for a suffix; the suffix is given by the context as
|
||
<code>:mime:.``suffix``:</code>, and the format of the handler is exactly that in
|
||
<code>mailcap</code>. Note in particular the ‘<code>.</code>’ and trailing colon to
|
||
distinguish this use of the context. This overrides any handler
|
||
specified by the <code>mailcap</code> files. If the handler requires a terminal,
|
||
the <code>flags</code> style should be set to include the word <code>needsterminal</code>, or
|
||
if the output is to be displayed through a pager (but not if the handler
|
||
is itself a pager), it should include <code>copiousoutput</code>.</p>
|
||
<p><span id="index-mailcap_002c-MIME-style"></span></p>
|
||
<p><code>mailcap</code></p>
|
||
<p>A list of files in the format of <code>~/.mailcap</code> and <code>/etc/mailcap</code> to be
|
||
read during setup, replacing the default list which consists of those
|
||
two files. The context is <code>:mime:</code>. A <code>+</code> in the list will be replaced
|
||
by the default files.</p>
|
||
<p><span id="index-mailcap_002dpriorities_002c-MIME-style"></span></p>
|
||
<p><code>mailcap-priorities</code></p>
|
||
<p>This style is used to resolve multiple mailcap entries for the same MIME
|
||
type. It consists of an array of the following elements, in descending
|
||
order of priority; later entries will be used if earlier entries are
|
||
unable to resolve the entries being compared. If none of the tests
|
||
resolve the entries, the first entry encountered is retained.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>files</code><br />
|
||
The order of files (entries in the <code>mailcap</code> style) read. Earlier
|
||
files are preferred. (Note this does not resolve entries in the same
|
||
file.)</p>
|
||
</li>
|
||
<li>
|
||
<p><code>priority</code><br />
|
||
The priority flag from the mailcap entry. The priority is an integer
|
||
from 0 to 9 with the default value being 5.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>flags</code><br />
|
||
The test given by the <code>mailcap-prio-flags</code> option is used to resolve
|
||
entries.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>place</code><br />
|
||
Later entries are preferred; as the entries are strictly ordered,
|
||
this test always succeeds.</p>
|
||
</li>
|
||
</ul>
|
||
<p>Note that as this style is handled during initialisation, the context is
|
||
always <code>:mime:</code>, with no discrimination by suffix.</p>
|
||
<p><span id="index-mailcap_002dprio_002dflags_002c-MIME-style"></span></p>
|
||
<p><code>mailcap-prio-flags</code></p>
|
||
<p>This style is used when the keyword <code>flags</code> is encountered in the list
|
||
of tests specified by the <code>mailcap-priorities</code> style. It should be set
|
||
to a list of patterns, each of which is tested against the flags
|
||
specified in the mailcap entry (in other words, the sets of assignments
|
||
found with some entries in the mailcap file). Earlier patterns in the
|
||
list are preferred to later ones, and matched patterns are preferred to
|
||
unmatched ones.</p>
|
||
<p><span id="index-mime_002dtypes_002c-MIME-style"></span></p>
|
||
<p><code>mime-types</code></p>
|
||
<p>A list of files in the format of <code>~/.mime.types</code> and <code>/etc/mime.types</code>
|
||
to be read during setup, replacing the default list which consists of
|
||
those two files. The context is <code>:mime:</code>. A <code>+</code> in the list will be
|
||
replaced by the default files.</p>
|
||
<p><span id="index-never_002dbackground_002c-MIME-style"></span></p>
|
||
<p><code>never-background</code></p>
|
||
<p>If this boolean style is set, the handler for the given context is
|
||
always run in the foreground, even if the flags provided in the mailcap
|
||
entry suggest it need not be (for example, it doesn’t require a
|
||
terminal).</p>
|
||
<p><span id="index-pager_002c-MIME-style"></span></p>
|
||
<p><code>pager</code></p>
|
||
<p>If set, will be used instead of <code>$PAGER</code> or <code>more</code> to handle suffixes
|
||
where the <code>copiousoutput</code> flag is set. The context is as for <code>handler</code>,
|
||
i.e. <code>:mime:.``suffix``:</code> for handling a file with the given <code>suffix</code>.</p>
|
||
<p>Examples:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':mime:*' mailcap ~/.mailcap /usr/local/etc/mailcap
|
||
zstyle ':mime:.txt:' handler less %s
|
||
zstyle ':mime:.txt:' flags needsterminal
|
||
</code></pre>
|
||
</div>
|
||
<p>When <code>zsh-mime-setup</code> is subsequently run, it will look for <code>mailcap</code>
|
||
entries in the two files given. Files of suffix <code>.txt</code> will be handled
|
||
by running ‘<code>less</code> <code>file.txt</code>’. The flag <code>needsterminal</code> is set to show
|
||
that this program must run attached to a terminal.</p>
|
||
<p>As there are several steps to dispatching a command, the following
|
||
should be checked if attempting to execute a file by extension <code>.``ext</code>
|
||
does not have the expected effect.</p>
|
||
<p>The command ‘<code>alias -s</code> <code>ext</code>’ should show ‘<code>ps=zsh-mime-handler</code>’. If
|
||
it shows something else, another suffix alias was already installed and
|
||
was not overwritten. If it shows nothing, no handler was installed: this
|
||
is most likely because no handler was found in the <code>.mime.types</code> and
|
||
<code>mailcap</code> combination for <code>.ext</code> files. In that case, appropriate
|
||
handling should be added to <code>~/.mime.types</code> and <code>mailcap</code>.</p>
|
||
<p>If the extension is handled by <code>zsh-mime-handler</code> but the file is not
|
||
opened correctly, either the handler defined for the type is incorrect,
|
||
or the flags associated with it are in appropriate. Running
|
||
<code>zsh-mime-setup -l</code> will show the handler and, if there are any, the
|
||
flags. A <code>%s</code> in the handler is replaced by the file (suitably quoted if
|
||
necessary). Check that the handler program listed lists and can be run
|
||
in the way shown. Also check that the flags <code>needsterminal</code> or
|
||
<code>copiousoutput</code> are set if the handler needs to be run under a terminal;
|
||
the second flag is used if the output should be sent to a pager.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">text/html; /usr/bin/lynx '%s'; needsterminal
|
||
</code></pre>
|
||
</div>
|
||
<p>Running ‘<code>zsh-mime-handler -l</code> <code>command line</code>’ prints the command line
|
||
that would be executed, simplified to remove the effect of any flags,
|
||
and quoted so that the output can be run as a complete zsh command line.
|
||
This is used by the completion system to decide how to complete after a
|
||
file handled by <code>zsh-mime-setup</code>.</p>
|
||
<p><span id="index-pick_002dweb_002dbrowser"></span></p>
|
||
<p><code>pick-web-browser</code></p>
|
||
<p>This function is separate from the two MIME functions described above
|
||
and can be assigned directly to a suffix:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">autoload -U pick-web-browser
|
||
alias -s html=pick-web-browser
|
||
</code></pre>
|
||
</div>
|
||
<p>It is provided as an intelligent front end to dispatch a web browser. It
|
||
may be run as either a function or a shell script. The status 255 is
|
||
returned if no browser could be started.</p>
|
||
<p>Various styles are available to customize the choice of browsers:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>browser-style</code><br />
|
||
The value of the style is an array giving preferences in decreasing
|
||
order for the type of browser to use. The values of elements may be</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>running</code><br />
|
||
Use a GUI browser that is already running when an X Window
|
||
display is available. The browsers listed in the <code>x-browsers</code>
|
||
style are tried in order until one is found; if it is, the file
|
||
will be displayed in that browser, so the user may need to check
|
||
whether it has appeared. If no running browser is found, one is
|
||
not started. Browsers other than Firefox, Opera and Konqueror
|
||
are assumed to understand the Mozilla syntax for opening a URL
|
||
remotely.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>x</code><br />
|
||
Start a new GUI browser when an X Window display is available.
|
||
Search for the availability of one of the browsers listed in the
|
||
<code>x-browsers</code> style and start the first one that is found. No
|
||
check is made for an already running browser.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>tty</code><br />
|
||
Start a terminal-based browser. Search for the availability of
|
||
one of the browsers listed in the <code>tty-browsers</code> style and start
|
||
the first one that is found.</p>
|
||
</li>
|
||
</ul>
|
||
<p>If the style is not set the default <code>running x tty</code> is used.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>x-browsers</code><br />
|
||
An array in decreasing order of preference of browsers to use when
|
||
running under the X Window System. The array consists of the command
|
||
name under which to start the browser. They are looked up in the
|
||
context <code>:mime:</code> (which may be extended in future, so appending
|
||
‘<code>*</code>’ is recommended). For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle ':mime:*' x-browsers opera konqueror firefox
|
||
</code></pre>
|
||
</div>
|
||
<p>specifies that <code>pick-web-browser</code> should first look for a running
|
||
instance of Opera, Konqueror or Firefox, in that order, and if it
|
||
fails to find any should attempt to start Opera. The default is
|
||
<code>firefox mozilla netscape opera konqueror</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>tty-browsers</code><br />
|
||
An array similar to <code>x-browsers</code>, except that it gives browsers to
|
||
use when no X Window display is available. The default is <code>elinks links lynx</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>command</code><br />
|
||
If it is set this style is used to pick the command used to open a
|
||
page for a browser. The context is <code>:mime:browser:new:$browser:</code> to
|
||
start a new browser or <code>:mime:browser:running:$browser:</code> to open a
|
||
URL in a browser already running on the current X display, where
|
||
<code>$browser</code> is the value matched in the <code>x-browsers</code> or
|
||
<code>tty-browsers</code> style. The escape sequence <code>%b</code> in the style’s value
|
||
will be replaced by the browser, while <code>%u</code> will be replaced by the
|
||
URL. If the style is not set, the default for all new instances is
|
||
equivalent to <code>%b %u</code> and the defaults for using running browsers
|
||
are equivalent to the values <code>kfmclient openURL %u</code> for Konqueror,
|
||
<code>firefox -new-tab %u</code> for Firefox, <code>opera -newpage %u</code> for Opera,
|
||
and <code>%b -remote "openUrl(%u)"</code> for all others.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Mathematical-Functions"></span>
|
||
<span id="Mathematical-Functions-1"></span></p>
|
||
<h2 id="2610-mathematical-functions"><a class="header" href="#2610-mathematical-functions">26.10 Mathematical Functions</a></h2>
|
||
<p><span id="index-zcalc"></span></p>
|
||
<p><code>zcalc</code> [ <code>-erf</code> ] [ <code>expression</code> ... ]</p>
|
||
<p>A reasonably powerful calculator based on zsh’s arithmetic evaluation
|
||
facility. The syntax is similar to that of formulae in most programming
|
||
languages; see <a href="Arithmetic-Evaluation.html#Arithmetic-Evaluation">Arithmetic
|
||
Evaluation</a> for
|
||
details.</p>
|
||
<p>Non-programmers should note that, as in many other programming
|
||
languages, expressions involving only integers (whether constants
|
||
without a ‘<code>.</code>’, variables containing such constants as strings, or
|
||
variables declared to be integers) are by default evaluated using
|
||
integer arithmetic, which is not how an ordinary desk calculator
|
||
operates. To force floating point operation, pass the option <code>-f</code>; see
|
||
further notes below.</p>
|
||
<p>If the file <code>~/.zcalcrc</code> exists it will be sourced inside the function
|
||
once it is set up and about to process the command line. This can be
|
||
used, for example, to set shell options; <code>emulate -L zsh</code> and <code>setopt extendedglob</code> are in effect at this point. Any failure to source the
|
||
file if it exists is treated as fatal. As with other initialisation
|
||
files, the directory <code>$ZDOTDIR</code> is used instead of <code>$HOME</code> if it is set.</p>
|
||
<p>The mathematical library <code>zsh/mathfunc</code> will be loaded if it is
|
||
available; see <a href="Zsh-Modules.html#The-zsh_002fmathfunc-Module">The zsh/mathfunc
|
||
Module</a>. The mathematical
|
||
functions correspond to the raw system libraries, so trigonometric
|
||
functions are evaluated using radians, and so on.</p>
|
||
<p>Each line typed is evaluated as an expression. The prompt shows a
|
||
number, which corresponds to a positional parameter where the result of
|
||
that calculation is stored. For example, the result of the calculation
|
||
on the line preceded by ‘<code>4> </code>’ is available as <code>$4</code>. The last value
|
||
calculated is available as <code>ans</code>. Full command line editing, including
|
||
the history of previous calculations, is available; the history is saved
|
||
in the file <code>~/.zcalc_history</code>. To exit, enter a blank line or type
|
||
‘<code>:q</code>’ on its own (‘<code>q</code>’ is allowed for historical compatibility).</p>
|
||
<p>A line ending with a single backslash is treated in the same fashion as
|
||
it is in command line editing: the backslash is removed, the function
|
||
prompts for more input (the prompt is preceded by ‘<code>...</code>’ to indicate
|
||
this), and the lines are combined into one to get the final result. In
|
||
addition, if the input so far contains more open than close parentheses
|
||
<code>zcalc</code> will prompt for more input.</p>
|
||
<p>If arguments are given to <code>zcalc</code> on start up, they are used to prime
|
||
the first few positional parameters. A visual indication of this is
|
||
given when the calculator starts.</p>
|
||
<p>The constants <code>PI</code> (3.14159...) and <code>E</code> (2.71828...) are provided.
|
||
Parameter assignment is possible, but note that all parameters will be
|
||
put into the global namespace unless the <code>:local</code> special command is
|
||
used. The function creates local variables whose names start with <code>_</code>,
|
||
so users should avoid doing so. The variables <code>ans</code> (the last answer)
|
||
and <code>stack</code> (the stack in RPN mode) may be referred to directly; <code>stack</code>
|
||
is an array but elements of it are numeric. Various other special
|
||
variables are used locally with their standard meaning, for example
|
||
<code>compcontext</code>, <code>match</code>, <code>mbegin</code>, <code>mend</code>, <code>psvar</code>.</p>
|
||
<p>The output base can be initialised by passing the option ‘<code>-#``base</code>’,
|
||
for example ‘<code>zcalc -#16</code>’ (the ‘<code>#</code>’ may have to be quoted, depending
|
||
on the globbing options set).</p>
|
||
<p>If the option ‘<code>-e</code>’ is set, the function runs non-interactively: the
|
||
arguments are treated as expressions to be evaluated as if entered
|
||
interactively line by line.</p>
|
||
<p>If the option ‘<code>-f</code>’ is set, all numbers are treated as floating point,
|
||
hence for example the expression ‘<code>3/4</code>’ evaluates to 0.75 rather than</p>
|
||
<ol start="0">
|
||
<li>Options must appear in separate words.</li>
|
||
</ol>
|
||
<p>If the option ‘<code>-r</code>’ is set, RPN (Reverse Polish Notation) mode is
|
||
entered. This has various additional properties:</p>
|
||
<ul>
|
||
<li>
|
||
<p>Stack<br />
|
||
Evaluated values are maintained in a stack; this is contained in an
|
||
array named <code>stack</code> with the most recent value in <code>${stack[1]}</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p>Operators and functions<br />
|
||
If the line entered matches an operator (<code>+</code>, <code>-</code>, <code>*</code>, <code>/</code>, <code>**</code>,
|
||
<code>^</code>, <code>|</code> or <code>&</code>) or a function supplied by the <code>zsh/mathfunc</code>
|
||
library, the bottom element or elements of the stack are popped to
|
||
use as the argument or arguments. The higher elements of stack
|
||
(least recent) are used as earlier arguments. The result is then
|
||
pushed into <code>${stack[1]}</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p>Expressions<br />
|
||
Other expressions are evaluated normally, printed, and added to the
|
||
stack as numeric values. The syntax within expressions on a single
|
||
line is normal shell arithmetic (not RPN).</p>
|
||
</li>
|
||
<li>
|
||
<p>Stack listing<br />
|
||
If an integer follows the option <code>-r</code> with no space, then on every
|
||
evaluation that many elements of the stack, where available, are
|
||
printed instead of just the most recent result. Hence, for example,
|
||
<code>zcalc -r4</code> shows <code>$stack[4]</code> to <code>$stack[1]</code> each time results are
|
||
printed.</p>
|
||
</li>
|
||
<li>
|
||
<p>Duplication: <code>=</code><br />
|
||
The pseudo-operator <code>=</code> causes the most recent element of the stack
|
||
to be duplicated onto the stack.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>pop</code><br />
|
||
The pseudo-function <code>pop</code> causes the most recent element of the
|
||
stack to be popped. A ‘<code>></code>’ on its own has the same effect.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>>``ident</code><br />
|
||
The expression <code>></code> followed (with no space) by a shell identifier
|
||
causes the most recent element of the stack to be popped and
|
||
assigned to the variable with that name. The variable is local to
|
||
the <code>zcalc</code> function.</p>
|
||
</li>
|
||
<li>
|
||
<p><code><``ident</code><br />
|
||
The expression <code><</code> followed (with no space) by a shell identifier
|
||
causes the value of the variable with that name to be pushed onto
|
||
the stack. <code>ident</code> may be an integer, in which case the previous
|
||
result with that number (as shown before the <code>></code> in the standard
|
||
<code>zcalc</code> prompt) is put on the stack.</p>
|
||
</li>
|
||
<li>
|
||
<p>Exchange: <code>xy</code><br />
|
||
The pseudo-function <code>xy</code> causes the most recent two elements of the
|
||
stack to be exchanged. ‘<code><></code>’ has the same effect.</p>
|
||
</li>
|
||
</ul>
|
||
<p>The prompt is configurable via the parameter <code>ZCALCPROMPT</code>, which
|
||
undergoes standard prompt expansion. The index of the current entry is
|
||
stored locally in the first element of the array <code>psvar</code>, which can be
|
||
referred to in <code>ZCALCPROMPT</code> as ‘<code>%1v</code>’. The default prompt is ‘<code>%1v>
|
||
</code>’.</p>
|
||
<p>The variable <code>ZCALC_ACTIVE</code> is set within the function and can be tested
|
||
by nested functions; it has the value <code>rpn</code> if RPN mode is active, else</p>
|
||
<ol>
|
||
<li></li>
|
||
</ol>
|
||
<p>A few special commands are available; these are introduced by a colon.
|
||
For backward compatibility, the colon may be omitted for certain
|
||
commands. Completion is available if <code>compinit</code> has been run.</p>
|
||
<p>The output precision may be specified within zcalc by special commands
|
||
familiar from many calculators.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>:norm</code><br />
|
||
The default output format. It corresponds to the printf <code>%g</code>
|
||
specification. Typically this shows six decimal digits.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>:sci</code> <code>digits</code><br />
|
||
Scientific notation, corresponding to the printf <code>%g</code> output format
|
||
with the precision given by <code>digits</code>. This produces either fixed
|
||
point or exponential notation depending on the value output.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>:fix</code> <code>digits</code><br />
|
||
Fixed point notation, corresponding to the printf <code>%f</code> output format
|
||
with the precision given by <code>digits</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>:eng</code> <code>digits</code><br />
|
||
Exponential notation, corresponding to the printf <code>%E</code> output format
|
||
with the precision given by <code>digits</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>:raw</code><br />
|
||
Raw output: this is the default form of the output from a math
|
||
evaluation. This may show more precision than the number actually
|
||
possesses.</p>
|
||
</li>
|
||
</ul>
|
||
<p>Other special commands:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>:!``line...</code><br />
|
||
Execute <code>line...</code> as a normal shell command line. Note that it is
|
||
executed in the context of the function, i.e. with local variables.
|
||
Space is optional after <code>:!</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>:local</code> <code>arg</code> ...<br />
|
||
Declare variables local to the function. Other variables may be
|
||
used, too, but they will be taken from or put into the global scope.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>:function</code> <code>name</code> [ <code>body</code> ]<br />
|
||
Define a mathematical function or (with no <code>body</code>) delete it.
|
||
<code>:function</code> may be abbreviated to <code>:func</code> or simply <code>:f</code>. The <code>name</code>
|
||
may contain the same characters as a shell function name. The
|
||
function is defined using <code>zmathfuncdef</code>, see below.</p>
|
||
<p>Note that <code>zcalc</code> takes care of all quoting. Hence for example:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">:f cube $1 * $1 * $1
|
||
</code></pre>
|
||
</div>
|
||
<p>defines a function to cube the sole argument. Functions so defined,
|
||
or indeed any functions defined directly or indirectly using
|
||
<code>functions -M</code>, are available to execute by typing only the name on
|
||
the line in RPN mode; this pops the appropriate number of arguments
|
||
off the stack to pass to the function, i.e. 1 in the case of the
|
||
example <code>cube</code> function. If there are optional arguments only the
|
||
mandatory arguments are supplied by this means.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>[#``base``]</code><br />
|
||
This is not a special command, rather part of normal arithmetic
|
||
syntax; however, when this form appears on a line by itself the
|
||
default output radix is set to <code>base</code>. Use, for example, ‘<code>[#16]</code>’
|
||
to display hexadecimal output preceded by an indication of the base,
|
||
or ‘<code>[##16]</code>’ just to display the raw number in the given base.
|
||
Bases themselves are always specified in decimal. ‘<code>[#]</code>’ restores
|
||
the normal output format. Note that setting an output base
|
||
suppresses floating point output; use ‘<code>[#]</code>’ to return to normal
|
||
operation.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>$``var</code><br />
|
||
Print out the value of var literally; does not affect the
|
||
calculation. To use the value of var, omit the leading ‘<code>$</code>’.</p>
|
||
</li>
|
||
</ul>
|
||
<p>See the comments in the function for a few extra tips.</p>
|
||
<p><span id="index-max"></span> <span id="index-min"></span>
|
||
<span id="index-sum"></span> <span id="index-zmathfunc"></span></p>
|
||
<p><code>min(``arg``, ...)</code></p>
|
||
<p><code>max(``arg``, ...)</code></p>
|
||
<p><code>sum(``arg``, ...)</code></p>
|
||
<p><code>zmathfunc</code></p>
|
||
<p>The function <code>zmathfunc</code> defines the three mathematical functions <code>min</code>,
|
||
<code>max</code>, and <code>sum</code>. The functions <code>min</code> and <code>max</code> take one or more
|
||
arguments. The function <code>sum</code> takes zero or more arguments. Arguments
|
||
can be of different types (ints and floats).</p>
|
||
<p>Not to be confused with the <code>zsh/mathfunc</code> module, described in <a href="Zsh-Modules.html#The-zsh_002fmathfunc-Module">The
|
||
zsh/mathfunc Module</a>.</p>
|
||
<p><span id="index-zmathfuncdef"></span></p>
|
||
<p><code>zmathfuncdef</code> [ <code>mathfunc</code> [ <code>body</code> ] ]</p>
|
||
<p>A convenient front end to <code>functions -M</code>.</p>
|
||
<p>With two arguments, define a mathematical function named <code>mathfunc</code>
|
||
which can be used in any form of arithmetic evaluation. <code>body</code> is a
|
||
mathematical expression to implement the function. It may contain
|
||
references to position parameters <code>$1</code>, <code>$2</code>, ... to refer to mandatory
|
||
parameters and <code>${1:-``defvalue``}</code> ... to refer to optional parameters.
|
||
Note that the forms must be strictly adhered to for the function to
|
||
calculate the correct number of arguments. The implementation is held in
|
||
a shell function named <code>zsh_math_func_``mathfunc</code>; usually the user will
|
||
not need to refer to the shell function directly. Any existing function
|
||
of the same name is silently replaced.</p>
|
||
<p>With one argument, remove the mathematical function <code>mathfunc</code> as well
|
||
as the shell function implementation.</p>
|
||
<p>With no arguments, list all <code>mathfunc</code> functions in a form The functions
|
||
have not necessarily been defined by <code>zmathfuncdef</code>.</p>
|
||
<hr />
|
||
<p><span id="User-Configuration-Functions"></span>
|
||
<span id="User-Configuration-Functions-1"></span></p>
|
||
<h2 id="2611-user-configuration-functions"><a class="header" href="#2611-user-configuration-functions">26.11 User Configuration Functions</a></h2>
|
||
<p>The <code>zsh/newuser</code> module comes with a function to aid in configuring
|
||
shell options for new users. If the module is installed, this function
|
||
can also be run by hand. It is available even if the module’s default
|
||
behaviour, namely running the function for a new user logging in without
|
||
startup files, is inhibited.</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>zsh-newuser-install</code> [ <code>-f</code> ]<br />
|
||
The function presents the user with various options for customizing
|
||
their initialization scripts. Currently only <code>~/.zshrc</code> is handled.
|
||
<code>$ZDOTDIR/.zshrc</code> is used instead if the parameter <code>ZDOTDIR</code> is set;
|
||
this provides a way for the user to configure a file without
|
||
altering an existing <code>.zshrc</code>.</p>
|
||
<p>By default the function exits immediately if it finds any of the
|
||
files <code>.zshenv</code>, <code>.zprofile</code>, <code>.zshrc</code>, or <code>.zlogin</code> in the
|
||
appropriate directory. The option <code>-f</code> is required in order to force
|
||
the function to continue. Note this may happen even if <code>.zshrc</code>
|
||
itself does not exist.</p>
|
||
<p>As currently configured, the function will exit immediately if the
|
||
user has root privileges; this behaviour cannot be overridden.</p>
|
||
<p>Once activated, the function’s behaviour is supposed to be
|
||
self-explanatory. Menus are present allowing the user to alter the
|
||
value of options and parameters. Suggestions for improvements are
|
||
always welcome.</p>
|
||
<p>When the script exits, the user is given the opportunity to save the
|
||
new file or not; changes are not irreversible until this point.
|
||
However, the script is careful to restrict changes to the file only
|
||
to a group marked by the lines ‘<code># Lines configured by zsh-newuser-install</code>’ and ‘<code># End of lines configured by zsh-newuser-install</code>’. In addition, the old version of <code>.zshrc</code> is
|
||
saved to a file with the suffix <code>.zni</code> appended.</p>
|
||
<p>If the function edits an existing <code>.zshrc</code>, it is up to the user to
|
||
ensure that the changes made will take effect. For example, if
|
||
control usually returns early from the existing <code>.zshrc</code> the lines
|
||
will not be executed; or a later initialization file may override
|
||
options or parameters, and so on. The function itself does not
|
||
attempt to detect any such conflicts.</p>
|
||
</li>
|
||
</ul>
|
||
<hr />
|
||
<p><span id="Other-Functions"></span> <span id="Other-Functions-1"></span></p>
|
||
<h2 id="2612-other-functions"><a class="header" href="#2612-other-functions">26.12 Other Functions</a></h2>
|
||
<p>There are a large number of helpful functions in the <code>Functions/Misc</code>
|
||
directory of the zsh distribution. Most are very simple and do not
|
||
require documentation here, but a few are worthy of special mention.</p>
|
||
<hr />
|
||
<p><span id="Descriptions"></span></p>
|
||
<h3 id="26121-descriptions"><a class="header" href="#26121-descriptions">26.12.1 Descriptions</a></h3>
|
||
<p><span id="index-colors"></span></p>
|
||
<p><code>colors</code></p>
|
||
<p>This function initializes several associative arrays to map color names
|
||
to (and from) the ANSI standard eight-color terminal codes. These are
|
||
used by the prompt theme system (<a href="User-Contributions.html#Prompt-Themes">Prompt Themes</a>). You
|
||
seldom should need to run <code>colors</code> more than once.</p>
|
||
<p>The eight base colors are: <code>black</code>, <code>red</code>, <code>green</code>, <code>yellow</code>, <code>blue</code>,
|
||
<code>magenta</code>, <code>cyan</code>, and <code>white</code>. Each of these has codes for foreground
|
||
and background. In addition there are seven intensity attributes:
|
||
<code>bold</code>, <code>faint</code>, <code>standout</code>, <code>underline</code>, <code>blink</code>, <code>reverse</code>, and
|
||
<code>conceal</code>. Finally, there are seven codes used to negate attributes:
|
||
<code>none</code> (reset all attributes to the defaults), <code>normal</code> (neither bold
|
||
nor faint), <code>no-standout</code>, <code>no-underline</code>, <code>no-blink</code>, <code>no-reverse</code>, and
|
||
<code>no-conceal</code>.</p>
|
||
<p>Some terminals do not support all combinations of colors and
|
||
intensities.</p>
|
||
<p>The associative arrays are:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>color</code><br />
|
||
<code>colour</code><br />
|
||
Map all the color names to their integer codes, and integer codes to
|
||
the color names. The eight base names map to the foreground color
|
||
codes, as do names prefixed with ‘<code>fg-</code>’, such as ‘<code>fg-red</code>’. Names
|
||
prefixed with ‘<code>bg-</code>’, such as ‘<code>bg-blue</code>’, refer to the background
|
||
codes. The reverse mapping from code to color yields base name for
|
||
foreground codes and the <code>bg-</code> form for backgrounds.</p>
|
||
<p>Although it is a misnomer to call them ‘colors’, these arrays also
|
||
map the other fourteen attributes from names to codes and codes to
|
||
names.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>fg</code><br />
|
||
<code>fg_bold</code><br />
|
||
<code>fg_no_bold</code><br />
|
||
Map the eight basic color names to ANSI terminal escape sequences
|
||
that set the corresponding foreground text properties. The <code>fg</code>
|
||
sequences change the color without changing the eight intensity
|
||
attributes.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>bg</code><br />
|
||
<code>bg_bold</code><br />
|
||
<code>bg_no_bold</code><br />
|
||
Map the eight basic color names to ANSI terminal escape sequences
|
||
that set the corresponding background properties. The <code>bg</code> sequences
|
||
change the color without changing the eight intensity attributes.</p>
|
||
</li>
|
||
</ul>
|
||
<p>In addition, the scalar parameters <code>reset_color</code> and <code>bold_color</code> are
|
||
set to the ANSI terminal escapes that turn off all attributes and turn
|
||
on bold intensity, respectively.</p>
|
||
<p><span id="index-fned"></span></p>
|
||
<p><code>fned</code> [ <code>-x</code> <code>num</code> ] <code>name</code></p>
|
||
<p>Same as <code>zed -f</code>. This function does not appear in the zsh distribution,
|
||
but can be created by linking <code>zed</code> to the name <code>fned</code> in some directory
|
||
in your <code>fpath</code>.</p>
|
||
<p><span id="index-is_002dat_002dleast"></span></p>
|
||
<p><code>is-at-least</code> <code>needed</code> [ <code>present</code> ]</p>
|
||
<p>Perform a greater-than-or-equal-to comparison of two strings having the
|
||
format of a zsh version number; that is, a string of numbers and text
|
||
with segments separated by dots or dashes. If the <code>present</code> string is
|
||
not provided, <code>$ZSH_VERSION</code> is used. Segments are paired left-to-right
|
||
in the two strings with leading non-number parts ignored. If one string
|
||
has fewer segments than the other, the missing segments are considered
|
||
zero.</p>
|
||
<p>This is useful in startup files to set options and other state that are
|
||
not available in all versions of zsh.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">is-at-least 3.1.6-15 && setopt NO_GLOBAL_RCS
|
||
is-at-least 3.1.0 && setopt HIST_REDUCE_BLANKS
|
||
is-at-least 2.6-17 || print "You can't use is-at-least here."
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-nslookup"></span></p>
|
||
<p><code>nslookup</code> [ <code>arg</code> ... ]</p>
|
||
<p>This wrapper function for the <code>nslookup</code> command requires the <code>zsh/zpty</code>
|
||
module (see <a href="Zsh-Modules.html#The-zsh_002fzpty-Module">The zsh/zpty
|
||
Module</a>). It behaves exactly
|
||
like the standard <code>nslookup</code> except that it provides customizable
|
||
prompts (including a right-side prompt) and completion of nslookup
|
||
commands, host names, etc. (if you use the function-based completion
|
||
system). Completion styles may be set with the context prefix
|
||
‘<code>:completion:nslookup</code>’.</p>
|
||
<p>See also the <code>pager</code>, <code>prompt</code> and <code>rprompt</code> styles below.</p>
|
||
<p><span id="index-regexp_002dreplace"></span></p>
|
||
<p><code>regexp-replace</code> <code>var</code> <code>regexp</code> <code>replace</code></p>
|
||
<p>Use regular expressions to perform a global search and replace operation
|
||
on a variable. POSIX extended regular expressions are used, unless the
|
||
option <code>RE_MATCH_PCRE</code> has been set, in which case Perl-compatible
|
||
regular expressions are used (this requires the shell to be linked
|
||
against the <code>pcre</code> library).</p>
|
||
<p><code>var</code> is the name of the variable containing the string to be matched.
|
||
The variable will be modified directly by the function. The variables
|
||
<code>MATCH</code>, <code>MBEGIN</code>, <code>MEND</code>, <code>match</code>, <code>mbegin</code>, <code>mend</code> should be avoided
|
||
as these are used by the regular expression code.</p>
|
||
<p><code>regexp</code> is the regular expression to match against the string.</p>
|
||
<p><code>replace</code> is the replacement text. This can contain parameter, command
|
||
and arithmetic expressions which will be replaced: in particular, a
|
||
reference to <code>$MATCH</code> will be replaced by the text matched by the
|
||
pattern.</p>
|
||
<p>The return status is 0 if at least one match was performed, else 1.</p>
|
||
<p><span id="index-run_002dhelp-1"></span></p>
|
||
<p><code>run-help</code> <code>cmd</code></p>
|
||
<p>This function is designed to be invoked by the <code>run-help</code> ZLE widget, in
|
||
place of the default alias. See ‘Accessing On-Line Help’
|
||
(<a href="User-Contributions.html#Utilities">Utilities</a>) for setup instructions.</p>
|
||
<p>In the discussion which follows, if <code>cmd</code> is a file system path, it is
|
||
first reduced to its rightmost component (the file name).</p>
|
||
<p>Help is first sought by looking for a file named <code>cmd</code> in the directory
|
||
named by the <code>HELPDIR</code> parameter. If no file is found, an assistant
|
||
function, alias, or command named <code>run-help-cmd</code> is sought. If found,
|
||
the assistant is executed with the rest of the current command line
|
||
(everything after the command name <code>cmd</code>) as its arguments. When neither
|
||
file nor assistant is found, the external command ‘<code>man</code> <code>cmd</code>’ is run.</p>
|
||
<p>An example assistant for the "ssh" command:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">run-help-ssh() {
|
||
emulate -LR zsh
|
||
local -a args
|
||
# Delete the "-l username" option
|
||
zparseopts -D -E -a args l:
|
||
# Delete other options, leaving: host command
|
||
args=(${@:#-*})
|
||
if [[ ${#args} -lt 2 ]]; then
|
||
man ssh
|
||
else
|
||
run-help $args[2]
|
||
fi
|
||
}
|
||
</code></pre>
|
||
</div>
|
||
<p>Several of these assistants are provided in the <code>Functions/Misc</code> your
|
||
search path, in order to be found and used by <code>run-help</code>.</p>
|
||
<p><span id="index-run_002dhelp_002dgit"></span>
|
||
<span id="index-run_002dhelp_002dip"></span>
|
||
<span id="index-run_002dhelp_002dopenssl"></span>
|
||
<span id="index-run_002dhelp_002dp4"></span>
|
||
<span id="index-run_002dhelp_002dsudo"></span>
|
||
<span id="index-run_002dhelp_002dsvk"></span>
|
||
<span id="index-run_002dhelp_002dsvn"></span></p>
|
||
<p>run-help-git</p>
|
||
<p>run-help-ip</p>
|
||
<p>run-help-openssl</p>
|
||
<p>run-help-p4</p>
|
||
<p>run-help-sudo</p>
|
||
<p>run-help-svk</p>
|
||
<p><code>run-help-svn</code></p>
|
||
<p>Assistant functions for the <code>git</code>, <code>ip</code>, <code>openssl</code>, <code>p4</code>, <code>sudo</code>, <code>svk</code>,
|
||
and <code>svn</code>, commands.</p>
|
||
<p><code>tetris</code></p>
|
||
<p>Zsh was once accused of not being as complete as Emacs, because it
|
||
lacked a Tetris game. This function was written to refute this vicious
|
||
slander.</p>
|
||
<p>This function must be used as a ZLE widget:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">autoload -U tetris
|
||
zle -N tetris
|
||
bindkey keys tetris
|
||
</code></pre>
|
||
</div>
|
||
<p>To start a game, execute the widget by typing the <code>keys</code>. Whatever
|
||
command line you were editing disappears temporarily, and your keymap is
|
||
also temporarily replaced by the Tetris control keys. The previous
|
||
editor state is restored when you quit the game (by pressing ‘<code>q</code>’) or
|
||
when you lose.</p>
|
||
<p>If you quit in the middle of a game, the next invocation of the <code>tetris</code>
|
||
widget will continue where you left off. If you lost, it will start a
|
||
new game.</p>
|
||
<p><code>tetriscurses</code></p>
|
||
<p>This is a port of the above to zcurses. The input handling is improved a
|
||
bit so that moving a block sideways doesn’t automatically advance a
|
||
timestep, and the graphics use unicode block graphics.</p>
|
||
<p>This version does not save the game state between invocations, and is
|
||
not invoked as a widget, but rather as:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">autoload -U tetriscurses
|
||
tetriscurses
|
||
</code></pre>
|
||
</div>
|
||
<p><span id="index-zargs"></span></p>
|
||
<p><code>zargs</code> [ <code>option</code> ... <code>-``-</code> ] [ <code>input</code> ... ] [ <code>-``-</code> <code>command</code>
|
||
[ <code>arg</code> ... ] ]</p>
|
||
<p>This function has a similar purpose to GNU xargs. Instead of reading
|
||
lines of arguments from the standard input, it takes them from the
|
||
command line. This is useful because zsh, especially with recursive glob
|
||
operators, often can construct a command line for a shell function that
|
||
is longer than can be accepted by an external command.</p>
|
||
<p>The <code>option</code> list represents options of the <code>zargs</code> command itself,
|
||
which are the same as those of <code>xargs</code>. The <code>input</code> list is the
|
||
collection of strings (often file names) that become the arguments of
|
||
the <code>command</code>, analogous to the standard input of <code>xargs</code>. Finally, the
|
||
<code>arg</code> list consists of those arguments (usually options) that are passed
|
||
to the <code>command</code> each time it runs. The <code>arg</code> list precedes the elements
|
||
from the <code>input</code> list in each run. If no <code>command</code> is provided, then no
|
||
<code>arg</code> list may be provided, and in that event the default command is
|
||
‘<code>print</code>’ with arguments ‘<code>-r -``-</code>’.</p>
|
||
<p>For example, to get a long <code>ls</code> listing of all non-hidden plain files in
|
||
the current directory or its subdirectories:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">autoload -U zargs
|
||
zargs -- **/*(.) -- ls -ld --
|
||
</code></pre>
|
||
</div>
|
||
<p>The first and third occurrences of ‘<code>-``-</code>’ are used to mark the end of
|
||
options for <code>zargs</code> and <code>ls</code> respectively to guard against filenames
|
||
starting with ‘<code>-</code>’, while the second is used to separate the list of
|
||
files from the command to run (‘<code>ls -ld –</code>’).</p>
|
||
<p>The first ‘<code>-``-</code>’ would also be needed if there was a chance the list
|
||
might be empty as in:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zargs -r -- ./*.back(#qN) -- rm -f
|
||
</code></pre>
|
||
</div>
|
||
<p>In the event that the string ‘<code>-``-</code>’ is or may be an <code>input</code>, the <code>-e</code>
|
||
option may be used to change the end-of-inputs marker. Note that this
|
||
does <em>not</em> change the end-of-options marker. For example, to use ‘<code>..</code>’
|
||
as the marker:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zargs -e.. -- **/*(.) .. ls -ld --
|
||
</code></pre>
|
||
</div>
|
||
<p>This is a good choice in that example because no plain file can be named
|
||
‘<code>..</code>’, but the best end-marker depends on the circumstances.</p>
|
||
<p>The options <code>-i</code>, <code>-I</code>, <code>-l</code>, <code>-L</code>, and <code>-n</code> differ slightly from their
|
||
usage in <code>xargs</code>. There are no input lines for <code>zargs</code> to count, so <code>-l</code>
|
||
and <code>-L</code> count through the <code>input</code> list, and <code>-n</code> counts the number of
|
||
arguments passed to each execution of <code>command</code>, <em>including</em> any <code>arg</code>
|
||
list. Also, any time <code>-i</code> or <code>-I</code> is used, each <code>input</code> is processed
|
||
separately as if by ‘<code>-L</code> <code>1</code>’.</p>
|
||
<p>For details of the other <code>zargs</code> options, see man page xargs(1) (but
|
||
note the difference in function between <code>zargs</code> and <code>xargs</code>) or run
|
||
<code>zargs</code> with the <code>-``-help</code> option.</p>
|
||
<p><span id="index-zed"></span></p>
|
||
<p><code>zed</code> [ <code>-f</code> [ <code>-x</code> <code>num</code> ] ] <code>name</code></p>
|
||
<p><code>zed -b</code></p>
|
||
<p>This function uses the ZLE editor to edit a file or function.</p>
|
||
<p>Only one <code>name</code> argument is allowed. If the <code>-f</code> option is given, the
|
||
name is taken to be that of a function; if the function is marked for
|
||
autoloading, <code>zed</code> searches for it in the <code>fpath</code> and loads it. Note
|
||
that functions edited this way are installed into the current shell, but
|
||
<em>not</em> written back to the autoload file. In this case the <code>-x</code> option
|
||
specifies that leading tabs indenting the function according to syntax
|
||
should be converted into the given number of spaces; ‘<code>-x 2</code>’ is
|
||
consistent with the layout of functions distributed with the shell.</p>
|
||
<p>Without <code>-f</code>, <code>name</code> is the path name of the file to edit, which need
|
||
not exist; it is created on write, if necessary.</p>
|
||
<p>While editing, the function sets the main keymap to <code>zed</code> and the vi
|
||
command keymap to <code>zed-vicmd</code>. These will be copied from the existing
|
||
<code>main</code> and <code>vicmd</code> keymaps if they do not exist the first time <code>zed</code> is
|
||
run. They can be used to provide special key bindings used only in zed.</p>
|
||
<p>If it creates the keymap, <code>zed</code> rebinds the return key to insert a line
|
||
break and ‘<code>^X^W</code>’ to accept the edit in the <code>zed</code> keymap, and binds
|
||
‘<code>ZZ</code>’ to accept the edit in the <code>zed-vicmd</code> keymap.</p>
|
||
<p>The bindings alone can be installed by running ‘<code>zed -b</code>’. This is this
|
||
will overwrite the existing <code>zed</code> and <code>zed-vicmd</code> keymaps.</p>
|
||
<p>Completion is available, and styles may be set with the context prefix
|
||
‘<code>:completion:zed</code>’.</p>
|
||
<p>A zle widget <code>zed-set-file-name</code> is available. This can be called by
|
||
name from within zed using ‘<code>\ex zed-set-file-name</code>’ (note, however,
|
||
that because of zed’s rebindings you will have to type <code>^j</code> at the end
|
||
instead of the return key), or can be bound to a key in either of the
|
||
<code>zed</code> or <code>zed-vicmd</code> keymaps after ‘<code>zed -b</code>’ has been run. When the
|
||
widget is called, it prompts for a new name for the file being edited.
|
||
When zed exits the file will be written under that name and the original
|
||
file will be left alone. The widget has no effect with ‘<code>zed -f</code>’.</p>
|
||
<p>While <code>zed-set-file-name</code> is running, zed uses the keymap
|
||
<code>zed-normal-keymap</code>, which is linked from the main keymap in effect at
|
||
the time zed initialised its bindings. (This is to make the return key
|
||
operate normally.) The result is that if the main keymap has been
|
||
changed, the widget won’t notice. This is not a concern for most users.</p>
|
||
<p><span id="index-zcp"></span> <span id="index-zln"></span></p>
|
||
<p><code>zcp</code> [ <code>-finqQvwW</code> ] <code>srcpat</code> <code>dest</code></p>
|
||
<p><code>zln</code> [ <code>-finqQsvwW</code> ] <code>srcpat</code> <code>dest</code></p>
|
||
<p>Same as <code>zmv -C</code> and <code>zmv -L</code>, respectively. These functions do not
|
||
appear in the zsh distribution, but can be created by linking <code>zmv</code> to
|
||
the names <code>zcp</code> and <code>zln</code> in some directory in your <code>fpath</code>.</p>
|
||
<p><code>zkbd</code></p>
|
||
<p>See ‘Keyboard Definition’ (<a href="User-Contributions.html#Utilities">Utilities</a>).</p>
|
||
<p><span id="index-zmv"></span></p>
|
||
<p><code>zmv</code> [ <code>-finqQsvwW</code> ] [ <code>-C</code> | <code>-L</code> | <code>-M</code> | -{<code>p</code>|<code>P</code>} <code>program</code> ]
|
||
[ <code>-o</code> <code>optstring</code> ]</p>
|
||
<p><code> ``srcpat</code> <code>dest</code></p>
|
||
<p>Move (usually, rename) files matching the pattern <code>srcpat</code> to
|
||
corresponding files having names of the form given by <code>dest</code>, where
|
||
<code>srcpat</code> contains parentheses surrounding patterns which will be
|
||
replaced in turn by <code>$1</code>, <code>$2</code>, ... in <code>dest</code>. For example,</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zmv '(*).lis' '$1.txt'
|
||
</code></pre>
|
||
</div>
|
||
<p>renames ‘<code>foo.lis</code>’ to ‘<code>foo.txt</code>’, ‘<code>my.old.stuff.lis</code>’ to
|
||
‘<code>my.old.stuff.txt</code>’, and so on.</p>
|
||
<p>The pattern is always treated as an <code>EXTENDED_GLOB</code> pattern. Any file
|
||
whose name is not changed by the substitution is simply ignored. Any
|
||
error (a substitution resulted in an empty string, two substitutions
|
||
gave the same result, the destination was an existing regular file and
|
||
<code>-f</code> was not given) causes the entire function to abort without doing
|
||
anything.</p>
|
||
<p>In addition to pattern replacement, the variable <code>$f</code> can be referrred
|
||
to in the second (replacement) argument. This makes it possible to use
|
||
variable substitution to alter the argument; see examples below.</p>
|
||
<p>Options:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>-f</code><br />
|
||
Force overwriting of destination files. Not currently passed down to
|
||
the <code>mv</code>/<code>cp</code>/<code>ln</code> command due to vagaries of implementations (but
|
||
you can use <code>-o-f</code> to do that).</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-i</code><br />
|
||
Interactive: show each line to be executed and ask the user whether
|
||
to execute it. ‘<code>Y</code>’ or ‘<code>y</code>’ will execute it, anything else will
|
||
skip it. Note that you just need to type one character.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-n</code><br />
|
||
No execution: print what would happen, but don’t do it.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-q</code><br />
|
||
Turn bare glob qualifiers off: now assumed by default, so this has
|
||
no effect.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-Q</code><br />
|
||
Force bare glob qualifiers on. Don’t turn this on unless you are
|
||
actually using glob qualifiers in a pattern.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-s</code><br />
|
||
Symbolic, passed down to <code>ln</code>; only works with <code>-L</code>.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-v</code><br />
|
||
Verbose: print each command as it’s being executed.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-w</code><br />
|
||
Pick out wildcard parts of the pattern, as described above, and
|
||
implicitly add parentheses for referring to them.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-W</code><br />
|
||
Just like <code>-w</code>, with the addition of turning wildcards in the
|
||
replacement pattern into sequential <code>${1}</code> .. <code>${N}</code> references.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-C</code><br />
|
||
<code>-L</code><br />
|
||
<code>-M</code><br />
|
||
Force <code>cp</code>, <code>ln</code> or <code>mv</code>, respectively, regardless of the name of
|
||
the function.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-p</code> <code>program</code><br />
|
||
Call <code>program</code> instead of <code>cp</code>, <code>ln</code> or <code>mv</code>. Whatever it does, it
|
||
should at least understand the form</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">program -- oldname newname
|
||
</code></pre>
|
||
</div>
|
||
<p>where <code>oldname</code> and <code>newname</code> are filenames generated by <code>zmv</code>.
|
||
<code>program</code> will be split into words, so might be e.g. the name of an
|
||
archive tool plus a copy or rename subcommand.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-P</code> <code>program</code><br />
|
||
As <code>-p</code> <code>program</code>, except that <code>program</code> does not accept a following
|
||
<code>-``-</code> to indicate the end of options. In this case filenames must
|
||
already be in a sane form for the program in question.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>-o</code> <code>optstring</code><br />
|
||
The <code>optstring</code> is split into words and passed down verbatim to the
|
||
<code>cp</code>, <code>ln</code> or <code>mv</code> command called to perform the work. It should
|
||
probably begin with a ‘<code>-</code>’.</p>
|
||
</li>
|
||
</ul>
|
||
<p>Further examples:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zmv -v '(* *)' '${1// /_}'
|
||
</code></pre>
|
||
</div>
|
||
<p>For any file in the current directory with at least one space in the
|
||
name, replace every space by an underscore and display the commands
|
||
executed.</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zmv -v '* *' '${f// /_}'
|
||
</code></pre>
|
||
</div>
|
||
<p>This does exactly the same by referring to the file name stored in <code>$f</code>.</p>
|
||
<p>For more complete examples and other implementation details, see the
|
||
<code>zmv</code> source file, usually located in one of the directories named in
|
||
your <code>fpath</code>, or in <code>Functions/Misc/zmv</code> in the zsh distribution.</p>
|
||
<p><code>zrecompile</code></p>
|
||
<p>See ‘Recompiling Functions’ (<a href="User-Contributions.html#Utilities">Utilities</a>).</p>
|
||
<p><span id="index-zstyle_002b"></span></p>
|
||
<p><code>zstyle+</code> <code>context</code> <code>style</code> <code>value</code> [ <code>+</code> <code>subcontext</code> <code>style</code> <code>value</code>
|
||
... ]</p>
|
||
<p>This makes defining styles a bit simpler by using a single ‘<code>+</code>’ as a
|
||
special token that allows you to append a context name to the previously
|
||
used context name. Like this:</p>
|
||
<div class="example">
|
||
<pre><code class="language-example">zstyle+ ':foo:bar' style1 value1 \
|
||
+':baz' style2 value2 \
|
||
+':frob' style3 value3
|
||
</code></pre>
|
||
</div>
|
||
<p>This defines <code>style1</code> with <code>value1</code> for the context <code>:foo:bar</code> as usual,
|
||
but it also defines <code>style2</code> with <code>value2</code> for the context
|
||
<code>:foo:bar:baz</code> and <code>style3</code> with <code>value3</code> for <code>:foo:bar:frob</code>. Any
|
||
<code>subcontext</code> may be the empty string to re-use the first context
|
||
unchanged.</p>
|
||
<hr />
|
||
<p><span id="Styles-2"></span></p>
|
||
<h3 id="26122-styles"><a class="header" href="#26122-styles">26.12.2 Styles</a></h3>
|
||
<p><span id="index-insert_002dtab_002c-completion-style-1"></span></p>
|
||
<p><code>insert-tab</code></p>
|
||
<p>The <code>zed</code> function <em>sets</em> this style in context ‘<code>:completion:zed:*</code>’ to
|
||
turn off completion when <code>TAB</code> is typed at the beginning of a line. You
|
||
may override this by setting your own value for this context and style.</p>
|
||
<p><span id="index-pager_002c-nslookup-style"></span></p>
|
||
<p><code>pager</code></p>
|
||
<p>The <code>nslookup</code> function looks up this style in the context ‘<code>:nslookup</code>’
|
||
to determine the program used to display output that does not fit on a
|
||
single screen.</p>
|
||
<p><span id="index-prompt_002c-nslookup-style"></span>
|
||
<span id="index-rprompt_002c-nslookup-style"></span></p>
|
||
<p><code>prompt</code></p>
|
||
<p><code>rprompt</code></p>
|
||
<p>The <code>nslookup</code> function looks up this style in the context ‘<code>:nslookup</code>’
|
||
to set the prompt and the right-side prompt, respectively. The usual
|
||
expansions for the <code>PS1</code> and <code>RPS1</code> parameters may be used (see <a href="Prompt-Expansion.html#Prompt-Expansion">Prompt
|
||
Expansion</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 -->
|
||
|
||
|
||
|
||
|
||
<div style="clear: both"></div>
|
||
</nav>
|
||
</div>
|
||
</div>
|
||
|
||
<nav class="nav-wide-wrapper" aria-label="Page navigation">
|
||
|
||
|
||
|
||
</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 -->
|
||
|
||
|
||
|
||
|
||
<script type="text/javascript">
|
||
window.addEventListener('load', function() {
|
||
window.setTimeout(window.print, 100);
|
||
});
|
||
</script>
|
||
|
||
|
||
|
||
</body>
|
||
</html>
|