Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Z-Shell Frequently-Asked Questions (monthly posting)
- From: P.Stephenson@xxxxxxxxxxxxx
- To: zsh-announce@xxxxxxxxxxxx
- Subject: Z-Shell Frequently-Asked Questions (monthly posting)
- Date: Wed, 24 Jan 96 12:48:33 +0000
Archive-Name: unix-faq/shell/zsh
Last-Modified: 1996/01/24
Submitted-By: pws@xxxxxxxxxxxxxx (Peter Stephenson)
Version: $Id: zsh.FAQ,v 2.9 1996/01/24 12:48:00 pypeters Exp pypeters $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996 (see end of document)
Changes since last issue:
- In A4: new beta version
This document contains a list of frequently-asked (or otherwise
significant) questions concerning the Z-shell, a command interpreter for
many UNIX systems which is freely available to anyone with FTP access.
In fact, zsh is currently the most powerful freely available shell.
If you have never heard of `sh', `csh' or `ksh', then you are probably
better off to start by reading a general introduction to UNIX rather
than this document.
If you just want to know how to get your hands on the latest version,
skip to question A5); if you want to know what to do with insoluble
problems, go to Z2).
Notation: Quotes `like this' are ordinary textual quotation
marks. Other uses of quotation marks are input to the shell.
Contents:
Section A: Introducing zsh and how to install it
A0) Sources of information
A1) What is it?
A2) What is good at?
A3) On what machines will it run? (Plus important compilation notes)
A4) What's the latest version?
A5) Where do I get it?
A6) I don't have root access: how do I make zsh my login shell?
Section B: How does zsh differ from...?
B1) sh and ksh?
B2) csh?
B3) Why do my csh aliases not work? (Plus other alias pitfalls.)
B4) tcsh?
B5) bash?
B6) Shouldn't zsh be more/less like ksh/(t)csh?
Section C: How to get various things to work
C1) How do I turn off spelling correction for an individual command?
C2) How do I get the meta key to work on my xterm?
C3) Why does my terminal act funny in some way?
C4) Why does `$var' where var="foo bar" not do what I expect?
C5) Why do my autoloaded functions not autoload [the first time]?
C6) How does base arithmetic work?
C7) How do I get a newline in my prompt?
C8) Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
C9) Why can't I bind \C-s and \C-q any more?
C10) How do I execute command `foo' within function `foo'?
C11) Why do history substitutions with single bangs do something funny?
C12) Why does zsh kill off all my background jobs when I logout?
Section D: The mysteries of completion
D1) What is completion?
D2) What sorts of things can be completed?
D3) How does zsh deal with ambiguous completions?
D4) How do I get started with programmable completion?
D5) And if programmable completion isn't good enough?
Section Z: The future of zsh
Z1) What bugs are currently known and unfixed?
Z2) Where do I report bugs, get more info / who's working on zsh?
Z3) What's on the wish-list?
Acknowledgments
Copyright
--- End of Contents ---
Section A: Introducing zsh and how to install it
A0) Sources of information
Information on zsh is now available via the World Wide Web. The URL
is "http://www.mal.com/zsh/";. The server provides this FAQ and much
else (thanks to Mark Borges for this). The FAQ is at
"http://www.mal.com/zsh/FAQ/";.
Another useful source of information is the collection of FAQ articles
posted frequently to the Usenet news groups comp.unix.questions,
comp.unix.shells and comp.answers with answers to general questions
about UNIX. The fifth of the seven articles deals with shells,
including zsh, with a brief description of differences. (This article
also talks about shell startup files which would otherwise rate a
mention here.) There is also a separate FAQ on shell differences
and how to change your shell. Usenet FAQs are available via FTP
from rtfm.mit.edu and mirrors and also on the World Wide Web; see
USA http://www.cis.ohio-state.edu/hypertext/faq/usenet/top.html
UK http://www.lib.ox.ac.uk/internet/news/faq/comp.unix.shell.html
Netherlands http://www.cs.ruu.nl/wais/html/na-dir/unix-faq/shell/.html
The latest version of this FAQ is also available directly from any
of the zsh archive sites listed in question A5).
Note that if you are reading this file with GNU Emacs 19 and have my
cross-referencing package xref.el (soon to be part of Emacs, but
currently available from
http://python.swan.ac.uk/~pypeters/comp/xref.html), you can pick up
a version of this FAQ which is internally cross-referenced from:
http://python.swan.ac.uk/~pypeters/comp/zsh.FAQ
(As a lower-tech method of reading this in Emacs, you can type
\M-2 \C-x $ to make all the indented text vanish, then \M-0 \C-x $
when you are on the title you want.)
For any more eclectic information, you should contact the mailing
list: see question Z2).
A1) What is it?
Zsh is a UNIX command interpreter (shell) which of the standard shells
most resembles the Korn shell (ksh), although it is not completely
compatible. It includes enhancements of many types, notably in the
command-line editor, options for customising its behaviour, filename
globbing, features to make C-shell (csh) users feel more at home and
extra features drawn from tcsh (another `custom' shell).
It was written by Paul Falstad when a student at Princeton; however,
Paul doesn't maintain it any more and enquiries should be sent to
the mailing list (see question Z2). Zsh is distributed under a
standard Berkeley style copyright.
For more information, the files Doc/intro.txt or Doc/intro.troff
included with the source distribution are highly recommended. A list
of features is given in FEATURES, also with the source.
A2) What is it good at?
Here are some things that zsh is particularly good at. No claim of
exclusivity is made, especially as shells copy one another, though
in the areas of command line editing and globbing zsh is well ahead
of the competition. I am not aware of a major feature in any other
freely-available shell which zsh does not also have.
Command line editing:
programmable completion: incorporates the ability to use
the full power of zsh globbing (compctl -g),
multi-line commands editable as a single buffer (even files!),
variable editing (vared),
command buffer stack,
print text straight into the buffer for immediate editing (print -z),
execution of unbound commands,
menu completion,
variable, editing function and option name completion,
inline expansion of variables, history commands.
Globbing --- extremely powerful, including:
recursive globbing (cf. find),
file attribute qualifiers (size, type, etc. also cf. find),
full alternation and negation of patterns.
Handling of multiple redirections (simpler than tee).
Large number of options for tailoring.
Path expansion (=foo -> /usr/bin/foo).
Adaptable messages for spelling, watch, time as well as prompt
(including conditional expressions).
Named directories.
Comprehensive integer arithmetic.
Manipulation of arrays (including reverse subscripting).
Spelling correction.
A3) On what machines will it run?
Zsh was written for machines of the Berkeley UNIX family; most such
machines (and all the most popular) will run it without major
surgery. Modifications have been made so that it works under
SYSVR4-based operating systems such as Solaris 2.x and OSF/1. The
best thing is to suck it and see. Success has been obtained on
older SYSVR3 systems, but you may need to modify the code.
From version 2.6, the installation mechanism has been altered to use
GNU Autoconf, which should make it easier to recognise new machine
types. If you need to change something to support a new machine, it
would be appreciated if you could add any necessary preprocessor
code and alter configure.in to configure zsh automatically, then
send the required context diffs to the list (see question Z2).
To get it to work, retrieve the source distribution (see question
A5), un-gzip it, un-tar it and read the INSTALL file in the top
directory. Here are a couple of known installation problems at
present.
*Note for Solaris 2.2 and 2.3*: The UCB versions of the routines for
reading directories are not usable (the struct definitions are
incompatible with the ones assumed by zsh). The symptom of this is
that globbed filenames in the compiled version of zsh will be
missing the first two letters. To avoid this, make sure you compile
zsh without any reference to /usr/ucblib in (e.g.) your
LD_LIBRARY_PATH.
*Note for OSF/1 3.0*: There is apparently a bug in the header file
/usr/include/rpcsvc/ypclnt.h; the prototype for yp_all() has a
struct ypall_callback as its final argument, which should be a
pointer (struct ypall_callback *). This prevents compilation of
zle_tricky.c. If you can't modify the header file, make a
subdirectory called rpcsvc, copy ypclnt.h there, modify that copy,
and put a `-I.' argument into CFLAGS in Makefile for the Src
subdirectory when compiling.
*Note for users of nawk* (The following information comes from
Zoltan Hidvegi): On some systems nawk is broken and produces an
incorrect signames.h file. This make the signals code unusable. This
often happens on Ultrix, HP-UX, IRIX (?). Install gawk if you
experience such problems.
A4) What's the latest version?
Zsh 2.5.0 was the last major release: the final form is 2.5.03.
Many bugs were fixed after 2.3.1, which was the previous major
release, and there were many new features, notably programmable
completion. This version is known to have a bug with pipelines
inside other shell structures (now fixed in 2.6).
Work has now started on 2.6 and 2.6-beta13 is available; note that
even numbered minor versions are not released. Development of zsh
is usually patch by patch, with each intermediate version publicly
available. Note that this `open' development system does mean bugs
are sometimes introduced into the most recent archived version.
These are usually fixed quickly. Note also that as the shell
changes, it may become incompatible with older versions; see the
end of question Z1 for a partial list. Changes of this kind are
almost always forced by an awkward or unnecessary feature in the
original design (as perceived by current users), or to enhance
compatibility with other Bourne shell derivatives.
A5) Where do I get it?
Richard Coleman <zsh@xxxxxxxxxxxxxxx> is in charge of the archive.
The following are known mirrors (kept frequently up to date); the
first is the official archive site. All are available by anonymous
FTP.
USA ftp://ftp.math.gatech.edu/pub/zsh
ftp://ftp.sterling.com/zsh
ftp://ftp.rge.com/pub/shells/zsh
France ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh
UK ftp://mrrl.lut.ac.uk/zsh
(also by FSP at port 21)
Germany ftp://ftp.fu-berlin.de/pub/unix/shells/zsh
Norway ftp://ftp.uit.no/pub/unix/shells/zsh
Australia ftp://ftp.ips.oz.au/pub/packages/zsh
(If you don't understand URL's, the first thing after the ftp:// is
the hostname and the remainder after the / is the directory.)
The latest full release is in zsh.tar.gz in these directories. Note
that this is in gzip format: you will need GNU gzip from your
nearest GNU archive to unpack it. The up-to-the-minute development
version is in zsh-beta.tar.gz. There is also a version under RCS
control which may be more suitable for source hackers.
There is another similar version with a few extra features and bug
fixes, most of which will eventually propagate to the `official'
version. It is maintaind by Zoltan Hidvegi <hzoli@xxxxxxxxxx> and
is available from
ftp://bolyai.cs.elte.hu/pub/zsh/
(links to the Hungarian academic network from the rest of Europe are
expected to improve shortly).
A6) I don't have root access: how do I make zsh my login shell?
Unfortunately, on many machines you can't use `chsh' to change your
shell unless the name of the shell is contained in /etc/shells, so if
you have your own copy of zsh you need some sleight-of-hand to use it
when you log on. (Simply typing `zsh' is not really a solution since
you still have your original login shell waiting for when you exit.)
The basic idea is to use `exec <zsh-path>' to replace the current
shell with zsh. Often you can do this in a login file such as
.profile (if your shell is sh or ksh) or .login (if it's csh). Make
sure you have some way of altering the file (e.g. via FTP) before you
try this as `exec' is often rather unforgiving.
If you have zsh in a subdirectory `bin' of your home directory,
put this in .profile:
[ -f $HOME/bin/zsh ] && exec $HOME/bin/zsh -l
or if your login shell is csh or tcsh, put this in .login:
if ( -f ~/bin/zsh ) exec ~/bin/zsh -l
(in each case the -l tells zsh it is a login shell).
It's not a good idea to put this (even without the -l) into .cshrc,
at least without some tests on what the csh is supposed to be doing,
as that will cause _every_ instance of csh to turn into a zsh and
will cause csh scripts (yes, unfortunately some people write these)
which do not call `csh -f' to fail. If you want to tell xterm to
run zsh, change the SHELL environment variable to the full path of
zsh at the same time as you exec zsh (in fact, this is sensible for
consistency even if you aren't using xterm). If you have to exec
zsh from your .cshrc, a minimum safety check is `if ($?prompt) exec
zsh'.
If you like your login shell to appear in the process list as '-zsh',
you can link zsh to -zsh (e.g. by `ln -s ~/bin/zsh ~/bin/-zsh') and
change the exec to `exec -zsh'. (Make sure -zsh is in your path.)
This has the same effect as the `-l' option.
Footnote: if you DO have root access, make sure zsh goes in
/etc/shells on all appropriate machines, including NIS clients, or you
may have problems with FTP to that machine.
Section B: How does zsh differ from...?
As has already been mentioned, zsh is most similar to ksh, while many
of the additions are to please csh users. Here are some more detailed
notes.
B1) Differences from sh and ksh
Most features of ksh (and hence also of sh) are implemented in zsh;
problems can arise because the implementation is slightly different.
Note also that not all ksh's are the same either. I have based this
on the 11/16/88f version of ksh.
Various options can be turned on which will increase ksh
compatibility, though decrease zsh's abilities: see the manual
entries for GLOB_SUBST, IGNORE_BRACES (though brace expansion occurs
in some versions of ksh), KSH_OPTION_PRINT, NO_BAD_PATTERN,
NO_BANG_HIST, NO_EQUALS, NO_HUP, NO_NOMATCH, NO_RCS, NO_SHORT_LOOPS,
PROMPT_SUBST, RM_STAR_SILENT, SH_WORD_SPLIT (see question C4) and
SINGLE_LINE_ZLE. Of these, SH_WORD_SPLIT and NO_NOMATCH are the
most likely to spoil your ksh scripts if unset. Note that you can
also disable any built-in commands which get in your way. If
invoked as `ksh', the shell will try and set suitable options.
Here are some differences from ksh which might prove significant for
ksh programmers, some of which may be interpreted as bugs; there must
be more. Note that this list is deliberately rather full and that
most of the items are fairly minor. Those marked `*' perform in a
ksh-like manner if the shell is invoked with the name `ksh'.
Capitalised words with underlines refer to shell options.
Syntax:
* Shell word splitting: see question C4). (This is particularly
frequently asked about; use SH_WORD_SPLIT.)
Arrays are more csh-like than ksh-like:
subscripts start at 1, not 0; array[0] refers to array[1];
`$array' refers to the whole array, not $array[0];
braces are unnecessary: $a[1] == ${a[1]}, etc.
Coprocesses are established by `coproc'; `|&' behaves like csh.
Opening for both input and output via <> is not yet supported.
(This syntax does numeric globbing.)
Command line substitutions, globbing etc.:
* Failure to match a globbing pattern causes an error (use
NO_NOMATCH).
* The results of parameter substitutions are treated as plain text:
`foo="*"; print $foo' prints all files in ksh but * in zsh.
(GLOB_SUBST has just been added to fix this.)
On the other hand, `foo=*' does globbing immediately on the right
hand side of the assignment (the default behaviour may change).
The backslash in $(echo '\$x') is treated differently: in ksh, it
is not stripped, in zsh it is. (The `...` form gives the same in
both shells.)
The $((...)) version of numeric evaluation was not available before
version 2.6 (use $[...]).
$PSn do not do parameter substitution by default (use PROMPT_SUBST:
this still needs some fixing for complex substitutions).
Globbing does not allow ksh-style `pattern-lists'. Equivalents:
-------------------------------------------------------------------
ksh zsh Meaning
----- ----- ---------
!(foo) ^foo Anything but foo.
or foo1~foo2 Anything matching foo1 but foo2[1].
@(foo1|foo2|...) (foo1|foo2|...) One of foo1 or foo2 or ...
?(foo) (foo|) Zero or one occurrences of foo.
*(foo) (foo)# Zero or more occurrences of foo.
+(foo) (foo)## One or more occurrences of foo.
-------------------------------------------------------------------
The `^' and ~ forms and the two with `#' require EXTENDED_GLOB.
[1] Note that ~ is the only globbing operator to have a lower
precedence than `/'. For example, `**/foo~bar' matches any
file in a subdirectory called `foo', except where `bar'
occurred somewhere in the path (e.g. `users/barstaff/foo' will
be excluded by the ~ operator). As the `**' operator cannot
be grouped (inside parentheses it is treated as *), this is
the way to exclude some subdirectories from matching a `**'.
The right hand side of an assignment is globbed in zsh.
Unquoted assignments do file expansion after ':'s (intended for PATHs).
`integer' does not allow -i; integers in bases other than 10 do not
have "base#" prefixed to them when printed.
Command execution:
* There is no $ENV variable (use /etc/zshrc, ~/.zshrc; note also $ZDOTDIR).
$PATH is not searched for commands specified at invocation without -c.
Aliases and functions:
The order in which aliases and functions are defined is significant
(function definitions with () expand aliases -- see question B3).
Aliases and functions cannot be exported.
There are no tracked aliases: command hashing replaces these.
The use of aliases for key bindings is replaced by `bindkey'.
Traps and signals:
Traps and options are not local to functions; traps are not reset
automatically when called; traps are called as functions themselves
(this is a bug for the `trap "..." NAL' form of trap setting).
TRAPERR has become TRAPZERR (this was forced by UNICOS which has SIGERR).
Editing:
The options emacs, gmacs, trackall, viraw are not supported.
Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
become `bindkey -{e,v}'; for gmacs, go to emacs mode and use
`bindkey \^t gosmacs-transpose-characters'. `Trackall' is replaced
by `hashcmds'.
The `keyword' option does not exist and -k is instead interactivecomments.
(`keyword' will not be in the next ksh release either.)
Management of histories in multiple shells is different:
the history list is not saved and restored after each command.
\ does not escape editing chars (use ^V).
Not all ksh bindings are set (e.g. `<ESC>#'; try <ESC>q).
* # in an interactive shell is not treated as a comment by default.
Built-in commands:
Some built-ins (r, autoload, history, integer ...) were aliases in ksh.
There is no built-in command newgrp: use e.g. `alias newgrp="exec newgrp"'
`jobs' has no `-n' flag.
`read' has no `-s' flag.
In `let "i = foo"', foo is evaluated as a number, not an expression
(although in `let "i = $foo"' it is treated as an expression).
Other idiosyncrasies:
`select' always redisplays the list of selections on each loop.
B2) Similarities with csh
Although certain features aim to ease the withdrawal symptoms of csh
(ab)users, the syntax is in general rather different and you should
certainly not try to run scripts without modification. The c2z script
is provided with the source (in scripts/c2z) to help convert .cshrc
and .login files; see also the next question concerning aliases,
particularly those with arguments.
Csh-compatibility additions include:
Logout, rehash, source, (un)limit built-in commands.
*rc file for interactive shells.
Directory stacks.
Cshjunkie*, ignoreeof options.
The CSH_NULL_GLOB option.
>&, |& etc. redirection.
foreach ... loops; alternative syntax for other loops.
Alternative syntax `if ( ... ) ...' (also `for', `which'; this now
requires the CSH_JUNKIE_PAREN option).
$PROMPT as well as $PS1, $status as well as $?, $#argv as well as $#, ....
Escape sequences via % for prompts.
Special array variables $PATH etc. are colon-separated, $path are arrays.
!-type history (which may be turned off via `setopt nobanghist').
Arrays have csh-like features (see under B1)).
B3) Why do my csh aliases not work? (Plus other alias pitfalls.)
First of all, check you are using the syntax
alias newcmd='list of commands'
and not
alias newcmd 'list of commands'
which won't work. (It tells you if `newcmd' and `list of commands' are
already defined as aliases.)
Otherwise, your aliases probably contain references to the command
line of the form `\!*', etc. Zsh does not handle this behaviour as it
has shell functions which provide a way of solving this problem more
consistent with other forms of argument handling. For example, the
csh alias
alias cd 'cd \!*; echo $cwd'
can be replaced by the zsh function,
cd() { builtin cd $*; echo $PWD; }
(the `builtin' tells zsh to use its own `cd', avoiding an infinite loop)
or, perhaps better,
cd() { builtin cd $*; print -D $PWD; }
(which converts your home directory to a ~). In fact, this problem is
better solved by defining the special function chpwd() (see the manual).
Note also that the `;' at the end of the function is optional in zsh,
but not in ksh or sh (for sh's where it exists).
Here is Bart Schaefer's guide to converting csh aliases for zsh.
1. If the csh alias references "parameters" (\!:1 \!* etc.),
then in zsh you need a function (referencing $1 $* etc.).
Otherwise, you can use a zsh alias.
2. If you use a zsh function, you need to refer _at_least_ to
$* in the body (inside the { }). Parameters don't magically
appear inside the { } the way they get appended to an alias.
3. If the csh alias references its own name (alias rm "rm -i"),
then in a zsh function you need the "command" keyword
(function rm() { command rm -i $* }), but in a zsh alias
you don't (alias rm="rm -i").
4. If you have aliases that refer to each other (alias ls "ls -C";
alias lf "ls -F" ==> lf == ls -C -F) then you must either:
a. convert all of them to zsh functions; or
b. after converting, be sure your .zshrc defines all of your
aliases before it defines any of your functions.
Those first four are all you really need, but here are four more for
heavy csh alias junkies:
5. Mapping from csh alias "parameter referencing" into zsh function
(assuming shwordsplit is NOT set in zsh):
csh zsh
===== ==========
\!* $* (or $argv)
\!^ $1 (or $argv[1])
\!:1 $1
\!:2 $2 (or $argv[2], etc.)
\!$ $*[$#] (or $argv[$#], or $*[-1])
\!:1-4 $*[1,4]
\!:1- $*[1,$#-1] (or $*[1,-2])
\!^- $*[1,$#-1]
\!*:q "$@" ($*:q doesn't work (yet))
\!*:x $=* ($*:x doesn't work (yet))
6. Remember that it is NOT a syntax error in a zsh function to
refer to a position ($1, $2, etc.) greater than the number of
parameters. (E.g., in a csh alias, a reference to \!:5 will
cause an error if 4 or fewer arguments are given; in a zsh
function, $5 is the empty string if there are 4 or fewer
parameters.)
7. To begin a zsh alias with a - (dash, hyphen) character, use
"alias --":
csh zsh
=============== ==================
alias - "fg %-" alias -- -="fg %-"
8. Stay away from "alias -g" in zsh until you REALLY know what
you're doing.
There is one other serious problem with aliases: consider
alias l='/bin/ls -F'
l() { /bin/ls -la $* | more }
`l' in the function definition is in command position and is expanded
as an alias, defining `/bin/ls' and `-F' as functions which call
`/bin/ls', which gets a bit recursive. This can be avoided if you use
`function' to define a function, which doesn't expand aliases. It is
possible to argue for extra warnings somewhere in this mess. Luckily,
it is not possible to define `function' as an alias.
B4) Similarities with tcsh:
(The sections on csh apply too, of course.) Certain features have
been borrowed from tcsh, including $watch, run-help, $savehist,
$histlit, periodic commands etc., extended prompts, sched and which
built-ins. Programmable completion was inspired by, but is entirely
different to, tcsh's `complete'. (There is a perl script called
lete2ctl in the scripts directory of the source distribution to
convert `complete' to `compctl' statements.) This list is not
definitive: some features have gone in the other direction.
If you're missing the editor function run-fg-editor, try something
with bindkey -s (which binds a string to a keystroke), e.g.
bindkey -s '^z' '\eqfg %$EDITOR:t\n'
which pushes the current line onto the stack and tries to bring a job
with the basename of your editor into the foreground. Bindkey -s
allows limitless possibilities along these lines.
B5) Similarities with bash
Zsh has almost all the features that bash has (and much more); in
addition it is about twice as fast, though this is less impressive
than it sounds. With the new malloc by Sven Wischnowsky (only used
if you used `configure --enable-zsh-mem' when configuring), zsh uses
about the same amount of heap memory as bash, which was previously
the biggest gripe. The only feature I am aware of that zsh doesn't
have is setting a numerical value for ignoreeof --- it's always 10
--- but of course I don't use bash :-).
However, zsh has no claims towards Posix compliancy and will not use
GNU readline (zle is more powerful). In fact, bash is intended more
as an enhanced sh than a ksh work-alike; it doesn't handle [[ ... ]],
for example.
B6) Shouldn't zsh be more/less like ksh/(t)csh?
People often ask why zsh has all these `unnecessary' csh-like features,
or alternatively why zsh doesn't understand more csh syntax. This is
far from a definitive answer and the debate will no doubt continue.
Paul's object in writing zsh was to produce a ksh-like shell which
would have features familiar to csh users. For a long time, csh was
the preferred interactive shell and there is a strong resistance to
changing to something unfamiliar, hence the additional syntax and
CSH_JUNKIE options. This argument still holds. On the other hand,
the arguments for having what is close to a plug-in replacement for ksh
are, if anything, even more powerful: the deficiencies of csh as a
programming language are well known (look in any Usenet FAQ archive, e.g.
rtfm.mit.edu:pub/usenet-by-group/news.answers/unix-faq/shell/csh-whynot
if you are in any doubt) and zsh is able to run many standard scripts
such as /etc/rc.
Of course, this makes zsh rather large and feature-ridden so that it
seems to appeal mainly to hackers --- but note it is only slightly
larger than bash and tcsh, and uses much less memory and CPU time
than tcsh. The only answer, perhaps not entirely satisfactory, is
that you have to ignore the bits you don't want.
Section C: How to get various things to work
C1) How do I turn off spelling correction for an individual command?
You presumably have `setopt correctall' in an initialisation file, so
that zsh checks the spelling of each word in the command line. You
probably do not want this behaviour for commands which do not operate
on existing files.
The answer is to alias the offending command to itself with
`nocorrect' stuck on the front, e.g.
alias mkdir='nocorrect mkdir'
C2) How do I get the meta key to work on my xterm?
As stated in the manual, zsh needs to be told about the meta key by
using `bindkey -me' or `bindkey -mv' in your .zshrc or on the command
line. You probably also need to tell the terminal driver to allow the
`meta' bit of the character through; `stty pass8' is the usual
incantation. Sample .zshrc entry:
[[ $TERM = "xterm" ]] && stty pass8 && bindkey -me
or, on SYSVR4-ish systems without pass8,
[[ $TERM = "xterm" ]] && stty -parenb -istrip cs8 && bindkey -me
(disable parity detection, don't strip high bit, use 8-bit characters).
Make sure this comes *before* any bindkey entries in your .zshrc which
redefine keys normally defined in the emacs/vi keymap.
C3) Why does my terminal act funny in some way?
If you are using an OpenWindows cmdtool as your terminal, any
escape sequences (such as those produced by cursor keys) will be
swallowed up and never reach zsh. Either use shelltool or avoid
commands with escape sequences. You can also disable scrolling from
the cmdtool pane menu (which effectively turns it into a shelltool).
If you still want scrolling, try using an xterm with the scrollbar
activated.
If that's not the problem, and you are using stty to change some tty
settings, make sure you haven't asked zsh to freeze the tty settings:
type
ttyctl -u
before any stty commands you use.
On the other hand, if you aren't using stty and have problems you may
need the opposite: `ttyctl -f' freezes the terminal to protect it
from hiccups introduced by other programmes (kermit has been known to
do this).
If _that's_ not the problem, and you are having difficulties with
external commands (not part of zsh), and you think some terminal
setting is wrong (e.g. ^V is getting interpreted as `literal next
character' when you don't want it to be), try
ttyctl -u
STTY='lnext "^-"' commandname
(in this example), or just export STTY for all commands to see. Note
that zsh doesn't reset the terminal completely afterwards: just the
modes it uses itself and a number of special processing characters
(see the stty(1) manual page).
At some point there may be an overhaul which allows the terminal
modes used by the shell to be modified separately from those seen by
external programmes. This is partially implemented already: in 2.5,
the shell is less susceptible to mode changes inherited from
programmes than it used to be.
C4) Why does `$var' where var="foo bar" not do what I expect?
In most Bourne-shell derivatives, multiple-word variables such as
var="foo bar"
are split into words when passed to a command or used in a `for foo in
$var' loop. By default, zsh does not have that behaviour: the
variable remains intact. (This is not a bug! See below.) An option
(shwordsplit) exists to provide compatibility.
For example, defining the function args to show the number of its
arguments:
args() { echo $#; }
and with our definition of vble,
args $vble
produces the output `1'. After
setopt shwordsplit
the same function produces the output `2', as with sh and ksh.
Unless you need strict sh/ksh compatibility, you should ask yourself
whether you really want this behaviour, as it can produce unexpected
effects for variables with entirely innocuous embedded spaces. This
can cause horrendous quoting problems when invoking scripts from
other shells. The natural way to produce word-splitting behaviour
in zsh is via arrays. For example,
set -A array one two three twenty
(or
array=(one two three twenty)
if you prefer), followed by
args $array
produces the output `4', regardless of the setting of shwordsplit.
Arrays are also much more versatile than single strings.
Other ways of causing word splitting include a judicious use of
`eval':
sentence="Longtemps, je me suis couch\\'e de bonne heure."
eval "words=(\"$sentence\")"
after which $words is an array with the words of $sentence, or, less
standard but more reliable, turning on shwordsplit for one variable
only:
args ${=sentence}
always returns 8 with the above definition of `args'. (In older
versions of zsh, ${=foo} toggled shwordsplit; now it forces it on.)
Note also the "$@" method of word splitting is always available in zsh
functions and scripts (though strictly this does array splitting, not
word splitting).
Shwordsplit is set when zsh is invoked with the names `ksh' or `sh'.
C5) Why do my autoloaded functions not autoload [the first time]?
When you put a shell function in an autoload directory (i.e. one
mentioned in $FPATH), it should be written just as if it were a
shell script. In other words, there should be no line at the
beginning saying `function foo {' or `foo () {', and consequently no
matching '}' at the end. If you include those, then the first time
you try to use the function, the _whole_ file is run --- in other
words, zsh simply defines the function and does nothing else.
As a concrete example, if you have a function which you would define
on the command line as `xhead () { print -n "\033]2;$*\a"; }' and
your have assigned `FPATH=~/fns', then your .zshrc should contain
`autoload xhead' and the file ~/fns/xhead should contain only
`print -n "\033]2;$*\a"'. (A neat trick to autoload all functions
in a given directory is to include a line like `autoload ~/fns/*(:t)'
in .zshrc; the bit in parentheses removes the directory part of the
filenames, leaving just the function names.)
The shell has just (version 2.6 beta 5) been enhanced to allow the
Korn shell syntax, where the file contains the whole function
including the definition lines. However, the form given above is
unlikely to disappear as it allows significant benefits, including
using a function directly as a script, and being able to link a
function under different names.
C6) How does base arithmetic work?
The ksh syntax is now understood, i.e.
let 'foo = 16#ff'
or equivalently
(( foo = 16#ff ))
or even
foo=$[16#ff]
(note that `foo=$((16#ff))' is supported from version 2.6 onward).
The original syntax was
(( foo = [16]ff ))
--- this was based on a misunderstanding of the ksh manual page. It
still works but its use is deprecated.
Then
echo $foo
gives the answer `255'. It is possible to declare variables explicitly
to be integers, via
typeset -i foo
which has a different effect: namely the base used in the first
assignment (hexadecimal in the example) is subsequently used whenever
`foo' is displayed (although the internal representation is unchanged).
To ensure foo is always displayed in decimal, declare it as
typeset -i 10 foo
which requests base 10 for output. You can change the output base of an
existing variable in this fashion. Using the `$[ ... ]' method will
always display in decimal.
C7) How do I get a newline in my prompt?
You can place a literal newline in quotes, i.e.
PROMPT="Hi Joe,
what now?%# "
If you have the bad taste to set the option cshjunkiequotes, which
inhibits such behaviour, you will have to bracket this with
`unsetopt cshjunkiequotes' and `setopt cshjunkiequotes', or put it in
your .zshrc before the option is set.
Arguably the prompt code should handle `print'-like escapes. Feel
free to write this :-).
C8) Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
You probably have the extendedglob option set in which case ^ and #
are metacharacters. ^a matches any file except one called a, so the
line is interpreted as bindkey followed by a list of files. Quote the
^ with a backslash or put quotation marks around ^a.
C9) Why can't I bind \C-s and \C-q any more?
The control-s and control-q keys now do flow control by default,
unless you have turned this off with `stty -ixon' or redefined the
keys which control it with `stty start' or `stty stop'. (This is
done by the system, not zsh; the shell simply respects these
settings.) In other words, \C-s stops all output to the terminal,
while \C-q resumes it.
There is an option NO_FLOW_CONTROL to stop zsh from allowing flow
control and hence restoring the use of the keys: put `setopt
noflowcontrol' in .zshrc.
C10) How do I execute command `foo' within function `foo'?
The command `command foo' does just that. You don't need this with
aliases, but you do with functions. Note that error messages like
zsh: job table full or recursion limit exceeded
are a good sign that you tried calling `foo' in function `foo' without
using `command'.
C11) Why do history substitutions with single bangs do something funny?
If you have a command like "echo !-2:$ !$", the first history
substitution then sets a default to which later history substitutions
with single unqualified bangs refer, so that !$ becomes equivalent to
!-2:$. The option CSH_JUNKIE_HISTORY makes all single bangs refer
to the last command.
C12) Why does zsh kill off all my background jobs when I logout?
Simple answer: you haven't asked it not to. Zsh (unlike [t]csh) gives
you the option of having background jobs killed or not: the `nohup'
option exists if you don't want them killed. Note that you can always
run programs with `nohup' in front of the pipeline whether or not the
option is set, which will prevent that job from being killed on
logout. (Nohup is actually an external command.)
The `disown' builtin is very useful in this respect: if zsh informs
you that you have background jobs when you try to logout, you can
`disown' all the ones you don't want killed when you exit. This is
also a good way of making jobs you don't need the shell to know about
(such as commands which create new windows) invisible to the shell.
Section D: The mysteries of completion
Programmable completion using the `compctl' command is one of the most
powerful, and also potentially confusing, features of zsh; here I give
a short introduction. There is a set of example completions supplied
with the source in Misc/compctl-examples; completion definitions for
many of the most obvious commands can be found there.
D1) What is completion?
`Completion' is where you hit a particular command key (TAB is the
standard one) and the shell tries to guess the word you are typing
and finish it for you --- a godsend for long file names, in
particular, but in zsh there are many, many more possibilities than
that.
There is also a related process, `expansion', where the shell sees
you have typed something which would be turned by the shell into
something else, such as a variable turning into its value ($PWD
becomes /home/users/mydir) or a history reference (!! becomes
everything on the last command line). In zsh, when you hit TAB it
will look to see if there is an expansion to be done; if there is,
it does that, otherwise it tries to perform completion. Expansion
is generally fairly intuitive and not under user control; for the
rest of the section I will discuss completion only.
D2) What sorts of things can be completed?
The simplest sort is filename completion, mentioned above. Unless
you have made special arrangements, as described below, then after
you type a command name, anything else you type is assumed by the
completion system to be a filename. If you type part of a word and
hit TAB, zsh will see if it matches the first part a file name and
if it does it will automatically insert the rest.
The other simple type is command completion, which applies
(naturally) to the first word on the line. In this case, zsh
assumes the word is some command to be executed lying in your $PATH
and try to complete that.
Other forms of completion have to be set up by special arrangement.
See the manual entry for compctl for a list of all the flags: you
can make commands complete variable names, user names, job names,
etc., etc.
For example, one common use is that you have an array variable,
$hosts, which contains names of other machines you use frequently on
the network:
hosts=(fred.ph.ku.ac.uk snuggles.floppy-bunnies.com here.there.edu)
then you can tell zsh that when you use telnet (or ftp, or ...), the
argument will be one of those names:
compctl -k hosts telnet ftp ...
so that if you type `telnet fr' and hit TAB, the rest of the name
will appear by itself.
An even more powerful option to compctl (-g) is to tell zsh that
only certain sorts of filename are allowed. The argument to -g is
exactly like a glob pattern, with the usual wildcards `*', `?', etc.
In the compctl statement it needs to be quoted to avoid it being
turned into filenames straight away. For example,
compctl -g '*.(ps|eps)' ghostview
tells zsh that if you type TAB on an argument after a ghostview
command, only files ending in `.ps' or `.eps' should be considered
for completion.
Note that flags may be combined; if you have more than one, all the
possible completions for all of them are put into the same list, all
of them being possible completions. So
compctl -k hosts -f rcp
tells zsh that rcp can have a hostname or a filename after it. (You
really need to be able to handle host:file, which is where
programmable completion comes in, see D4).)
D3) How does zsh deal with ambiguous completions?
Often there will be more than one possible completion: two files
start with the same characters, for example. Zsh has a lot of
flexibility for what it does here via it's options. The default is
for it to beep and completion to stop until you type another
character. You can type ^D to see all the possible completions.
This can be changed by the following options, among others (1) with
nobeep set, that annoying beep goes away (2) with autolist set, when
the completion is ambiguous you get a list without having to type
^D, (3) with menucomplete set, one completion is always inserted
completely, then when you hit TAB it changes to the next, and so on
until you get back to where you started (4) with automenu, you only
get the menu behaviour when you hit TAB again on the ambiguous
completion. Combinations of these are possible.
D4) How do I get started with programmable completion?
Finally, the hairiest part of completion. It is possible to get zsh
to consider different completions not only for different commands,
but for different words of the same command, or even to look at
other words on the command line (for example, if the last word was a
particular flag) and decide then.
There are really two sorts of things to worry about. The simpler is
alternative completion: that just means zsh will try one
alternative, and only if there are no possible completions try the
next. For example
compctl -g '*.ps' + -f lpr
says that after lpr you'd prefer to find only `.ps' files, so if
there are any, only those are used, but if there aren't any, any
old file is a possibility. You can also have a + with no flags
after it, which tells zsh that it's to treat the command like any
other if nothing was found. That's only really useful if your
default completion is fancy, i.e. you have done something with
`compctl -D' to tell zsh how commands which aren't specially handled
are to have their arguments completed.
The second sort is the hard one. Following a `-x', zsh expects that
the next thing will be some completion code, which is a single
letter followed by an argument in square brackets. For example
'p[1]': `p' is for position, and the argument tells it to look at
position 1; that says that this completion only applies to the word
immediately after the command. You can also say 'p[1,3]' which says
the completion only applies to the word if it's between the first
and third words, inclusive, after the command, and so on. See the
list in the `compctl' manual entry for a list of these conditions:
some conditions take one argument in the square brackets, some two.
Usually, negative numeric arguments count backwards from the end
(for example, 'p[-1]' applies to the last word on the line).
The condition is then followed by the flags as usual (as in D2)),
and possibly other condition/flag sets following a single -; the
whole lot ends with a double -- before the command name. In other
words, each extended completion section looks like this:
-x <pattern> <flags>... [ - <pattern> <flags>... ...] --
Let's look at rcp again: this assumes you've set up $hosts as above.
This uses the `n[<n>,<string>]' flag, which tells zsh to look for
the <n>'th occurrence of <string> in the word, ignoring anything up
to and including that. We'll use it for completing the bits of
rcp's `user@host:file' combination. (Of course, the file name is on
the local machine, not `host', but let's ignore that; it may still
be useful.)
compctl -k hosts -S ':' + -f -x 'n[1,:]' -f - \
'n[1,@]' -k hosts -S ':' -- rcp
This means: (1) try and complete a hostname (the bit before the
`+'), if successful add a `:' (-S for suffix); (2) if that fails
move on to try the code after the `+': look and see if there is a
`:' in a word (the `n[1,:]'); if there is, complete filenames (-f)
after the first of them; (3) otherwise look for an `@' and complete
hostnames after the first of them (the `n[1,@]'), adding a `:' if
successful; (4) if all else fails use the -f before the `-x' and try
to complete files.
So the rules for order are (1) try anything before a `+' before
anything after it (2) try the conditions after a -x in order until
one succeeds (3) use the default flags before the -x if none of the
conditions was true.
Different conditions can also be combined. There are three levels
of this (in decreasing order of precedence):
i) multiple square brackets after a single condition give
alternatives: for example, 's[foo][bar]' says apply the
completion if the word begins with `foo' or `bar',
ii) spaces between conditions mean both must match: for example,
'p[1] s[-]' says this completion only applies for the first word
after the command and only if it begins with a `-',
iii) commas between conditions mean either can match: for example,
'c[-1,-f], s[-f]' means either the previous word (-1 relative to
the current one) is -f, or the current word begins with -f ---
useful to use the same completion whether or not the -f has a
space after it.
Here's a useless example just to show a general `-x' completion.
compctl -f -x 'c[-1,-u][-1,-U] p[2], s[-u]' -u - \
'c[-1,-j]' -P % -j -- foobar
The way to read this is: for command `foobar', look and see if (((the
word before the current one is -u) or (the word before the current
one is -U)) and (the current word is 2)) or (the current word begins
with -u); if so, try to complete user names. If the word before
the current one is -j, insert the prefix `%' before the current word
if it's not there already and complete job names. Otherwise, just
complete file names.
D5) And if programmable completion isn't good enough?
...then your last resort is to write a shell function to do it for
you. By combining the `-U' and `-K func' flags you can get almost
unlimited power. The `-U' tells zsh that whatever the completion
produces is to be used, even if it doesn't fit what's there already
(so that gets deleted when the completion is inserted). The `-K
func' tells zsh a function name. The function is passed what's on
the line already, but it can return anything it likes via the
`reply' array, and this becomes the set of possible completions.
The best way to understand this is to look at `multicomp' and other
functions supplied with the zsh distribution.
Section Z: The future of zsh
Z1) What bugs are currently known and unfixed?
Here are some of the more well-known ones, very roughly in
decreasing order of significance. Many of these can also be counted
against differences from ksh in question B1); note that this applies
to the latest beta version and that simple bugs are often fixed
quite quickly. There is a file Etc/BUGS in the source distribution
with more detail.
Special variables won't be unset after e.g. `PATH=... read ...',
i.e. if used with a builtin command or shell function.
The `HISTLIT' option is broken in various ways and is being removed:
the rewritten history mechanism doesn't alter history lines, making
the option unnecessary (from zsh-2.6-beta12).
`time' is ignored with builtins and can't be used with {...}.
`set -x' (`setopt xtrace') still has a few glitches.
The :q modifier doesn't split words and -q and -x don't work for variables.
In vi mode, `u' can go past the original modification point.
Autocd won't use globbed filenames.
The singlelinezle option has problems with prompts containing escapes.
Builtins at the end of a pipeline lose their status to previous
commands (fixed from 2.6 beta8).
The `r' command does not work inside $(...) or `...` expansions.
Note that a few recent changes introduce incompatibilities (these
are not bugs):
An option CSH_JUNKIE_PAREN has proved necessary for the syntax `if (
<condition> ) <code>' and for similar `for' and `while' (but not
`foreach') commands. This is because it is valid Bourne/Korn shell
syntax to have a subshell command immediately after if, and the
default syntax should be compliant with that.
You also need CSH_JUNKIE_PAREN if you want to use the syntax
`if [[ ... ]] command' (maybe with `command' being in the form `{
command1; ...}'; this was mainly here for csh compatibility.
Remember you can use `[[ ... ]] && command' to do the same thing.
Assignment of `...` and $(...) to variables in the form `foo=$(...)'
is now always scalar; previously the command output was split and
array assignment performed if more than one word resulted. You
can still generate an array vie `foo=($(...))', which was always
the safe way of doing it. Again, this is for Bourne/Korn compliance.
The -h option to compctl has been removed (use `-k hosts' for the
same effect); automatic handling of hosts after '@' has been removed
(use e.g. `compctl -u -x "n[-1,@]" -k hosts -- finger').
Handling of backslashes in `echo' and `print' has changed.
umask's behaviour with respect to symbolic operators has reversed
(and is now ksh-compatible).
The option CSH_JUNKIE_TILDE has been upgraded to GLOB_SUBST: instead
of just ~'s and ='s, all characters become eligible for file
expansion and globbing when the option is set. (The option was
not present in 2.3 at all.)
Z2) Where do I report bugs, get more info / who's working on zsh?
The shell is being maintained by various (entirely self-appointed)
subscribers to the mailing list (NOTE CHANGE OF ADDRESS),
zsh-workers@xxxxxxxxxxxxxxx
so any suggestions, complaints, questions and matters for discussion
should be sent there. If you want someone to mail you directly, say
so. Most patches to zsh appear there first.
Two progressively lower volume lists exist, one with messages
concerning the use of zsh,
zsh-users@xxxxxxxxxxxxxxx
and one just containing announcements: about releases, about major
changes in the shell, or this FAQ, for example,
zsh-announce@xxxxxxxxxxxxxxx
(posting to the last one is currently restricted).
Note that you should only join one of these lists: people on
zsh-workers receive all the lists, and people on zsh-users will
also receive the announcements list.
The lists are handled by an automated server. The instructions for
zsh-announce and zsh-users are the same as for zsh-workers: just
change zsh-workers to whatever in the following.
To join zsh-workers, send email to
zsh-workers-request@xxxxxxxxxxxxxxx
with the *subject* line (this is a change from the old list)
subscribe <your-email-address>
e.g.
Subject: subscribe P.Stephenson@xxxxxxxxxxxxx
and you can unsubscribe in the same way.
The list maintainer, Richard Coleman, can be reached at
zsh@xxxxxxxxxxxxxxx
(his own e-mail address is coleman@xxxxxxxxxxxxxxx).
The list (everything since May 1992) is archived in
ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
where YY-MM are the year and month in digits. A useful World Wide
Web interface to recent mailings is currently kept at
http://www-stud.enst.fr/~tardieu/mailarchive/zsh-list/index.html
by Samuel Tardieu.
Of course, you can also post zsh queries to the Usenet group
comp.unix.shell; if all else fails, you could even e-mail me.
Z3) What's on the wish-list?
Mostly, a lot of the code needs a major clean-up: particular
offenders are the history code (hist.c: this is under way),
parameter code (params.c) and substitution code (subst.c). A more
efficient set of code for lexing/parsing/execution might also be an
advantage. Volunteers are particularly welcome for these tasks.
Ksh/sh compatibility could be improved; this is a useful long term goal.
Option for glob qualifiers to follow perl syntax.
Binding of shell functions (or commands?) to key strokes --
requires some way of accessing the editing buffer from functions
and probably of executing zle functions as a command.
trap '...' FOO should be eval'd rather than called as a function.
`PATH=' should clear the PATH: it inserts `.'; use `unset PATH' or
`path=()' for the time being. This is not really a bug as the .
would be used internally in any case (cf. ksh).
Users should be able to create their own foopath/FOOPATH array/path
combinations.
Acknowledgments:
Thanks to zsh-list, in particular Bart Schaefer, for suggestions
regarding this document; thanks to Jim Mattson, Bas de Bakker and now
Richard Coleman for their hard work as archivists, and to Peter Gray
for maintaining the mailing list, without which zsh might easily have
died, and to his successor, Rick Ohnemus. The world is eternally in
the debt of Paul Falstad for inventing zsh in the first place (though
the wizzo extended completion is by Sven Wishnowsky).
Copyright Information:
This document is copyright (C) P.W. Stephenson, 1995. This text
originates in the U.K. and the author asserts his moral rights under
the Copyrights, Designs and Patents Act, 1988.
Permission is hereby granted, without written agreement and without
license or royalty fees, to use, copy, modify, and distribute this
documentation for any purpose, provided that the above copyright
notice appears in all copies of this documentation. Remember,
however, that this document changes monthly and it may be more useful
to provide a pointer to it rather than the entire text. A suitable
pointer is "information on the Z-shell can be obtained on the World
Wide Web at URL http://www.mal.com/zsh/";.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author