Archive-Name: unix-faq/shell/zsh
Last-Modified: 2012/06/15
Submitted-By: coordinator@zsh.org (Peter Stephenson)
Posting-Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995--2010 (see end of document)
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. Zsh is among the most powerful freely available Bourne-like
shell for interactive use.
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 1.6; if you want to know what to do with
insoluble problems, go to 5.2.
Notation: Quotes `like this' are ordinary textual quotation
marks. Other uses of quotation marks are input to the shell.
Contents:
Chapter 1: Introducing zsh and how to install it
1.1. Sources of information
1.2. What is it?
1.3. What is it good at?
1.4. On what machines will it run? (Plus important compilation notes)
1.5. What's the latest version?
1.6. Where do I get it?
1.7. I don't have root access: how do I make zsh my login shell?
Chapter 2: How does zsh differ from...?
2.1. sh and ksh?
2.2. csh?
2.3. Why do my csh aliases not work? (Plus other alias pitfalls.)
2.4. tcsh?
2.5. bash?
2.6. Shouldn't zsh be more/less like ksh/(t)csh?
2.7. What is zsh's support for Unicode/UTF-8?
Chapter 3: How to get various things to work
3.1. Why does `$var' where `var="foo bar"' not do what I expect?
3.2. In which startup file do I put...?
3.3. What is the difference between `export' and the ALL_EXPORT option?
3.4. How do I turn off spelling correction/globbing for a single command?
3.5. How do I get the Meta key to work on my xterm?
3.6. How do I automatically display the directory in my xterm title bar?
3.7. How do I make the completion list use eight bit characters?
3.8. Why do the cursor (arrow) keys not work? (And other terminal oddities.)
3.9. Why does my terminal act funny in some way?
3.10. Why does zsh not work in an Emacs shell mode any more?
3.11. Why do my autoloaded functions not autoload [the first time]?
3.12. How does base arithmetic work?
3.13. How do I get a newline in my prompt?
3.14. Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
3.15. Why can't I bind \C-s and \C-q any more?
3.16. How do I execute command `foo' within function `foo'?
3.17. Why do history substitutions with single bangs do something funny?
3.18. Why does zsh kill off all my background jobs when I logout?
3.19. How do I list all my history entries?
3.20. How does the alternative loop syntax, e.g. `while {...} {...}' work?
3.21. Why is my history not being saved?
3.22. How do I get a variable's value to be evaluated as another variable?
3.23. How do I prevent the prompt overwriting output when there is no newline?
3.24. What's wrong with cut and paste on my xterm?
3.25. How do I get coloured prompts on my colour xterm?
3.26. Why is my output duplicated with `foo 2>&1 >foo.out | bar'?
Chapter 4: The mysteries of completion
4.1. What is completion?
4.2. What sorts of things can be completed?
4.3. How does zsh deal with ambiguous completions?
4.4. How do I complete in the middle of words / just what's before the cursor?
4.5. How do I get started with programmable completion?
4.6. Suppose I want to complete all files during a special completion?
Chapter 5: Multibyte input and output
5.1. What is multibyte input?
5.2. How does zsh handle multibyte input and output?
5.3. How do I ensure multibyte input and output work on my system?
5.4. How can I input characters that aren't on my keyboard?
Chapter 6: The future of zsh
6.1. What bugs are currently known and unfixed? (Plus recent important changes)
6.2. Where do I report bugs, get more info / who's working on zsh?
6.3. What's on the wish-list?
6.4. Did zsh have problems in the year 2000?
Acknowledgments
Copyright
--- End of Contents ---
Chapter 1: Introducing zsh and how to install it
1.1: Sources of information
Information on zsh is available via the World Wide Web. The URL
is http://zsh.sourceforge.net/ .
The server provides this FAQ and much else and is
now maintained by the zsh workers (email zsh-workers@zsh.org).
The FAQ is at http://zsh.sourceforge.net/FAQ/ .
The site also contains some contributed zsh scripts and functions;
we are delighted to add more, or simply links to your own collection.
This document was originally written in YODL, allowing it to be converted
easily into various other formats. The master source file lives at
http://zsh.sourceforge.net/FAQ/zshfaq.yo and the plain text version
can be found at http://zsh.sourceforge.net/FAQ/zshfaq.txt .
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. 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.uu.nl/wais/html/na-dir/unix-faq/shell/.html
You can also get it via email by emailing mail-server@rtfm.mit.edu
with, in the body of the message, `send faqs/unix-faq/shell/zsh'.
The latest version of this FAQ is also available directly from any
of the zsh archive sites listed in question 1.6.
I have put together a user guide to complement the manual by
explaining the most useful features of zsh in a more easy to read way.
This can be found at the zsh web site:
http://zsh.sourceforge.net/Guide/
(As a method of reading the following 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 5.2.
1.2: What is it?
Zsh is a UNIX command interpreter (shell) which of the standard
shells most resembles the Korn shell (ksh); its compatibility with
the 1988 Korn shell has been gradually increasing. 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 5.2). 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.
1.3: 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 interactive feature
in any other freely-available shell which zsh does not also have
(except smallness).
o Command line editing:
o programmable completion: incorporates the ability to use the
full power of zsh's globbing and shell programming features,
o multi-line commands editable as a single buffer (even files!),
o variable editing (vared),
o command buffer stack,
o print text straight into the buffer for immediate editing (print -z),
o execution of unbound commands,
o menu completion in two flavours,
o variable, editing function and option name completion,
o inline expansion of variables and history commands.
o Globbing --- extremely powerful, including:
o recursive globbing (cf. find),
o file attribute qualifiers (size, type, etc. also cf. find),
o full alternation and negation of patterns.
o Handling of multiple redirections (simpler than tee).
o Large number of options for tailoring.
o Path expansion (=foo -> /usr/bin/foo).
o Adaptable messages for spelling, watch, time as well as prompt
(including conditional expressions).
o Named directories.
o Comprehensive integer and floating point arithmetic.
o Manipulation of arrays (including reverse subscripting).
o Associative arrays (key-to-value hashes)
o Spelling correction.
1.4: On what machines will it run?
From version 3.0, zsh uses GNU autoconf as the installation
mechanism. This considerably increases flexibility over the old
`buildzsh' mechanism. Consequently, zsh should compile and run on
any modern version of UNIX, and a great many not-so-modern versions
too. The file MACHINES in the distribution has more details.
There used to be separate ports for Windows and OS/2, but these
are rather out of date and hard to get; however, zsh exists for
the Cygwin environment. See further notes below.
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 and acconfig.h to configure zsh automatically,
then send the required context diffs to the list (see question
5.2). Please make sure you have the latest version first.
To get it to work, retrieve the source distribution (see question
1.6), un-gzip it, un-tar it and read the INSTALL file in the top
directory. Also read the MACHINES file for up-to-date
information on compilation on certain architectures.
*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 makes the signals code unusable. This often happens
on Ultrix, HP-UX, IRIX (?). Install gawk if you experience such problems.
1.5: What's the latest version?
Zsh 5.0.2 is the latest production version. For details of all the
changes, see the NEWS file in the source distribution.
A beta of the next version is sometimes available. Development of zsh is
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. If you are really interested in getting the latest
improvements, and less worried about providing a stable environment,
development versions are uploaded quite frequently to the archive in the
development subdirectory.
Note also that as the shell changes, it may become incompatible with
older versions; see the end of question 5.1 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, or (mostly in the 3.0 series) to provide POSIX compliancy.
1.6: Where do I get it?
The coordinator of development is currently me; the alias
coordinator@zsh.org can be used to contact whoever is in the hot
seat. The following are known mirrors (kept frequently up to date); the
first is the official archive site, currently in Australia. All are
available by anonymous FTP. The major sites keep test versions in the
`testing' subdirectory: such up-to-the-minute development versions should
only be retrieved if you actually plan to help test the latest version of
the shell. The following list also appears on the WWW at
http://www.zsh.org/ .
Primary site:
ftp://ftp.zsh.org/pub/
http://www.zsh.org/pub/
Australia:
ftp://ftp.zsh.org/pub/
http://www.zsh.org/pub/
http://mirror.dejanseo.com.au/pub/zsh/
Hungary:
ftp://ftp.cs.elte.hu/pub/zsh/
http://www.cs.elte.hu/pub/zsh/
A Windows port was created by Amol Deshpandem based on 3.0.5 (which
is now rather old). This has now been restored and can be found at
http://zsh-nt.sourceforge.net/.
All recent releases of zsh compile under Cygwin, a freely available
UNIX-style environment for the Win32 API, and a pre-compiled version of
zsh can be downloaded by the Cygwin installer. You can find information
about this at http://www.cygwin.com/.
Please email zsh-workers@zsh.org if you have information about
other ports.
Starting from mid-October 1997, there is an archive of patches sent
to the maintainers' mailing list. Note that these may not all be
added to the shell, and some may already have been; you simply have
to search for something you might want which is not in the version
you have. Also, there may be some prerequisites earlier in the
archive. It can be found on the zsh WWW pages (as described in
1.1) at:
http://zsh.sourceforge.net/Patches/
1.7: 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).
If you want to check this works before committing yourself to it,
you can make the login shell ask whether to exec zsh. The following
work for Bourne-like shells:
[ -f $HOME/bin/zsh ] && {
echo "Type Y to run zsh: \c"
read line
[ "$line" = Y ] && exec $HOME/bin/zsh -l
}
and for C-shell-like shells:
if ( -f ~/bin/zsh ) then
echo -n "Type Y to run zsh: "
if ( "$<" == Y ) exec ~/bin/zsh -l
endif
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.
Chapter 2: 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. See also the article `UNIX shell differences and how to change
your shell' posted frequently to the USENET group comp.unix.shell.
2.1: 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; differences from ksh93 will be more
substantial.
As a summary of the status:
1) because of all the options it is not safe to assume a general
zsh run by a user will behave as if sh or ksh compatible;
2) invoking zsh as sh or ksh (or if either is a symbolic link to
zsh) sets appropriate options and improves compatibility (from
within zsh itself, calling `ARGV0=sh zsh' will also work);
3) from version 3.0 onward the degree of compatibility with sh
under these circumstances is very high: zsh can now be used
with GNU configure or perl's Configure, for example;
4) the degree of compatibility with ksh is also high, but a few
things are missing: for example the more sophisticated
pattern-matching expressions are different for versions before
3.1.3 --- see the detailed list below;
5) also from 3.0, the command `emulate' is available: `emulate
ksh' and `emulate sh' set various options as well as changing the
effect of single-letter option flags as if the shell had been
invoked with the appropriate name. Including the command
`emulate sh; setopt localoptions' in a shell function will
turn on sh emulation for that function only. In version 4 (and in
3.0.6 through 8), this can be abbreviated as `emulate -L sh'.
The classic difference is word splitting, discussed in question 3.1;
this catches out very many beginning zsh users. As explained there,
this is actually a bug in every other shell. The answer is to set
SH_WORD_SPLIT for backward compatibility. The next most classic
difference is that unmatched glob patterns cause the command to abort;
set NO_NOMATCH for those.
Here is a list of various options which will increase ksh
compatibility, though maybe decrease zsh's abilities: see the manual
entries for GLOB_SUBST, IGNORE_BRACES (though brace expansion occurs
in some versions of ksh), KSH_ARRAYS, KSH_GLOB, KSH_OPTION_PRINT,
LOCAL_OPTIONS, NO_BAD_PATTERN, NO_BANG_HIST, NO_EQUALS, NO_HUP,
NO_NOMATCH, NO_RCS, NO_SHORT_LOOPS, PROMPT_SUBST, RM_STAR_SILENT,
POSIX_ALIASES, POSIX_BUILTINS, POSIX_IDENTIFIERS,
SH_FILE_EXPANSION, SH_GLOB, SH_OPTION_LETTERS,
SH_WORD_SPLIT (see question 3.1) and SINGLE_LINE_ZLE.
Note that you can also disable any built-in commands which get in
your way. If invoked as `ksh', the shell will try to 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', or
if `emulate ksh' is in effect. Capitalised words with underlines
refer to shell options.
o Syntax:
o * Shell word splitting: see question 3.1.
o * Arrays are (by default) 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.
Set the KSH_ARRAYS option for compatibility.
o Furthermore, individual elements of arrays in zsh are always
strings, not separate parameters. This means, for example, you
can't `unset' an array element in zsh as you can in ksh; you
can only set it to the empty string, or shorten the array.
(You can unset elements of associative arrays in zsh because
those are a completely different type of object.)
o Coprocesses are established by `coproc'; `|&' behaves like
csh. Handling of coprocess file descriptors is also different.
o In `cmd1 && cmd2 &', only `cmd2' instead of the whole
expression is run in the background in zsh. The manual implies
this is a bug. Use `{ cmd1 && cmd2 } &' as a workaround.
o Command line substitutions, globbing etc.:
o * Failure to match a globbing pattern causes an error (use
NO_NOMATCH).
o * The results of parameter substitutions are treated as plain text:
`foo="*"; print $foo' prints all files in ksh but `*' in zsh
(use GLOB_SUBST).
o * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
o * Standard 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 `#' (but not `|')forms require EXTENDED_GLOB.
From version 3.1.3, the ksh forms are fully supported when the
option KSH_GLOB is in effect; for previous versions you
must use the table above.
[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
one way to exclude some subdirectories from matching a `**'.
The form (^foo/)# also works.
o Unquoted assignments do file expansion after `:'s (intended for
PATHs).
o * `typeset' and `integer' have special behaviour for
assignments in ksh, but not in zsh. For example, this doesn't
work in zsh:
integer k=$(wc -l ~/.zshrc)
because the return value from wc includes leading
whitespace which causes wordsplitting. Ksh handles the
assignment specially as a single word.
o Command execution:
o * There is no $ENV variable (use /etc/zshrc, ~/.zshrc;
note also $ZDOTDIR).
o * $PATH is not searched for commands specified
at invocation without -c.
o Aliases and functions:
o The order in which aliases and functions are defined is significant:
function definitions with () expand aliases -- see question 2.3.
o Aliases and functions cannot be exported.
o There are no tracked aliases: command hashing replaces these.
o The use of aliases for key bindings is replaced by `bindkey'.
o * Options are not local to functions (use LOCAL_OPTIONS; note this
may always be unset locally to propagate options settings from a
function to the calling level).
o Functions defined with `function funcname { body }' behave the
same way as those defined with `funcname () { body }'. In ksh,
the former behave as if the body were read from a file with `.',
and only the latter behave as true functions.
o Traps and signals:
o * Traps are not local to functions. The option LOCAL_TRAPS is
available from 3.1.6.
o TRAPERR has become TRAPZERR (this was forced by UNICOS which
has SIGERR).
o Editing:
o The options gmacs, viraw are not supported.
Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
becomes `bindkey -{e,v}', although `set -o emacs' and `set -o vi'
are supported for compatibility; for gmacs, go to emacs mode and
use `bindkey \^t gosmacs-transpose-characters'.
o The `keyword' option does not exist and `-k' is instead
interactivecomments. (`keyword' is not in recent versions
of ksh either.)
o * Management of histories in multiple shells is different:
the history list is not saved and restored after each command.
The option SHARE_HISTORY appeared in 3.1.6 and is set in ksh
compatibility mode to remedy this.
o `\' does not escape editing chars (use `^V').
o Not all ksh bindings are set (e.g. `<ESC>#'; try `<ESC>q').
o * `#' in an interactive shell is not treated as a comment by
default.
o In vi command mode the keys "k" and "j" move the cursor to the
end of the line. To move the cursor to the start instead, use
bindkey -M vicmd 'k' vi-up-line-or-history
bindkey -M vicmd 'j' vi-down-line-or-history
o Built-in commands:
o Some built-ins (r, autoload, history, integer ...)
were aliases in ksh.
o There is no built-in command newgrp: use e.g. `alias
newgrp="exec newgrp"'
o `jobs' has no `-n' flag.
o Other idiosyncrasies:
o `select' always redisplays the list of selections on each loop.
2.2: 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 Misc/c2z) to help convert .cshrc
and .login files; see also the next question concerning aliases,
particularly those with arguments.
Csh-compatibility additions include:
o logout, rehash, source, (un)limit built-in commands.
o *rc file for interactive shells.
o Directory stacks.
o cshjunkie*, ignoreeof options.
o The CSH_NULL_GLOB option.
o >&, |& etc. redirection.
(Note that `>file 2>&1' is the standard Bourne shell command for
csh's `>&file'.)
o foreach ... loops; alternative syntax for other loops.
o Alternative syntax `if ( ... ) ...', though this still doesn't
work like csh: it expects a command in the parentheses. Also
`for', `which'.
o $PROMPT as well as $PS1, $status as well as $?,
$#argv as well as $#, ....
o Escape sequences via % for prompts.
o Special array variables $PATH etc. are colon-separated, $path
are arrays.
o !-type history (which may be turned off via `setopt
nobanghist').
o Arrays have csh-like features (see under 2.1).
2.3: 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" or "builtin" 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:
o convert all of them to zsh functions; or
o 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 SH_WORD_SPLIT and KSH_ARRAYS are 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 "$@"
\!*: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.
Bart Schaefer's rule is: Define first those aliases you expect to
use in the body of a function, but define the function first if the
alias has the same name as the function.
If you aware of the problem, you can always escape part or all of the
name of the function:
'l'() { /bin/ls -la "$@" | more }
Adding the quotes has no effect on the function definition, but
suppresses alias expansion for the function name. Hence this is
guaranteed to be safe---unless you are in the habit of defining
aliases for expressions such as 'l', which is valid, but probably
confusing.
2.4: Similarities with tcsh
(The sections on csh apply too, of course.) Certain features have
been borrowed from tcsh, including $watch, run-help, $savehist,
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
Misc 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. You can execute
any command in the middle of editing a line in the same way,
corresponding to tcsh's `-c' option:
bindkey -s '^p' '\eqpwd\n'
In both these examples, the `\eq' saves the current input line to
be restored after the command runs; a better effect with multiline
buffers is achieved if you also have
bindkey '\eq' push-input
to save the entire buffer. In version 4 and recent versions of zsh 3.1,
you have the following more sophisticated option,
run-fg-editor() {
zle push-input
BUFFER="fg %$EDITOR:t"
zle accept-line
}
zle -N run-fg-editor
and can now bind run-fg-editor just like any other editor function.
2.5: Similarities with bash
The Bourne-Again Shell, bash, is another enhanced Bourne-like shell;
the most obvious difference from zsh is that it does not attempt to
emulate the Korn shell. Since both shells are under active
development it is probably not sensible to be too specific here.
Broadly, bash has paid more attention to standards compliancy
(i.e. POSIX) for longer, and has so far avoided the more abstruse
interactive features (programmable completion, etc.) that zsh has.
In recent years there has been a certain amount of crossover in the
extensions, however. Zsh (as of 3.1.6) has bash's `${var/old/new}'
feature for replacing the text old with the text new in the
parameter $var. Note one difference here: while both shells
implement the syntax `${var/#old/new}' and `${var/%old/new}' for
anchoring the match of old to the start or end of the parameter text,
respectively, in zsh you can't put the `#' or `%' inside a
parameter: in other words `{var/$old/new}' where old begins with
a `#' treats that as an ordinary character in zsh, unlike bash. To
do this sort of thing in zsh you can use (from 3.1.7) the new syntax
for anchors in any pattern, `(#s)' to match the start of a string,
and `(#e)' to match the end. These require the option
EXTENDED_GLOB to be set.
2.6: 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.
http://www.cis.ohio-state.edu/hypertext/faq/usenet/unix-faq/\
shell/csh-whynot/faq.html
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. The only answer, perhaps not
entirely satisfactory, is that you have to ignore the bits you don't
want. The introduction of loadable in modules in version 3.1 should
help.
2.7: What is zsh's support for Unicode/UTF-8?
`Unicode', or UCS for Universal Character Set, is the modern way
of specifying character sets. It replaces a large number of ad hoc
ways of supporting character sets beyond ASCII. `UTF-8' is an
encoding of Unicode that is particularly natural on Unix-like systems.
The production branch of zsh, 4.2, has very limited support:
the built-in printf command supports "\u" and "\U" escapes
to output arbitrary Unicode characters; ZLE (the Zsh Line Editor) has
no concept of character encodings, and is confused by multi-octet
encodings.
However, the 4.3 branch has much better support, and furthermore this
is now fairly stable. (Only a few minor areas need fixing before
this becomes a production release.) This is discussed more
fully below, see `Multibyte input and output'.
Chapter 3: How to get various things to work
3.1: 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.) The option
SH_WORD_SPLIT exists to provide compatibility.
For example, defining the function args to show the number of its
arguments:
args() { echo $#; }
and with our definition of `var',
args $var
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 SH_WORD_SPLIT.
Arrays are also much more versatile than single strings. Probably
if this mechanism had always been available there would never have
been automatic word splitting in scalars, which is a sort of
uncontrollable poor man's array.
Note that this happens regardless of the value of the internal field
separator, $IFS; in other words, with `IFS=:; foo=a:b; args $foo'
you get the answer 1.
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 (note
characters special to the shell, such as the `'' in this example,
must already be quoted), or, less standard but more reliable,
turning on SH_WORD_SPLIT for one variable only:
args ${=sentence}
always returns 8 with the above definition of `args'. (In older
versions of zsh, ${=foo} toggled SH_WORD_SPLIT; 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). This is more portable than the $*, since it
will work regardless of the SH_WORD_SPLIT setting; the other
difference is that $* removes empty arguments from the array.
You can fix the first half of that objection by using ${==*},
which turns off SH_WORD_SPLIT for the duration of the expansion.
SH_WORD_SPLIT is set when zsh is invoked with the names `ksh' or `sh',
or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
effect.
There is one other effect of word splitting which differs between ksh
and zsh. In ksh, the builtin commands that declare parameters such
as typeset and export force word-splitting not to take place
after on an assignment argument:
typeset param=`echo foo bar`
in ksh will create a parameter with value `foo bar', but in zsh will
create a parameter param with value foo and a parameter bar
whose value is empty. Contrast this with a normal assignment (no
typeset or other command in front), which never causes a word split
unless you have GLOB_ASSIGN set. From zsh version 4.0.2 the option
KSH_TYPESET, set automatically in compatibility mode, fixes this
problem. Note that in bash this behaviour occurs with all arguments that
look like assignments, whatever the command name; to get this behaviour
in zsh you have to set the option MAGIC_EQUAL_SUBST.
3.2: In which startup file do I put...?
When zsh starts up, there are four files you can change which it will
run under various circumstances: .zshenv, .zprofile, .zshrc
and .zlogin. They are usually in your home directory, but the
variable $ZDOTDIR may be set to alter that. Here are a few simple
hints about how to use them. There are also files which the system
administrator can set for all shells; you can avoid running all except
/etc/zshenv by starting zsh with the -f option --- for this
reason it is important for administrators to make sure /etc/zshenv
is as brief as possible.
The order in which the four files are searched (none of them _need_
to exist) is the one just given. However, .zprofile and .zlogin
are only run when the shell is a login shell --- when you first login,
of course, and whenever you start zsh with the -l option. All
login shells are interactive. The order is the only difference
between those; you should decide whether you need things set before or
after .zshrc. These files are a good place to set environment
variables (i.e. `export' commands), since they are passed on to
all shells without you having to set them again, and also to check
that your terminal is set up properly (except that if you want to
change settings for terminal emulator windows like xterm you will
need to put those in .zshrc, since usually you do not get a login
shell here).
The only file you can alter which is started with every zsh (unless
you use the -f option) is .zshenv, so this is a good place to put
things you want even if the shell is non-interactive: options for
changing the syntax, like EXTENDED_GLOB, any changes to set with
`limit', any more variables you want to make sure are set as for
example $fpath to find functions. You almost certainly do not
want .zshenv to produce any output. Some people prefer not to
use .zshenv for setting options, as this affects scripts; but
making zsh scripts portable usually requires special handling anyway.
Finally, .zshrc is run for every interactive shell; that includes
login shells, but also any other time you start up a shell, such as
simply by typing `zsh' or opening a new terminal emulator window.
This file is the place to change the editing behaviour via options or
`bindkey', control how your history is saved, set aliases unless
you want to use them in scripts too, and for any other clutter which
can't be exported but you only use when interacting directly with the
shell. You probably don't want .zshrc to produce output, either,
since there are occasions when this can be a problem, such as when
using `rsh' from another host. See 3.21 for what to put in .zshrc
to save your history.
3.3: What is the difference between `export' and the ALL_EXPORT option?
Normally, you would put a variable into the environment by using
`export var'. The command `setopt allexport' causes all
variables which are subsequently set (N.B. not all the ones which
already exist) to be put into the environment.
This may seem a useful shorthand, but in practice it can have
unhelpful side effects:
1) Since every variable is in the environment as well as remembered
by the shell, the memory for it needs to be allocated twice.
This is bigger as well as slower.
2) It really is *every* variable which is exported, even loop
variables in `for' loops. This is probably a waste.
3) An arbitrary variable created by the user might have a special
meaning to a command. Since all shell variables are visible to
commands, there is no protection against this.
For these reasons it is usually best to avoid ALL_EXPORT unless you
have a specific use for it. One safe use is to set it before
creating a list of variables in an initialisation file, then unset
it immediately afterwards. Only those variables will be automatically
exported.
3.4: How do I turn off spelling correction/globbing for a single command?
In the first case, 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'
To turn off globbing, the rationale is identical:
alias mkdir='noglob mkdir'
You can have both nocorrect and noglob, if you like, but the
nocorrect must come first, since it is needed by the line editor,
while noglob is only handled when the command is examined.
Note also that a shell function won't work: the no... directives must
be expanded before the rest of the command line is parsed.
3.5: How do I get the Meta key to work on my xterm?
The Meta key isn't present on a lot of keyboards, but on some
the Alt key has the same effect. If a character is typed on the
keyboard while the Meta key is held down, the characters is sent
as terminal input with its eighth bit set. For example, ASCII
`A', hex 65, becomes hex E5. This is sometimes used to provide
extra editing commands.
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. You may also
need to set the eightBitOutput resource in your ~/.Xdefaults
file, although this is on by default and it's unlikely anybody will
have tinkered with it.
You don't need the `bindkey' to be able to define your own sequences
with the Meta key, though you still need the `stty'.
If you are using multibyte input directly from the keyboard you
probably don't want to use this feature since the eighth bit in
each byte is used to indicate a part of a multibyte character. See
chapter 5.
3.6: How do I automatically display the directory in my xterm title bar?
You should use the special function `chpwd', which is called when
the directory changes. The following checks that standard output is
a terminal, then puts the directory in the title bar if the terminal
is an xterm or some close relative, or a sun-cmd.
chpwd() {
[[ -t 1 ]] || return
case $TERM in
sun-cmd) print -Pn "\e]l%~\e\\"
;;
*xterm*|rxvt|(dt|k|E)term) print -Pn "\e]2;%~\a"
;;
esac
}
Change `%~' if you want the message to be different. (The `-P'
option interprets such sequences just like in prompts, in this case
producing the current directory; you can of course use `$PWD' here,
but that won't use the `~' notation which I find clearer.) Note that
when the xterm starts up you will probably want to call chpwd
directly: just put `chpwd' in .zshrc after it is defined or autoloaded.
3.7: How do I make the completion list use eight bit characters?
If you are sure your terminal handles this, the easiest way from versions
3.0.6 and 3.1 of the shell is to set the option PRINT_EIGHT_BIT. In
principle, this will work automatically if your computer uses the
`locale' system and your locale variables are set properly, as zsh
understands this. However, it is quite complicated, so if it isn't
already set up, trying the option is a lot easier. For earlier versions
of zsh 3, you are stuck with trying to understand locales, see the
setlocale(3) and zshparam(1) manual pages: the simplest
possibility may be to set LC_ALL=en_US. For older versions of the
shell, there is no easy way out.
3.8: Why do the cursor (arrow) keys not work? (And other terminal oddities.)
The cursor keys send different codes depending on the terminal; zsh
only binds the most well known versions. If you see these problems,
try putting the following in your .zshrc:
bindkey "$(echotc kl)" backward-char
bindkey "$(echotc kr)" forward-char
bindkey "$(echotc ku)" up-line-or-history
bindkey "$(echotc kd)" down-line-or-history
If you use vi mode, use `vi-backward-char' and `vi-forward-char'
where appropriate. As of version 4.0.1, zsh attempts to look up these
codes and to set the key bindings for you (both emacs and vi), but in
some circumstances this may not work.
Note, however, that up to version 3.0 binding arbitrary multiple key
sequences can cause problems, so check that this works with your set
up first. Also, from version 3.1.3, more sequences are supported by
default, namely those in the form `<ESC>O' followed by A,
B, C or D, as well as the corresponding set beginning
`<ESC>[', so this may be redundant.
A particular problem which sometimes occurs is that there are two
different modes for arrow keys, normal mode and keypad mode, which
send different sequences. Although this is largely a historical
artifact, it sometimes happens that your terminal can be switched from
one mode to the other, for example by a rogue programme that sends the
sequence to switch one way, but not the sequence to switch back. Thus
you are stuck with the effects. Luckily in this case the arrow key
sequences are likely to be standard, and you can simply bind both sets.
The following code does this.
bindkey '\e[A' up-line-or-history
bindkey '\e[B' down-line-or-history
bindkey '\e[C' forward-char
bindkey '\e[D' backward-char
bindkey '\eOA' up-line-or-history
bindkey '\eOB' down-line-or-history
bindkey '\eOC' forward-char
bindkey '\eOD' backward-char
For most even vaguely VT100-compatible terminals, the above eight
instructions are a fairly safe bet for your .zshrc. Of course
you can substitute variant functions for the second argument here too.
It should be noted that the `O' / `[' confusion can occur
with other keys such as Home and End. Some systems let you query
the key sequences sent by these keys from the system's terminal
database, terminfo. Unfortunately, the key sequences given there
typically apply to the mode that is not the one zsh uses by default (it's
the "application" mode rather than the "raw" mode). Explaining the use
of terminfo is outside the scope of this FAQ, but if you wish to use the
key sequences given there you can tell the line editor to turn on
"application" mode when it starts and turn it off when it stops:
function zle-line-init () { echoti smkx }
function zle-line-finish () { echoti rmkx }
zle -N zle-line-init
zle -N zle-line-finish
If you only have the predecessor to terminfo, called termcap (which is
what we used to get the cursor keys above), replace `echoti smkx'
with `echotc ks' and replace `echoti rmkx' with `echotc ke'.
3.9: 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).
A problem I have experienced myself (on an AIX 3.2 workstation with
xterm) is that termcap deinitialization sequences sent by `less'
were causing automargins to be turned off --- not actually a shell
problem, but you might have thought it was. The fix is to put `X'
into the environment variable LESS to stop the sequences being sent.
Other programs (though not zsh) may also send that sequence.
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). 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).
3.10: Why does zsh not work in an Emacs shell mode any more?
(This information comes from Bart Schaefer and other zsh-workers.)
Emacs 19.29 or thereabouts stopped using a terminal type of "emacs"
in shell buffers, and instead sets it to "dumb". Zsh only kicks in
its special I'm-inside-emacs initialization when the terminal type
is "emacs".
Probably the most reliable way of dealing with this is to look for
the environment variable `$EMACS', which is set to `t' in
Emacs' shell mode. Putting
[[ $EMACS = t ]] && unsetopt zle
in your .zshrc should be sufficient.
Another method is to put
#!/bin/sh
TERM=emacs exec zsh
into a file ~/bin/eshell, then `chmod +x ~/bin/eshell', and
tell emacs to use that as the shell by adding
(setenv "ESHELL" (expand-file-name "~/bin/eshell"))
to ~/.emacs.
3.11: Why do my autoloaded functions not autoload [the first time]?
The problem is that there are two possible ways of autoloading a
function (see the AUTOLOADING FUNCTIONS section of the zsh manual
page zshmisc for more detailed information):
1) The file contains just the body of the function, i.e.
there should be no line at the beginning saying `function foo {'
or `foo () {', and consequently no matching `}' at the end.
This is the traditional zsh method. The advantage is that the
file is called exactly like a script, so can double as both.
To define a function `xhead () { print -n "\033]2;$*\a"; }',
the file would just contain `print -n "\033]2;$*\a"'.
2) The file contains the entire definition, and maybe even
other code: it is run when the function needs to be loaded, then
the function itself is called up. This is the method in ksh.
To define the same function `xhead', the whole of the
usual definition should be in the file.
In old versions of zsh, before 3.0, only the first behaviour was
allowed, so you had to make sure the file found for autoload just
contained the function body. You could still define other functions
in the file with the standard form for definitions, though they
would be redefined each time you called the main function.
In version 3.0.x, the second behaviour is activated if the file
defines the autoloaded function. Unfortunately, this is
incompatible with the old zsh behaviour which allowed you to
redefine the function when you called it.
From version 3.1, there is an option KSH_AUTOLOAD to allow full ksh
compatiblity, i.e. the function _must_ be in the second form
above. If that is not set, zsh tries to guess which form you are
using: if the file contains only a complete definition of the
function in the second form, and nothing else apart from comments
and whitespace, it will use the function defined in the file;
otherwise, it will assume the old behaviour. The option is set
if `emulate ksh' is in effect, of course.
(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.)
3.12: 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))
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, except that in 3.1.9 there is a new feature
for selecting a base for displaying here:
print $(( [#16] 255 ))
3.13: 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.
In recent versions of zsh (not 3.0), there is a form of quoting which
interprets print sequences like `\n' but otherwise acts like single
quotes: surround the string with $'...'. Hence:
PROMPT=$'Hi Joe,\nwhat now?%# '
is a neat way of doing what you want. Note that it is the quotes, not
the prompt expansion, which turns the `\n' into a newline.
3.14: 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.
3.15: 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 your .zshrc file.
3.16: 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'. If `foo' is a builtin rather than an external
command, use `builtin foo' instead.
3.17: 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.
3.18: 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.
Likewise, you can start a background job with `&!' instead of just
`&' at the end, which will automatically disown the job.
3.19: How do I list all my history entries?
Tell zsh to start from entry 1: `history 1'. Those entries at the
start which are no longer in memory will be silently omitted.
3.20: How does the alternative loop syntax, e.g. `while {...} {...}' work?
Zsh provides an alternative to the traditional sh-like forms with `do',
while TEST; do COMMANDS; done
allowing you to have the COMMANDS delimited with some other command
structure, often `{...}'. The rules are quite complicated and
in most scripts it is probably safer --- and certainly more
compatible --- to stick with the sh-like rules. If you are
wondering, the following is a rough guide.
To make it work you must make sure the TEST itself is clearly
delimited. For example, this works:
while (( i++ < 10 )) { echo i is $i; }
but this does _not_:
while let "i++ < 10"; { echo i is $i; } # Wrong!
The reason is that after `while', any sort of command list is valid.
This includes the whole list `let "i++ < 10"; { echo i $i; }';
the parser simply doesn't know when to stop. Furthermore, it is
wrong to miss out the semicolon, as this makes the `{...}' part
of the argument to `let'. A newline behaves the same as a
semicolon, so you can't put the brace on the next line as in C.
So when using this syntax, the test following the `while' must
be wrapped up: any of `((...))', `[[...]]', `{...}' or
`(...)' will have this effect. (They have their usual syntactic
meanings too, of course; they are not interchangeable.) Note that
here too it is wrong to put in the semicolon, as then the case
becomes identical to the preceding one:
while (( i++ < 10 )); { echo i is $i; } # Wrong!
The same is true of the `if' and `until' constructs:
if { true } { echo yes } else { echo no }
but with `for', which only needs a list of words, you can get
away with it:
for foo in a b; { echo foo is $a; bar=$foo; }
since the parser knows it only needs everything up to the first
semicolon. For the same reason, there is no problem with the `repeat',
`case' or `select' constructs; in fact, `repeat' doesn't even
need the semicolon since it knows the repeat count is just one word.
This is independent of the behaviour of the SHORTLOOPS option (see
manual), which you are in any case encouraged even more strongly not
to use in programs as it can be very confusing.
3.21: Why is my history not being saved?
In zsh, you need to set three variables to make sure your history is
written out when the shell exits. For example,
HISTSIZE=200
HISTFILE=~/.zsh_history
SAVEHIST=200
$HISTSIZE tells the shell how many lines to keep internally,
$HISTFILE tells it where to write the history, and $SAVEHIST,
the easiest one to forget, tells it how many to write out. The
simplest possibility is to set it to the same as $HISTSIZE as
above. There are also various options affecting history; see the
manual.
3.22: How do I get a variable's value to be evaluated as another variable?
The problem is that you have a variable $E containing the string
`EDITOR', and a variable $EDITOR containing the string `emacs',
or something such. How do you get from $E to emacs in one easy
stage?
There is no standard single-stage way of doing this. However, there
is a zsh idiom (available in all versions of zsh since 3.0) for this:
print ${(e)E:+\$$E}
Ignore the `(e)' for now. The `:+' means: if the variable
$E is set, substitute the following, i.e. `\$$E'. This is
expanded to `$EDITOR' by the normal rules. Finally, the `(e)' means
`evaluate the expression you just made'. This gives `emacs'.
For a standard shell way of doing this, you are stuck with `eval':
eval echo \$$E
produces the same result.
Versions since 3.1.6 allow you to do this directly with a new flag;
`${(P)E}'.
As a slight aside, sometimes people note that the syntax `${${E}}'
is valid and expect it to have this effect. It probably ought to, but
in the early days of zsh it was found convenient to have this way of
producing different substitutions on the same parameter; for example,
`${${file##**/}%.*}' removes everything up to the last slash in
`$file', then everything from the last dot on, inclusive (try
it, this works). So in `${${E}}', the internal `${...}'
actually does nothing.
3.23: How do I prevent the prompt overwriting output when there is no newline?
The problem is normally limited to zsh versions prior to 4.3.0 due to the
advent of the PROMPT_SP option (which is enabled by default, and eliminates
this problem for most terminals). An example of the overwriting is:
% echo -n foo
%
This shows a case where the word foo was output without a newline, and
then overwritten by the prompt line %. The reason this happens is that
the option PROMPT_CR is enabled by default, and it outputs a carriage
return before the prompt in order to ensure that the line editor knows what
column it is in (this is needed to position the right-side prompt correctly
(`$RPROMPT', `$RPS1') and to avoid screen corruption when performing
line editing). If you add unsetopt promptcr to your .zshrc, you
will see any partial output, but your screen may look weird until you press
return or refresh the screen.
A better solution than disabling PROMPT_CR (for most terminals) is adding
a simpler version of the PROMPT_SP functionality to an older zsh using a
custom precmd function, like this one:
# Skip defining precmd if the PROMPT_SP option is available.
if ! eval '[[ -o promptsp ]] 2>/dev/null'; then
function precmd {
# Output an inverse char and a bunch spaces. We include
# a CR at the end so that any user-input that gets echoed
# between this output and the prompt doesn't cause a wrap.
print -nP "%B%S%#%s%b${(l:$((COLUMNS-1)):::):-}\r"
}
fi
That precmd function will only bump the screen down to a new line if there
was output on the prompt line, otherwise the extra chars get removed by
the PROMPT_CR action. Although this typically looks fine, it may result
in the spaces preceding the prompt being included when you select a line
of preserved text with the mouse.
One final alternative is to put a newline in your prompt -- see question
3.13 for that.
3.24: What's wrong with cut and paste on my xterm?
On the majority of modern UNIX systems, cutting text from one window and
pasting it into another should work fine. On a few, however, there are
problems due to issues about how the terminal is handled: most programs
expect the terminal to be in `canonical input mode', which means that the
program is passed a whole line of input at a time, while for editing
the shell needs a single character at a time and must be in
`non-canonical input mode'. On the systems in question, input can be
lost or re-ordered when the mode changes. There are actually two
slightly different problems:
1) When you paste something in while a programme is running, so that
the shell only retrieves it later. Traditionally, there was a test
which was used only on systems where the problem was known to exist,
so it is possible some other systems were not handled (for example,
certain versions of IRIX, it appears); also, continuation lines were
not handled properly. A more reliable approach appears from versions
3.0.6 and 3.1.6.
2) When the shell is waiting for input, and you paste in a chunk of
text consisting of more than one complete set of commands.
Unfortunately, this is a much harder problem: the line editor is
already active, and needs to be turned off when the first command is
executed. The shell doesn't even know if the remaining text is input
to a command or for the shell, so there's simply nothing it can do.
However, if you have problems you can trick it: type `{' on a line
by itself, then paste the input, then type `}' on a line by
itself. The shell will not execute anything until the final brace is
read; all input is read as continuation lines (this may require the
fixes referred to above in order to be reliable).
3.25: How do I get coloured prompts on my colour xterm?
(Or `color xterm', if you're reading this in black and white.)
Versions of the shell starting with the 4.3 series have this
built in. Use
PS1='%K{white}%F{red}<red on white>%f%k<default colours>'
to change the prompt. Names are only usable for the colours
black, red, green, yellow, blue, magenta, cyan and white, understood
by most terminals, but if you happen to know the details of how
your terminal implements colours you can specify a number, e.g.
`%20F' to turn the foreground into colour number 20. `echotc
Co' will often output the number of colours the terminal supports.
(Careful: `echotc co' is different; it also outputs a number
but it's the number of columns in the terminal.) If this is 8
then probably you have the named colours and nothing more.
In older versions of the shell you need to find the sequences which
generate the various colours from the manual for your terminal
emulator; these are ANSI standard on those I know about which support
colour. With a recent (post 3.1.6) distribution of zsh, there is a
theme system to handle this for you; even if you don't see that, the
installed function ``colors'' (meaning `colours', if you're not
reading this in black and white) gives the escape sequences. You will
end up with code looking like this (borrowed from Oliver Kiddle):
PS1=$'%{\e[1;31m%}<the rest of your prompt here>%{\e[0m%}'
The `$'' form of quoting turns the ``\e'' into a real escape
character; this only works from about version 3.1.4, so if you're using
3.0.x, you need to do something like
PS1="$(print '%{\e[1;31m%}<the rest goes here>%{\e[0m%}')"
The ``%{...%}'' is used in prompts for strings which will
not appear as characters, so that the prompt code doesn't miscalculate the
length of the prompt which would have a bad effect on editing. The
resulting ``<ESC>[1;31m'' makes the prompt red, and the
``<ESC>[0m'' puts printing back to normal so that the rest of the line
is unchanged.
3.26: Why is my output duplicated with `foo 2>&1 >foo.out | bar'?
This is a slightly unexpected effect of the option MULTIOS, which is
set by default. Let's look more closely:
foo 2>&1 >foo.out | bar
What you're probably expecting is that the command `foo' sends its
standard output to the pipe and so to the input of the command `bar',
while it sends its standard error to the file `foo.out'. What you
actually see is that the output is going both to the pipe and into the
file. To be more explicit, here's the same example with real commands:
% { print output; print error >&2 } 2>&1 >foo.out | sed 's/error/erratic'
erratic
output
% cat foo.out
output
and you can see `output' appears twice.
It becomes clearer what's going on if we write:
% print output >foo1.out >foo2.out
% cat foo1.out
output
% cat foo2.out
output
You might recognise this as a standard feature of zsh, called `multios'
and controlled by the option of the same name, whereby output is copied
to both files when the redirector appears twice. What's going on in the
first example is exactly the same, however the second redirector is
disguised as a pipe. So if you want to turn this effect off, you need
to unset the option `MULTIOS'.
Chapter 4: The mysteries of completion
4.1: 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. (You can
see if the word would be expanded --- not completed --- by TAB by
typing `\C-x g', which lists expansions.) Expansion is generally
fairly intuitive and not under user control; for the rest of the
chapter I will discuss completion only.
An elegant completion system appeared in version 4, replacing the old
compctl command. This is based on functions called automatically for
completion in particular contexts (for example, there is a function
called _cd to handle completion for the cd command) and is
installed automatically with the shell, so all you need to do, in
principal, is to arrange for this to be loaded. Putting `autoload -U
compinit; compinit' in your .zshrc should be enough if the system is
installed properly.
4.2: 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 filename 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
(or something else you can execute, like a builtin command, a
function or an alias) and tries to complete that.
However, the new completion system is highly sensitive to context
and comes with completions for many UNIX commands. These are
automatically loaded when you run compinit as described above.
So the real answer to the question `what can be completed?' is
`anything where an automated guess is possible'. Just hit TAB
and see if the shell manages to guess correctly.
4.3: 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 its options. The default is
for it to beep and completion to stop until you type another
character. You can type \C-D to see all the possible completions.
(That's assuming you're at the end of the line, otherwise \C-D will
delete the next character and you have to use ESC-\C-D.) This can be
changed by the following options, among others:
o with NO_BEEP set, that annoying beep goes away
o with NO_LIST_BEEP, beeping is only turned off for ambiguous
completions
o with AUTO_LIST set, when the completion is ambiguous you get a
list without having to type \C-D
o with BASH_AUTO_LIST set, the list only happens the second
time you hit tab on an ambiguous completion
o with LIST_AMBIGUOUS, this is modified so that nothing is listed if
there is an unambiguous prefix or suffix to be inserted --- this
can be combined with BASH_AUTO_LIST, so that where both are
applicable you need to hit tab three times for a listing.
o with MENU_COMPLETE 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
o with AUTO_MENU, you only get the menu behaviour when you hit TAB
again on the ambiguous completion.
o Finally, although it affects all completion lists, including
those explicitly requested, note also ALWAYS_LAST_PROMPT, which
causes the cursor to return to the line you were editing after
printing the list, provided that is short enough.
Combinations of these are possible; for example, AUTO_LIST and
AUTO_MENU together give an intuitive combination. Note that
from version 3.1 LIST_AMBIGUOUS is set by default; if you use
autolist, you may well want to `unsetopt listambiguous'.
4.4: How do I complete in the middle of words / just what's before the cursor?
Sometimes you have a word on the command-line which is incomplete in the
middle. Normally if you hit tab in zsh, it will simply go to the end of
the word and try to complete there. However, there are two ways of
changing this.
First, there is the option COMPLETE_IN_WORD. This tries to fill in
the word at the point of the cursor. For example, if the current
directory contains `foobar', then with the option set, you can
complete `fbar' to `foobar' by moving the cursor to the
`b' and hitting tab.
To complete just what's before the cursor, ignoring anything after, you
need the function expand-or-complete-prefix: it works mostly like the
usual function bound to tab, but it ignores anything on the right of the
cursor. If you always want this behaviour (some other shells do this),
bind it to tab; otherwise put another binding, e.g. `^X TAB' in
~/.zshrc:
bindkey "^X^I" expand-or-complete-prefix
The completion system's handling of filenames allows you to complete
multiple segments of a path in one go, so for example /u/l/b
can expand to /usr/local/bin or anything else that matches. This
saves you having to expand the middle part of the path separately.
4.5: How do I get started with programmable completion?
The main resource is the zshcompsys manual page. It's complicated,
I'm afraid, far too much to go into here. See also the user guide
referred to above, or copy one of the very many existing functions. For
a professionally produced guide, see the book `From Bash to Z Shell:
Conquering the Command Line' by Oliver Kiddle, Jerry Peek and Peter
Stephenson (me), published by Apress, ISBN 1-59059-376-6. Chapter 10
tells you how to configure the completion system and chapter 15 how
to write your own completion functions.
4.6: Suppose I want to complete all files during a special completion?
If you're using the completion system the shell will decide what
to complete when you hit TAB. That's usually the right thing for
the context, but sometimes you just want to complete files, like
TAB used to do in the old days. You can set up this up as follows:
zle -C complete-file complete-word _generic
zstyle ':completion:complete-file::::' completer _files
bindkey '^xF' complete-file
This turns the key \C-x F into a command complete-file which
goes straight to the completion system's file completion command,
ignoring the normal context. Change the binding how you like.
Note the way the form of completion to use is specified by picking a
`completer' called `_files'. You can define any completion
to be bound to a keystroke by putting the appropriate completion
function at that point. Then change all occurrences of
`complete-file' to a name of your own.
If you simply want to try filename completion as a default when other
completions fail, add it to the `completer' style for normal
completion, for example:
zstyle ':completion:*' completer _complete _ignored _files
This adds filename completion to the end of the default types of
completion. Your actual completer style may include other actions,
such as expansion or approximate completion.
Chapter 5: Multibyte input and output
5.1: What is multibyte input?
For a long time computers had a simple idea of a character: each octet
(8-bit byte) of text contained one character. This meant an application
could only use 256 characters at once. The first 128 characters (0 to
127) on Unix and similar systems usually corresponded to the ASCII
character set, as they still do. So all other possibilities had to be
crammed into the remaining 128. This was done by picking the appropriate
character set for the use you were making. For example, ISO 8859
specified a set of extensions to ASCII for various alphabets.
This was fine for simple extensions and certain short enough relatives of
the Latin alphabet (with no more than a few dozen alphabetic characters),
but useless for complex alphabets. Also, having a different character
set for each language is inconvenient: you have to start a new terminal
to run the shell with each character set. So the character set had to be
extended. To cut a long story short, the world has mostly standardised
on a character set called Unicode, related to the international standard
ISO 10646. The intention is that this will contain every single
character used in all the languages of the world.
This has far too many characters to fit into a single octet. What's
more, UNIX utilities such as zsh are so used to dealing with ASCII that
removing it would cause no end of trouble. So what happens is this: the
128 ASCII characters are kept exactly the same (and they're the same as
the first 128 characters of Unicode), but the remaining 128 characters
are used to build up any other Unicode character by combining multiple
octets together. The shell doesn't need to interpret these directly; it
just needs to ask the system library how many octets form the next
character, and if there's a valid character there at all. (It can also
ask the system what width the character takes up on the screen, so that
characters no longer need to be exactly one position wide.)
The way this is done is called UTF-8. Multibyte encodings of other
character sets exist (you might encounter them for Asian character sets);
zsh will be able to use any such encoding as long as it contains ASCII as
a single-octet subset and the system can provide information about other
characters. However, in the case of Unicode, UTF-8 is the only one you
are likely to enounter that is useful in zsh.
(In case you're confused: Unicode is the character set, while UTF-8 is
an encoding of it. You might hear about other encodings, such as UCS-2
and UCS-4 which are basically the character's index in the character set
as a two-octet or four-octet integer. You might see files encoded this
way, for example on Windows, but the shell can't deal directly with text
in those formats.)
5.2: How does zsh handle multibyte input and output?
Until version 4.3, zsh didn't handle multibyte input properly at all.
Each octet in a multibyte character would look to the shell like a
separate character. If your terminal handled the character set,
characters might appear correct on screen, but trying to edit them would
cause all sorts of odd effects. (It was possible to edit in zsh using
single-byte extensions of ASCII such as the ISO 8859 family, however.)
From version 4.3.4, multibyte input is handled in the line editor if zsh
has been compiled with the appropriate definitions, and is automatically
activated. This is indicated by the option MULTIBYTE, which is
set by default on shells that support multibyte mode. Hence you
can test this with a standard option test: `[[ -o multibyte ]]'.
The MULTIBYTE option affects the entire shell: parameter expansion,
pattern matching, etc. count valid multibyte character strings as a
single character. You can unset the option locally in a function to
revert to single-byte operation.
Note that if the shell is emulating a Bourne shell the MULTIBYTE
option is unset by default. This allows various POSIX modes to
work normally (POSIX does not deal with multibyte characters). If
you use a "sh" or "ksh" emulation interactively you should probably
set the MULTIBYTE option.
The other option that affects multibyte support is COMBINING_CHARS,
new in version 4.3.9. When this is set, any zero-length punctuation
characters that follow an alphanumeric character (the base character) are
assumed to be modifications (accents etc.) to the base character and to
be displayed within the same screen area as the base character. As not
all terminals handle this, even if they correctly display the base
multibyte character, this option is not on by default. Recent versions
of the KDE and GNOME terminal emulators konsole and
gnome-terminal as well as rxvt-unicode, and the Unicode version
of xterm, xterm -u8 or the front-end uxterm, are known to handle
combining characters.
The COMBINING_CHARS option only affects output; combining characters
may always be input, but when the option is off will be displayed
specially. By default this is as a code point (the index of the
character in the character set) between angle brackets, usually
in inverse video. Highlighting of such special characters can
be modified using the new array parameter zle_highlight.
5.3: How do I ensure multibyte input and output work on my system?
Once you have a version of zsh with multibyte support, you need to
ensure the environment is correct. We'll assume you're using UTF-8.
Many modern systems may come set up correctly already. Try one of
the editing widgets described in the next section to see.
There are basically three components.
o The locale. This describes a whole series of features specific
to countries or regions of which the character set is one. Usually
it is controlled by the environment variable LANG (there are
others but this is the one to start with). You need to find a
locale whose name contains `UTF-8'. This will be a variant on
your usual locale, which typically indicates the language and
country; for example, mine is `en_GB.UTF-8'. Luckily, zsh can
complete locale names, so if you have the new completion system
loaded you can type `export LANG=' and attempt to complete a
suitable locale. It's the locale that tells the shell to expect the
right form of multibyte input. (However, there's no guarantee that
the shell is actually going to get this input: for example, if you
edit file names that have been created using a different character
set it won't work properly.)
o The terminal emulator. Those that are supplied with a recent
desktop environment, such as konsole and gnome-terminal, are
likely to have extensive support for localization and may work
correctly as soon as they know the locale. You can enable UTF-8
support for xterm in its application defaults file. The
following are the relevant resources; you don't actually need all of
them, as described below. If you use a `~/.Xdefaults' or
`~/.Xresources' file for setting resources, prefix all the lines
with `xterm':
*wideChars: true
*locale: true
*utf8: 1
*vt100Graphics: true
This turns on support for wide characters (this is enabled by the
utf8 resource, too); enables conversions to UTF-8 from other
locales (this is the key resource and actually overrides
`utf8'); turns on UTF-8 mode (this resource is mostly used to
force use of UTF-8 characters if your locale system isn't up to it);
and allows certain graphic characters to work even with UTF-8
enabled. (Thanks to Phil Pennock for suggestions.)
o The font. If you selected this from a menu in your terminal
emulator, there's a good chance it already selected the right
character set to go with it. If you hand-picked an old fashioned
X font with a lot of dashes, you need to make sure it ends with
the right character encoding, `iso10646-1' (and not, for
example, `iso8859-1'). Not all characters will be available
in any font, and some fonts may have a more restricted range of
Unicode characters than others.
As mentioned in the previous section, `bindkey -m' now outputs
a warning message telling you that multibyte input from the terminal
is likely not to work. (See 3.5 if you don't know what
this feature does.) If your terminal doesn't have characters
that need to be input as multibyte, however, you can still use
the meta bindings and can ignore the warning message. Use
`bindkey -m 2>/dev/null' to suppress it.
You might also note that the latest version of the Cygwin environment
for Windows supports UTF-8. In previous versions, zsh was able
to compile with the MULTIBYTE option enabled, but the system
didn't provide full support for it.
5.4: How can I input characters that aren't on my keyboard?
Two functions are provided with zsh that help you input characters.
As with all editing widgets implemented by functions, you need to
mark the function for autoload, create the widget, and, if you are
going to use it frequently, bind it to a key sequence. The
following binds insert-composed-char to F5 on my keyboard:
autoload -Uz insert-composed-char
zle -N insert-composed-char
bindkey '\e[15~' insert-composed-char
The two widgets are described in the zshcontrib(1) manual
page, but here is a brief summary:
insert-composed-char is followed by two characters that
are a mnemonic for a multibyte character. For example `a:'
is a with an Umlaut; `cH' is the symbol for hearts on a playing
card. Various accented characters, European and related alphabets,
and punctuation and mathematical symbols are available. The
mnemonics are mostly those given by RFC 1345, see
http://www.faqs.org/rfcs/rfc1345.html.
insert-unicode-char is used to input a Unicode character by
its hexadecimal number. This is the number given in the Unicode
character charts, see for example http://www.unicode.org/charts/.
You need to execute the function, then type the hexadecimal number
(you can omit any leading zeroes), then execute the function again.
Both functions can be used without multibyte mode, provided the locale is
correct and the character selected exists in the current character set;
however, using UTF-8 massively extends the number of valid characters
that can be produced.
If you have a recent X Window System installation, you might find
the AltGr key helps you input accented Latin characters; for
example on my keyboard AltGr-; e gives `e' with an acute accent.
See also http://www.cl.cam.ac.uk/~mgk25/unicode.html#input
for general information on entering Unicode characters from a keyboard.
Chapter 6: The future of zsh
6.1: What bugs are currently known and unfixed? (Plus recent important changes)
Bugs tend to be tracked on the zsh-workers mailing list; see the
next section. Check the mailing list to see if a bug has been
reported. (There is a bug tracker at the zsh development site
at Sourceforge, but it's not in active use.)
To see how recent versions of the shell have changed, look at
the README file in the source distribution. This indicates the
most important changes, and in particular draws attention to
incompatibilities you might notice.
6.2: 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,
zsh-workers@zsh.org
so mail on any issues (bug reports, suggestions, complaints...)
related to the development of the shell should be sent there. If
you want someone to mail you directly, say so. Most patches to zsh
appear there first.
Note that this location has just changed (January 1999), and the
instructions to go with it are slightly different --- in particular,
if you are already subscribed, the instructions about how to
unsubscribe are different.
Please note when reporting bugs that many exist only on certain
architectures, which the developers may not have access to. In
this case debugging information, as detailed as possible, is
particularly welcome.
Two progressively lower volume lists exist, one with messages
concerning the use of zsh,
zsh-users@zsh.org
and one just containing announcements: about releases, about major
changes in the shell, or this FAQ, for example,
zsh-announce@zsh.org
(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-subscribe@zsh.org
(the actual content is unimportant). Replace subscribe with
unsubscribe to unsubscribe. The mailing software (ezlm) has
various bells and whistles: you can retrieve archived messages.
Mail zsh-workers-help@zsh.org for detailed information.
Adminstrative matters are best sent to
zsh-workers-owner@zsh.org.
real name is Geoff Wing <gcw@zsh.org>.
An archive of mailings for the last few years can be found at
http://www.zsh.org/mla/
at the main zsh archive in Australia.
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.
6.3: What's on the wish-list?
The code bears the marks of the ages and many things could be done much
better with a rewrite. A more efficient set of code for
lexing/parsing/execution might also be an advantage. Volunteers are
particularly welcome for these tasks.
Some future possibilities which have been suggested:
o The shell, in particular the line editor, should support Unicode
characters. Initial support for this appeared in version 4.3;
it is reasonably complete in the line editor but patchy elsewhere
(note this may require the configuration option --enable-multibyte).
o The parameter code could do with tidying up, maybe with more of the
features made available in ksh93.
o Configuration files to enable zsh startup files to be created
with the Dotfile Generator.
o Further improvements in integrating the line editor with shell
functions.
o POSIX compatibility could be improved.
o Option for glob qualifiers to follow perl syntax (a traditional item).
6.4: Did zsh have problems in the year 2000?
Not that I heard of; it's up to you to be careful with two-digit dates,
though, which are produced by the prompt escapes `%W' and `%D',
and also by the command `print -P'. Earlier versions of zsh may
show problems here.
Acknowledgments:
Thanks to zsh-list, in particular Bart Schaefer, for suggestions
regarding this document. Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman, Zoltan Hidvegi and Andrew
Main, and the mailing list has been run by Peter Gray, Rick Ohnemus,
Richard Coleman, Karsten Thygesen and Geoff Wing, all of whom deserve
thanks. 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
Wischnowsky).
Copyright Information:
This document is copyright (C) P.W. Stephenson, 1995, 1996, 1997,
1998, 1999, 2000, 2012. 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://zsh.sourceforge.net/".
Mini Shell