zsh-announce
 help / color / mirror / code / Atom feed
* Z-Shell Frequently Asked Questions (monthly posting)
@ 1996-12-19  9:55 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1996-12-19  9:55 UTC (permalink / raw)
  To: Zsh announcements list

[I shall be away till 2.1.97 (that's second of January to US
customers) so this is early -- pws]

Archive-Name: unix-faq/shell/zsh
Last-Modified: 1996/12/19
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zsh.FAQ,v 2.22 1996/12/19 09:52:11 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996 (see end of document)

Changes since last issue:
in A4) new version 3.0.2
in A5) update archive list, avoid product placement
in C) reorder, putting the old favourite (word splitting) first
in C2) added a couple of notes on noXXX.
in Z1) added note that `$1=$2' doesn't work, plus workaround.

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 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 it 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) Why does `$var' where var="foo bar" not do what I expect?
C2) How do I turn off spelling correction/globbing for an individual command?
C3) How do I get the meta key to work on my xterm?
C4) Why does my terminal act funny in some way?
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?
C13) How do I list all my history entries?

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? (Plus recent important changes)
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).

  (As a 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); it's 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 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 interactive feature
  in any other freely-available shell which zsh does not also have
  (except smallness).

  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?

  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 Etc/MACHINES in the distribution has more details.

  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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question Z2).
  Changes based on version 2.5 are very unlikely to be useful.

  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.  Also read the Etc/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 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 3.0.2 has now been relased. The new major number 3.0 largely
  reflects the considerable internal changes in zsh to make it more
  reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of Z1).  This is longer
  than usual due to enhanced sh, ksh and POSIX compatibility.

  Version 3.1.0 is under test and will be released shortly.  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, or (most recently) to provide POSIX compliancy.


A5) Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.
  The following are known mirrors (kept frequently up to date); the
  first is the official archive site.  All are available by anonymous
  FTP.

    Hungary     ftp://ftp.cs.elte.hu/pub/zsh/
                (also http://www.cs.elte.hu/pub/zsh/ )
    Australia   ftp://ftp.ips.gov.au/mirror/zsh/
    Finland     ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France      ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany     ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
                ftp://ftp.prz.tu-berlin.de/pub/unix/shells/zsh
    Japan       ftp://ftp.tohoku.ac.jp/mirror/zsh/
                ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway      ftp://ftp.uit.no/pub/unix/shells/zsh/
    Slovenia    ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden      ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK          ftp://ftp.net.lut.ac.uk/zsh/
                (also by FSP at port 21)
    USA         ftp://ftp.math.gatech.edu/pub/zsh/
                ftp://uiarchive.cso.uiuc.edu/pub/packages/shells/zsh/
                ftp://ftp.sterling.com/zsh/
                ftp://ftp.rge.com/pub/shells/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.  You
  can supply these directly to a Web browser.  If you're reading this
  with a recent Web browser, you may just have to click on them.)

  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.


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).

  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.


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; differences with ksh93 will be more
  substantial.

  As a summary of the status:
    i) 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;
   ii) 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);
  iii) 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;
   iv) 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 --- see the detailed
       list below;
    v) 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 commands
       `emulate sh; setopt localoptions' in a shell function will
       turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in C1); 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_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_BUILTINS,
  SH_FILE_EXPANSION, SH_GLOB, SH_OPTION_LETTERS, SH_WORD_SPLIT (see
  question C1) 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 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', or
  if `emulate ksh' is in effect.  Capitalised words with underlines
  refer to shell options. 

  Syntax:
  * Shell word splitting: see question C1).
  * 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.
      The KSH_ARRAYS option is now available.
    Coprocesses are established by `coproc'; `|&' behaves like csh.
  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 been added to fix this.)
    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.)
  * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    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.
      [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 `**'.
    Unquoted assignments do file expansion after `:'s (intended for PATHs).
    `integer' does not allow -i.
  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'.
  * 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).
  Traps and signals:
    Traps are not local to functions.
    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.
      (Note that `>file 2>&1' is the standard Bourne shell command for
      csh's `>&file'.)
    foreach ... loops; alternative syntax for other loops.
    Alternative syntax `if ( ... ) ...', though this still doesn't
      work like csh: it expects a command in the parentheses.  Also
      `for', `which').
    $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 and ksharrays 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               "$@"            ($*: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 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.


B5) 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.


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.
    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.


Section C:  How to get various things to work

C1) 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 `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 shwordsplit.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.


C2) How do I turn off spelling correction/globbing for an individual 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).

  Two notes: 1) a shell function won't work, the no... directives must
  be expanded before the rest of the command line is parsed 2) nocorrect
  must come earlier than noglob if both appear, since it is needed by the
  line editor, while noglob is only handled when the command is examined.


C3) 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.


C4) 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.


C5) Why do my autoloaded functions not autoload [the first time]?

  (Before version 3.0, autoloading in the Korn shell way was not
  allowed; this article is now a historical artefact and will
  eventually be removed.  Note, however, that the old form of
  autoloading is still allowed and there are no plans to remove it.)

  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.)


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 now supported).  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 :-).  Otherwise, you can use
        PROMPT=$(print "Hi Joe,\nwhat now?%# ")
  in your initialisation file.


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.


C13) 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.


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.  (You can
  see if the word would be expanded --- not completed --- by TAB by
  typing "CTRL-x g", which lists expansions.)  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
  (or something else you can execute, like a builtin comman, a
  function or an alias) and tries 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 its 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.
  (That's assuming your at the end of the line, otherwise ^D will
  delete the next character and you have to use Esc-^D.)  This can be
  changed by the following options, among others:
    - with nobeep set, that annoying beep goes away
    - with nolistbeep, beeping is only turned off for ambiguous completions
    - with autolist set, when the completion is ambiguous you get a
      list without having to type ^D
    - with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
    - 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
    - with automenu, you only get the menu behaviour when you hit TAB
      again on the ambiguous completion.  
  Combinations of these are possible; for example, autolist and
  automenu together give an intuitive combination. 


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? (Plus recent important changes)

  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.
    (According to POSIX, this is not a bug with `special' builtins.)
  `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.
  The singlelinezle option has problems with prompts containing escapes.
  The `r' command does not work inside $(...) or `...` expansions.
  `typeset' handling is non-optimal, particularly with regard to flags,
    and is ksh-incompatible in unpredictable ways. 

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes since zsh 2.5:
  The left hand of an assignment is no longer substituted.  Thus,
    `$1=$2' will not work.  You can use something like `eval
    "$1=\$2"', which should have the identical effect.
  Signal traps established with the `trap' builtin are now called with
    the environment of the caller, instead of as a new function level,
    as in ksh.  Traps established as functions (e.g. `TRAPINT()
    {...}') work as before.
  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
    to be the other way around.  (Use of names rather than letters is
    generally recommended.)
  `[[' is a reserved word, hence must be separated from
    other characters by whitespace; `{' and `}' are also reserved
    words if the IGNORE_BRACES option is set.
  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
    always does what it looks like it does, so `if ( ... ) ...'
    executes the code in parentheses in a subshell.  To make this
    useful, the syntax expected after an `if', etc., is less strict
    than in other shells.
  On the other hand, `foo=*' does not perform globbing immediately on
    the right hand side of the assignment; the old behaviour now
    requires the option GLOB_ASSIGN.  (`foo=(*)' is and has always
    been the consistent way of doing this.)
  <> performs redirection of input and output to the specified file.
    For numeric globs, you now need <->.
  The command line qualifiers exec, noglob, command, - are now treated
    more like builtin commands:  previously they were syntactically
    special.  This should make it easier to perform tricks with them
    (disabling, hiding in parameters, etc.).
  The pushd builtin has been rewritten for compatibility with other
    shells.  The old behavour can be achieved with a shell function.
  The current version now uses ~'s for directory stack substitution
    instead of ='s.  This is for consistency:  all other directory
    substitution (~user, ~name, ~+, ...) used a tilde, while =<number>
    caused problems with =program substitution.
  The `HISTLIT' option was broken in various ways and has been removed:
    the rewritten history mechanism doesn't alter history lines, making
    the option unnecessary.
  History expansion is disabled in single-quoted strings, like other
    forms of expansion -- hence exclamation marks there should not be
    backslashed.
  The `HISTCHARS' variable is now `histchars'.  Currently both are
    tied together for compatibility.
  The PROMPT_SUBST option now performs backquote expansion -- hence
    you should quote these in prompts.  (SPROMPT has changed as a result.)
  Quoting in prompts has changed: close parentheses inside ternary
    expressions should be quoted with a %; history is now %!, not !.
    Backslashes are no longer special.


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,
        zsh-workers@math.gatech.edu
  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.

  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@math.gatech.edu
  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,
        zsh-announce@math.gatech.edu
  (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@math.gatech.edu
  with the *subject* line (this is a change from the old list)
        subscribe <your-email-address>
  e.g.
        Subject:  subscribe P.Stephenson@swansea.ac.uk
  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
        coleman@math.gatech.edu

  The list from May 1992 to May 1995 is archived in
        ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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?

  With version 3, the code is much cleaner than before, but still
  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.

  Loadable module support (will be in 3.1 but much work still needs doing).
  Ksh compatibility could be improved.
  Option for glob qualifiers to follow perl syntax (now a traditional item).
  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.
  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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/".

# Local Variables: 
# xref-1:(t 3279 49 0) 
# xref-2:(t 3330 26 1) 
# xref-3:(t 4822 15 2) 
# xref-4:(t 5730 23 3) 
# xref-5:(t 7201 33 4) 
# xref-6:(t 8463 29 5) 
# xref-7:(t 9612 22 6) 
# xref-8:(t 11414 63 7) 
# xref-9:(t 14065 40 8) 
# xref-10:(t 14256 31 9) 
# xref-11:(t 16824 20 10) 
# xref-12:(t 17309 6 11) 
# xref-13:(t 19025 1 12) 
# xref-14:(t 19118 12 13) 
# xref-15:(t 21657 25 14) 
# xref-16:(t 22340 10 15) 
# xref-17:(t 22953 35 16) 
# xref-18:(t 26738 38 17) 
# xref-19:(t 27268 27 18) 
# xref-20:(t 28201 26 19) 
# xref-21:(t 28702 47 20) 
# xref-22:(t 29943 45 21) 
# xref-23:(t 29990 61 22) 
# xref-24:(t 32588 77 23) 
# xref-25:(t 33499 50 24) 
# xref-26:(t 34376 47 25) 
# xref-27:(t 36140 65 26) 
# xref-28:(t 37468 34 27) 
# xref-29:(t 38114 40 28) 
# xref-30:(t 38480 40 29) 
# xref-31:(t 39062 76 30) 
# xref-32:(t 39411 44 31) 
# xref-33:(t 39980 58 32) 
# xref-34:(t 40329 71 33) 
# xref-35:(t 40704 64 34) 
# xref-36:(t 41529 42 35) 
# xref-37:(t 41704 39 36) 
# xref-38:(t 42081 23 37) 
# xref-39:(t 43106 42 38) 
# xref-40:(t 45470 49 39) 
# xref-41:(t 46818 54 40) 
# xref-42:(t 51767 53 41) 
# xref-43:(t 52485 29 42) 
# xref-44:(t 52516 78 43) 
# xref-45:(t 53719 17 44) 
# xref-46:(t 54850 33 45) 
# xref-47:(t 56581 65 46) 
# xref-48:(t 58224 39 47) 
# xref-49:(t 58554 28 48) 
# xref-50:(1243 12 (6)) 
# xref-51:(1319 3 (46)) 
# xref-52:(1458 10 (6)) 
# xref-53:(1508 3 (1)) 
# xref-54:(1535 3 (2)) 
# xref-55:(1551 3 (8)) 
# xref-56:(1575 3 (8)) 
# xref-57:(1645 3 (8)) 
# xref-58:(1676 3 (6)) 
# xref-59:(1699 3 (7)) 
# xref-60:(1764 10 (8)) 
# xref-61:(1805 3 (9)) 
# xref-62:(1821 3 (14)) 
# xref-63:(1830 3 (16)) 
# xref-64:(1868 26 (28)) 
# xref-65:(1896 3 (18)) 
# xref-66:(1906 3 (19)) 
# xref-67:(1916 3 (20)) 
# xref-68:(1965 10 (21)) 
# xref-69:(2011 3 (22)) 
# xref-70:(2073 3 (23)) 
# xref-71:(2151 3 (24)) 
# xref-72:(2202 3 (25)) 
# xref-73:(2250 3 (26)) 
# xref-74:(2316 3 (27)) 
# xref-75:(2351 3 (29)) 
# xref-76:(2392 3 (46)) 
# xref-77:(2469 3 (31)) 
# xref-78:(2514 4 (32)) 
# xref-79:(2573 4 (33)) 
# xref-80:(2645 4 (34)) 
# xref-81:(2710 4 (35)) 
# xref-82:(2754 10 (36)) 
# xref-83:(2794 3 (37)) 
# xref-84:(2818 3 (38)) 
# xref-85:(2861 3 (39)) 
# xref-86:(2911 3 (40)) 
# xref-87:(2966 3 (41)) 
# xref-88:(3021 10 (42)) 
# xref-89:(3051 3 (43)) 
# xref-90:(3130 3 (46)) 
# xref-91:(3196 3 (48)) 
# xref-92:(4556 3 (6)) 
# xref-93:(4815 3 (46)) 
# xref-94:(5451 11 (46)) 
# xref-95:(7833 15 (46)) 
# xref-96:(7985 3 (6)) 
# xref-97:(8776 17 (44)) 
# xref-98:(9311 18 (44)) 
# xref-99:(15831 3 (22)) 
# xref-100:(16625 12 (22)) 
# xref-101:(17291 12 (22)) 
# xref-102:(19923 12 (16)) 
# xref-103:(22945 3 (11)) 
# xref-104:(45458 7 (40)) 
# xref-105:(52762 12 (10)) 
# End: 


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1998-10-26 10:09 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1998-10-26 10:09 UTC (permalink / raw)
  To: zsh-announce


Archive-Name: unix-faq/shell/zsh
Last-Modified: 1998/10/26
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zshfaq.yo,v 1.31 1998/10/26 09:43:13 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996, 1997, 1998 (see end of document)

Changes since issue posted September 1998:

2.1  Another `typeset' difference turned up.
5.4  Slight addition to Y2K item (prompt formatting)

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?

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. What is the difference between `export' and the ALL_EXPORT option?
3.3. How do I turn off spelling correction/globbing for a single command?
3.4. How do I get the meta key to work on my xterm?
3.5. How do I automatically display the directory in my xterm title bar?
3.6. How do I make the completion list use eight bit characters?
3.7. Why do the cursor (arrow) keys not work?
3.8. Why does my terminal act funny in some way?
3.9. Why does zsh not work in an Emacs shell mode any more?
3.10. Why do my autoloaded functions not autoload [the first time]?
3.11. How does base arithmetic work?
3.12. How do I get a newline in my prompt?
3.13. Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
3.14. Why can't I bind \C-s and \C-q any more?
3.15. How do I execute command `foo' within function `foo'?
3.16. Why do history substitutions with single bangs do something funny?
3.17. Why does zsh kill off all my background jobs when I logout?
3.18. How do I list all my history entries?
3.19. How does the alternative loop syntax, e.g. `while {...} {...}' work?
3.20. Why is my history not being saved?

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. And if programmable completion isn't good enough?

Chapter 5:  The future of zsh
5.1. What bugs are currently known and unfixed? (Plus recent important changes)
5.2. Where do I report bugs, get more info / who's working on zsh?
5.3. What's on the wish-list?
5.4. Will 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://sunsite.auc.dk/zsh/ (note the change of address from the
  end of April 1998).  The server provides this FAQ and much else and is
  now maintained by Karsten Thygesen and others (mail zsh@sunsite.auc.dk
  with any related messages).  The FAQ is at http://sunsite.auc.dk/zsh/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://sunsite.auc.dk/zsh/FAQ/zshfaq.yo .

  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 1.6.

  There is now a preliminary version of a reference card for
  zsh 3.0, which you can find (while it's being developed) at
    http://www.ifh.de/~pws/computing/refcard.ps
  This is optimised for A4 paper. The LaTeX source is in the
  same place with the extension .tex.  It is not a good place
  from which to learn zsh for the first time.

  (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 globbing (compctl -g),
    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,
    o  variable, editing function and option name completion,
    o  inline expansion of variables, 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 arithmetic.
  o  Manipulation of arrays (including reverse subscripting).
  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 Etc/MACHINES in the distribution has more details.

  There are also now separate ports for Windows and OS/2, see `Where
  do I get it' 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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question
  5.2).  Changes based on version 2.5 are very unlikely to
  be useful.

  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 Etc/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 3.0.5 is the latest production version. The new major number 3.0
  largely reflects the considerable internal changes in zsh to make it
  more reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of 5.1.  This is
  longer than usual due to enhanced sh, ksh and POSIX compatibility.

  The beta version 3.1.4 is also available.  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 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 (most recently) to provide POSIX compliancy.

1.6: Where do I get it?

  The archive is now run by Andrew Main <zefram@tao.co.uk>.
  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 .

    Home site ftp://ftp.zsh.org
    Australia ftp://ftp.ips.gov.au/mirror/zsh/
    Denmark   ftp://sunsite.auc.dk/pub/unix/shells/zsh
    Finland   ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France    ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany   ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
              ftp://ftp.gmd.de/packages/zsh/
              ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Hungary   ftp://ftp.cs.elte.hu/pub/zsh/
              (also http://www.cs.elte.hu/pub/zsh/ )
    Israel    ftp://ftp.math.technion.ac.il/mirror/ftp.zsh.org/pub/zsh/
              http://www.math.technion.ac.il/mirror/ftp.zsh.org/pub/zsh/
    Japan     ftp://ftp.tohoku.ac.jp/mirror/zsh/
              ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway    ftp://ftp.uit.no/pub/unix/shells/zsh/
    Romania   ftp://ftp.roedu.net/pub/mirrors/ftp.zsh.org/pub/zsh/
    Slovenia  ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden    ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK        ftp://ftp.net.lut.ac.uk/zsh/
              (also by FSP at port 21)
              ftp://src.doc.ic.ac.uk/packages/unix/shells/zsh/
    USA       ftp://ftp.math.gatech.edu/pub/zsh/
              ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
              ftp://ftp.sterling.com/zsh/
              ftp://ftp.rge.com/pub/shells/zsh/

  The Windows port mentioned above is maintained separately by Amol
  Deshpande <amold@microsoft.com>; please mail Amol directly about any
  Windows-specific problems.  This is quite new, so don't expect it to
  be perfect.  You can get it from:

            ftp://ftp.blarg.net/users/amol/zsh  

  Likewise the OS/2 port is available from TAMURA Kent
  <kent@tril.ibm.co.jp> at

            http://cgi.din.or.jp/~tkent/tmp/zsh-3.0.0-os2-a01.zip

  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://sunsite.auc.dk/zsh/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 commands
     `emulate sh; setopt localoptions' in a shell function will
     turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in 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_BUILTINS, 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 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', 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.
        The KSH_ARRAYS option is now available.
    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.
        (GLOB_SUBST has been added to fix this.)
    o   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.)
    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
        the way to exclude some subdirectories from matching a `**'.
    o   Unquoted assignments do file expansion after `:'s (intended for
        PATHs). 
    o   `integer' does not allow `-i'.
    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  Traps and signals:

    o   Traps are not local to functions.
    o   TRAPERR has become TRAPZERR (this was forced by UNICOS which
        has SIGERR).

  o  Editing:

    o   The options emacs, gmacs, viraw are not supported.
        Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
        becomes `bindkey -{e,v}'; 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' will not be in the next ksh
        release either.)
    o   Management of histories in multiple shells is different:
        the history list is not saved and restored after each command.
    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  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   `read' has no `-s' 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" 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 shwordsplit and ksharrays 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         "$@"            ($*: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.

  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.

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,
  $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 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.

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.

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.

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.)  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 `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 SHWORDSPLIT.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.

3.2: 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.3: 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.4: 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.

3.5: 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 a sun-cmd.

  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) 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.6: How do I make the completion list use eight bit characters?

  A traditional UNIX environment (character terminal and ASCII
  character sets) is not sufficient to be able to handle non-ASCII
  characters, and there are so many possible enhancements that in
  general this is hard.  However, if you have something like an xterm
  using a standard character set like ISO-8859-1 (which is often the
  default for xterm), read on.  You should also note question
  3.4 on the subject of eight bit characters.

  You are probably creating files with names including non-ASCII
  accented characters, and find they show up in the completion list as
  \M-i or something such.  This is because the library routines
  (not zsh itself) which test whether a character is printable have
  replied that it is not; zsh has simply found a way to show them
  anyway.

  The answer, under a modern POSIXy operating system, is to find a
  locale where these are treated as printable characters.  Zsh has
  handling for locales built in and will recognise when you set a
  relevant variable. You need to look in /usr/lib/locale to find one
  which suits you; the subdirectories correspond to the locale names.
  The simplest possibility is likely to be en_US, so that the simplest
  answer to your problem is to set

    LC_CTYPE=en_US

  when your terminal is capable of showing eight bit characters.  If
  you only have a default domain (called C), you may need to have some
  additional files installed on your system.

3.7: Why do the cursor (arrow) keys not work?

  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.

  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.

3.8: 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.

3.9: 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" "~/bin/eshell")

  to ~/.emacs.

3.10: 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 KSHAUTOLOAD 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.11: 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 now supported).  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.

3.12: 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 :-).  Otherwise, you can use

    PROMPT=$(print "Hi Joe,\nwhat now?%# ")

  in your initialisation file.

3.13: 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.14: 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.15: 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.16: 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.17: 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.18: 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.19: 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.20: 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.

Chapter 4: 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.

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.

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 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
  (or something else you can execute, like a builtin command, a
  function or an alias) and tries 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.

  A useful addition for zsh from version 3.1 is directory completion:

    compctl -/ cd

  Before, you had to use -g, but this is neater: it takes care of
  things like ignoring directories beginning with a dot unless you've
  typed the dot yourself, and whole directory paths are understood.

  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 4.5.)  Also, from
  version 3.1 you can always handle directories at the same time as
  other files just by adding -/ to the list.

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 your 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 nobeep set, that annoying beep goes away
   o  with nolistbeep, beeping is only turned off for ambiguous completions
   o  with autolist set, when the completion is ambiguous you get a
      list without having to type \C-D
   o  with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
   o  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
   o  with automenu, 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 alwayslastprompt, 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, autolist and
  automenu together give an intuitive combination.  Note that
  from version 3.1 listambiguous 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 (let's stick to file
  names) 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.

  That's not the full story, however.  Sometimes you just want the
  part of the word before the cursor completed.  For example, the word
  is `/usr/loc/b', which you want to complete to `/usr/local/bin'.
  Normally, zsh won't do this in one go because there are two bits
  missing (but see below!), so you need to complete the `/usr/loc'
  on its own first.  For this 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

  then in the example you can move to just after `/usr/loc', hit
  whatever key you've just bound, move to the end, and hit tab.
  (Note that AUTO_REMOVE_SLASH behaviour applies here, see the manual.)

  Even that doesn't exhaust the possibilities.  Included with the
  source distribution is the file Functions/multicomp, a function
  which you can bind as an alternative form of default completion (see
  below for a description of alternative completion), e.g.

    compctl -D -f + -U -Q -K multicomp

  and whole sequences of directories, like `/usr/loc/b' or even
  `/u/l/b' can be completed in one go.  It works best with
  menucompletion if the result is ambiguous.

4.5: 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).

  (Note the difference in the ways `+' and `-x' work.  A `+'
  completion will always try and find completions for what's before
  the `+' first; it will only produce a list for what's after if
  the first list was empty.  On the other hand, if a condition for a
  `-x' matches, the appropriate set of completions is always used,
  even if the list of completions produced is empty.)

  The condition is then followed by the flags as usual (as in 4.2),
  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):

   1) 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',
   2) 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 `-',
   3) 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.

  You must be careful to put the whole expression inside quotation
  marks, so that it appears as a single argument to compctl.

  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.

4.6: 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 the part of the word already typed, and can read
  the rest of the line with `read -c'.  It can return a set of
  completions 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.

Chapter 5: The future of zsh

5.1: What bugs are currently known and unfixed? (Plus recent important changes)

  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 2.1; 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.

  o  `time' is ignored with builtins and can't be used with `{...}'.
  o  `set -x' (`setopt xtrace') still has a few glitches.
  o  Zsh's notion of the current line number (via $LINENO) is
     sometimes not well handled, particularly when using functions and traps.
  o  In vi mode, `u' can go past the original modification point.
  o  The singlelinezle option has problems with prompts containing escapes.
  o  The `r' command does not work inside `$(...)' or ``...`'
     expansions.   (This is fixed in 3.1.)
  o  `typeset' handling is non-optimal, particularly with regard to
     flags, and is ksh-incompatible in unpredictable ways. 
  o  Nested closures in extended globbing and pattern matching, such as

      [[ fofo = (fo#)# ]]

     were not correctly handled, and there were problems with
     complicated exclusions using `^' or `~'.  (These
     are fixed in version 3.1.3.)

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes after zsh 3.0 (3.1.x is still currently in beta):

  o  The options ALWAYS_LAST_PROMPT (return to the line you were
     editing after displaying completion lists) and LIST_AMBIGUOUS
     (show matching files when there are several) are now set by
     default.  This is in response to complaints that too many zsh
     features are never noticed by many users.  To turn them off,
     just put `unsetopt alwayslastprompt listambiguous' in your
     .zshrc file.
  o  history-search-{forward,backward} now only find previous
     lines where the first word is the same as the current one.  For
     example, 

      comp<ESC>p

     will find lines in the history like `comp -edit emacs', but not
     `compress file' any more.  For this reason, `\M-n' and
     `\M-p' use history-beginning-search-{forward,backward} which
     search for a line with the same prefix up to the cursor position.
     It is possible to write functions which go a little closer to the
     original behaviour; further changes are still possible.
  o  In vi insert mode, the cursor keys no longer work.  The following
     will bind them:

       bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \ 
                      '^[[A' up-line-or-history '^[[B' down-line-or-history

     (unless your terminal requires `^[O' instead of `^[[').  The
     rationale is that the insert mode and command mode keymaps for
     keys with prefixes are now separate.

  Changes since zsh 2.5:

  o  The left hand of an assignment is no longer substituted.  Thus,
     `$1=$2' will not work.  You can use something like `eval
     "$1=\$2"', which should have the identical effect.
  o  Signal traps established with the `trap' builtin are now called with
     the environment of the caller, as in ksh, instead of as a new
     function level.  Traps established as functions (e.g. `TRAPINT()
     {...}') work as before.
  o  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
     to be the other way around.  (Use of names rather than letters is
     generally recommended.)
  o  `[[' is a reserved word, hence must be separated from
     other characters by whitespace; `{' and `}' are also reserved
     words if the IGNORE_BRACES option is set.
  o  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
     always does what it looks like it does, so `if ( ... ) ...'
     executes the code in parentheses in a subshell.  To make this
     useful, the syntax expected after an `if', etc., is less strict
     than in other shells.
  o  `foo=*' does not perform globbing immediately on the right
     hand side of the assignment; the old behaviour now requires the
     option GLOB_ASSIGN.  (`foo=(*)' is and has always been the
     consistent way of doing this.)
  o  <> performs redirection of input and output to the specified file.
     For numeric globs, you now need <->.
  o  The command line qualifiers exec, noglob, command, - are now
     treated more like builtin commands:  previously they were
     syntactically special.  This should make it easier to perform
     tricks with them (disabling, hiding in parameters, etc.).
  o  The pushd builtin has been rewritten for compatibility with other
     shells.  The old behavour can be achieved with a shell function.
  o  The current version now uses ~'s for directory stack substitution
     instead of ='s.  This is for consistency:  all other directory
     substitution (~user, ~name, ~+, ...) used a tilde, while
     =<number> caused problems with =program substitution.
  o  The `HISTLIT' option was broken in various ways and has been removed:
     the rewritten history mechanism doesn't alter history lines, making
     the option unnecessary.
  o  History expansion is disabled in single-quoted strings, like other
     forms of expansion -- hence exclamation marks there should not be
     backslashed.
  o  The `$HISTCHARS' variable is now `$histchars'.  Currently both
     are tied together for compatibility.
  o  The PROMPT_SUBST option now performs backquote expansion -- hence
     you should quote these in prompts.  (SPROMPT has changed as a result.)
  o  Quoting in prompts has changed: close parentheses inside ternary
     expressions should be quoted with a %; history is now %!, not
     !.  Backslashes are no longer special.

5.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@math.gatech.edu

  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.

  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@math.gatech.edu

  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,

    zsh-announce@math.gatech.edu

  (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@math.gatech.edu

  with the *subject* line (this is a change from the old list)

    subscribe <your-email-address>

  e.g.

    Subject:  subscribe P.Stephenson@swansea.ac.uk

  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
  coleman@math.gatech.edu.

  The list from May 1992 to May 1995 is archived in
    ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.  More recent
  mailings up to date are to 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.

5.3: What's on the wish-list?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  o  Loadable module support (will be in 3.1 but much work still needs doing).
  o  Ksh compatibility could be improved.
  o  Option for glob qualifiers to follow perl syntax (a traditional item).
  o  Binding of shell functions to key strokes, accessing editing
     buffer from functions, executing zle functions as a command:  now
     under development for 3.1. 
  o  Users should be able to create their own foopath/FOOPATH array/path
     combinations.

5.4: Will zsh have problems in the year 2000?

  (This information was written by Bart Schaefer.  Note it is a
  description of the state of affairs as seen by the developers, it is
  not a guarantee!)

  You can confirm the following by looking at the source code yourself
  if necessary; there's no other definitive reference:

  Zsh uses UNIX/POSIX time_t, timeval, and tm data types for internal
  date manipulations.  These types either do not store year values at
  all (for example, time_t is measured in seconds since midnight, Jan
  1, 1970) or store them as integer types and NOT as pairs of digits.
  Thus there can be no overflows at year 2000.  On some unix systems,
  time_t is a 32-bit value and will overflow during the year 2038, but
  more modern systems use a 64-bit time_t.

  The only input and output of dates that zsh performs for its own use
  is optional history time-stamping.  This is performed using time_t
  values converted to long integers, which are either 32 or 64 bits,
  see above.

  Note, however, that zsh does provide facilities for formatted date
  output, in particular in prompt escapes such as `%W' and
  `%D' using `print -P', so it's possible that scripts written
  for zsh might employ 2-digit years.  Shell scripts should always be
  considered separate programs and therefore evaluated individually.

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
and Richard Coleman, 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. 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://sunsite.auc.dk/zsh/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1998-09-24  9:46 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1998-09-24  9:46 UTC (permalink / raw)
  To: zsh-announce


Archive-Name: unix-faq/shell/zsh
Last-Modified: 1998/9/24
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zshfaq.yo,v 1.29 1998/09/24 09:56:03 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996, 1997, 1998 (see end of document)

Changes since issue posted August 1998:

1.1  Add note on contributed scripts and functions at web site.
4.5  Extra note on differences between `+' and `-x' in compctl
5.1  Moved item on quirks of $LINENO here, as it's really a bug

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?

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. What is the difference between `export' and the ALL_EXPORT option?
3.3. How do I turn off spelling correction/globbing for a single command?
3.4. How do I get the meta key to work on my xterm?
3.5. How do I automatically display the directory in my xterm title bar?
3.6. How do I make the completion list use eight bit characters?
3.7. Why do the cursor (arrow) keys not work?
3.8. Why does my terminal act funny in some way?
3.9. Why does zsh not work in an Emacs shell mode any more?
3.10. Why do my autoloaded functions not autoload [the first time]?
3.11. How does base arithmetic work?
3.12. How do I get a newline in my prompt?
3.13. Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
3.14. Why can't I bind \C-s and \C-q any more?
3.15. How do I execute command `foo' within function `foo'?
3.16. Why do history substitutions with single bangs do something funny?
3.17. Why does zsh kill off all my background jobs when I logout?
3.18. How do I list all my history entries?
3.19. How does the alternative loop syntax, e.g. `while {...} {...}' work?
3.20. Why is my history not being saved?

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. And if programmable completion isn't good enough?

Chapter 5:  The future of zsh
5.1. What bugs are currently known and unfixed? (Plus recent important changes)
5.2. Where do I report bugs, get more info / who's working on zsh?
5.3. What's on the wish-list?
5.4. Will 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://sunsite.auc.dk/zsh/ (note the change of address from the
  end of April 1998).  The server provides this FAQ and much else and is
  now maintained by Karsten Thygesen and others (mail zsh@sunsite.auc.dk
  with any related messages).  The FAQ is at http://sunsite.auc.dk/zsh/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://sunsite.auc.dk/zsh/FAQ/zshfaq.yo .

  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 1.6.

  There is now a preliminary version of a reference card for
  zsh 3.0, which you can find (while it's being developed) at
    http://www.ifh.de/~pws/computing/refcard.ps
  This is optimised for A4 paper. The LaTeX source is in the
  same place with the extension .tex.  It is not a good place
  from which to learn zsh for the first time.

  (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 globbing (compctl -g),
    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,
    o  variable, editing function and option name completion,
    o  inline expansion of variables, 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 arithmetic.
  o  Manipulation of arrays (including reverse subscripting).
  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 Etc/MACHINES in the distribution has more details.

  There are also now separate ports for Windows and OS/2, see `Where
  do I get it' 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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question
  5.2).  Changes based on version 2.5 are very unlikely to
  be useful.

  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 Etc/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 3.0.5 is the latest production version. The new major number 3.0
  largely reflects the considerable internal changes in zsh to make it
  more reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of 5.1.  This is
  longer than usual due to enhanced sh, ksh and POSIX compatibility.

  The beta version 3.1.4 is also available.  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 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 (most recently) to provide POSIX compliancy.

1.6: Where do I get it?

  The archive is now run by Andrew Main <zefram@tao.co.uk>.
  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 .

    Home site ftp://ftp.zsh.org
    Australia ftp://ftp.ips.gov.au/mirror/zsh/
    Denmark   ftp://sunsite.auc.dk/pub/unix/shells/zsh
    Finland   ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France    ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany   ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
              ftp://ftp.gmd.de/packages/zsh/
              ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Hungary   ftp://ftp.cs.elte.hu/pub/zsh/
              (also http://www.cs.elte.hu/pub/zsh/ )
    Israel    ftp://ftp.math.technion.ac.il/mirror/ftp.zsh.org/pub/zsh/
              http://www.math.technion.ac.il/mirror/ftp.zsh.org/pub/zsh/
    Japan     ftp://ftp.tohoku.ac.jp/mirror/zsh/
              ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway    ftp://ftp.uit.no/pub/unix/shells/zsh/
    Romania   ftp://ftp.roedu.net/pub/mirrors/ftp.zsh.org/pub/zsh/
    Slovenia  ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden    ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK        ftp://ftp.net.lut.ac.uk/zsh/
              (also by FSP at port 21)
              ftp://src.doc.ic.ac.uk/packages/unix/shells/zsh/
    USA       ftp://ftp.math.gatech.edu/pub/zsh/
              ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
              ftp://ftp.sterling.com/zsh/
              ftp://ftp.rge.com/pub/shells/zsh/

  The Windows port mentioned above is maintained separately by Amol
  Deshpande <amold@microsoft.com>; please mail Amol directly about any
  Windows-specific problems.  This is quite new, so don't expect it to
  be perfect.  You can get it from:

            ftp://ftp.blarg.net/users/amol/zsh  

  Likewise the OS/2 port is available from TAMURA Kent
  <kent@tril.ibm.co.jp> at

            http://cgi.din.or.jp/~tkent/tmp/zsh-3.0.0-os2-a01.zip

  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://sunsite.auc.dk/zsh/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 commands
     `emulate sh; setopt localoptions' in a shell function will
     turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in 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_BUILTINS, 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 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', 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.
        The KSH_ARRAYS option is now available.
    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.
        (GLOB_SUBST has been added to fix this.)
    o   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.)
    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
        the way to exclude some subdirectories from matching a `**'.
    o   Unquoted assignments do file expansion after `:'s (intended for
        PATHs). 
    o   `integer' does not allow `-i'.

  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  Traps and signals:

    o   Traps are not local to functions.
    o   TRAPERR has become TRAPZERR (this was forced by UNICOS which
        has SIGERR).

  o  Editing:

    o   The options emacs, gmacs, viraw are not supported.
        Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
        becomes `bindkey -{e,v}'; 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' will not be in the next ksh
        release either.)
    o   Management of histories in multiple shells is different:
        the history list is not saved and restored after each command.
    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  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   `read' has no `-s' 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" 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 shwordsplit and ksharrays 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         "$@"            ($*: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.

  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.

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,
  $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 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.

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.

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.

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.)  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 `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 SHWORDSPLIT.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.

3.2: 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.3: 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.4: 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.

3.5: 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 a sun-cmd.

  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) 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.6: How do I make the completion list use eight bit characters?

  A traditional UNIX environment (character terminal and ASCII
  character sets) is not sufficient to be able to handle non-ASCII
  characters, and there are so many possible enhancements that in
  general this is hard.  However, if you have something like an xterm
  using a standard character set like ISO-8859-1 (which is often the
  default for xterm), read on.  You should also note question
  3.4 on the subject of eight bit characters.

  You are probably creating files with names including non-ASCII
  accented characters, and find they show up in the completion list as
  \M-i or something such.  This is because the library routines
  (not zsh itself) which test whether a character is printable have
  replied that it is not; zsh has simply found a way to show them
  anyway.

  The answer, under a modern POSIXy operating system, is to find a
  locale where these are treated as printable characters.  Zsh has
  handling for locales built in and will recognise when you set a
  relevant variable. You need to look in /usr/lib/locale to find one
  which suits you; the subdirectories correspond to the locale names.
  The simplest possibility is likely to be en_US, so that the simplest
  answer to your problem is to set

    LC_CTYPE=en_US

  when your terminal is capable of showing eight bit characters.  If
  you only have a default domain (called C), you may need to have some
  additional files installed on your system.

3.7: Why do the cursor (arrow) keys not work?

  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.

  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.

3.8: 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.

3.9: 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" "~/bin/eshell")

  to ~/.emacs.

3.10: 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 KSHAUTOLOAD 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.11: 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 now supported).  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.

3.12: 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 :-).  Otherwise, you can use

    PROMPT=$(print "Hi Joe,\nwhat now?%# ")

  in your initialisation file.

3.13: 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.14: 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.15: 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.16: 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.17: 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.18: 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.19: 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.20: 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.

Chapter 4: 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.

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.

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 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
  (or something else you can execute, like a builtin command, a
  function or an alias) and tries 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.

  A useful addition for zsh from version 3.1 is directory completion:

    compctl -/ cd

  Before, you had to use -g, but this is neater: it takes care of
  things like ignoring directories beginning with a dot unless you've
  typed the dot yourself, and whole directory paths are understood.

  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 4.5.)  Also, from
  version 3.1 you can always handle directories at the same time as
  other files just by adding -/ to the list.

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 your 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 nobeep set, that annoying beep goes away
   o  with nolistbeep, beeping is only turned off for ambiguous completions
   o  with autolist set, when the completion is ambiguous you get a
      list without having to type \C-D
   o  with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
   o  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
   o  with automenu, 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 alwayslastprompt, 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, autolist and
  automenu together give an intuitive combination.  Note that
  from version 3.1 listambiguous 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 (let's stick to file
  names) 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.

  That's not the full story, however.  Sometimes you just want the
  part of the word before the cursor completed.  For example, the word
  is `/usr/loc/b', which you want to complete to `/usr/local/bin'.
  Normally, zsh won't do this in one go because there are two bits
  missing (but see below!), so you need to complete the `/usr/loc'
  on its own first.  For this 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

  then in the example you can move to just after `/usr/loc', hit
  whatever key you've just bound, move to the end, and hit tab.
  (Note that AUTO_REMOVE_SLASH behaviour applies here, see the manual.)

  Even that doesn't exhaust the possibilities.  Included with the
  source distribution is the file Functions/multicomp, a function
  which you can bind as an alternative form of default completion (see
  below for a description of alternative completion), e.g.

    compctl -D -f + -U -Q -K multicomp

  and whole sequences of directories, like `/usr/loc/b' or even
  `/u/l/b' can be completed in one go.  It works best with
  menucompletion if the result is ambiguous.

4.5: 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).

  (Note the difference in the ways `+' and `-x' work.  A `+'
  completion will always try and find completions for what's before
  the `+' first; it will only produce a list for what's after if
  the first list was empty.  On the other hand, if a condition for a
  `-x' matches, the appropriate set of completions is always used,
  even if the list of completions produced is empty.)

  The condition is then followed by the flags as usual (as in 4.2),
  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):

   1) 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',
   2) 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 `-',
   3) 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.

  You must be careful to put the whole expression inside quotation
  marks, so that it appears as a single argument to compctl.

  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.

4.6: 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 the part of the word already typed, and can read
  the rest of the line with `read -c'.  It can return a set of
  completions 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.

Chapter 5: The future of zsh

5.1: What bugs are currently known and unfixed? (Plus recent important changes)

  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 2.1; 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.

  o  `time' is ignored with builtins and can't be used with `{...}'.
  o  `set -x' (`setopt xtrace') still has a few glitches.
  o  Zsh's notion of the current line number (via $LINENO) is
     sometimes not well handled, particularly when using functions and traps.
  o  In vi mode, `u' can go past the original modification point.
  o  The singlelinezle option has problems with prompts containing escapes.
  o  The `r' command does not work inside `$(...)' or ``...`'
     expansions.   (This is fixed in 3.1.)
  o  `typeset' handling is non-optimal, particularly with regard to
     flags, and is ksh-incompatible in unpredictable ways. 
  o  Nested closures in extended globbing and pattern matching, such as

      [[ fofo = (fo#)# ]]

     are not correctly handled, and there were problems with
     complicated exclusions using `^' or `~'.  (These
     are fixed in version 3.1.3.)

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes after zsh 3.0 (3.1.x is still currently in beta):

  o  The options ALWAYS_LAST_PROMPT (return to the line you were
     editing after displaying completion lists) and LIST_AMBIGUOUS
     (show matching files when there are several) are now set by
     default.  This is in response to complaints that too many zsh
     features are never noticed by many users.  To turn them off,
     just put `unsetopt alwayslastprompt listambiguous' in your
     .zshrc file.
  o  history-search-{forward,backward} now only find previous
     lines where the first word is the same as the current one.  For
     example, 

      comp<ESC>p

     will find lines in the history like `comp -edit emacs', but not
     `compress file' any more.  For this reason, `\M-n' and
     `\M-p' use history-beginning-search-{forward,backward} which
     search for a line with the same prefix up to the cursor position.
     It is possible to write functions which go a little closer to the
     original behaviour; further changes are still possible.
  o  In vi insert mode, the cursor keys no longer work.  The following
     will bind them:

       bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \ 
                      '^[[A' up-line-or-history '^[[B' down-line-or-history

     (unless your terminal requires `^[O' instead of `^[[').  The
     rationale is that the insert mode and command mode keymaps for
     keys with prefixes are now separate.

  Changes since zsh 2.5:

  o  The left hand of an assignment is no longer substituted.  Thus,
     `$1=$2' will not work.  You can use something like `eval
     "$1=\$2"', which should have the identical effect.
  o  Signal traps established with the `trap' builtin are now called with
     the environment of the caller, as in ksh, instead of as a new
     function level.  Traps established as functions (e.g. `TRAPINT()
     {...}') work as before.
  o  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
     to be the other way around.  (Use of names rather than letters is
     generally recommended.)
  o  `[[' is a reserved word, hence must be separated from
     other characters by whitespace; `{' and `}' are also reserved
     words if the IGNORE_BRACES option is set.
  o  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
     always does what it looks like it does, so `if ( ... ) ...'
     executes the code in parentheses in a subshell.  To make this
     useful, the syntax expected after an `if', etc., is less strict
     than in other shells.
  o  `foo=*' does not perform globbing immediately on the right
     hand side of the assignment; the old behaviour now requires the
     option GLOB_ASSIGN.  (`foo=(*)' is and has always been the
     consistent way of doing this.)
  o  <> performs redirection of input and output to the specified file.
     For numeric globs, you now need <->.
  o  The command line qualifiers exec, noglob, command, - are now
     treated more like builtin commands:  previously they were
     syntactically special.  This should make it easier to perform
     tricks with them (disabling, hiding in parameters, etc.).
  o  The pushd builtin has been rewritten for compatibility with other
     shells.  The old behavour can be achieved with a shell function.
  o  The current version now uses ~'s for directory stack substitution
     instead of ='s.  This is for consistency:  all other directory
     substitution (~user, ~name, ~+, ...) used a tilde, while
     =<number> caused problems with =program substitution.
  o  The `HISTLIT' option was broken in various ways and has been removed:
     the rewritten history mechanism doesn't alter history lines, making
     the option unnecessary.
  o  History expansion is disabled in single-quoted strings, like other
     forms of expansion -- hence exclamation marks there should not be
     backslashed.
  o  The `$HISTCHARS' variable is now `$histchars'.  Currently both
     are tied together for compatibility.
  o  The PROMPT_SUBST option now performs backquote expansion -- hence
     you should quote these in prompts.  (SPROMPT has changed as a result.)
  o  Quoting in prompts has changed: close parentheses inside ternary
     expressions should be quoted with a %; history is now %!, not
     !.  Backslashes are no longer special.

5.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@math.gatech.edu

  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.

  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@math.gatech.edu

  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,

    zsh-announce@math.gatech.edu

  (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@math.gatech.edu

  with the *subject* line (this is a change from the old list)

    subscribe <your-email-address>

  e.g.

    Subject:  subscribe P.Stephenson@swansea.ac.uk

  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
  coleman@math.gatech.edu.

  The list from May 1992 to May 1995 is archived in
    ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.  More recent
  mailings up to date are to 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.

5.3: What's on the wish-list?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  o  Loadable module support (will be in 3.1 but much work still needs doing).
  o  Ksh compatibility could be improved.
  o  Option for glob qualifiers to follow perl syntax (a traditional item).
  o  Binding of shell functions to key strokes, accessing editing
     buffer from functions, executing zle functions as a command:  now
     under development for 3.1. 
  o  Users should be able to create their own foopath/FOOPATH array/path
     combinations.

5.4: Will zsh have problems in the year 2000?

  (This information was written by Bart Schaefer.  Note it is a
  description of the state of affairs as seen by the developers, it is
  not a guarantee!)

  You can confirm the following by looking at the source code yourself
  if necessary; there's no other definitive reference:

  Zsh uses UNIX/POSIX time_t, timeval, and tm data types for internal
  date manipulations.  These types either do not store year values at
  all (for example, time_t is measured in seconds since midnight, Jan
  1, 1970) or store them as integer types and NOT as pairs of digits.
  Thus there can be no overflows at year 2000.  On some unix systems,
  time_t is a 32-bit value and will overflow during the year 2038, but
  more modern systems use a 64-bit time_t.

  The only input and output of dates that zsh performs is optional
  history time-stamping.  This is performed using time_t values
  converted to long integers, which are either 32 or 64 bits, see
  above.

  Note, however, that zsh does provide facilities for formatted date
  output, so it's possible that scripts written for zsh might employ
  2-digit years.  Shell scripts should always be considered separate
  programs and therefore evaluated individually.

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
and Richard Coleman, 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. 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://sunsite.auc.dk/zsh/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1998-08-21  8:33 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1998-08-21  8:33 UTC (permalink / raw)
  To: zsh-announce

[ After today I shall be away for three weeks, 2 2/7 without email.
  Please try not to introduce any major incompatibilities into the
  shell while I'm gone :-)     --- pws ]

Archive-Name: unix-faq/shell/zsh
Last-Modified: 1998/8/21
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zshfaq.yo,v 1.27 1998/08/21 08:39:10 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996, 1997, 1998 (see end of document)

Changes since issue posted July 1998:

4.2  Mention directory completion.
4.4  New item `how do I complete in the middle of words / just
  what's before the cursor?'.

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?

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. What is the difference between `export' and the ALL_EXPORT option?
3.3. How do I turn off spelling correction/globbing for a single command?
3.4. How do I get the meta key to work on my xterm?
3.5. How do I automatically display the directory in my xterm title bar?
3.6. How do I make the completion list use eight bit characters?
3.7. Why do the cursor (arrow) keys not work?
3.8. Why does my terminal act funny in some way?
3.9. Why does zsh not work in an Emacs shell mode any more?
3.10. Why do my autoloaded functions not autoload [the first time]?
3.11. How does base arithmetic work?
3.12. How do I get a newline in my prompt?
3.13. Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
3.14. Why can't I bind \C-s and \C-q any more?
3.15. How do I execute command `foo' within function `foo'?
3.16. Why do history substitutions with single bangs do something funny?
3.17. Why does zsh kill off all my background jobs when I logout?
3.18. How do I list all my history entries?
3.19. How does the alternative loop syntax, e.g. `while {...} {...}' work?
3.20. Why is my history not being saved?

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. And if programmable completion isn't good enough?

Chapter 5:  The future of zsh
5.1. What bugs are currently known and unfixed? (Plus recent important changes)
5.2. Where do I report bugs, get more info / who's working on zsh?
5.3. What's on the wish-list?
5.4. Will 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://sunsite.auc.dk/zsh/ (note the change of address from the
  end of April 1998).  The server provides this FAQ and much else and is
  now maintained by Karsten Thygesen and others (mail zsh@sunsite.auc.dk
  with any related messages).  The FAQ is at http://sunsite.auc.dk/zsh/FAQ/ .

  This document was originally written in YODL, allowing it to be
  converted easily into various other formats.  The master source
  file lives at http://sunsite.auc.dk/zsh/FAQ/zshfaq.yo .

  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 1.6.

  There is now a preliminary version of a reference card for
  zsh 3.0, which you can find (while it's being developed) at
    http://www.ifh.de/~pws/computing/refcard.ps
  This is optimised for A4 paper. The LaTeX source is in the
  same place with the extension .tex.  It is not a good place
  from which to learn zsh for the first time.

  (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 globbing (compctl -g),
    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,
    o  variable, editing function and option name completion,
    o  inline expansion of variables, 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 arithmetic.
  o  Manipulation of arrays (including reverse subscripting).
  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 Etc/MACHINES in the distribution has more details.

  There are also now separate ports for Windows and OS/2, see `Where
  do I get it' 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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question
  5.2).  Changes based on version 2.5 are very unlikely to
  be useful.

  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 Etc/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 3.0.5 is the latest production version. The new major number 3.0
  largely reflects the considerable internal changes in zsh to make it
  more reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of 5.1.  This is
  longer than usual due to enhanced sh, ksh and POSIX compatibility.

  The beta version 3.1.4 is also available.  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 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 (most recently) to provide POSIX compliancy.

1.6: Where do I get it?

  The archive is now run by Andrew Main <zefram@tao.co.uk>.
  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 .

    Home site ftp://ftp.zsh.org
    Australia ftp://ftp.ips.gov.au/mirror/zsh/
    Denmark   ftp://sunsite.auc.dk/pub/unix/shells/zsh
    Finland   ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France    ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany   ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
              ftp://ftp.gmd.de/packages/zsh/
              ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Hungary   ftp://ftp.cs.elte.hu/pub/zsh/
              (also http://www.cs.elte.hu/pub/zsh/ )
    Israel    ftp://ftp.math.technion.ac.il/mirror/ftp.zsh.org/pub/zsh/
              http://www.math.technion.ac.il/mirror/ftp.zsh.org/pub/zsh/
    Japan     ftp://ftp.tohoku.ac.jp/mirror/zsh/
              ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway    ftp://ftp.uit.no/pub/unix/shells/zsh/
    Romania   ftp://ftp.roedu.net/pub/mirrors/ftp.zsh.org/pub/zsh/
    Slovenia  ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden    ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK        ftp://ftp.net.lut.ac.uk/zsh/
              (also by FSP at port 21)
              ftp://src.doc.ic.ac.uk/packages/unix/shells/zsh/
    USA       ftp://ftp.math.gatech.edu/pub/zsh/
              ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
              ftp://ftp.sterling.com/zsh/
              ftp://ftp.rge.com/pub/shells/zsh/

  The Windows port mentioned above is maintained separately by Amol
  Deshpande <amold@microsoft.com>; please mail Amol directly about any
  Windows-specific problems.  This is quite new, so don't expect it to
  be perfect.  You can get it from:

            ftp://ftp.blarg.net/users/amol/zsh  

  Likewise the OS/2 port is available from TAMURA Kent
  <kent@tril.ibm.co.jp> at

            http://cgi.din.or.jp/~tkent/tmp/zsh-3.0.0-os2-a01.zip

  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://sunsite.auc.dk/zsh/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 commands
     `emulate sh; setopt localoptions' in a shell function will
     turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in 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_BUILTINS, 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 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', 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.
        The KSH_ARRAYS option is now available.
    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.
        (GLOB_SUBST has been added to fix this.)
    o   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.)
    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
        the way to exclude some subdirectories from matching a `**'.
    o   Unquoted assignments do file expansion after `:'s (intended for
        PATHs). 
    o   `integer' does not allow `-i'.
    o   The line number in `$LINENO' can be capricious in zsh scripts.

  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  Traps and signals:

    o   Traps are not local to functions.
    o   TRAPERR has become TRAPZERR (this was forced by UNICOS which
        has SIGERR).

  o  Editing:

    o   The options emacs, gmacs, viraw are not supported.
        Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
        becomes `bindkey -{e,v}'; 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' will not be in the next ksh
        release either.)
    o   Management of histories in multiple shells is different:
        the history list is not saved and restored after each command.
    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  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   `read' has no `-s' 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" 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 shwordsplit and ksharrays 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         "$@"            ($*: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.

  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.

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,
  $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 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.

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.

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.

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.)  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 `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 SHWORDSPLIT.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.

3.2: 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.3: 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.4: 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.

3.5: 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 a sun-cmd.

  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) 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.6: How do I make the completion list use eight bit characters?

  A traditional UNIX environment (character terminal and ASCII
  character sets) is not sufficient to be able to handle non-ASCII
  characters, and there are so many possible enhancements that in
  general this is hard.  However, if you have something like an xterm
  using a standard character set like ISO-8859-1 (which is often the
  default for xterm), read on.  You should also note question
  3.4 on the subject of eight bit characters.

  You are probably creating files with names including non-ASCII
  accented characters, and find they show up in the completion list as
  \M-i or something such.  This is because the library routines
  (not zsh itself) which test whether a character is printable have
  replied that it is not; zsh has simply found a way to show them
  anyway.

  The answer, under a modern POSIXy operating system, is to find a
  locale where these are treated as printable characters.  Zsh has
  handling for locales built in and will recognise when you set a
  relevant variable. You need to look in /usr/lib/locale to find one
  which suits you; the subdirectories correspond to the locale names.
  The simplest possibility is likely to be en_US, so that the simplest
  answer to your problem is to set

    LC_CTYPE=en_US

  when your terminal is capable of showing eight bit characters.  If
  you only have a default domain (called C), you may need to have some
  additional files installed on your system.

3.7: Why do the cursor (arrow) keys not work?

  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.

  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.

3.8: 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.

3.9: 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" "~/bin/eshell")

  to ~/.emacs.

3.10: 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 KSHAUTOLOAD 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.11: 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 now supported).  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.

3.12: 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 :-).  Otherwise, you can use

    PROMPT=$(print "Hi Joe,\nwhat now?%# ")

  in your initialisation file.

3.13: 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.14: 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.15: 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.16: 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.17: 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.18: 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.19: 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.20: 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.

Chapter 4: 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.

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.

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 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
  (or something else you can execute, like a builtin command, a
  function or an alias) and tries 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.

  A useful addition for zsh from version 3.1 is directory completion:

    compctl -/ cd

  Before, you had to use -g, but this is neater: it takes care of
  things like ignoring directories beginning with a dot unless you've
  typed the dot yourself, and whole directory paths are understood.

  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 4.5.)  Also, from
  version 3.1 you can always handle directories at the same time as
  other files just by adding -/ to the list.

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 your 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 nobeep set, that annoying beep goes away
   o  with nolistbeep, beeping is only turned off for ambiguous completions
   o  with autolist set, when the completion is ambiguous you get a
      list without having to type \C-D
   o  with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
   o  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
   o  with automenu, 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 alwayslastprompt, 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, autolist and
  automenu together give an intuitive combination.  Note that
  from version 3.1 listambiguous 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 (let's stick to file
  names) 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.

  That's not the full story, however.  Sometimes you just want the
  part of the word before the cursor completed.  For example, the word
  is `/usr/loc/b', which you want to complete to `/usr/local/bin'.
  Normally, zsh won't do this in one go because there are two bits
  missing (but see below!), so you need to complete the `/usr/loc'
  on its own first.  For this 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

  then in the example you can move to just after `/usr/loc', hit
  whatever key you've just bound, move to the end, and hit tab.
  (Note that AUTO_REMOVE_SLASH behaviour applies here, see the manual.)

  Even that doesn't exhaust the possibilities.  Included with the
  source distribution is the file Functions/multicomp, a function
  which you can bind as an alternative form of default completion (see
  below for a description of alternative completion), e.g.

    compctl -D -f + -U -Q -K multicomp

  and whole sequences of directories, like `/usr/loc/b' or even
  `/u/l/b' can be completed in one go.  It works best with
  menucompletion if the result is ambiguous.

4.5: 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 4.2),
  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):

   1) 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',
   2) 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 `-',
   3) 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.

  You must be careful to put the whole expression inside quotation
  marks, so that it appears as a single argument to compctl.

  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.

4.6: 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 the part of the word already typed, and can read
  the rest of the line with `read -c'.  It can return a set of
  completions 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.

Chapter 5: The future of zsh

5.1: What bugs are currently known and unfixed? (Plus recent important changes)

  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 2.1; 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.

  o  `time' is ignored with builtins and can't be used with `{...}'.
  o  `set -x' (`setopt xtrace') still has a few glitches.
  o  In vi mode, `u' can go past the original modification point.
  o  The singlelinezle option has problems with prompts containing escapes.
  o  The `r' command does not work inside `$(...)' or ``...`'
     expansions.   (This is fixed in 3.1.)
  o  `typeset' handling is non-optimal, particularly with regard to
     flags, and is ksh-incompatible in unpredictable ways. 
  o  Nested closures in extended globbing and pattern matching, such as

      [[ fofo = (fo#)# ]]

     are not correctly handled, and there were problems with
     complicated exclusions using `^' or `~'.  (These
     are fixed in version 3.1.3.)

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes after zsh 3.0 (3.1.x is still currently in beta):

  o  The options ALWAYS_LAST_PROMPT (return to the line you were
     editing after displaying completion lists) and LIST_AMBIGUOUS
     (show matching files when there are several) are now set by
     default.  This is in response to complaints that too many zsh
     features are never noticed by many users.  To turn them off,
     just put `unsetopt alwayslastprompt listambiguous' in your
     .zshrc file.
  o  history-search-{forward,backward} now only find previous
     lines where the first word is the same as the current one.  For
     example, 

      comp<ESC>p

     will find lines in the history like `comp -edit emacs', but not
     `compress file' any more.  For this reason, `\M-n' and
     `\M-p' use history-beginning-search-{forward,backward} which
     search for a line with the same prefix up to the cursor position.
     It is possible to write functions which go a little closer to the
     original behaviour; further changes are still possible.
  o  In vi insert mode, the cursor keys no longer work.  The following
     will bind them:

       bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \ 
                      '^[[A' up-line-or-history '^[[B' down-line-or-history

     (unless your terminal requires `^[O' instead of `^[[').  The
     rationale is that the insert mode and command mode keymaps for
     keys with prefixes are now separate.

  Changes since zsh 2.5:

  o  The left hand of an assignment is no longer substituted.  Thus,
     `$1=$2' will not work.  You can use something like `eval
     "$1=\$2"', which should have the identical effect.
  o  Signal traps established with the `trap' builtin are now called with
     the environment of the caller, as in ksh, instead of as a new
     function level.  Traps established as functions (e.g. `TRAPINT()
     {...}') work as before.
  o  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
     to be the other way around.  (Use of names rather than letters is
     generally recommended.)
  o  `[[' is a reserved word, hence must be separated from
     other characters by whitespace; `{' and `}' are also reserved
     words if the IGNORE_BRACES option is set.
  o  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
     always does what it looks like it does, so `if ( ... ) ...'
     executes the code in parentheses in a subshell.  To make this
     useful, the syntax expected after an `if', etc., is less strict
     than in other shells.
  o  `foo=*' does not perform globbing immediately on the right
     hand side of the assignment; the old behaviour now requires the
     option GLOB_ASSIGN.  (`foo=(*)' is and has always been the
     consistent way of doing this.)
  o  <> performs redirection of input and output to the specified file.
     For numeric globs, you now need <->.
  o  The command line qualifiers exec, noglob, command, - are now
     treated more like builtin commands:  previously they were
     syntactically special.  This should make it easier to perform
     tricks with them (disabling, hiding in parameters, etc.).
  o  The pushd builtin has been rewritten for compatibility with other
     shells.  The old behavour can be achieved with a shell function.
  o  The current version now uses ~'s for directory stack substitution
     instead of ='s.  This is for consistency:  all other directory
     substitution (~user, ~name, ~+, ...) used a tilde, while
     =<number> caused problems with =program substitution.
  o  The `HISTLIT' option was broken in various ways and has been removed:
     the rewritten history mechanism doesn't alter history lines, making
     the option unnecessary.
  o  History expansion is disabled in single-quoted strings, like other
     forms of expansion -- hence exclamation marks there should not be
     backslashed.
  o  The `$HISTCHARS' variable is now `$histchars'.  Currently both
     are tied together for compatibility.
  o  The PROMPT_SUBST option now performs backquote expansion -- hence
     you should quote these in prompts.  (SPROMPT has changed as a result.)
  o  Quoting in prompts has changed: close parentheses inside ternary
     expressions should be quoted with a %; history is now %!, not
     !.  Backslashes are no longer special.

5.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@math.gatech.edu

  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.

  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@math.gatech.edu

  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,

    zsh-announce@math.gatech.edu

  (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@math.gatech.edu

  with the *subject* line (this is a change from the old list)

    subscribe <your-email-address>

  e.g.

    Subject:  subscribe P.Stephenson@swansea.ac.uk

  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
  coleman@math.gatech.edu.

  The list from May 1992 to May 1995 is archived in
    ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.  More recent
  mailings up to date are to 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.

5.3: What's on the wish-list?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  o  Loadable module support (will be in 3.1 but much work still needs doing).
  o  Ksh compatibility could be improved.
  o  Option for glob qualifiers to follow perl syntax (a traditional item).
  o  Binding of shell functions to key strokes, accessing editing
     buffer from functions, executing zle functions as a command:  now
     under development for 3.1. 
  o  Users should be able to create their own foopath/FOOPATH array/path
     combinations.

5.4: Will zsh have problems in the year 2000?

  (This information was written by Bart Schaefer.  Note it is a
  description of the state of affairs as seen by the developers, it is
  not a guarantee!)

  You can confirm the following by looking at the source code yourself
  if necessary; there's no other definitive reference:

  Zsh uses UNIX/POSIX time_t, timeval, and tm data types for internal
  date manipulations.  These types either do not store year values at
  all (for example, time_t is measured in seconds since midnight, Jan
  1, 1970) or store them as integer types and NOT as pairs of digits.
  Thus there can be no overflows at year 2000.  On some unix systems,
  time_t is a 32-bit value and will overflow during the year 2038, but
  more modern systems use a 64-bit time_t.

  The only input and output of dates that zsh performs is optional
  history time-stamping.  This is performed using time_t values
  converted to long integers, which are either 32 or 64 bits, see
  above.

  Note, however, that zsh does provide facilities for formatted date
  output, so it's possible that scripts written for zsh might employ
  2-digit years.  Shell scripts should always be considered separate
  programs and therefore evaluated individually.

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
and Richard Coleman, 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. 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://sunsite.auc.dk/zsh/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1998-07-27 13:54 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1998-07-27 13:54 UTC (permalink / raw)
  To: zsh-announce


Archive-Name: unix-faq/shell/zsh
Last-Modified: 1998/7/27
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zshfaq.yo,v 1.25 1998/07/27 13:59:48 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996, 1997, 1998 (see end of document)

Changes since issue posted June 1998:

2.1  `let' behaviour more ksh-like, `$LINENO' not.
4.5  Mention `read -c'.
5.1  Slight update on history-search-backward saga
5.4  Note on year 2000 issues

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?

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. What is the difference between `export' and the ALL_EXPORT option?
3.3. How do I turn off spelling correction/globbing for a single command?
3.4. How do I get the meta key to work on my xterm?
3.5. How do I automatically display the directory in my xterm title bar?
3.6. How do I make the completion list use eight bit characters?
3.7. Why do the cursor (arrow) keys not work?
3.8. Why does my terminal act funny in some way?
3.9. Why does zsh not work in an Emacs shell mode any more?
3.10. Why do my autoloaded functions not autoload [the first time]?
3.11. How does base arithmetic work?
3.12. How do I get a newline in my prompt?
3.13. Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
3.14. Why can't I bind \C-s and \C-q any more?
3.15. How do I execute command `foo' within function `foo'?
3.16. Why do history substitutions with single bangs do something funny?
3.17. Why does zsh kill off all my background jobs when I logout?
3.18. How do I list all my history entries?
3.19. How does the alternative loop syntax, e.g. `while {...} {...}' work?
3.20. Why is my history not being saved?

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 get started with programmable completion?
4.5. And if programmable completion isn't good enough?

Chapter 5:  The future of zsh
5.1. What bugs are currently known and unfixed? (Plus recent important changes)
5.2. Where do I report bugs, get more info / who's working on zsh?
5.3. What's on the wish-list?
5.4. Will 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://sunsite.auc.dk/zsh/ (note the change of address from the
  end of April 1998).  The server provides this FAQ and much else and is
  now maintained by Karsten Thygesen and others (mail zsh@sunsite.auc.dk
  with any related messages).  The FAQ is at http://sunsite.auc.dk/zsh/FAQ/ .

  This document was originally written in YODL, allowing it to be
  converted easily into various other formats.  The master source
  file lives at http://sunsite.auc.dk/zsh/FAQ/zshfaq.yo .

  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 1.6.

  There is now a preliminary version of a reference card for
  zsh 3.0, which you can find (while it's being developed) at
    http://www.ifh.de/~pws/computing/refcard.ps
  This is optimised for A4 paper. The LaTeX source is in the
  same place with the extension .tex.  It is not a good place
  from which to learn zsh for the first time.

  (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 globbing (compctl -g),
    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,
    o  variable, editing function and option name completion,
    o  inline expansion of variables, 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 arithmetic.
  o  Manipulation of arrays (including reverse subscripting).
  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 Etc/MACHINES in the distribution has more details.

  There are also now separate ports for Windows and OS/2, see `Where
  do I get it' 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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question
  5.2).  Changes based on version 2.5 are very unlikely to
  be useful.

  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 Etc/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 3.0.5 is the latest production version. The new major number 3.0
  largely reflects the considerable internal changes in zsh to make it
  more reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of 5.1.  This is
  longer than usual due to enhanced sh, ksh and POSIX compatibility.

  The beta version 3.1.4 is also available.  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 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 (most recently) to provide POSIX compliancy.

1.6: Where do I get it?

  The archive is now run by Andrew Main <zefram@tao.co.uk>.
  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 .

    Home site ftp://ftp.zsh.org
    Australia ftp://ftp.ips.gov.au/mirror/zsh/
    Denmark   ftp://sunsite.auc.dk/pub/unix/shells/zsh
    Finland   ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France    ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany   ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
              ftp://ftp.gmd.de/packages/zsh/
              ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Hungary   ftp://ftp.cs.elte.hu/pub/zsh/
              (also http://www.cs.elte.hu/pub/zsh/ )
    Israel    ftp://ftp.math.technion.ac.il/mirror/ftp.zsh.org/pub/zsh/
              http://www.math.technion.ac.il/mirror/ftp.zsh.org/pub/zsh/
    Japan     ftp://ftp.tohoku.ac.jp/mirror/zsh/
              ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway    ftp://ftp.uit.no/pub/unix/shells/zsh/
    Romania   ftp://ftp.roedu.net/pub/mirrors/ftp.zsh.org/pub/zsh/
    Slovenia  ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden    ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK        ftp://ftp.net.lut.ac.uk/zsh/
              (also by FSP at port 21)
              ftp://src.doc.ic.ac.uk/packages/unix/shells/zsh/
    USA       ftp://ftp.math.gatech.edu/pub/zsh/
              ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
              ftp://ftp.sterling.com/zsh/
              ftp://ftp.rge.com/pub/shells/zsh/

  The Windows port mentioned above is maintained separately by Amol
  Deshpande <amold@microsoft.com>; please mail Amol directly about any
  Windows-specific problems.  This is quite new, so don't expect it to
  be perfect.  You can get it from:

            ftp://ftp.blarg.net/users/amol/zsh  

  Likewise the OS/2 port is available from TAMURA Kent
  <kent@tril.ibm.co.jp> at

            http://cgi.din.or.jp/~tkent/tmp/zsh-3.0.0-os2-a01.zip

  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://sunsite.auc.dk/zsh/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 commands
     `emulate sh; setopt localoptions' in a shell function will
     turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in 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_BUILTINS, 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 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', 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.
        The KSH_ARRAYS option is now available.
    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.
        (GLOB_SUBST has been added to fix this.)
    o   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.)
    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
        the way to exclude some subdirectories from matching a `**'.
    o   Unquoted assignments do file expansion after `:'s (intended for
        PATHs). 
    o   `integer' does not allow `-i'.
    o   The line number in `$LINENO' can be capricious in zsh scripts.

  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  Traps and signals:

    o   Traps are not local to functions.
    o   TRAPERR has become TRAPZERR (this was forced by UNICOS which
        has SIGERR).

  o  Editing:

    o   The options emacs, gmacs, viraw are not supported.
        Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
        becomes `bindkey -{e,v}'; 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' will not be in the next ksh
        release either.)
    o   Management of histories in multiple shells is different:
        the history list is not saved and restored after each command.
    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  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   `read' has no `-s' 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" 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 shwordsplit and ksharrays 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         "$@"            ($*: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.

  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.

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,
  $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 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.

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.

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.

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.)  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 `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 SHWORDSPLIT.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.

3.2: 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.3: 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.4: 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.

3.5: 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 a sun-cmd.

  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) 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.6: How do I make the completion list use eight bit characters?

  A traditional UNIX environment (character terminal and ASCII
  character sets) is not sufficient to be able to handle non-ASCII
  characters, and there are so many possible enhancements that in
  general this is hard.  However, if you have something like an xterm
  using a standard character set like ISO-8859-1 (which is often the
  default for xterm), read on.  You should also note question
  3.4 on the subject of eight bit characters.

  You are probably creating files with names including non-ASCII
  accented characters, and find they show up in the completion list as
  \M-i or something such.  This is because the library routines
  (not zsh itself) which test whether a character is printable have
  replied that it is not; zsh has simply found a way to show them
  anyway.

  The answer, under a modern POSIXy operating system, is to find a
  locale where these are treated as printable characters.  Zsh has
  handling for locales built in and will recognise when you set a
  relevant variable. You need to look in /usr/lib/locale to find one
  which suits you; the subdirectories correspond to the locale names.
  The simplest possibility is likely to be en_US, so that the simplest
  answer to your problem is to set

    LC_CTYPE=en_US

  when your terminal is capable of showing eight bit characters.  If
  you only have a default domain (called C), you may need to have some
  additional files installed on your system.

3.7: Why do the cursor (arrow) keys not work?

  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.

  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.

3.8: 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.

3.9: 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" "~/bin/eshell")

  to ~/.emacs.

3.10: 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 KSHAUTOLOAD 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.11: 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 now supported).  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.

3.12: 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 :-).  Otherwise, you can use

    PROMPT=$(print "Hi Joe,\nwhat now?%# ")

  in your initialisation file.

3.13: 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.14: 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.15: 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.16: 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.17: 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.18: 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.19: 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.20: 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.

Chapter 4: 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.

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.

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 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
  (or something else you can execute, like a builtin command, a
  function or an alias) and tries 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 4.4.)

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 your 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 nobeep set, that annoying beep goes away
   o  with nolistbeep, beeping is only turned off for ambiguous completions
   o  with autolist set, when the completion is ambiguous you get a
      list without having to type \C-D
   o  with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
   o  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
   o  with automenu, 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 alwayslastprompt, 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, autolist and
  automenu together give an intuitive combination.  Note that
  from version 3.1 listambiguous is set by default; if you use
  autolist, you may well want to `unsetopt listambiguous'.

4.4: 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 4.2),
  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):

   1) 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',
   2) 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 `-',
   3) 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.

  You must be careful to put the whole expression inside quotation
  marks, so that it appears as a single argument to compctl.

  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.

4.5: 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 the part of the word already typed, and can read
  the rest of the line with `read -c'.  It can return a set of
  completions 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.

Chapter 5: The future of zsh

5.1: What bugs are currently known and unfixed? (Plus recent important changes)

  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 2.1; 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.

  o  `time' is ignored with builtins and can't be used with `{...}'.
  o  `set -x' (`setopt xtrace') still has a few glitches.
  o  In vi mode, `u' can go past the original modification point.
  o  The singlelinezle option has problems with prompts containing escapes.
  o  The `r' command does not work inside `$(...)' or ``...`'
     expansions.   (This is fixed in 3.1.)
  o  `typeset' handling is non-optimal, particularly with regard to
     flags, and is ksh-incompatible in unpredictable ways. 
  o  Nested closures in extended globbing and pattern matching, such as

      [[ fofo = (fo#)# ]]

     are not correctly handled, and there were problems with
     complicated exclusions using `^' or `~'.  (These
     are fixed in version 3.1.3.)

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes after zsh 3.0 (3.1.x is still currently in beta):

  o  The options ALWAYS_LAST_PROMPT (return to the line you were
     editing after displaying completion lists) and LIST_AMBIGUOUS
     (show matching files when there are several) are now set by
     default.  This is in response to complaints that too many zsh
     features are never noticed by many users.  To turn them off,
     just put `unsetopt alwayslastprompt listambiguous' in your
     .zshrc file.
  o  history-search-{forward,backward} now only find previous
     lines where the first word is the same as the current one.  For
     example, 

      comp<ESC>p

     will find lines in the history like `comp -edit emacs', but not
     `compress file' any more.  For this reason, `\M-n' and
     `\M-p' use history-beginning-search-{forward,backward} which
     search for a line with the same prefix up to the cursor position.
     It is possible to write functions which go a little closer to the
     original behaviour; further changes are still possible.
  o  In vi insert mode, the cursor keys no longer work.  The following
     will bind them:

       bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \ 
                      '^[[A' up-line-or-history '^[[B' down-line-or-history

     (unless your terminal requires `^[O' instead of `^[[').  The
     rationale is that the insert mode and command mode keymaps for
     keys with prefixes are now separate.

  Changes since zsh 2.5:

  o  The left hand of an assignment is no longer substituted.  Thus,
     `$1=$2' will not work.  You can use something like `eval
     "$1=\$2"', which should have the identical effect.
  o  Signal traps established with the `trap' builtin are now called with
     the environment of the caller, as in ksh, instead of as a new
     function level.  Traps established as functions (e.g. `TRAPINT()
     {...}') work as before.
  o  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
     to be the other way around.  (Use of names rather than letters is
     generally recommended.)
  o  `[[' is a reserved word, hence must be separated from
     other characters by whitespace; `{' and `}' are also reserved
     words if the IGNORE_BRACES option is set.
  o  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
     always does what it looks like it does, so `if ( ... ) ...'
     executes the code in parentheses in a subshell.  To make this
     useful, the syntax expected after an `if', etc., is less strict
     than in other shells.
  o  `foo=*' does not perform globbing immediately on the right
     hand side of the assignment; the old behaviour now requires the
     option GLOB_ASSIGN.  (`foo=(*)' is and has always been the
     consistent way of doing this.)
  o  <> performs redirection of input and output to the specified file.
     For numeric globs, you now need <->.
  o  The command line qualifiers exec, noglob, command, - are now
     treated more like builtin commands:  previously they were
     syntactically special.  This should make it easier to perform
     tricks with them (disabling, hiding in parameters, etc.).
  o  The pushd builtin has been rewritten for compatibility with other
     shells.  The old behavour can be achieved with a shell function.
  o  The current version now uses ~'s for directory stack substitution
     instead of ='s.  This is for consistency:  all other directory
     substitution (~user, ~name, ~+, ...) used a tilde, while
     =<number> caused problems with =program substitution.
  o  The `HISTLIT' option was broken in various ways and has been removed:
     the rewritten history mechanism doesn't alter history lines, making
     the option unnecessary.
  o  History expansion is disabled in single-quoted strings, like other
     forms of expansion -- hence exclamation marks there should not be
     backslashed.
  o  The `$HISTCHARS' variable is now `$histchars'.  Currently both
     are tied together for compatibility.
  o  The PROMPT_SUBST option now performs backquote expansion -- hence
     you should quote these in prompts.  (SPROMPT has changed as a result.)
  o  Quoting in prompts has changed: close parentheses inside ternary
     expressions should be quoted with a %; history is now %!, not
     !.  Backslashes are no longer special.

5.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@math.gatech.edu

  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.

  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@math.gatech.edu

  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,

    zsh-announce@math.gatech.edu

  (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@math.gatech.edu

  with the *subject* line (this is a change from the old list)

    subscribe <your-email-address>

  e.g.

    Subject:  subscribe P.Stephenson@swansea.ac.uk

  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
  coleman@math.gatech.edu.

  The list from May 1992 to May 1995 is archived in
    ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.  More recent
  mailings up to date are to 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.

5.3: What's on the wish-list?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  o  Loadable module support (will be in 3.1 but much work still needs doing).
  o  Ksh compatibility could be improved.
  o  Option for glob qualifiers to follow perl syntax (a traditional item).
  o  Binding of shell functions to key strokes, accessing editing
     buffer from functions, executing zle functions as a command:  now
     under development for 3.1. 
  o  Users should be able to create their own foopath/FOOPATH array/path
     combinations.

5.4: Will zsh have problems in the year 2000?

  (This information was written by Bart Schaefer.  Note it is a
  description of the state of affairs as seen by the developers, it is
  not a guarantee!)

  You can confirm the following by looking at the source code yourself
  if necessary; there's no other definitive reference:

  Zsh uses UNIX/POSIX time_t, timeval, and tm data types for internal
  date manipulations.  These types either do not store year values at
  all (for example, time_t is measured in seconds since midnight, Jan
  1, 1970) or store them as integer types and NOT as pairs of digits.
  Thus there can be no overflows at year 2000.  On some unix systems,
  time_t is a 32-bit value and will overflow during the year 2038, but
  more modern systems use a 64-bit time_t.

  The only input and output of dates that zsh performs is optional
  history time-stamping.  This is performed using time_t values
  converted to long integers, which are either 32 or 64 bits, see
  above.

  Note, however, that zsh does provide facilities for formatted date
  output, so it's possible that scripts written for zsh might employ
  2-digit years.  Shell scripts should always be considered separate
  programs and therefore evaluated individually.

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
and Richard Coleman, 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. 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://sunsite.auc.dk/zsh/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1998-06-25 16:32 Richard Coleman
  0 siblings, 0 replies; 30+ messages in thread
From: Richard Coleman @ 1998-06-25 16:32 UTC (permalink / raw)
  To: zsh-announce


------- Forwarded Message

Date:    Thu, 25 Jun 1998 05:14:41 -0400
From:    Peter Stephenson <pws@ibmth.df.unipi.it>
To:      zsh-announce@math.gatech.edu
Subject: Z-Shell Frequently Asked Questions (monthly posting)


Archive-Name: unix-faq/shell/zsh
Last-Modified: 1998/6/1
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zshfaq.yo,v 1.23 1998/06/01 08:55:08 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996, 1997, 1998 (see end of document)

Changes since issue posted May 1998:

1.5  New beta version 3.1.4.
1.6  Updated list of sites.
4.3  Note about listambiguous and autolist.
5.2  Finally caught up with mailing list archive.

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?

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. What is the difference between `export' and the ALL_EXPORT option?
3.3. How do I turn off spelling correction/globbing for a single command?
3.4. How do I get the meta key to work on my xterm?
3.5. How do I automatically display the directory in my xterm title bar?
3.6. How do I make the completion list use eight bit characters?
3.7. Why do the cursor (arrow) keys not work?
3.8. Why does my terminal act funny in some way?
3.9. Why does zsh not work in an Emacs shell mode any more?
3.10. Why do my autoloaded functions not autoload [the first time]?
3.11. How does base arithmetic work?
3.12. How do I get a newline in my prompt?
3.13. Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
3.14. Why can't I bind \C-s and \C-q any more?
3.15. How do I execute command `foo' within function `foo'?
3.16. Why do history substitutions with single bangs do something funny?
3.17. Why does zsh kill off all my background jobs when I logout?
3.18. How do I list all my history entries?
3.19. How does the alternative loop syntax, e.g. `while {...} {...}' work?
3.20. Why is my history not being saved?

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 get started with programmable completion?
4.5. And if programmable completion isn't good enough?

Chapter 5:  The future of zsh
5.1. What bugs are currently known and unfixed? (Plus recent important changes)
5.2. Where do I report bugs, get more info / who's working on zsh?
5.3. What's on the wish-list?

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://sunsite.auc.dk/zsh/ (note the change of address from the
  end of April 1998).  The server provides this FAQ and much else and is
  now maintained by Karsten Thygesen and others (mail zsh@sunsite.auc.dk
  with any related messages).  The FAQ is at http://sunsite.auc.dk/zsh/FAQ/ .

  This document was originally written in YODL, allowing it to be
  converted easily into various other formats.  The master source
  file lives at http://sunsite.auc.dk/zsh/FAQ/zshfaq.yo .

  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 1.6.

  There is now a preliminary version of a reference card for
  zsh 3.0, which you can find (while it's being developed) at
    http://www.ifh.de/~pws/computing/refcard.ps
  This is optimised for A4 paper. The LaTeX source is in the
  same place with the extension .tex.  It is not a good place
  from which to learn zsh for the first time.

  (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 globbing (compctl -g),
    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,
    o  variable, editing function and option name completion,
    o  inline expansion of variables, 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 arithmetic.
  o  Manipulation of arrays (including reverse subscripting).
  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 Etc/MACHINES in the distribution has more details.

  There are also now separate ports for Windows and OS/2, see `Where
  do I get it' 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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question
  5.2).  Changes based on version 2.5 are very unlikely to
  be useful.

  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 Etc/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 3.0.5 is the latest production version. The new major number 3.0
  largely reflects the considerable internal changes in zsh to make it
  more reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of 5.1.  This is
  longer than usual due to enhanced sh, ksh and POSIX compatibility.

  The beta version 3.1.4 has been 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 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 (most recently) to provide POSIX compliancy.

1.6: Where do I get it?

  The archive is now run by Andrew Main <zefram@tao.co.uk>.
  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 .

    Home site ftp://ftp.zsh.org
    Australia ftp://ftp.ips.gov.au/mirror/zsh/
    Denmark   ftp://sunsite.auc.dk/pub/unix/shells/zsh
    Finland   ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France    ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany   ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
              ftp://ftp.gmd.de/packages/zsh/
              ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Hungary   ftp://ftp.cs.elte.hu/pub/zsh/
              (also http://www.cs.elte.hu/pub/zsh/ )
    Israel    ftp://ftp.math.technion.ac.il/mirror/ftp.zsh.org/pub/zsh/
              http://www.math.technion.ac.il/mirror/ftp.zsh.org/pub/zsh/
    Japan     ftp://ftp.tohoku.ac.jp/mirror/zsh/
              ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway    ftp://ftp.uit.no/pub/unix/shells/zsh/
    Romania   ftp://ftp.roedu.net/pub/mirrors/ftp.zsh.org/pub/zsh/
    Slovenia  ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden    ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK        ftp://ftp.net.lut.ac.uk/zsh/
              (also by FSP at port 21)
    USA       ftp://ftp.math.gatech.edu/pub/zsh/
              ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
              ftp://ftp.sterling.com/zsh/
              ftp://ftp.rge.com/pub/shells/zsh/

  The Windows port mentioned above is maintained separately by Amol
  Deshpande <amold@microsoft.com>; please mail Amol directly about any
  Windows-specific problems.  This is quite new, so don't expect it to
  be perfect.  You can get it from:

            ftp://ftp.blarg.net/users/amol/zsh  

  Likewise the OS/2 port is available from TAMURA Kent
  <kent@tril.ibm.co.jp> at

            http://cgi.din.or.jp/~tkent/tmp/zsh-3.0.0-os2-a01.zip

  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://sunsite.auc.dk/zsh/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 with 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 --- 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 commands
     `emulate sh; setopt localoptions' in a shell function will
     turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in 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_BUILTINS, 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 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', 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.
        The KSH_ARRAYS option is now available.
    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.
        (GLOB_SUBST has been added to fix this.)
    o   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.)
    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
        the way to exclude some subdirectories from matching a `**'.
    o   Unquoted assignments do file expansion after `:'s (intended for
        PATHs). 
    o   `integer' does not allow `-i'.

  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  Traps and signals:

    o   Traps are not local to functions.
    o   TRAPERR has become TRAPZERR (this was forced by UNICOS which
        has SIGERR).

  o  Editing:

    o   The options emacs, gmacs, viraw are not supported.
        Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
        becomes `bindkey -{e,v}'; 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' will not be in the next ksh
        release either.)
    o   Management of histories in multiple shells is different:
        the history list is not saved and restored after each command.
    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  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   `read' has no `-s' flag.
    o   In `let "i = foo"', foo is evaluated as a number, not an
        expression (in `let "i = $foo"', however, it is treated as an
        expression).

  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" 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 shwordsplit and ksharrays 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         "$@"            ($*: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.

  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.

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,
  $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 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.

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.

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.

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.)  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 `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 SHWORDSPLIT.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.

3.2: 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.3: 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.4: 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.

3.5: 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 a sun-cmd.

  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) 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.6: How do I make the completion list use eight bit characters?

  A traditional UNIX environment (character terminal and ASCII
  character sets) is not sufficient to be able to handle non-ASCII
  characters, and there are so many possible enhancements that in
  general this is hard.  However, if you have something like an xterm
  using a standard character set like ISO-8859-1 (which is often the
  default for xterm), read on.  You should also note question
  3.4 on the subject of eight bit characters.

  You are probably creating files with names including non-ASCII
  accented characters, and find they show up in the completion list as
  \M-i or something such.  This is because the library routines
  (not zsh itself) which test whether a character is printable have
  replied that it is not; zsh has simply found a way to show them
  anyway.

  The answer, under a modern POSIXy operating system, is to find a
  locale where these are treated as printable characters.  Zsh has
  handling for locales built in and will recognise when you set a
  relevant variable. You need to look in /usr/lib/locale to find one
  which suits you; the subdirectories correspond to the locale names.
  The simplest possibility is likely to be en_US, so that the simplest
  answer to your problem is to set

    LC_CTYPE=en_US

  when your terminal is capable of showing eight bit characters.  If
  you only have a default domain (called C), you may need to have some
  additional files installed on your system.

3.7: Why do the cursor (arrow) keys not work?

  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.

  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.

3.8: 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.

3.9: 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" "~/bin/eshell")

  to ~/.emacs.

3.10: 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 KSHAUTOLOAD 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.11: 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 now supported).  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.

3.12: 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 :-).  Otherwise, you can use

    PROMPT=$(print "Hi Joe,\nwhat now?%# ")

  in your initialisation file.

3.13: 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.14: 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.15: 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.16: 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.17: 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.18: 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.19: 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.20: 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.

Chapter 4: 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.

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.

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 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
  (or something else you can execute, like a builtin command, a
  function or an alias) and tries 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 4.4.)

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 your 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 nobeep set, that annoying beep goes away
   o  with nolistbeep, beeping is only turned off for ambiguous completions
   o  with autolist set, when the completion is ambiguous you get a
      list without having to type \C-D
   o  with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
   o  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
   o  with automenu, 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 alwayslastprompt, 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, autolist and
  automenu together give an intuitive combination.  Note that
  from version 3.1 listambiguous is set by default; if you use
  autolist, you may well want to `unsetopt listambiguous'.

4.4: 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 4.2),
  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):

   1) 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',
   2) 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 `-',
   3) 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.

  You must be careful to put the whole expression inside quotation
  marks, so that it appears as a single argument to compctl.

  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.

4.5: 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.

Chapter 5: The future of zsh

5.1: What bugs are currently known and unfixed? (Plus recent important changes)

  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 2.1; 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.

  o  `time' is ignored with builtins and can't be used with `{...}'.
  o  `set -x' (`setopt xtrace') still has a few glitches.
  o  In vi mode, `u' can go past the original modification point.
  o  The singlelinezle option has problems with prompts containing escapes.
  o  The `r' command does not work inside `$(...)' or ``...`'
     expansions.   (This is fixed in 3.1.)
  o  `typeset' handling is non-optimal, particularly with regard to
     flags, and is ksh-incompatible in unpredictable ways. 
  o  Nested closures in extended globbing and pattern matching, such as

    [[ fofo = (fo#)# ]]

     are not correctly handled, and there were problems with
     complicated exclusions using `^' or `~'.  (These
     are fixed in version 3.1.3.)

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes after zsh 3.0 (3.1.x is still currently in beta):

  o  The options ALWAYS_LAST_PROMPT (return to the line you were
     editing after displaying completion lists) and LIST_AMBIGUOUS
     (show matching files when there are several) are now set by
     default.  This is in response to complaints that too many zsh
     features are never noticed by many users.  To turn them off,
     just put `unsetopt alwayslastprompt listambiguous' in your
     .zshrc file.
  o  history-search-{forward,backward} (bound to \M-n, \M-p)
     now only find previous lines where the first word is the same as the
     current one.  For example,

      comp<ESC>p

     will find lines in the history like `comp -edit emacs', but not
     `compress file' any more.  For an approximation to the old
     behaviour, use history-beginning-search-{forward,backward} which
     search for a line with the same prefix up to the cursor position.
  o  In vi insert mode, the cursor keys no longer work.  The following
     will bind them:

       bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \ 
                      '^[[A' up-line-or-history '^[[B' down-line-or-history

     (unless your terminal requires `^[O' instead of `^[[').  The
     rationale is that the insert mode and command mode keymaps for
     keys with prefixes are now separate.

  Changes since zsh 2.5:

  o  The left hand of an assignment is no longer substituted.  Thus,
     `$1=$2' will not work.  You can use something like `eval
     "$1=\$2"', which should have the identical effect.
  o  Signal traps established with the `trap' builtin are now called with
     the environment of the caller, as in ksh, instead of as a new
     function level.  Traps established as functions (e.g. `TRAPINT()
     {...}') work as before.
  o  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
     to be the other way around.  (Use of names rather than letters is
     generally recommended.)
  o  `[[' is a reserved word, hence must be separated from
     other characters by whitespace; `{' and `}' are also reserved
     words if the IGNORE_BRACES option is set.
  o  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
     always does what it looks like it does, so `if ( ... ) ...'
     executes the code in parentheses in a subshell.  To make this
     useful, the syntax expected after an `if', etc., is less strict
     than in other shells.
  o  `foo=*' does not perform globbing immediately on the right
     hand side of the assignment; the old behaviour now requires the
     option GLOB_ASSIGN.  (`foo=(*)' is and has always been the
     consistent way of doing this.)
  o  <> performs redirection of input and output to the specified file.
     For numeric globs, you now need <->.
  o  The command line qualifiers exec, noglob, command,
     - are now treated more like builtin commands:  previously they were
     syntactically special.  This should make it easier to perform tricks with
     them (disabling, hiding in parameters, etc.).
  o  The pushd builtin has been rewritten for compatibility with other
     shells.  The old behavour can be achieved with a shell function.
  o  The current version now uses ~'s for directory stack substitution
     instead of ='s.  This is for consistency:  all other directory
     substitution (~user, ~name, ~+, ...) used a tilde, while
     =<number> caused problems with =program substitution.
  o  The `HISTLIT' option was broken in various ways and has been removed:
     the rewritten history mechanism doesn't alter history lines, making
     the option unnecessary.
  o  History expansion is disabled in single-quoted strings, like other
     forms of expansion -- hence exclamation marks there should not be
     backslashed.
  o  The `$HISTCHARS' variable is now `$histchars'.  Currently both
     are tied together for compatibility.
  o  The PROMPT_SUBST option now performs backquote expansion -- hence
     you should quote these in prompts.  (SPROMPT has changed as a result.)
  o  Quoting in prompts has changed: close parentheses inside ternary
     expressions should be quoted with a %; history is now %!, not
     !.  Backslashes are no longer special.

5.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@math.gatech.edu

  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.

  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@math.gatech.edu

  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,

    zsh-announce@math.gatech.edu

  (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@math.gatech.edu

  with the *subject* line (this is a change from the old list)

    subscribe <your-email-address>

  e.g.

    Subject:  subscribe P.Stephenson@swansea.ac.uk

  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
  coleman@math.gatech.edu.

  The list from May 1992 to May 1995 is archived in
    ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.  More recent
  mailings up to date are to 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.

5.3: What's on the wish-list?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  o  Loadable module support (will be in 3.1 but much work still needs doing).
  o  Ksh compatibility could be improved.
  o  Option for glob qualifiers to follow perl syntax (a traditional item).
  o  Binding of shell functions to key strokes, accessing editing
     buffer from functions, executing zle functions as a command:  now
     under development for 3.1. 
  o  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.  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
and Richard Coleman, 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. 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://sunsite.auc.dk/zsh/".


------- End of Forwarded Message


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1998-04-24 17:40 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1998-04-24 17:40 UTC (permalink / raw)
  To: zsh-announce


Archive-Name: unix-faq/shell/zsh
Last-Modified: 1998/4/24
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zshfaq.yo,v 1.17 1998/04/24 17:10:21 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996, 1997, 1998 (see end of document)

Changes since last issue:

1.6  New archive maintainer
3.7  New item:  why do the cursor (arrow) keys not work?

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?

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. What is the difference between `export' and the ALL_EXPORT option?
3.3. How do I turn off spelling correction/globbing for a single command?
3.4. How do I get the meta key to work on my xterm?
3.5. How do I automatically display the directory in my xterm title bar?
3.6. How do I make the completion list use eight bit characters?
3.7. Why do the cursor (arrow) keys not work?
3.8. Why does my terminal act funny in some way?
3.9. Why does zsh not work in an Emacs shell mode any more?
3.10. Why do my autoloaded functions not autoload [the first time]?
3.11. How does base arithmetic work?
3.12. How do I get a newline in my prompt?
3.13. Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
3.14. Why can't I bind \C-s and \C-q any more?
3.15. How do I execute command `foo' within function `foo'?
3.16. Why do history substitutions with single bangs do something funny?
3.17. Why does zsh kill off all my background jobs when I logout?
3.18. How do I list all my history entries?
3.19. How does the alternative loop syntax, e.g. `while {...} {...}' work?
3.20. Why is my history not being saved?

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 get started with programmable completion?
4.5. And if programmable completion isn't good enough?

Chapter 5:  The future of zsh
5.1. What bugs are currently known and unfixed? (Plus recent important changes)
5.2. Where do I report bugs, get more info / who's working on zsh?
5.3. What's on the wish-list?

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://www.peak.org/zsh/ (note the change of address from the
  end of April 1997).  The server provides this FAQ and much else and is
  now maintained by Timothy Luoma.  The FAQ is at
  http://www.peak.org/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 1.6.

  There is now a preliminary version of a reference card for
  zsh 3.0, which you can find (while it's being developed) at
    http://www.ifh.de/~pws/computing/refcard.ps
  This is optimised for A4 paper. The LaTeX source is in the
  same place with the extension .tex.  It is not a good place
  from which to learn zsh for the first time.

  (As a 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 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 globbing (compctl -g),
    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,
    o  variable, editing function and option name completion,
    o  inline expansion of variables, 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 arithmetic.
  o  Manipulation of arrays (including reverse subscripting).
  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 Etc/MACHINES in the distribution has more details.

  There are also now separate ports for Windows and OS/2, see `Where
  do I get it' 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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question
  5.2).  Changes based on version 2.5 are very unlikely to
  be useful.

  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 Etc/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 make 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 3.0.5 is the latest production version. The new major number 3.0
  largely reflects the considerable internal changes in zsh to make it
  more reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of 5.1.  This is
  longer than usual due to enhanced sh, ksh and POSIX compatibility.

  The beta version 3.1.2 has also been released; 3.1.3 is expected to
  appear shortly.  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 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 (most recently) to provide POSIX compliancy.

1.6: Where do I get it?

  The archive is now run by Andrew Main <zefram@tao.co.uk>.
  The following are known mirrors (kept frequently up to date); the
  first is the official archive site.  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.

    Australia ftp://mason.primenet.com.au/pub/zsh/
              ftp://ftp.ips.gov.au/mirror/zsh/
    Finland   ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France    ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany   ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
              ftp://ftp.gmd.de/packages/zsh/
              ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Hungary   ftp://ftp.cs.elte.hu/pub/zsh/
              (also http://www.cs.elte.hu/pub/zsh/ )
    Japan     ftp://ftp.tohoku.ac.jp/mirror/zsh/
              ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway    ftp://ftp.uit.no/pub/unix/shells/zsh/
    Slovenia  ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden    ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK        ftp://ftp.net.lut.ac.uk/zsh/
              (also by FSP at port 21)
    USA       ftp://ftp.math.gatech.edu/pub/zsh/
              ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
              ftp://ftp.sterling.com/zsh/
              ftp://ftp.rge.com/pub/shells/zsh/

  The Windows port mentioned above is maintained separately by Amol
  Deshpande <amold@microsoft.com>; please mail Amol directly about any
  Windows-specific problems.  This is quite new, so don't expect it to
  be perfect.  You can get it from:

            ftp://ftp.blarg.net/users/amol/zsh  

  Likewise the OS/2 port is available from TAMURA Kent
  <kent@tril.ibm.co.jp> at

            http://cgi.din.or.jp/~tkent/tmp/zsh-3.0.0-os2-a01.zip

  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://www.peak.org/zsh/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 with 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 --- 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 commands
     `emulate sh; setopt localoptions' in a shell function will
     turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in 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_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_BUILTINS,
  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 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', 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.
        The KSH_ARRAYS option is now available.
    o   Coprocesses are established by `coproc'; `|&' behaves like
        csh. 
    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.
        (GLOB_SUBST has been added to fix this.)
    o   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.)
    o * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    o   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.

      [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 `**'.
    o   Unquoted assignments do file expansion after `:'s (intended for
        PATHs). 
    o   `integer' does not allow `-i'.

  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  Traps and signals:

    o   Traps are not local to functions.
    o   TRAPERR has become TRAPZERR (this was forced by UNICOS which
        has SIGERR).

  o  Editing:

    o   The options emacs, gmacs, viraw are not supported.
        Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
        becomes `bindkey -{e,v}'; 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' will not be in the next ksh
        release either.)
    o   Management of histories in multiple shells is different:
        the history list is not saved and restored after each command.
    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  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   `read' has no `-s' flag.
    o   In `let "i = foo"', foo is evaluated as a number, not an
        expression (in `let "i = $foo"', however, it is treated as an
        expression).

  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" 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 shwordsplit and ksharrays 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         "$@"            ($*: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.

  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.

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,
  $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 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.

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.

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.

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.)  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 `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 shwordsplit.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.

3.2: 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.3: 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.4: 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.

3.5: 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 a sun-cmd.

  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) 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.6: How do I make the completion list use eight bit characters?

  A traditional UNIX environment (character terminal and ASCII
  character sets) is not sufficient to be able to handle non-ASCII
  characters, and there are so many possible enhancements that in
  general this is hard.  However, if you have something like an xterm
  using a standard character set like ISO-8859-1 (which is often the
  default for xterm), read on.  You should also note question
  3.4 on the subject of eight bit characters.

  You are probably creating files with names including non-ASCII
  accented characters, and find they show up in the completion list as
  \M-i or something such.  This is because the library routines
  (not zsh itself) which test whether a character is printable have
  replied that it is not; zsh has simply found a way to show them
  anyway.

  The answer, under a modern POSIXy operating system, is to find a
  locale where these are treated as printable characters.  Zsh has
  handling for locales built in and will recognise when you set a
  relevant variable. You need to look in /usr/lib/locale to find one
  which suits you; the subdirectories correspond to the locale names.
  The simplest possibility is likely to be en_US, so that the simplest
  answer to your problem is to set

    LC_CTYPE=en_US

  when your terminal is capable of showing eight bit characters.  If
  you only have a default domain (called C), you may need to have some
  additional files installed on your system.

3.7: Why do the cursor (arrow) keys not work?

  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.

  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.

3.8: 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.

3.9: 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" "~/bin/eshell")

  to ~/.emacs.

3.10: 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 KSHAUTOLOAD 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.11: 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 now supported).  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.

3.12: 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 :-).  Otherwise, you can use

    PROMPT=$(print "Hi Joe,\nwhat now?%# ")

  in your initialisation file.

3.13: 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.14: 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.

3.15: 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.16: 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.17: 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.

3.18: 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.19: 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.20: 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.

Chapter 4: 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.

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.

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 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
  (or something else you can execute, like a builtin comman, a
  function or an alias) and tries 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 4.4.)

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 your 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 nobeep set, that annoying beep goes away
   o  with nolistbeep, beeping is only turned off for ambiguous completions
   o  with autolist set, when the completion is ambiguous you get a
      list without having to type \C-D
   o  with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
   o  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
   o  with automenu, you only get the menu behaviour when you hit TAB
      again on the ambiguous completion.

  Combinations of these are possible; for example, autolist and
  automenu together give an intuitive combination. 

4.4: 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 4.2),
  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):

   1) 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',
   2) 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 `-',
   3) 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.

4.5: 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.

Chapter 5: The future of zsh

5.1: What bugs are currently known and unfixed? (Plus recent important changes)

  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 2.1; 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.

  o  `time' is ignored with builtins and can't be used with `{...}'.
  o  `set -x' (`setopt xtrace') still has a few glitches.
  o  In vi mode, `u' can go past the original modification point.
  o  The singlelinezle option has problems with prompts containing escapes.
  o  The `r' command does not work inside `$(...)' or ``...`'
     expansions.   (A fix for this will appear shortly.)
  o  `typeset' handling is non-optimal, particularly with regard to
     flags, and is ksh-incompatible in unpredictable ways. 
  o  Nested closures in extended globbing and pattern matching, such as

    [[ fofo = (fo#)# ]]

     are not correctly handled (this will be fixed in version 3.1).

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes after zsh 3.0 (3.1.x is still currently in beta):

  o  history-search-{forward,backward} (bound to \M-n, \M-p)
     now only find previous lines where the first word is the same as the
     current one.  For example,

      comp<ESC>p

     will find lines in the history like `comp -edit emacs', but not
     `compress file' any more.  For an approximation to the old
     behaviour, use history-beginning-search-{forward,backward} which
     search for a line with the same prefix up to the cursor position.
  o  In vi insert mode, the cursor keys no longer work.  The following
     will bind them:

       bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \ 
                      '^[[A' up-line-or-history '^[[B' down-line-or-history

     (unless your terminal requires `^[O' instead of `^[[').  The
     rationale is that the insert mode and command mode keymaps for
     keys with prefixes are now separate.

  Changes since zsh 2.5:

  o  The left hand of an assignment is no longer substituted.  Thus,
     `$1=$2' will not work.  You can use something like `eval
     "$1=\$2"', which should have the identical effect.
  o  Signal traps established with the `trap' builtin are now called with
     the environment of the caller, as in ksh, instead of as a new
     function level.  Traps established as functions (e.g. `TRAPINT()
     {...}') work as before.
  o  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
     to be the other way around.  (Use of names rather than letters is
     generally recommended.)
  o  `[[' is a reserved word, hence must be separated from
     other characters by whitespace; `{' and `}' are also reserved
     words if the IGNORE_BRACES option is set.
  o  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
     always does what it looks like it does, so `if ( ... ) ...'
     executes the code in parentheses in a subshell.  To make this
     useful, the syntax expected after an `if', etc., is less strict
     than in other shells.
  o  Mytt(foo=*) does not perform globbing immediately on the right
     hand side of the assignment; the old behaviour now requires the
     option GLOB_ASSIGN.  (`foo=(*)' is and has always been the
     consistent way of doing this.)
  o  <> performs redirection of input and output to the specified file.
     For numeric globs, you now need <->.
  o  The command line qualifiers exec, noglob, command,
     - are now treated more like builtin commands:  previously they were
     syntactically special.  This should make it easier to perform tricks with
     them (disabling, hiding in parameters, etc.).
  o  The pushd builtin has been rewritten for compatibility with other
     shells.  The old behavour can be achieved with a shell function.
  o  The current version now uses ~'s for directory stack substitution
     instead of ='s.  This is for consistency:  all other directory
     substitution (~user, ~name, ~+, ...) used a tilde, while
     =<number> caused problems with =program substitution.
  o  The `HISTLIT' option was broken in various ways and has been removed:
     the rewritten history mechanism doesn't alter history lines, making
     the option unnecessary.
  o  History expansion is disabled in single-quoted strings, like other
     forms of expansion -- hence exclamation marks there should not be
     backslashed.
  o  The `$HISTCHARS' variable is now `$histchars'.  Currently both
     are tied together for compatibility.
  o  The PROMPT_SUBST option now performs backquote expansion -- hence
     you should quote these in prompts.  (SPROMPT has changed as a result.)
  o  Quoting in prompts has changed: close parentheses inside ternary
     expressions should be quoted with a %; history is now %!, not
     !.  Backslashes are no longer special.

5.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@math.gatech.edu

  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.

  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@math.gatech.edu

  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,

    zsh-announce@math.gatech.edu

  (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@math.gatech.edu

  with the *subject* line (this is a change from the old list)

    subscribe <your-email-address>

  e.g.

    Subject:  subscribe P.Stephenson@swansea.ac.uk

  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
  coleman@math.gatech.edu.

  The list from May 1992 to May 1995 is archived in
    ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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.

5.3: What's on the wish-list?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  o  Loadable module support (will be in 3.1 but much work still needs doing).
  o  Ksh compatibility could be improved.
  o  Option for glob qualifiers to follow perl syntax (now a traditional item).
  o  Binding of shell functions to key strokes, accessing editing
     buffer from functions, executing zle functions as a command:  now
     under development for 3.1. 
  o  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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.peak.org/zsh/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1998-03-24  8:55 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1998-03-24  8:55 UTC (permalink / raw)
  To: zsh-announce


Archive-Name: unix-faq/shell/zsh
Last-Modified: 1998/3/24
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zshfaq.yo,v 1.16 1998/03/24 08:53:23 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996, 1997, 1998 (see end of document)

Changes since last issue:

1.6  New address for Zoltan

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?

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. What is the difference between `export' and the ALL_EXPORT option?
3.3. How do I turn off spelling correction/globbing for a single command?
3.4. How do I get the meta key to work on my xterm?
3.5. How do I automatically display the directory in my xterm title bar?
3.6. How do I make the completion list use eight bit characters?
3.7. Why does my terminal act funny in some way?
3.8. Why does zsh not work in an Emacs shell mode any more?
3.9. Why do my autoloaded functions not autoload [the first time]?
3.10. How does base arithmetic work?
3.11. How do I get a newline in my prompt?
3.12. Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
3.13. Why can't I bind \C-s and \C-q any more?
3.14. How do I execute command `foo' within function `foo'?
3.15. Why do history substitutions with single bangs do something funny?
3.16. Why does zsh kill off all my background jobs when I logout?
3.17. How do I list all my history entries?
3.18. How does the alternative loop syntax, e.g. `while {...} {...}' work?
3.19. Why is my history not being saved?

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 get started with programmable completion?
4.5. And if programmable completion isn't good enough?

Chapter 5:  The future of zsh
5.1. What bugs are currently known and unfixed? (Plus recent important changes)
5.2. Where do I report bugs, get more info / who's working on zsh?
5.3. What's on the wish-list?

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://www.peak.org/zsh/ (note the change of address from the
  end of April 1997).  The server provides this FAQ and much else and is
  now maintained by Timothy Luoma.  The FAQ is at
  http://www.peak.org/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 1.6.

  There is now a preliminary version of a reference card for
  zsh 3.0, which you can find (while it's being developed) at
    http://www.ifh.de/~pws/computing/refcard.ps
  This is optimised for A4 paper. The LaTeX source is in the
  same place with the extension .tex.  It is not a good place
  from which to learn zsh for the first time.

  (As a 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 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 globbing (compctl -g),
    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,
    o  variable, editing function and option name completion,
    o  inline expansion of variables, 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 arithmetic.
  o  Manipulation of arrays (including reverse subscripting).
  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 Etc/MACHINES in the distribution has more details.

  There are also now separate ports for Windows and OS/2, see `Where
  do I get it' 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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question
  5.2).  Changes based on version 2.5 are very unlikely to
  be useful.

  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 Etc/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 make 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 3.0.5 is the latest production version. The new major number 3.0
  largely reflects the considerable internal changes in zsh to make it
  more reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of 5.1.  This is
  longer than usual due to enhanced sh, ksh and POSIX compatibility.

  The beta version 3.1.2 has also been 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 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 (most recently) to provide POSIX compliancy.

1.6: Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@frontiernet.net>.
  The following are known mirrors (kept frequently up to date); the
  first is the official archive site.  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.

    Hungary   ftp://ftp.cs.elte.hu/pub/zsh/
              (also http://www.cs.elte.hu/pub/zsh/ )
    Australia ftp://ftp.ips.gov.au/mirror/zsh/
    Finland   ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France    ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany   ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
              ftp://ftp.gmd.de/packages/zsh/
              ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Japan     ftp://ftp.tohoku.ac.jp/mirror/zsh/
              ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway    ftp://ftp.uit.no/pub/unix/shells/zsh/
    Slovenia  ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden    ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK        ftp://ftp.net.lut.ac.uk/zsh/
              (also by FSP at port 21)
    USA       ftp://ftp.math.gatech.edu/pub/zsh/
              ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
              ftp://ftp.sterling.com/zsh/
              ftp://ftp.rge.com/pub/shells/zsh/

  The Windows port mentioned above is maintained separately by Amol
  Deshpande <amold@microsoft.com>; please mail Amol directly about any
  Windows-specific problems.  This is quite new, so don't expect it to
  be perfect.  You can get it from:

            ftp://ftp.blarg.net/users/amol/zsh  

  Likewise the OS/2 port is available from TAMURA Kent
  <kent@tril.ibm.co.jp> at

            http://cgi.din.or.jp/~tkent/tmp/zsh-3.0.0-os2-a01.zip

  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://www.peak.org/zsh/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 with 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 --- 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 commands
     `emulate sh; setopt localoptions' in a shell function will
     turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in 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_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_BUILTINS,
  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 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', 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.
        The KSH_ARRAYS option is now available.
    o   Coprocesses are established by `coproc'; `|&' behaves like
        csh. 
    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.
        (GLOB_SUBST has been added to fix this.)
    o   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.)
    o * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    o   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.

      [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 `**'.
    o   Unquoted assignments do file expansion after `:'s (intended for
        PATHs). 
    o   `integer' does not allow `-i'.

  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  Traps and signals:

    o   Traps are not local to functions.
    o   TRAPERR has become TRAPZERR (this was forced by UNICOS which
        has SIGERR).

  o  Editing:

    o   The options emacs, gmacs, viraw are not supported.
        Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
        becomes `bindkey -{e,v}'; 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' will not be in the next ksh
        release either.)
    o   Management of histories in multiple shells is different:
        the history list is not saved and restored after each command.
    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  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   `read' has no `-s' flag.
    o   In `let "i = foo"', foo is evaluated as a number, not an
        expression (in `let "i = $foo"', however, it is treated as an
        expression).

  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" 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 shwordsplit and ksharrays 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         "$@"            ($*: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.

  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.

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,
  $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 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.

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.

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.

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.)  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 `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 shwordsplit.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.

3.2: 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.3: 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.4: 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.

3.5: 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 a sun-cmd.

  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) 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.6: How do I make the completion list use eight bit characters?

  A traditional UNIX environment (character terminal and ASCII
  character sets) is not sufficient to be able to handle non-ASCII
  characters, and there are so many possible enhancements that in
  general this is hard.  However, if you have something like an xterm
  using a standard character set like ISO-8859-1 (which is often the
  default for xterm), read on.  You should also note question
  3.4 on the subject of eight bit characters.

  You are probably creating files with names including non-ASCII
  accented characters, and find they show up in the completion list as
  \M-i or something such.  This is because the library routines
  (not zsh itself) which test whether a character is printable have
  replied that it is not; zsh has simply found a way to show them
  anyway.

  The answer, under a modern POSIXy operating system, is to find a
  locale where these are treated as printable characters.  Zsh has
  handling for locales built in and will recognise when you set a
  relevant variable. You need to look in /usr/lib/locale to find one
  which suits you; the subdirectories correspond to the locale names.
  The simplest possibility is likely to be en_US, so that the simplest
  answer to your problem is to set

    LC_CTYPE=en_US

  when your terminal is capable of showing eight bit characters.  If
  you only have a default domain (called C), you may need to have some
  additional files installed on your system.

3.7: 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.

3.8: 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" "~/bin/eshell")

  to ~/.emacs.

3.9: 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 KSHAUTOLOAD 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.10: 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 now supported).  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.

3.11: 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 :-).  Otherwise, you can use

    PROMPT=$(print "Hi Joe,\nwhat now?%# ")

  in your initialisation file.

3.12: 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.13: 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.

3.14: 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.15: 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.16: 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.

3.17: 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.18: 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.19: 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.

Chapter 4: 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.

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.

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 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
  (or something else you can execute, like a builtin comman, a
  function or an alias) and tries 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 4.4.)

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 your 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 nobeep set, that annoying beep goes away
   o  with nolistbeep, beeping is only turned off for ambiguous completions
   o  with autolist set, when the completion is ambiguous you get a
      list without having to type \C-D
   o  with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
   o  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
   o  with automenu, you only get the menu behaviour when you hit TAB
      again on the ambiguous completion.

  Combinations of these are possible; for example, autolist and
  automenu together give an intuitive combination. 

4.4: 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 4.2),
  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):

   1) 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',
   2) 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 `-',
   3) 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.

4.5: 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.

Chapter 5: The future of zsh

5.1: What bugs are currently known and unfixed? (Plus recent important changes)

  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 2.1; 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.

  o  `time' is ignored with builtins and can't be used with `{...}'.
  o  `set -x' (`setopt xtrace') still has a few glitches.
  o  In vi mode, `u' can go past the original modification point.
  o  The singlelinezle option has problems with prompts containing escapes.
  o  The `r' command does not work inside `$(...)' or ``...`'
     expansions.   (A fix for this will appear shortly.)
  o  `typeset' handling is non-optimal, particularly with regard to
     flags, and is ksh-incompatible in unpredictable ways. 
  o  Nested closures in extended globbing and pattern matching, such as

    [[ fofo = (fo#)# ]]

     are not correctly handled (this will be fixed in version 3.1).

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes after zsh 3.0 (3.1.x is still currently in beta):

  o  history-search-{forward,backward} (bound to \M-n, \M-p)
     now only find previous lines where the first word is the same as the
     current one.  For example,

      comp<ESC>p

     will find lines in the history like `comp -edit emacs', but not
     `compress file' any more.  For an approximation to the old
     behaviour, use history-beginning-search-{forward,backward} which
     search for a line with the same prefix up to the cursor position.
  o  In vi insert mode, the cursor keys no longer work.  The following
     will bind them:

       bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \ 
                      '^[[A' up-line-or-history '^[[B' down-line-or-history

     (unless your terminal requires `^[O' instead of `^[[').  The
     rationale is that the insert mode and command mode keymaps for
     keys with prefixes are now separate.

  Changes since zsh 2.5:

  o  The left hand of an assignment is no longer substituted.  Thus,
     `$1=$2' will not work.  You can use something like `eval
     "$1=\$2"', which should have the identical effect.
  o  Signal traps established with the `trap' builtin are now called with
     the environment of the caller, as in ksh, instead of as a new
     function level.  Traps established as functions (e.g. `TRAPINT()
     {...}') work as before.
  o  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
     to be the other way around.  (Use of names rather than letters is
     generally recommended.)
  o  `[[' is a reserved word, hence must be separated from
     other characters by whitespace; `{' and `}' are also reserved
     words if the IGNORE_BRACES option is set.
  o  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
     always does what it looks like it does, so `if ( ... ) ...'
     executes the code in parentheses in a subshell.  To make this
     useful, the syntax expected after an `if', etc., is less strict
     than in other shells.
  o  Mytt(foo=*) does not perform globbing immediately on the right
     hand side of the assignment; the old behaviour now requires the
     option GLOB_ASSIGN.  (`foo=(*)' is and has always been the
     consistent way of doing this.)
  o  <> performs redirection of input and output to the specified file.
     For numeric globs, you now need <->.
  o  The command line qualifiers exec, noglob, command,
     - are now treated more like builtin commands:  previously they were
     syntactically special.  This should make it easier to perform tricks with
     them (disabling, hiding in parameters, etc.).
  o  The pushd builtin has been rewritten for compatibility with other
     shells.  The old behavour can be achieved with a shell function.
  o  The current version now uses ~'s for directory stack substitution
     instead of ='s.  This is for consistency:  all other directory
     substitution (~user, ~name, ~+, ...) used a tilde, while
     =<number> caused problems with =program substitution.
  o  The `HISTLIT' option was broken in various ways and has been removed:
     the rewritten history mechanism doesn't alter history lines, making
     the option unnecessary.
  o  History expansion is disabled in single-quoted strings, like other
     forms of expansion -- hence exclamation marks there should not be
     backslashed.
  o  The `$HISTCHARS' variable is now `$histchars'.  Currently both
     are tied together for compatibility.
  o  The PROMPT_SUBST option now performs backquote expansion -- hence
     you should quote these in prompts.  (SPROMPT has changed as a result.)
  o  Quoting in prompts has changed: close parentheses inside ternary
     expressions should be quoted with a %; history is now %!, not
     !.  Backslashes are no longer special.

5.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@math.gatech.edu

  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.

  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@math.gatech.edu

  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,

    zsh-announce@math.gatech.edu

  (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@math.gatech.edu

  with the *subject* line (this is a change from the old list)

    subscribe <your-email-address>

  e.g.

    Subject:  subscribe P.Stephenson@swansea.ac.uk

  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
  coleman@math.gatech.edu.

  The list from May 1992 to May 1995 is archived in
    ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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.

5.3: What's on the wish-list?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  o  Loadable module support (will be in 3.1 but much work still needs doing).
  o  Ksh compatibility could be improved.
  o  Option for glob qualifiers to follow perl syntax (now a traditional item).
  o  Binding of shell functions to key strokes, accessing editing
     buffer from functions, executing zle functions as a command:  now
     under development for 3.1. 
  o  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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.peak.org/zsh/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1998-03-02  9:16 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1998-03-02  9:16 UTC (permalink / raw)
  To: zsh-announce


Archive-Name: unix-faq/shell/zsh
Last-Modified: 1998/3/2
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zshfaq.yo,v 1.15 1998/03/02 09:14:41 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996, 1997, 1998 (see end of document)

Changes since last issue:

3.19  New: `why is my history not being saved?'

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?

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. What is the difference between `export' and the ALL_EXPORT option?
3.3. How do I turn off spelling correction/globbing for a single command?
3.4. How do I get the meta key to work on my xterm?
3.5. How do I automatically display the directory in my xterm title bar?
3.6. How do I make the completion list use eight bit characters?
3.7. Why does my terminal act funny in some way?
3.8. Why does zsh not work in an Emacs shell mode any more?
3.9. Why do my autoloaded functions not autoload [the first time]?
3.10. How does base arithmetic work?
3.11. How do I get a newline in my prompt?
3.12. Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
3.13. Why can't I bind \C-s and \C-q any more?
3.14. How do I execute command `foo' within function `foo'?
3.15. Why do history substitutions with single bangs do something funny?
3.16. Why does zsh kill off all my background jobs when I logout?
3.17. How do I list all my history entries?
3.18. How does the alternative loop syntax, e.g. `while {...} {...}' work?
3.19. Why is my history not being saved?

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 get started with programmable completion?
4.5. And if programmable completion isn't good enough?

Chapter 5:  The future of zsh
5.1. What bugs are currently known and unfixed? (Plus recent important changes)
5.2. Where do I report bugs, get more info / who's working on zsh?
5.3. What's on the wish-list?

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://www.peak.org/zsh/ (note the change of address from the
  end of April 1997).  The server provides this FAQ and much else and is
  now maintained by Timothy Luoma.  The FAQ is at
  http://www.peak.org/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 1.6.

  There is now a preliminary version of a reference card for
  zsh 3.0, which you can find (while it's being developed) at
    http://www.ifh.de/~pws/computing/refcard.ps
  This is optimised for A4 paper. The LaTeX source is in the
  same place with the extension .tex.  It is not a good place
  from which to learn zsh for the first time.

  (As a 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 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 globbing (compctl -g),
    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,
    o  variable, editing function and option name completion,
    o  inline expansion of variables, 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 arithmetic.
  o  Manipulation of arrays (including reverse subscripting).
  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 Etc/MACHINES in the distribution has more details.

  There are also now separate ports for Windows and OS/2, see `Where
  do I get it' 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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question
  5.2).  Changes based on version 2.5 are very unlikely to
  be useful.

  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 Etc/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 make 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 3.0.5 is the latest production version. The new major number 3.0
  largely reflects the considerable internal changes in zsh to make it
  more reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of 5.1.  This is
  longer than usual due to enhanced sh, ksh and POSIX compatibility.

  The beta version 3.1.2 has also been 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 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 (most recently) to provide POSIX compliancy.

1.6: Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.  The
  following are known mirrors (kept frequently up to date); the first
  is the official archive site.  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.

    Hungary   ftp://ftp.cs.elte.hu/pub/zsh/
              (also http://www.cs.elte.hu/pub/zsh/ )
    Australia ftp://ftp.ips.gov.au/mirror/zsh/
    Finland   ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France    ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany   ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
              ftp://ftp.gmd.de/packages/zsh/
              ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Japan     ftp://ftp.tohoku.ac.jp/mirror/zsh/
              ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway    ftp://ftp.uit.no/pub/unix/shells/zsh/
    Slovenia  ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden    ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK        ftp://ftp.net.lut.ac.uk/zsh/
              (also by FSP at port 21)
    USA       ftp://ftp.math.gatech.edu/pub/zsh/
              ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
              ftp://ftp.sterling.com/zsh/
              ftp://ftp.rge.com/pub/shells/zsh/

  The Windows port mentioned above is maintained separately by Amol
  Deshpande <amold@microsoft.com>; please mail Amol directly about any
  Windows-specific problems.  This is quite new, so don't expect it to
  be perfect.  You can get it from:

            ftp://ftp.blarg.net/users/amol/zsh  

  Likewise the OS/2 port is available from TAMURA Kent
  <kent@tril.ibm.co.jp> at

            http://cgi.din.or.jp/~tkent/tmp/zsh-3.0.0-os2-a01.zip

  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://www.peak.org/zsh/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 with 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 --- 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 commands
     `emulate sh; setopt localoptions' in a shell function will
     turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in 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_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_BUILTINS,
  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 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', 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.
        The KSH_ARRAYS option is now available.
    o   Coprocesses are established by `coproc'; `|&' behaves like
        csh. 
    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.
        (GLOB_SUBST has been added to fix this.)
    o   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.)
    o * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    o   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.

      [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 `**'.
    o   Unquoted assignments do file expansion after `:'s (intended for
        PATHs). 
    o   `integer' does not allow `-i'.

  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  Traps and signals:

    o   Traps are not local to functions.
    o   TRAPERR has become TRAPZERR (this was forced by UNICOS which
        has SIGERR).

  o  Editing:

    o   The options emacs, gmacs, viraw are not supported.
        Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
        becomes `bindkey -{e,v}'; 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' will not be in the next ksh
        release either.)
    o   Management of histories in multiple shells is different:
        the history list is not saved and restored after each command.
    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  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   `read' has no `-s' flag.
    o   In `let "i = foo"', foo is evaluated as a number, not an
        expression (in `let "i = $foo"', however, it is treated as an
        expression).

  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" 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 shwordsplit and ksharrays 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         "$@"            ($*: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.

  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.

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,
  $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 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.

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.

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.

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.)  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 `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 shwordsplit.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.

3.2: 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.3: 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.4: 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.

3.5: 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 a sun-cmd.

  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) 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.6: How do I make the completion list use eight bit characters?

  A traditional UNIX environment (character terminal and ASCII
  character sets) is not sufficient to be able to handle non-ASCII
  characters, and there are so many possible enhancements that in
  general this is hard.  However, if you have something like an xterm
  using a standard character set like ISO-8859-1 (which is often the
  default for xterm), read on.  You should also note question
  3.4 on the subject of eight bit characters.

  You are probably creating files with names including non-ASCII
  accented characters, and find they show up in the completion list as
  \M-i or something such.  This is because the library routines
  (not zsh itself) which test whether a character is printable have
  replied that it is not; zsh has simply found a way to show them
  anyway.

  The answer, under a modern POSIXy operating system, is to find a
  locale where these are treated as printable characters.  Zsh has
  handling for locales built in and will recognise when you set a
  relevant variable. You need to look in /usr/lib/locale to find one
  which suits you; the subdirectories correspond to the locale names.
  The simplest possibility is likely to be en_US, so that the simplest
  answer to your problem is to set

    LC_CTYPE=en_US

  when your terminal is capable of showing eight bit characters.  If
  you only have a default domain (called C), you may need to have some
  additional files installed on your system.

3.7: 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.

3.8: 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" "~/bin/eshell")

  to ~/.emacs.

3.9: 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 KSHAUTOLOAD 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.10: 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 now supported).  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.

3.11: 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 :-).  Otherwise, you can use

    PROMPT=$(print "Hi Joe,\nwhat now?%# ")

  in your initialisation file.

3.12: 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.13: 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.

3.14: 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.15: 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.16: 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.

3.17: 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.18: 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.19: 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.

Chapter 4: 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.

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.

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 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
  (or something else you can execute, like a builtin comman, a
  function or an alias) and tries 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 4.4.)

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 your 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 nobeep set, that annoying beep goes away
   o  with nolistbeep, beeping is only turned off for ambiguous completions
   o  with autolist set, when the completion is ambiguous you get a
      list without having to type \C-D
   o  with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
   o  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
   o  with automenu, you only get the menu behaviour when you hit TAB
      again on the ambiguous completion.

  Combinations of these are possible; for example, autolist and
  automenu together give an intuitive combination. 

4.4: 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 4.2),
  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):

   1) 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',
   2) 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 `-',
   3) 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.

4.5: 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.

Chapter 5: The future of zsh

5.1: What bugs are currently known and unfixed? (Plus recent important changes)

  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 2.1; 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.

  o  `time' is ignored with builtins and can't be used with `{...}'.
  o  `set -x' (`setopt xtrace') still has a few glitches.
  o  In vi mode, `u' can go past the original modification point.
  o  The singlelinezle option has problems with prompts containing escapes.
  o  The `r' command does not work inside `$(...)' or ``...`'
     expansions.   (A fix for this will appear shortly.)
  o  `typeset' handling is non-optimal, particularly with regard to
     flags, and is ksh-incompatible in unpredictable ways. 
  o  Nested closures in extended globbing and pattern matching, such as

    [[ fofo = (fo#)# ]]

     are not correctly handled (this will be fixed in version 3.1).

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes after zsh 3.0 (3.1.x is still currently in beta):

  o  history-search-{forward,backward} (bound to \M-n, \M-p)
     now only find previous lines where the first word is the same as the
     current one.  For example,

      comp<ESC>p

     will find lines in the history like `comp -edit emacs', but not
     `compress file' any more.  For an approximation to the old
     behaviour, use history-beginning-search-{forward,backward} which
     search for a line with the same prefix up to the cursor position.
  o  In vi insert mode, the cursor keys no longer work.  The following
     will bind them:

       bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \ 
                      '^[[A' up-line-or-history '^[[B' down-line-or-history

     (unless your terminal requires `^[O' instead of `^[[').  The
     rationale is that the insert mode and command mode keymaps for
     keys with prefixes are now separate.

  Changes since zsh 2.5:

  o  The left hand of an assignment is no longer substituted.  Thus,
     `$1=$2' will not work.  You can use something like `eval
     "$1=\$2"', which should have the identical effect.
  o  Signal traps established with the `trap' builtin are now called with
     the environment of the caller, as in ksh, instead of as a new
     function level.  Traps established as functions (e.g. `TRAPINT()
     {...}') work as before.
  o  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
     to be the other way around.  (Use of names rather than letters is
     generally recommended.)
  o  `[[' is a reserved word, hence must be separated from
     other characters by whitespace; `{' and `}' are also reserved
     words if the IGNORE_BRACES option is set.
  o  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
     always does what it looks like it does, so `if ( ... ) ...'
     executes the code in parentheses in a subshell.  To make this
     useful, the syntax expected after an `if', etc., is less strict
     than in other shells.
  o  Mytt(foo=*) does not perform globbing immediately on the right
     hand side of the assignment; the old behaviour now requires the
     option GLOB_ASSIGN.  (`foo=(*)' is and has always been the
     consistent way of doing this.)
  o  <> performs redirection of input and output to the specified file.
     For numeric globs, you now need <->.
  o  The command line qualifiers exec, noglob, command,
     - are now treated more like builtin commands:  previously they were
     syntactically special.  This should make it easier to perform tricks with
     them (disabling, hiding in parameters, etc.).
  o  The pushd builtin has been rewritten for compatibility with other
     shells.  The old behavour can be achieved with a shell function.
  o  The current version now uses ~'s for directory stack substitution
     instead of ='s.  This is for consistency:  all other directory
     substitution (~user, ~name, ~+, ...) used a tilde, while
     =<number> caused problems with =program substitution.
  o  The `HISTLIT' option was broken in various ways and has been removed:
     the rewritten history mechanism doesn't alter history lines, making
     the option unnecessary.
  o  History expansion is disabled in single-quoted strings, like other
     forms of expansion -- hence exclamation marks there should not be
     backslashed.
  o  The `$HISTCHARS' variable is now `$histchars'.  Currently both
     are tied together for compatibility.
  o  The PROMPT_SUBST option now performs backquote expansion -- hence
     you should quote these in prompts.  (SPROMPT has changed as a result.)
  o  Quoting in prompts has changed: close parentheses inside ternary
     expressions should be quoted with a %; history is now %!, not
     !.  Backslashes are no longer special.

5.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@math.gatech.edu

  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.

  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@math.gatech.edu

  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,

    zsh-announce@math.gatech.edu

  (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@math.gatech.edu

  with the *subject* line (this is a change from the old list)

    subscribe <your-email-address>

  e.g.

    Subject:  subscribe P.Stephenson@swansea.ac.uk

  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
  coleman@math.gatech.edu.

  The list from May 1992 to May 1995 is archived in
    ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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.

5.3: What's on the wish-list?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  o  Loadable module support (will be in 3.1 but much work still needs doing).
  o  Ksh compatibility could be improved.
  o  Option for glob qualifiers to follow perl syntax (now a traditional item).
  o  Binding of shell functions to key strokes, accessing editing
     buffer from functions, executing zle functions as a command:  now
     under development for 3.1. 
  o  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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.peak.org/zsh/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1998-01-26  9:06 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1998-01-26  9:06 UTC (permalink / raw)
  To: zsh-announce

[ The FAQ doesn't mention zsh-3.1.2-zefram3 since that's not on the usual
distribution network.  If the current situation goes on I will eventually
have to add it - pws]

Archive-Name: unix-faq/shell/zsh
Last-Modified: 1998/1/26
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zshfaq.yo,v 1.14 1998/01/26 09:01:19 pws Exp pws $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996, 1997, 1998 (see end of document)

Changes since last issue:

  No changes (except this one, and the date of course).

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?

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. What is the difference between `export' and the ALL_EXPORT option?
3.3. How do I turn off spelling correction/globbing for a single command?
3.4. How do I get the meta key to work on my xterm?
3.5. How do I automatically display the directory in my xterm title bar?
3.6. How do I make the completion list use eight bit characters?
3.7. Why does my terminal act funny in some way?
3.8. Why does zsh not work in an Emacs shell mode any more?
3.9. Why do my autoloaded functions not autoload [the first time]?
3.10. How does base arithmetic work?
3.11. How do I get a newline in my prompt?
3.12. Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
3.13. Why can't I bind \C-s and \C-q any more?
3.14. How do I execute command `foo' within function `foo'?
3.15. Why do history substitutions with single bangs do something funny?
3.16. Why does zsh kill off all my background jobs when I logout?
3.17. How do I list all my history entries?
3.18. How does the alternative loop syntax, e.g. `while {...} {...}' work?

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 get started with programmable completion?
4.5. And if programmable completion isn't good enough?

Chapter 5:  The future of zsh
5.1. What bugs are currently known and unfixed? (Plus recent important changes)
5.2. Where do I report bugs, get more info / who's working on zsh?
5.3. What's on the wish-list?

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://www.peak.org/zsh/ (note the change of address from the
  end of April 1997).  The server provides this FAQ and much else and is
  now maintained by Timothy Luoma.  The FAQ is at
  http://www.peak.org/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 1.6.

  There is now a preliminary version of a reference card for
  zsh 3.0, which you can find (while it's being developed) at
    http://www.ifh.de/~pws/computing/refcard.ps
  This is optimised for A4 paper. The LaTeX source is in the
  same place with the extension .tex.  It is not a good place
  from which to learn zsh for the first time.

  (As a 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 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 globbing (compctl -g),
    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,
    o  variable, editing function and option name completion,
    o  inline expansion of variables, 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 arithmetic.
  o  Manipulation of arrays (including reverse subscripting).
  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 Etc/MACHINES in the distribution has more details.

  There are also now separate ports for Windows and OS/2, see `Where
  do I get it' 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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question
  5.2).  Changes based on version 2.5 are very unlikely to
  be useful.

  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 Etc/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 make 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 3.0.5 is the latest production version. The new major number 3.0
  largely reflects the considerable internal changes in zsh to make it
  more reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of 5.1.  This is
  longer than usual due to enhanced sh, ksh and POSIX compatibility.

  The beta version 3.1.2 has also been 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 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 (most recently) to provide POSIX compliancy.

1.6: Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.  The
  following are known mirrors (kept frequently up to date); the first
  is the official archive site.  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.

    Hungary   ftp://ftp.cs.elte.hu/pub/zsh/
              (also http://www.cs.elte.hu/pub/zsh/ )
    Australia ftp://ftp.ips.gov.au/mirror/zsh/
    Finland   ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France    ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany   ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
              ftp://ftp.gmd.de/packages/zsh/
              ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Japan     ftp://ftp.tohoku.ac.jp/mirror/zsh/
              ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway    ftp://ftp.uit.no/pub/unix/shells/zsh/
    Slovenia  ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden    ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK        ftp://ftp.net.lut.ac.uk/zsh/
              (also by FSP at port 21)
    USA       ftp://ftp.math.gatech.edu/pub/zsh/
              ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
              ftp://ftp.sterling.com/zsh/
              ftp://ftp.rge.com/pub/shells/zsh/

  The Windows port mentioned above is maintained separately by Amol
  Deshpande <amold@microsoft.com>; please mail Amol directly about any
  Windows-specific problems.  This is quite new, so don't expect it to
  be perfect.  You can get it from:

            ftp://ftp.blarg.net/users/amol/zsh  

  Likewise the OS/2 port is available from TAMURA Kent
  <kent@tril.ibm.co.jp> at

            http://cgi.din.or.jp/~tkent/tmp/zsh-3.0.0-os2-a01.zip

  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://www.peak.org/zsh/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 with 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 --- 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 commands
     `emulate sh; setopt localoptions' in a shell function will
     turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in 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_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_BUILTINS,
  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 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', 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.
        The KSH_ARRAYS option is now available.
    o   Coprocesses are established by `coproc'; `|&' behaves like
        csh. 
    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.
        (GLOB_SUBST has been added to fix this.)
    o   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.)
    o * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    o   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.

      [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 `**'.
    o   Unquoted assignments do file expansion after `:'s (intended for
        PATHs). 
    o   `integer' does not allow `-i'.

  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  Traps and signals:

    o   Traps are not local to functions.
    o   TRAPERR has become TRAPZERR (this was forced by UNICOS which
        has SIGERR).

  o  Editing:

    o   The options emacs, gmacs, viraw are not supported.
        Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
        becomes `bindkey -{e,v}'; 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' will not be in the next ksh
        release either.)
    o   Management of histories in multiple shells is different:
        the history list is not saved and restored after each command.
    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  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   `read' has no `-s' flag.
    o   In `let "i = foo"', foo is evaluated as a number, not an
        expression (in `let "i = $foo"', however, it is treated as an
        expression).

  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" 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 shwordsplit and ksharrays 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         "$@"            ($*: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.

  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.

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,
  $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 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.

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.

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.

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.)  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 `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 shwordsplit.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.

3.2: 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.3: 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.4: 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.

3.5: 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 a sun-cmd.

  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) 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.6: How do I make the completion list use eight bit characters?

  A traditional UNIX environment (character terminal and ASCII
  character sets) is not sufficient to be able to handle non-ASCII
  characters, and there are so many possible enhancements that in
  general this is hard.  However, if you have something like an xterm
  using a standard character set like ISO-8859-1 (which is often the
  default for xterm), read on.  You should also note question
  3.4 on the subject of eight bit characters.

  You are probably creating files with names including non-ASCII
  accented characters, and find they show up in the completion list as
  \M-i or something such.  This is because the library routines
  (not zsh itself) which test whether a character is printable have
  replied that it is not; zsh has simply found a way to show them
  anyway.

  The answer, under a modern POSIXy operating system, is to find a
  locale where these are treated as printable characters.  Zsh has
  handling for locales built in and will recognise when you set a
  relevant variable. You need to look in /usr/lib/locale to find one
  which suits you; the subdirectories correspond to the locale names.
  The simplest possibility is likely to be en_US, so that the simplest
  answer to your problem is to set

    LC_CTYPE=en_US

  when your terminal is capable of showing eight bit characters.  If
  you only have a default domain (called C), you may need to have some
  additional files installed on your system.

3.7: 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.

3.8: 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" "~/bin/eshell")

  to ~/.emacs.

3.9: 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 KSHAUTOLOAD 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.10: 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 now supported).  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.

3.11: 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 :-).  Otherwise, you can use

    PROMPT=$(print "Hi Joe,\nwhat now?%# ")

  in your initialisation file.

3.12: 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.13: 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.

3.14: 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.15: 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.16: 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.

3.17: 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.18: 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.

Chapter 4: 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.

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.

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 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
  (or something else you can execute, like a builtin comman, a
  function or an alias) and tries 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 4.4.)

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 your 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 nobeep set, that annoying beep goes away
   o  with nolistbeep, beeping is only turned off for ambiguous completions
   o  with autolist set, when the completion is ambiguous you get a
      list without having to type \C-D
   o  with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
   o  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
   o  with automenu, you only get the menu behaviour when you hit TAB
      again on the ambiguous completion.

  Combinations of these are possible; for example, autolist and
  automenu together give an intuitive combination. 

4.4: 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 4.2),
  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):

   1) 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',
   2) 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 `-',
   3) 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.

4.5: 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.

Chapter 5: The future of zsh

5.1: What bugs are currently known and unfixed? (Plus recent important changes)

  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 2.1; 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.

  o  `time' is ignored with builtins and can't be used with `{...}'.
  o  `set -x' (`setopt xtrace') still has a few glitches.
  o  In vi mode, `u' can go past the original modification point.
  o  The singlelinezle option has problems with prompts containing escapes.
  o  The `r' command does not work inside `$(...)' or ``...`'
     expansions.   (A fix for this will appear shortly.)
  o  `typeset' handling is non-optimal, particularly with regard to
     flags, and is ksh-incompatible in unpredictable ways. 
  o  Nested closures in extended globbing and pattern matching, such as

    [[ fofo = (fo#)# ]]

     are not correctly handled (this will be fixed in version 3.1).

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes after zsh 3.0 (3.1.x is still currently in beta):

  o  history-search-{forward,backward} (bound to \M-n, \M-p)
     now only find previous lines where the first word is the same as the
     current one.  For example,

      comp<ESC>p

     will find lines in the history like `comp -edit emacs', but not
     `compress file' any more.  For an approximation to the old
     behaviour, use history-beginning-search-{forward,backward} which
     search for a line with the same prefix up to the cursor position.
  o  In vi insert mode, the cursor keys no longer work.  The following
     will bind them:

       bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \ 
                      '^[[A' up-line-or-history '^[[B' down-line-or-history

     (unless your terminal requires `^[O' instead of `^[[').  The
     rationale is that the insert mode and command mode keymaps for
     keys with prefixes are now separate.

  Changes since zsh 2.5:

  o  The left hand of an assignment is no longer substituted.  Thus,
     `$1=$2' will not work.  You can use something like `eval
     "$1=\$2"', which should have the identical effect.
  o  Signal traps established with the `trap' builtin are now called with
     the environment of the caller, as in ksh, instead of as a new
     function level.  Traps established as functions (e.g. `TRAPINT()
     {...}') work as before.
  o  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
     to be the other way around.  (Use of names rather than letters is
     generally recommended.)
  o  `[[' is a reserved word, hence must be separated from
     other characters by whitespace; `{' and `}' are also reserved
     words if the IGNORE_BRACES option is set.
  o  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
     always does what it looks like it does, so `if ( ... ) ...'
     executes the code in parentheses in a subshell.  To make this
     useful, the syntax expected after an `if', etc., is less strict
     than in other shells.
  o  Mytt(foo=*) does not perform globbing immediately on the right
     hand side of the assignment; the old behaviour now requires the
     option GLOB_ASSIGN.  (`foo=(*)' is and has always been the
     consistent way of doing this.)
  o  <> performs redirection of input and output to the specified file.
     For numeric globs, you now need <->.
  o  The command line qualifiers exec, noglob, command,
     - are now treated more like builtin commands:  previously they were
     syntactically special.  This should make it easier to perform tricks with
     them (disabling, hiding in parameters, etc.).
  o  The pushd builtin has been rewritten for compatibility with other
     shells.  The old behavour can be achieved with a shell function.
  o  The current version now uses ~'s for directory stack substitution
     instead of ='s.  This is for consistency:  all other directory
     substitution (~user, ~name, ~+, ...) used a tilde, while
     =<number> caused problems with =program substitution.
  o  The `HISTLIT' option was broken in various ways and has been removed:
     the rewritten history mechanism doesn't alter history lines, making
     the option unnecessary.
  o  History expansion is disabled in single-quoted strings, like other
     forms of expansion -- hence exclamation marks there should not be
     backslashed.
  o  The `$HISTCHARS' variable is now `$histchars'.  Currently both
     are tied together for compatibility.
  o  The PROMPT_SUBST option now performs backquote expansion -- hence
     you should quote these in prompts.  (SPROMPT has changed as a result.)
  o  Quoting in prompts has changed: close parentheses inside ternary
     expressions should be quoted with a %; history is now %!, not
     !.  Backslashes are no longer special.

5.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@math.gatech.edu

  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.

  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@math.gatech.edu

  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,

    zsh-announce@math.gatech.edu

  (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@math.gatech.edu

  with the *subject* line (this is a change from the old list)

    subscribe <your-email-address>

  e.g.

    Subject:  subscribe P.Stephenson@swansea.ac.uk

  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
  coleman@math.gatech.edu.

  The list from May 1992 to May 1995 is archived in
    ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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.

5.3: What's on the wish-list?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  o  Loadable module support (will be in 3.1 but much work still needs doing).
  o  Ksh compatibility could be improved.
  o  Option for glob qualifiers to follow perl syntax (now a traditional item).
  o  Binding of shell functions to key strokes, accessing editing
     buffer from functions, executing zle functions as a command:  now
     under development for 3.1. 
  o  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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.peak.org/zsh/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1997-12-19 10:45 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1997-12-19 10:45 UTC (permalink / raw)
  To: Zsh announcements list

[This is early because I will be away for three weeks --- pws]

Archive-Name: unix-faq/shell/zsh
Last-Modified: 1997/12/19
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zshfaq.yo,v 1.13 1997/12/19 10:42:31 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996, 1997 (see end of document)

Changes since last issue:

1.1:  Mention new reference card (under development).
1.5:  3.0.5 has appeared (and had last time, too).

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?

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. What is the difference between `export' and the ALL_EXPORT option?
3.3. How do I turn off spelling correction/globbing for a single command?
3.4. How do I get the meta key to work on my xterm?
3.5. How do I automatically display the directory in my xterm title bar?
3.6. How do I make the completion list use eight bit characters?
3.7. Why does my terminal act funny in some way?
3.8. Why does zsh not work in an Emacs shell mode any more?
3.9. Why do my autoloaded functions not autoload [the first time]?
3.10. How does base arithmetic work?
3.11. How do I get a newline in my prompt?
3.12. Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
3.13. Why can't I bind \C-s and \C-q any more?
3.14. How do I execute command `foo' within function `foo'?
3.15. Why do history substitutions with single bangs do something funny?
3.16. Why does zsh kill off all my background jobs when I logout?
3.17. How do I list all my history entries?
3.18. How does the alternative loop syntax, e.g. `while {...} {...}' work?

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 get started with programmable completion?
4.5. And if programmable completion isn't good enough?

Chapter 5:  The future of zsh
5.1. What bugs are currently known and unfixed? (Plus recent important changes)
5.2. Where do I report bugs, get more info / who's working on zsh?
5.3. What's on the wish-list?

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://www.peak.org/zsh/ (note the change of address from the
  end of April 1997).  The server provides this FAQ and much else and is
  now maintained by Timothy Luoma.  The FAQ is at
  http://www.peak.org/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 1.6.

  There is now a preliminary version of a reference card for
  zsh 3.0, which you can find (while it's being developed) at
    http://www.ifh.de/~pws/computing/refcard.ps
  This is optimised for A4 paper. The LaTeX source is in the
  same place with the extension .tex.  It is not a good place
  from which to learn zsh for the first time.

  (As a 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 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 globbing (compctl -g),
    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,
    o  variable, editing function and option name completion,
    o  inline expansion of variables, 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 arithmetic.
  o  Manipulation of arrays (including reverse subscripting).
  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 Etc/MACHINES in the distribution has more details.

  There are also now separate ports for Windows and OS/2, see `Where
  do I get it' 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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question
  5.2).  Changes based on version 2.5 are very unlikely to
  be useful.

  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 Etc/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 make 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 3.0.5 is the latest production version. The new major number 3.0
  largely reflects the considerable internal changes in zsh to make it
  more reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of 5.1.  This is
  longer than usual due to enhanced sh, ksh and POSIX compatibility.

  The beta version 3.1.2 has also been 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 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 (most recently) to provide POSIX compliancy.

1.6: Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.  The
  following are known mirrors (kept frequently up to date); the first
  is the official archive site.  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.

    Hungary   ftp://ftp.cs.elte.hu/pub/zsh/
              (also http://www.cs.elte.hu/pub/zsh/ )
    Australia ftp://ftp.ips.gov.au/mirror/zsh/
    Finland   ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France    ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany   ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
              ftp://ftp.gmd.de/packages/zsh/
              ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Japan     ftp://ftp.tohoku.ac.jp/mirror/zsh/
              ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway    ftp://ftp.uit.no/pub/unix/shells/zsh/
    Slovenia  ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden    ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK        ftp://ftp.net.lut.ac.uk/zsh/
              (also by FSP at port 21)
    USA       ftp://ftp.math.gatech.edu/pub/zsh/
              ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
              ftp://ftp.sterling.com/zsh/
              ftp://ftp.rge.com/pub/shells/zsh/

  The Windows port mentioned above is maintained separately by Amol
  Deshpande <amold@microsoft.com>; please mail Amol directly about any
  Windows-specific problems.  This is quite new, so don't expect it to
  be perfect.  You can get it from:

            ftp://ftp.blarg.net/users/amol/zsh  

  Likewise the OS/2 port is available from TAMURA Kent
  <kent@tril.ibm.co.jp> at

            http://cgi.din.or.jp/~tkent/tmp/zsh-3.0.0-os2-a01.zip

  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://www.peak.org/zsh/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 with 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 --- 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 commands
     `emulate sh; setopt localoptions' in a shell function will
     turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in 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_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_BUILTINS,
  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 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', 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.
        The KSH_ARRAYS option is now available.
    o   Coprocesses are established by `coproc'; `|&' behaves like
        csh. 
    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.
        (GLOB_SUBST has been added to fix this.)
    o   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.)
    o * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    o   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.

      [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 `**'.
    o   Unquoted assignments do file expansion after `:'s (intended for
        PATHs). 
    o   `integer' does not allow `-i'.

  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  Traps and signals:

    o   Traps are not local to functions.
    o   TRAPERR has become TRAPZERR (this was forced by UNICOS which
        has SIGERR).

  o  Editing:

    o   The options emacs, gmacs, viraw are not supported.
        Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
        becomes `bindkey -{e,v}'; 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' will not be in the next ksh
        release either.)
    o   Management of histories in multiple shells is different:
        the history list is not saved and restored after each command.
    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  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   `read' has no `-s' flag.
    o   In `let "i = foo"', foo is evaluated as a number, not an
        expression (in `let "i = $foo"', however, it is treated as an
        expression).

  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" 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 shwordsplit and ksharrays 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         "$@"            ($*: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.

  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.

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,
  $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 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.

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.

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.

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.)  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 `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 shwordsplit.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.

3.2: 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.3: 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.4: 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.

3.5: 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 a sun-cmd.

  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) 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.6: How do I make the completion list use eight bit characters?

  A traditional UNIX environment (character terminal and ASCII
  character sets) is not sufficient to be able to handle non-ASCII
  characters, and there are so many possible enhancements that in
  general this is hard.  However, if you have something like an xterm
  using a standard character set like ISO-8859-1 (which is often the
  default for xterm), read on.  You should also note question
  3.4 on the subject of eight bit characters.

  You are probably creating files with names including non-ASCII
  accented characters, and find they show up in the completion list as
  \M-i or something such.  This is because the library routines
  (not zsh itself) which test whether a character is printable have
  replied that it is not; zsh has simply found a way to show them
  anyway.

  The answer, under a modern POSIXy operating system, is to find a
  locale where these are treated as printable characters.  Zsh has
  handling for locales built in and will recognise when you set a
  relevant variable. You need to look in /usr/lib/locale to find one
  which suits you; the subdirectories correspond to the locale names.
  The simplest possibility is likely to be en_US, so that the simplest
  answer to your problem is to set

    LC_CTYPE=en_US

  when your terminal is capable of showing eight bit characters.  If
  you only have a default domain (called C), you may need to have some
  additional files installed on your system.

3.7: 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.

3.8: 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" "~/bin/eshell")

  to ~/.emacs.

3.9: 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 KSHAUTOLOAD 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.10: 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 now supported).  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.

3.11: 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 :-).  Otherwise, you can use

    PROMPT=$(print "Hi Joe,\nwhat now?%# ")

  in your initialisation file.

3.12: 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.13: 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.

3.14: 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.15: 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.16: 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.

3.17: 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.18: 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.

Chapter 4: 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.

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.

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 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
  (or something else you can execute, like a builtin comman, a
  function or an alias) and tries 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 4.4.)

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 your 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 nobeep set, that annoying beep goes away
   o  with nolistbeep, beeping is only turned off for ambiguous completions
   o  with autolist set, when the completion is ambiguous you get a
      list without having to type \C-D
   o  with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
   o  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
   o  with automenu, you only get the menu behaviour when you hit TAB
      again on the ambiguous completion.

  Combinations of these are possible; for example, autolist and
  automenu together give an intuitive combination. 

4.4: 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 4.2),
  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):

   1) 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',
   2) 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 `-',
   3) 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.

4.5: 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.

Chapter 5: The future of zsh

5.1: What bugs are currently known and unfixed? (Plus recent important changes)

  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 2.1; 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.

  o  `time' is ignored with builtins and can't be used with `{...}'.
  o  `set -x' (`setopt xtrace') still has a few glitches.
  o  In vi mode, `u' can go past the original modification point.
  o  The singlelinezle option has problems with prompts containing escapes.
  o  The `r' command does not work inside `$(...)' or ``...`'
     expansions.   (A fix for this will appear shortly.)
  o  `typeset' handling is non-optimal, particularly with regard to
     flags, and is ksh-incompatible in unpredictable ways. 
  o  Nested closures in extended globbing and pattern matching, such as

    [[ fofo = (fo#)# ]]

     are not correctly handled (this will be fixed in version 3.1).

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes after zsh 3.0 (3.1.x is still currently in beta):

  o  history-search-{forward,backward} (bound to \M-n, \M-p)
     now only find previous lines where the first word is the same as the
     current one.  For example,

      comp<ESC>p

     will find lines in the history like `comp -edit emacs', but not
     `compress file' any more.  For an approximation to the old
     behaviour, use history-beginning-search-{forward,backward} which
     search for a line with the same prefix up to the cursor position.
  o  In vi insert mode, the cursor keys no longer work.  The following
     will bind them:

       bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \ 
                      '^[[A' up-line-or-history '^[[B' down-line-or-history

     (unless your terminal requires `^[O' instead of `^[[').  The
     rationale is that the insert mode and command mode keymaps for
     keys with prefixes are now separate.

  Changes since zsh 2.5:

  o  The left hand of an assignment is no longer substituted.  Thus,
     `$1=$2' will not work.  You can use something like `eval
     "$1=\$2"', which should have the identical effect.
  o  Signal traps established with the `trap' builtin are now called with
     the environment of the caller, as in ksh, instead of as a new
     function level.  Traps established as functions (e.g. `TRAPINT()
     {...}') work as before.
  o  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
     to be the other way around.  (Use of names rather than letters is
     generally recommended.)
  o  `[[' is a reserved word, hence must be separated from
     other characters by whitespace; `{' and `}' are also reserved
     words if the IGNORE_BRACES option is set.
  o  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
     always does what it looks like it does, so `if ( ... ) ...'
     executes the code in parentheses in a subshell.  To make this
     useful, the syntax expected after an `if', etc., is less strict
     than in other shells.
  o  Mytt(foo=*) does not perform globbing immediately on the right
     hand side of the assignment; the old behaviour now requires the
     option GLOB_ASSIGN.  (`foo=(*)' is and has always been the
     consistent way of doing this.)
  o  <> performs redirection of input and output to the specified file.
     For numeric globs, you now need <->.
  o  The command line qualifiers exec, noglob, command,
     - are now treated more like builtin commands:  previously they were
     syntactically special.  This should make it easier to perform tricks with
     them (disabling, hiding in parameters, etc.).
  o  The pushd builtin has been rewritten for compatibility with other
     shells.  The old behavour can be achieved with a shell function.
  o  The current version now uses ~'s for directory stack substitution
     instead of ='s.  This is for consistency:  all other directory
     substitution (~user, ~name, ~+, ...) used a tilde, while
     =<number> caused problems with =program substitution.
  o  The `HISTLIT' option was broken in various ways and has been removed:
     the rewritten history mechanism doesn't alter history lines, making
     the option unnecessary.
  o  History expansion is disabled in single-quoted strings, like other
     forms of expansion -- hence exclamation marks there should not be
     backslashed.
  o  The `$HISTCHARS' variable is now `$histchars'.  Currently both
     are tied together for compatibility.
  o  The PROMPT_SUBST option now performs backquote expansion -- hence
     you should quote these in prompts.  (SPROMPT has changed as a result.)
  o  Quoting in prompts has changed: close parentheses inside ternary
     expressions should be quoted with a %; history is now %!, not
     !.  Backslashes are no longer special.

5.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@math.gatech.edu

  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.

  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@math.gatech.edu

  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,

    zsh-announce@math.gatech.edu

  (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@math.gatech.edu

  with the *subject* line (this is a change from the old list)

    subscribe <your-email-address>

  e.g.

    Subject:  subscribe P.Stephenson@swansea.ac.uk

  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
  coleman@math.gatech.edu.

  The list from May 1992 to May 1995 is archived in
    ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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.

5.3: What's on the wish-list?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  o  Loadable module support (will be in 3.1 but much work still needs doing).
  o  Ksh compatibility could be improved.
  o  Option for glob qualifiers to follow perl syntax (now a traditional item).
  o  Binding of shell functions to key strokes, accessing editing
     buffer from functions, executing zle functions as a command:  now
     under development for 3.1. 
  o  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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.peak.org/zsh/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1997-11-25  8:45 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1997-11-25  8:45 UTC (permalink / raw)
  To: zsh-announce


Archive-Name: unix-faq/shell/zsh
Last-Modified: 1997/10/27
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zshfaq.yo,v 1.12 1997/11/25 08:42:40 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996, 1997 (see end of document)

Changes since last issue:

  None

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?

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. What is the difference between `export' and the ALL_EXPORT option?
3.3. How do I turn off spelling correction/globbing for a single command?
3.4. How do I get the meta key to work on my xterm?
3.5. How do I automatically display the directory in my xterm title bar?
3.6. How do I make the completion list use eight bit characters?
3.7. Why does my terminal act funny in some way?
3.8. Why does zsh not work in an Emacs shell mode any more?
3.9. Why do my autoloaded functions not autoload [the first time]?
3.10. How does base arithmetic work?
3.11. How do I get a newline in my prompt?
3.12. Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
3.13. Why can't I bind \C-s and \C-q any more?
3.14. How do I execute command `foo' within function `foo'?
3.15. Why do history substitutions with single bangs do something funny?
3.16. Why does zsh kill off all my background jobs when I logout?
3.17. How do I list all my history entries?
3.18. How does the alternative loop syntax, e.g. `while {...} {...}' work?

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 get started with programmable completion?
4.5. And if programmable completion isn't good enough?

Chapter 5:  The future of zsh
5.1. What bugs are currently known and unfixed? (Plus recent important changes)
5.2. Where do I report bugs, get more info / who's working on zsh?
5.3. What's on the wish-list?

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://www.peak.org/zsh/ (note the change of address from the
  end of April 1997).  The server provides this FAQ and much else and is
  now maintained by Timothy Luoma.  The FAQ is at
  http://www.peak.org/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 1.6.

  (As a 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 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); it's 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 globbing (compctl -g),
    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,
    o  variable, editing function and option name completion,
    o  inline expansion of variables, 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 arithmetic.
  o  Manipulation of arrays (including reverse subscripting).
  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 Etc/MACHINES in the distribution has more details.

  There are also now separate ports for Windows and OS/2, see `Where
  do I get it' 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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question
  5.2).  Changes based on version 2.5 are very unlikely to
  be useful.

  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 Etc/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 make 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 3.0.5 is in test and is expected to appear within days. The new
  major number 3.0 largely reflects the considerable internal changes
  in zsh to make it more reliable, consistent and (where possible)
  compatible.  Those planning on upgrading their zsh installation
  should take a look at the list of incompatibilities at the end of
  5.1.  This is longer than usual due to enhanced sh, ksh
  and POSIX compatibility.

  The beta version 3.1.2 has also been 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 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 (most recently) to provide POSIX compliancy.

1.6: Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.  The
  following are known mirrors (kept frequently up to date); the first
  is the official archive site.  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.

    Hungary   ftp://ftp.cs.elte.hu/pub/zsh/
              (also http://www.cs.elte.hu/pub/zsh/ )
    Australia ftp://ftp.ips.gov.au/mirror/zsh/
    Finland   ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France    ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany   ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
              ftp://ftp.gmd.de/packages/zsh/
              ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Japan     ftp://ftp.tohoku.ac.jp/mirror/zsh/
              ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway    ftp://ftp.uit.no/pub/unix/shells/zsh/
    Slovenia  ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden    ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK        ftp://ftp.net.lut.ac.uk/zsh/
              (also by FSP at port 21)
    USA       ftp://ftp.math.gatech.edu/pub/zsh/
              ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
              ftp://ftp.sterling.com/zsh/
              ftp://ftp.rge.com/pub/shells/zsh/

  The Windows port mentioned above is maintained separately by Amol
  Deshpande <amold@microsoft.com>; please mail Amol directly about any
  Windows-specific problems.  This is quite new, so don't expect it to
  be perfect.  You can get it from:

            ftp://ftp.blarg.net/users/amol/zsh  

  Likewise the OS/2 port is available from TAMURA Kent
  <kent@tril.ibm.co.jp at

            http://cgi.din.or.jp/~tkent/tmp/zsh-3.0.0-os2-a01.zip

  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://www.peak.org/zsh/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 with 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 --- 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 commands
     `emulate sh; setopt localoptions' in a shell function will
     turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in 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_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_BUILTINS,
  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 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', 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.
        The KSH_ARRAYS option is now available.
    o   Coprocesses are established by `coproc'; `|&' behaves like
        csh. 
    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.
        (GLOB_SUBST has been added to fix this.)
    o   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.)
    o * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    o   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.

      [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 `**'.
    o   Unquoted assignments do file expansion after `:'s (intended for
        PATHs). 
    o   `integer' does not allow `-i'.

  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  Traps and signals:

    o   Traps are not local to functions.
    o   TRAPERR has become TRAPZERR (this was forced by UNICOS which
        has SIGERR).

  o  Editing:

    o   The options emacs, gmacs, viraw are not supported.
        Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
        becomes `bindkey -{e,v}'; 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' will not be in the next ksh
        release either.)
    o   Management of histories in multiple shells is different:
        the history list is not saved and restored after each command.
    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  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   `read' has no `-s' flag.
    o   In `let "i = foo"', foo is evaluated as a number, not an
        expression (although in `let "i = $foo"' +it is treated as an
        expression). 

  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" 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 shwordsplit and ksharrays 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         "$@"            ($*: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.

  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.

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,
  $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 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.

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.

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.

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.)  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 `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 shwordsplit.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.

3.2: 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.3: 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.4: 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.

3.5: 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 a sun-cmd.

  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) 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.6: How do I make the completion list use eight bit characters?

  A traditional UNIX environment (character terminal and ASCII
  character sets) is not sufficient to be able to handle non-ASCII
  characters, and there are so many possible enhancements that in
  general this is hard.  However, if you have something like an xterm
  using a standard character set like ISO-8859-1 (which is often the
  default for xterm), read on.  You should also note question
  3.4 on the subject of eight bit characters.

  You are probably creating files with names including non-ASCII
  accented characters, and find they show up in the completion list as
  \M-i or something such.  This is because the library routines
  (not zsh itself) which test whether a character is printable have
  replied that it is not; zsh has simply found a way to show them
  anyway.

  The answer, under a modern POSIXy operating system, is to find a
  locale where these are treated as printable characters.  Zsh has
  handling for locales built in and will recognise when you set a
  relevant variable. You need to look in /usr/lib/locale to find one
  which suits you; the subdirectories correspond to the locale names.
  The simplest possibility is likely to be en_US, so that the simplest
  answer to your problem is to set

    LC_CTYPE=en_US

  when your terminal is capable of showing eight bit characters.  If
  you only have a default domain (called C), you may need to have some
  additional files installed on your system.

3.7: 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.

3.8: 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" "~/bin/eshell")

  to ~/.emacs.

3.9: 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 KSHAUTOLOAD 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.10: 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 now supported).  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.

3.11: 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 :-).  Otherwise, you can use

    PROMPT=$(print "Hi Joe,\nwhat now?%# ")

  in your initialisation file.

3.12: 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.13: 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.

3.14: 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.15: 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.16: 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.

3.17: 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.18: 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.

Chapter 4: 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.

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.

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 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
  (or something else you can execute, like a builtin comman, a
  function or an alias) and tries 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 4.4.)

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 your 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 nobeep set, that annoying beep goes away
   o  with nolistbeep, beeping is only turned off for ambiguous completions
   o  with autolist set, when the completion is ambiguous you get a
      list without having to type \C-D
   o  with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
   o  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
   o  with automenu, you only get the menu behaviour when you hit TAB
      again on the ambiguous completion.

  Combinations of these are possible; for example, autolist and
  automenu together give an intuitive combination. 

4.4: 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 4.2),
  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):

   1) 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',
   2) 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 `-',
   3) 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.

4.5: 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.

Chapter 5: The future of zsh

5.1: What bugs are currently known and unfixed? (Plus recent important changes)

  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 2.1; 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.

  o  `time' is ignored with builtins and can't be used with `{...}'.
  o  `set -x' (`setopt xtrace') still has a few glitches.
  o  In vi mode, `u' can go past the original modification point.
  o  The singlelinezle option has problems with prompts containing escapes.
  o  The `r' command does not work inside `$(...)' or ``...`'
     expansions.   (A fix for this will appear shortly.)
  o  `typeset' handling is non-optimal, particularly with regard to
     flags, and is ksh-incompatible in unpredictable ways. 
  o  Nested closures in extended globbing and pattern matching, such as

    [[ fofo = (fo#)# ]]

     are not correctly handled (this will be fixed in version 3.1).

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes after zsh 3.0 (3.1.x is still currently in beta):

  o  history-search-{forward,backward} (bound to \M-n, \M-p)
     now only find previous lines where the first word is the same as the
     current one.  For example,

      comp<ESC>p

     will find lines in the history like `comp -edit emacs', but not
     `compress file' any more.  For an approximation to the old
     behaviour, use history-beginning-search-{forward,backward} which
     search for a line with the same prefix up to the cursor position.
  o  In vi insert mode, the cursor keys no longer work.  The following
     will bind them:

       bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \ 
                      '^[[A' up-line-or-history '^[[B' down-line-or-history

     (unless your terminal requires `^[O' instead of `^[[').  The
     rationale is that the insert mode and command mode keymaps for
     keys with prefixes are now separate.

  Changes since zsh 2.5:

  o  The left hand of an assignment is no longer substituted.  Thus,
     `$1=$2' will not work.  You can use something like `eval
     "$1=\$2"', which should have the identical effect.
  o  Signal traps established with the `trap' builtin are now called with
     the environment of the caller, as in ksh, instead of as a new
     function level.  Traps established as functions (e.g. `TRAPINT()
     {...}') work as before.
  o  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
     to be the other way around.  (Use of names rather than letters is
     generally recommended.)
  o  `[[' is a reserved word, hence must be separated from
     other characters by whitespace; `{' and `}' are also reserved
     words if the IGNORE_BRACES option is set.
  o  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
     always does what it looks like it does, so `if ( ... ) ...'
     executes the code in parentheses in a subshell.  To make this
     useful, the syntax expected after an `if', etc., is less strict
     than in other shells.
  o  Mytt(foo=*) does not perform globbing immediately on the right
     hand side of the assignment; the old behaviour now requires the
     option GLOB_ASSIGN.  (`foo=(*)' is and has always been the
     consistent way of doing this.)
  o  <> performs redirection of input and output to the specified file.
     For numeric globs, you now need <->.
  o  The command line qualifiers exec, noglob, command,
     - are now treated more like builtin commands:  previously they were
     syntactically special.  This should make it easier to perform tricks with
     them (disabling, hiding in parameters, etc.).
  o  The pushd builtin has been rewritten for compatibility with other
     shells.  The old behavour can be achieved with a shell function.
  o  The current version now uses ~'s for directory stack substitution
     instead of ='s.  This is for consistency:  all other directory
     substitution (~user, ~name, ~+, ...) used a tilde, while
     =<number> caused problems with =program substitution.
  o  The `HISTLIT' option was broken in various ways and has been removed:
     the rewritten history mechanism doesn't alter history lines, making
     the option unnecessary.
  o  History expansion is disabled in single-quoted strings, like other
     forms of expansion -- hence exclamation marks there should not be
     backslashed.
  o  The `$HISTCHARS' variable is now `$histchars'.  Currently both
     are tied together for compatibility.
  o  The PROMPT_SUBST option now performs backquote expansion -- hence
     you should quote these in prompts.  (SPROMPT has changed as a result.)
  o  Quoting in prompts has changed: close parentheses inside ternary
     expressions should be quoted with a %; history is now %!, not
     !.  Backslashes are no longer special.

5.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@math.gatech.edu

  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.

  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@math.gatech.edu

  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,

    zsh-announce@math.gatech.edu

  (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@math.gatech.edu

  with the *subject* line (this is a change from the old list)

    subscribe <your-email-address>

  e.g.

    Subject:  subscribe P.Stephenson@swansea.ac.uk

  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
  coleman@math.gatech.edu.

  The list from May 1992 to May 1995 is archived in
    ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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.

5.3: What's on the wish-list?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  o  Loadable module support (will be in 3.1 but much work still needs doing).
  o  Ksh compatibility could be improved.
  o  Option for glob qualifiers to follow perl syntax (now a traditional item).
  o  Binding of shell functions to key strokes, accessing editing
     buffer from functions, executing zle functions as a command:  now
     under development for 3.1. 
  o  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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.peak.org/zsh/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1997-10-27 16:08 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1997-10-27 16:08 UTC (permalink / raw)
  To: zsh-announce


Archive-Name: unix-faq/shell/zsh
Last-Modified: 1997/10/27
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zshfaq.yo,v 1.11 1997/10/27 16:07:02 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996, 1997 (see end of document)

Changes since last issue:

1.6:  New patch archive
2.1:  Mention `cmd1 && cmd2 &' difference.
5.1:  Mention $(r) bug fix

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?

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. What is the difference between `export' and the ALL_EXPORT option?
3.3. How do I turn off spelling correction/globbing for a single command?
3.4. How do I get the meta key to work on my xterm?
3.5. How do I automatically display the directory in my xterm title bar?
3.6. How do I make the completion list use eight bit characters?
3.7. Why does my terminal act funny in some way?
3.8. Why does zsh not work in an Emacs shell mode any more?
3.9. Why do my autoloaded functions not autoload [the first time]?
3.10. How does base arithmetic work?
3.11. How do I get a newline in my prompt?
3.12. Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
3.13. Why can't I bind \C-s and \C-q any more?
3.14. How do I execute command `foo' within function `foo'?
3.15. Why do history substitutions with single bangs do something funny?
3.16. Why does zsh kill off all my background jobs when I logout?
3.17. How do I list all my history entries?
3.18. How does the alternative loop syntax, e.g. `while {...} {...}' work?

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 get started with programmable completion?
4.5. And if programmable completion isn't good enough?

Chapter 5:  The future of zsh
5.1. What bugs are currently known and unfixed? (Plus recent important changes)
5.2. Where do I report bugs, get more info / who's working on zsh?
5.3. What's on the wish-list?

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://www.peak.org/zsh/ (note the change of address from the
  end of April 1997).  The server provides this FAQ and much else and is
  now maintained by Timothy Luoma.  The FAQ is at
  http://www.peak.org/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 1.6.

  (As a 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 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); it's 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 globbing (compctl -g),
    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,
    o  variable, editing function and option name completion,
    o  inline expansion of variables, 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 arithmetic.
  o  Manipulation of arrays (including reverse subscripting).
  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 Etc/MACHINES in the distribution has more details.

  There are also now separate ports for Windows and OS/2, see `Where
  do I get it' 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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question
  5.2).  Changes based on version 2.5 are very unlikely to
  be useful.

  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 Etc/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 make 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 3.0.5 is in test and is expected to appear within days. The new
  major number 3.0 largely reflects the considerable internal changes
  in zsh to make it more reliable, consistent and (where possible)
  compatible.  Those planning on upgrading their zsh installation
  should take a look at the list of incompatibilities at the end of
  5.1.  This is longer than usual due to enhanced sh, ksh
  and POSIX compatibility.

  The beta version 3.1.2 has also been 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 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 (most recently) to provide POSIX compliancy.

1.6: Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.  The
  following are known mirrors (kept frequently up to date); the first
  is the official archive site.  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.

    Hungary   ftp://ftp.cs.elte.hu/pub/zsh/
              (also http://www.cs.elte.hu/pub/zsh/ )
    Australia ftp://ftp.ips.gov.au/mirror/zsh/
    Finland   ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France    ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany   ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
              ftp://ftp.gmd.de/packages/zsh/
              ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Japan     ftp://ftp.tohoku.ac.jp/mirror/zsh/
              ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway    ftp://ftp.uit.no/pub/unix/shells/zsh/
    Slovenia  ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden    ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK        ftp://ftp.net.lut.ac.uk/zsh/
              (also by FSP at port 21)
    USA       ftp://ftp.math.gatech.edu/pub/zsh/
              ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
              ftp://ftp.sterling.com/zsh/
              ftp://ftp.rge.com/pub/shells/zsh/

  The Windows port mentioned above is maintained separately by Amol
  Deshpande <amold@microsoft.com>; please mail Amol directly about any
  Windows-specific problems.  This is quite new, so don't expect it to
  be perfect.  You can get it from:

            ftp://ftp.blarg.net/users/amol/zsh  

  Likewise the OS/2 port is available from TAMURA Kent
  <kent@tril.ibm.co.jp at

            http://cgi.din.or.jp/~tkent/tmp/zsh-3.0.0-os2-a01.zip

  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://www.peak.org/zsh/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 with 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 --- 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 commands
     `emulate sh; setopt localoptions' in a shell function will
     turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in 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_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_BUILTINS,
  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 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', 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.
        The KSH_ARRAYS option is now available.
    o   Coprocesses are established by `coproc'; `|&' behaves like
        csh. 
    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.
        (GLOB_SUBST has been added to fix this.)
    o   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.)
    o * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    o   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.

      [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 `**'.
    o   Unquoted assignments do file expansion after `:'s (intended for
        PATHs). 
    o   `integer' does not allow `-i'.

  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  Traps and signals:

    o   Traps are not local to functions.
    o   TRAPERR has become TRAPZERR (this was forced by UNICOS which
        has SIGERR).

  o  Editing:

    o   The options emacs, gmacs, viraw are not supported.
        Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
        becomes `bindkey -{e,v}'; 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' will not be in the next ksh
        release either.)
    o   Management of histories in multiple shells is different:
        the history list is not saved and restored after each command.
    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  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   `read' has no `-s' flag.
    o   In `let "i = foo"', foo is evaluated as a number, not an
        expression (although in `let "i = $foo"' +it is treated as an
        expression). 

  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" 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 shwordsplit and ksharrays 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         "$@"            ($*: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.

  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.

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,
  $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 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.

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.

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.

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.)  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 `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 shwordsplit.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.

3.2: 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.3: 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.4: 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.

3.5: 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 a sun-cmd.

  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) 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.6: How do I make the completion list use eight bit characters?

  A traditional UNIX environment (character terminal and ASCII
  character sets) is not sufficient to be able to handle non-ASCII
  characters, and there are so many possible enhancements that in
  general this is hard.  However, if you have something like an xterm
  using a standard character set like ISO-8859-1 (which is often the
  default for xterm), read on.  You should also note question
  3.4 on the subject of eight bit characters.

  You are probably creating files with names including non-ASCII
  accented characters, and find they show up in the completion list as
  \M-i or something such.  This is because the library routines
  (not zsh itself) which test whether a character is printable have
  replied that it is not; zsh has simply found a way to show them
  anyway.

  The answer, under a modern POSIXy operating system, is to find a
  locale where these are treated as printable characters.  Zsh has
  handling for locales built in and will recognise when you set a
  relevant variable. You need to look in /usr/lib/locale to find one
  which suits you; the subdirectories correspond to the locale names.
  The simplest possibility is likely to be en_US, so that the simplest
  answer to your problem is to set

    LC_CTYPE=en_US

  when your terminal is capable of showing eight bit characters.  If
  you only have a default domain (called C), you may need to have some
  additional files installed on your system.

3.7: 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.

3.8: 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" "~/bin/eshell")

  to ~/.emacs.

3.9: 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 KSHAUTOLOAD 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.10: 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 now supported).  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.

3.11: 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 :-).  Otherwise, you can use

    PROMPT=$(print "Hi Joe,\nwhat now?%# ")

  in your initialisation file.

3.12: 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.13: 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.

3.14: 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.15: 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.16: 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.

3.17: 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.18: 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.

Chapter 4: 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.

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.

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 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
  (or something else you can execute, like a builtin comman, a
  function or an alias) and tries 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 4.4.)

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 your 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 nobeep set, that annoying beep goes away
   o  with nolistbeep, beeping is only turned off for ambiguous completions
   o  with autolist set, when the completion is ambiguous you get a
      list without having to type \C-D
   o  with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
   o  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
   o  with automenu, you only get the menu behaviour when you hit TAB
      again on the ambiguous completion.

  Combinations of these are possible; for example, autolist and
  automenu together give an intuitive combination. 

4.4: 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 4.2),
  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):

   1) 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',
   2) 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 `-',
   3) 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.

4.5: 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.

Chapter 5: The future of zsh

5.1: What bugs are currently known and unfixed? (Plus recent important changes)

  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 2.1; 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.

  o  `time' is ignored with builtins and can't be used with `{...}'.
  o  `set -x' (`setopt xtrace') still has a few glitches.
  o  In vi mode, `u' can go past the original modification point.
  o  The singlelinezle option has problems with prompts containing escapes.
  o  The `r' command does not work inside `$(...)' or ``...`'
     expansions.   (A fix for this will appear shortly.)
  o  `typeset' handling is non-optimal, particularly with regard to
     flags, and is ksh-incompatible in unpredictable ways. 
  o  Nested closures in extended globbing and pattern matching, such as

    [[ fofo = (fo#)# ]]

     are not correctly handled (this will be fixed in version 3.1).

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes after zsh 3.0 (3.1.x is still currently in beta):

  o  history-search-{forward,backward} (bound to \M-n, \M-p)
     now only find previous lines where the first word is the same as the
     current one.  For example,

      comp<ESC>p

     will find lines in the history like `comp -edit emacs', but not
     `compress file' any more.  For an approximation to the old
     behaviour, use history-beginning-search-{forward,backward} which
     search for a line with the same prefix up to the cursor position.
  o  In vi insert mode, the cursor keys no longer work.  The following
     will bind them:

       bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \ 
                      '^[[A' up-line-or-history '^[[B' down-line-or-history

     (unless your terminal requires `^[O' instead of `^[[').  The
     rationale is that the insert mode and command mode keymaps for
     keys with prefixes are now separate.

  Changes since zsh 2.5:

  o  The left hand of an assignment is no longer substituted.  Thus,
     `$1=$2' will not work.  You can use something like `eval
     "$1=\$2"', which should have the identical effect.
  o  Signal traps established with the `trap' builtin are now called with
     the environment of the caller, as in ksh, instead of as a new
     function level.  Traps established as functions (e.g. `TRAPINT()
     {...}') work as before.
  o  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
     to be the other way around.  (Use of names rather than letters is
     generally recommended.)
  o  `[[' is a reserved word, hence must be separated from
     other characters by whitespace; `{' and `}' are also reserved
     words if the IGNORE_BRACES option is set.
  o  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
     always does what it looks like it does, so `if ( ... ) ...'
     executes the code in parentheses in a subshell.  To make this
     useful, the syntax expected after an `if', etc., is less strict
     than in other shells.
  o  Mytt(foo=*) does not perform globbing immediately on the right
     hand side of the assignment; the old behaviour now requires the
     option GLOB_ASSIGN.  (`foo=(*)' is and has always been the
     consistent way of doing this.)
  o  <> performs redirection of input and output to the specified file.
     For numeric globs, you now need <->.
  o  The command line qualifiers exec, noglob, command,
     - are now treated more like builtin commands:  previously they were
     syntactically special.  This should make it easier to perform tricks with
     them (disabling, hiding in parameters, etc.).
  o  The pushd builtin has been rewritten for compatibility with other
     shells.  The old behavour can be achieved with a shell function.
  o  The current version now uses ~'s for directory stack substitution
     instead of ='s.  This is for consistency:  all other directory
     substitution (~user, ~name, ~+, ...) used a tilde, while
     =<number> caused problems with =program substitution.
  o  The `HISTLIT' option was broken in various ways and has been removed:
     the rewritten history mechanism doesn't alter history lines, making
     the option unnecessary.
  o  History expansion is disabled in single-quoted strings, like other
     forms of expansion -- hence exclamation marks there should not be
     backslashed.
  o  The `$HISTCHARS' variable is now `$histchars'.  Currently both
     are tied together for compatibility.
  o  The PROMPT_SUBST option now performs backquote expansion -- hence
     you should quote these in prompts.  (SPROMPT has changed as a result.)
  o  Quoting in prompts has changed: close parentheses inside ternary
     expressions should be quoted with a %; history is now %!, not
     !.  Backslashes are no longer special.

5.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@math.gatech.edu

  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.

  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@math.gatech.edu

  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,

    zsh-announce@math.gatech.edu

  (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@math.gatech.edu

  with the *subject* line (this is a change from the old list)

    subscribe <your-email-address>

  e.g.

    Subject:  subscribe P.Stephenson@swansea.ac.uk

  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
  coleman@math.gatech.edu.

  The list from May 1992 to May 1995 is archived in
    ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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.

5.3: What's on the wish-list?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  o  Loadable module support (will be in 3.1 but much work still needs doing).
  o  Ksh compatibility could be improved.
  o  Option for glob qualifiers to follow perl syntax (now a traditional item).
  o  Binding of shell functions to key strokes, accessing editing
     buffer from functions, executing zle functions as a command:  now
     under development for 3.1. 
  o  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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.peak.org/zsh/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1997-09-25 12:36 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1997-09-25 12:36 UTC (permalink / raw)
  To: zsh-announce


Archive-Name: unix-faq/shell/zsh
Last-Modified: 1997/09/25
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zshfaq.yo,v 1.10 1997/09/25 12:33:36 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996, 1997 (see end of document)

Changes since last issue:

1.5:  New 3.0.x version imminent
5.1:  Delete `PATH=... builtin' bug
      Mention closure bug and fix
5.3:  Mention zle development

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?

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. What is the difference between `export' and the ALL_EXPORT option?
3.3. How do I turn off spelling correction/globbing for a single command?
3.4. How do I get the meta key to work on my xterm?
3.5. How do I automatically display the directory in my xterm title bar?
3.6. How do I make the completion list use eight bit characters?
3.7. Why does my terminal act funny in some way?
3.8. Why does zsh not work in an Emacs shell mode any more?
3.9. Why do my autoloaded functions not autoload [the first time]?
3.10. How does base arithmetic work?
3.11. How do I get a newline in my prompt?
3.12. Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
3.13. Why can't I bind \C-s and \C-q any more?
3.14. How do I execute command `foo' within function `foo'?
3.15. Why do history substitutions with single bangs do something funny?
3.16. Why does zsh kill off all my background jobs when I logout?
3.17. How do I list all my history entries?
3.18. How does the alternative loop syntax, e.g. `while {...} {...}' work?

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 get started with programmable completion?
4.5. And if programmable completion isn't good enough?

Chapter 5:  The future of zsh
5.1. What bugs are currently known and unfixed? (Plus recent important changes)
5.2. Where do I report bugs, get more info / who's working on zsh?
5.3. What's on the wish-list?

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://www.peak.org/zsh/ (note the change of address from the
  end of April 1997).  The server provides this FAQ and much else and is
  now maintained by Timothy Luoma.  The FAQ is at
  http://www.peak.org/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 1.6.

  (As a 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 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); it's 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 globbing (compctl -g),
    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,
    o  variable, editing function and option name completion,
    o  inline expansion of variables, 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 arithmetic.
  o  Manipulation of arrays (including reverse subscripting).
  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 Etc/MACHINES in the distribution has more details.

  There are also now separate ports for Windows and OS/2, see `Where
  do I get it' 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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question
  5.2).  Changes based on version 2.5 are very unlikely to
  be useful.

  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 Etc/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 make 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 3.0.5 is in test and is expected to appear within days. The new
  major number 3.0 largely reflects the considerable internal changes
  in zsh to make it more reliable, consistent and (where possible)
  compatible.  Those planning on upgrading their zsh installation
  should take a look at the list of incompatibilities at the end of
  5.1.  This is longer than usual due to enhanced sh, ksh
  and POSIX compatibility.

  The beta version 3.1.2 has also been 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 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 (most recently) to provide POSIX compliancy.

1.6: Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.  The
  following are known mirrors (kept frequently up to date); the first
  is the official archive site.  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.

    Hungary   ftp://ftp.cs.elte.hu/pub/zsh/
              (also http://www.cs.elte.hu/pub/zsh/ )
    Australia ftp://ftp.ips.gov.au/mirror/zsh/
    Finland   ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France    ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany   ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
              ftp://ftp.gmd.de/packages/zsh/
              ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Japan     ftp://ftp.tohoku.ac.jp/mirror/zsh/
              ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway    ftp://ftp.uit.no/pub/unix/shells/zsh/
    Slovenia  ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden    ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK        ftp://ftp.net.lut.ac.uk/zsh/
              (also by FSP at port 21)
    USA       ftp://ftp.math.gatech.edu/pub/zsh/
              ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
              ftp://ftp.sterling.com/zsh/
              ftp://ftp.rge.com/pub/shells/zsh/

  The Windows port mentioned above is maintained separately by Amol
  Deshpande <amold@microsoft.com>; please mail Amol directly about any
  Windows-specific problems.  This is quite new, so don't expect it to
  be perfect.  You can get it from:

            ftp://ftp.blarg.net/users/amol/zsh  

  Likewise the OS/2 port is available from TAMURA Kent
  <kent@tril.ibm.co.jp at

            http://cgi.din.or.jp/~tkent/tmp/zsh-3.0.0-os2-a01.zip

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 with 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 --- 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 commands
     `emulate sh; setopt localoptions' in a shell function will
     turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in 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_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_BUILTINS,
  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 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', 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.
        The KSH_ARRAYS option is now available.
    o   Coprocesses are established by `coproc'; `|&' behaves like
        csh. 

  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.
        (GLOB_SUBST has been added to fix this.)
    o   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.)
    o * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    o   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.

      [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 `**'.
    o   Unquoted assignments do file expansion after `:'s (intended for
        PATHs). 
    o   `integer' does not allow `-i'.

  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  Traps and signals:

    o   Traps are not local to functions.
    o   TRAPERR has become TRAPZERR (this was forced by UNICOS which
        has SIGERR).

  o  Editing:

    o   The options emacs, gmacs, viraw are not supported.
        Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
        becomes `bindkey -{e,v}'; 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' will not be in the next ksh
        release either.)
    o   Management of histories in multiple shells is different:
        the history list is not saved and restored after each command.
    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  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   `read' has no `-s' flag.
    o   In `let "i = foo"', foo is evaluated as a number, not an
        expression (although in `let "i = $foo"' +it is treated as an
        expression). 

  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" 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 shwordsplit and ksharrays 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         "$@"            ($*: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.

  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.

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,
  $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 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.

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.

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.

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.)  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 `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 shwordsplit.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.

3.2: 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.3: 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.4: 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.

3.5: 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 a sun-cmd.

  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) 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.6: How do I make the completion list use eight bit characters?

  A traditional UNIX environment (character terminal and ASCII
  character sets) is not sufficient to be able to handle non-ASCII
  characters, and there are so many possible enhancements that in
  general this is hard.  However, if you have something like an xterm
  using a standard character set like ISO-8859-1 (which is often the
  default for xterm), read on.  You should also note question
  3.4 on the subject of eight bit characters.

  You are probably creating files with names including non-ASCII
  accented characters, and find they show up in the completion list as
  \M-i or something such.  This is because the library routines
  (not zsh itself) which test whether a character is printable have
  replied that it is not; zsh has simply found a way to show them
  anyway.

  The answer, under a modern POSIXy operating system, is to find a
  locale where these are treated as printable characters.  Zsh has
  handling for locales built in and will recognise when you set a
  relevant variable. You need to look in /usr/lib/locale to find one
  which suits you; the subdirectories correspond to the locale names.
  The simplest possibility is likely to be en_US, so that the simplest
  answer to your problem is to set

    LC_CTYPE=en_US

  when your terminal is capable of showing eight bit characters.  If
  you only have a default domain (called C), you may need to have some
  additional files installed on your system.

3.7: 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.

3.8: 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" "~/bin/eshell")

  to ~/.emacs.

3.9: 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 KSHAUTOLOAD 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.10: 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 now supported).  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.

3.11: 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 :-).  Otherwise, you can use

    PROMPT=$(print "Hi Joe,\nwhat now?%# ")

  in your initialisation file.

3.12: 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.13: 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.

3.14: 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.15: 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.16: 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.

3.17: 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.18: 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.

Chapter 4: 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.

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.

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 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
  (or something else you can execute, like a builtin comman, a
  function or an alias) and tries 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 4.4.)

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 your 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 nobeep set, that annoying beep goes away
   o  with nolistbeep, beeping is only turned off for ambiguous completions
   o  with autolist set, when the completion is ambiguous you get a
      list without having to type \C-D
   o  with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
   o  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
   o  with automenu, you only get the menu behaviour when you hit TAB
      again on the ambiguous completion.

  Combinations of these are possible; for example, autolist and
  automenu together give an intuitive combination. 

4.4: 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 4.2),
  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):

   1) 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',
   2) 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 `-',
   3) 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.

4.5: 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.

Chapter 5: The future of zsh

5.1: What bugs are currently known and unfixed? (Plus recent important changes)

  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 2.1; 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.

  o  `time' is ignored with builtins and can't be used with `{...}'.
  o  `set -x' (`setopt xtrace') still has a few glitches.
  o  The `:q' and `:x' modifiers don't work for variables.
  o  In vi mode, `u' can go past the original modification point.
  o  The singlelinezle option has problems with prompts containing escapes.
  o  The `r' command does not work inside `$(...)' or ``...`'
     expansions. 
  o  `typeset' handling is non-optimal, particularly with regard to
     flags, and is ksh-incompatible in unpredictable ways. 
  o  Nested closures in extended globbing and pattern matching, such as

    [[ fofo = (fo#)# ]]

     are not correctly handled (this will be fixed in version 3.1).

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes after zsh 3.0 (3.1.x is still currently in beta):

  o  history-search-{forward,backward} (bound to \M-n, \M-p)
     now only find previous lines where the first word is the same as the
     current one.  For example,

      comp<ESC>p

     will find lines in the history like `comp -edit emacs', but not
     `compress file' any more.  For an approximation to the old
     behaviour, use history-beginning-search-{forward,backward} which
     search for a line with the same prefix up to the cursor position.
  o  In vi insert mode, the cursor keys no longer work.  The following
     will bind them:

       bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \ 
                      '^[[A' up-line-or-history '^[[B' down-line-or-history

     (unless your terminal requires `^[O' instead of `^[[').  The
     rationale is that the insert mode and command mode keymaps for
     keys with prefixes are now separate.

  Changes since zsh 2.5:

  o  The left hand of an assignment is no longer substituted.  Thus,
     `$1=$2' will not work.  You can use something like `eval
     "$1=\$2"', which should have the identical effect.
  o  Signal traps established with the `trap' builtin are now called with
     the environment of the caller, instead of as a new function level,
     as in ksh.  Traps established as functions (e.g. `TRAPINT()
     {...}') work as before.
  o  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
     to be the other way around.  (Use of names rather than letters is
     generally recommended.)
  o  `[[' is a reserved word, hence must be separated from
     other characters by whitespace; `{' and `}' are also reserved
     words if the IGNORE_BRACES option is set.
  o  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
     always does what it looks like it does, so `if ( ... ) ...'
     executes the code in parentheses in a subshell.  To make this
     useful, the syntax expected after an `if', etc., is less strict
     than in other shells.
  o  Mytt(foo=*) does not perform globbing immediately on the right
     hand side of the assignment; the old behaviour now requires the
     option GLOB_ASSIGN.  (`foo=(*)' is and has always been the
     consistent way of doing this.)
  o  <> performs redirection of input and output to the specified file.
     For numeric globs, you now need <->.
  o  The command line qualifiers exec, noglob, command,
     - are now treated more like builtin commands:  previously they were
     syntactically special.  This should make it easier to perform tricks with
     them (disabling, hiding in parameters, etc.).
  o  The pushd builtin has been rewritten for compatibility with other
     shells.  The old behavour can be achieved with a shell function.
  o  The current version now uses ~'s for directory stack substitution
     instead of ='s.  This is for consistency:  all other directory
     substitution (~user, ~name, ~+, ...) used a tilde, while
     =<number> caused problems with =program substitution.
  o  The `HISTLIT' option was broken in various ways and has been removed:
     the rewritten history mechanism doesn't alter history lines, making
     the option unnecessary.
  o  History expansion is disabled in single-quoted strings, like other
     forms of expansion -- hence exclamation marks there should not be
     backslashed.
  o  The `$HISTCHARS' variable is now `$histchars'.  Currently both
     are tied together for compatibility.
  o  The PROMPT_SUBST option now performs backquote expansion -- hence
     you should quote these in prompts.  (SPROMPT has changed as a result.)
  o  Quoting in prompts has changed: close parentheses inside ternary
     expressions should be quoted with a %; history is now %!, not
     !.  Backslashes are no longer special.

5.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@math.gatech.edu

  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.

  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@math.gatech.edu

  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,

    zsh-announce@math.gatech.edu

  (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@math.gatech.edu

  with the *subject* line (this is a change from the old list)

    subscribe <your-email-address>

  e.g.

    Subject:  subscribe P.Stephenson@swansea.ac.uk

  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
  coleman@math.gatech.edu.

  The list from May 1992 to May 1995 is archived in
    ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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.

5.3: What's on the wish-list?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  o  Loadable module support (will be in 3.1 but much work still needs doing).
  o  Ksh compatibility could be improved.
  o  Option for glob qualifiers to follow perl syntax (now a traditional item).
  o  Binding of shell functions to key strokes, accessing editing
     buffer from functions, executing zle functions as a command:  now
     under development for 3.1. 
  o  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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.peak.org/zsh/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1997-09-03  8:09 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1997-09-03  8:09 UTC (permalink / raw)
  To: zsh-announce


Archive-Name: unix-faq/shell/zsh
Last-Modified: 1997/09/03
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zshfaq.yo,v 1.9 1997/09/03 08:07:18 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996, 1997 (see end of document)

Changes since last issue:

1.4,1.6:  Mention Windows and OS/2 versions
3.9:      Rewrote explanation of autoload problems

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?

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. What is the difference between `export' and the ALL_EXPORT option?
3.3. How do I turn off spelling correction/globbing for a single command?
3.4. How do I get the meta key to work on my xterm?
3.5. How do I automatically display the directory in my xterm title bar?
3.6. How do I make the completion list use eight bit characters?
3.7. Why does my terminal act funny in some way?
3.8. Why does zsh not work in an Emacs shell mode any more?
3.9. Why do my autoloaded functions not autoload [the first time]?
3.10. How does base arithmetic work?
3.11. How do I get a newline in my prompt?
3.12. Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
3.13. Why can't I bind \C-s and \C-q any more?
3.14. How do I execute command `foo' within function `foo'?
3.15. Why do history substitutions with single bangs do something funny?
3.16. Why does zsh kill off all my background jobs when I logout?
3.17. How do I list all my history entries?
3.18. How does the alternative loop syntax, e.g. `while {...} {...}' work?

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 get started with programmable completion?
4.5. And if programmable completion isn't good enough?

Chapter 5:  The future of zsh
5.1. What bugs are currently known and unfixed? (Plus recent important changes)
5.2. Where do I report bugs, get more info / who's working on zsh?
5.3. What's on the wish-list?

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://www.peak.org/zsh/ (note the change of address from the
  end of April 1997).  The server provides this FAQ and much else and is
  now maintained by Timothy Luoma.  The FAQ is at
  http://www.peak.org/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 1.6.

  (As a 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 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); it's 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 globbing (compctl -g),
    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,
    o  variable, editing function and option name completion,
    o  inline expansion of variables, 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 arithmetic.
  o  Manipulation of arrays (including reverse subscripting).
  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 Etc/MACHINES in the distribution has more details.

  There are also now separate ports for Windows and OS/2, see `Where
  do I get it' 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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question
  5.2).  Changes based on version 2.5 are very unlikely to
  be useful.

  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 Etc/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 make 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 3.0.4 has now been released. The new major number 3.0 largely
  reflects the considerable internal changes in zsh to make it more
  reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of 5.1.  This is longer
  than usual due to enhanced sh, ksh and POSIX compatibility.

  The beta version 3.1.2 has also been 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 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 (most recently) to provide POSIX compliancy.

1.6: Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.  The
  following are known mirrors (kept frequently up to date); the first
  is the official archive site.  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.

    Hungary   ftp://ftp.cs.elte.hu/pub/zsh/
              (also http://www.cs.elte.hu/pub/zsh/ )
    Australia ftp://ftp.ips.gov.au/mirror/zsh/
    Finland   ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France    ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany   ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
              ftp://ftp.gmd.de/packages/zsh/
              ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Japan     ftp://ftp.tohoku.ac.jp/mirror/zsh/
              ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway    ftp://ftp.uit.no/pub/unix/shells/zsh/
    Slovenia  ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden    ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK        ftp://ftp.net.lut.ac.uk/zsh/
              (also by FSP at port 21)
    USA       ftp://ftp.math.gatech.edu/pub/zsh/
              ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
              ftp://ftp.sterling.com/zsh/
              ftp://ftp.rge.com/pub/shells/zsh/

  The Windows port mentioned above is maintained separately by Amol
  Deshpande <amol@microsoft.com>; please mail Amol directly about any
  Windows-specific problems.  This is quite new, so don't expect it to
  be perfect.  You can get it from:

            ftp://ftp.blarg.net/users/amol/zsh  

  Likewise the OS/2 port is available from TAMURA Kent
  <kent@tril.ibm.co.jp at

            http://cgi.din.or.jp/~tkent/tmp/zsh-3.0.0-os2-a01.zip

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 with 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 --- 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 commands
     `emulate sh; setopt localoptions' in a shell function will
     turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in 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_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_BUILTINS,
  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 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', 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.
        The KSH_ARRAYS option is now available.
    o   Coprocesses are established by `coproc'; `|&' behaves like
        csh. 

  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.
        (GLOB_SUBST has been added to fix this.)
    o   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.)
    o * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    o   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.

      [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 `**'.
    o   Unquoted assignments do file expansion after `:'s (intended for
        PATHs). 
    o   `integer' does not allow `-i'.

  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  Traps and signals:

    o   Traps are not local to functions.
    o   TRAPERR has become TRAPZERR (this was forced by UNICOS which
        has SIGERR).

  o  Editing:

    o   The options emacs, gmacs, viraw are not supported.
        Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
        becomes `bindkey -{e,v}'; 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' will not be in the next ksh
        release either.)
    o   Management of histories in multiple shells is different:
        the history list is not saved and restored after each command.
    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  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   `read' has no `-s' flag.
    o   In `let "i = foo"', foo is evaluated as a number, not an
        expression (although in `let "i = $foo"' +it is treated as an
        expression). 

  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" 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 shwordsplit and ksharrays 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         "$@"            ($*: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.

  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.

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,
  $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 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.

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.

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.

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.)  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 `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 shwordsplit.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.

3.2: 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.3: 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.4: 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.

3.5: 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 a sun-cmd.

  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) 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.6: How do I make the completion list use eight bit characters?

  A traditional UNIX environment (character terminal and ASCII
  character sets) is not sufficient to be able to handle non-ASCII
  characters, and there are so many possible enhancements that in
  general this is hard.  However, if you have something like an xterm
  using a standard character set like ISO-8859-1 (which is often the
  default for xterm), read on.  You should also note question
  3.4 on the subject of eight bit characters.

  You are probably creating files with names including non-ASCII
  accented characters, and find they show up in the completion list as
  \M-i or something such.  This is because the library routines
  (not zsh itself) which test whether a character is printable have
  replied that it is not; zsh has simply found a way to show them
  anyway.

  The answer, under a modern POSIXy operating system, is to find a
  locale where these are treated as printable characters.  Zsh has
  handling for locales built in and will recognise when you set a
  relevant variable. You need to look in /usr/lib/locale to find one
  which suits you; the subdirectories correspond to the locale names.
  The simplest possibility is likely to be en_US, so that the simplest
  answer to your problem is to set

    LC_CTYPE=en_US

  when your terminal is capable of showing eight bit characters.  If
  you only have a default domain (called C), you may need to have some
  additional files installed on your system.

3.7: 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.

3.8: 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" "~/bin/eshell")

  to ~/.emacs.

3.9: 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 KSHAUTOLOAD 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.10: 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 now supported).  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.

3.11: 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 :-).  Otherwise, you can use

    PROMPT=$(print "Hi Joe,\nwhat now?%# ")

  in your initialisation file.

3.12: 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.13: 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.

3.14: 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.15: 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.16: 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.

3.17: 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.18: 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.

Chapter 4: 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.

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.

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 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
  (or something else you can execute, like a builtin comman, a
  function or an alias) and tries 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 4.4.)

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 your 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 nobeep set, that annoying beep goes away
   o  with nolistbeep, beeping is only turned off for ambiguous completions
   o  with autolist set, when the completion is ambiguous you get a
      list without having to type \C-D
   o  with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
   o  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
   o  with automenu, you only get the menu behaviour when you hit TAB
      again on the ambiguous completion.

  Combinations of these are possible; for example, autolist and
  automenu together give an intuitive combination. 

4.4: 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 4.2),
  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):

   1) 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',
   2) 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 `-',
   3) 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.

4.5: 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.

Chapter 5: The future of zsh

5.1: What bugs are currently known and unfixed? (Plus recent important changes)

  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 2.1; 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.

  o  Special variables won't be unset after e.g. `PATH=... read ...',
     i.e. if used with a builtin command or shell function.
     (According to POSIX, this is not a bug with `special' builtins.)
  o  `time' is ignored with builtins and can't be used with `{...}'.
  o  `set -x' (`setopt xtrace') still has a few glitches.
  o  The `:q' and `:x' modifiers don't work for variables.
  o  In vi mode, `u' can go past the original modification point.
  o  The singlelinezle option has problems with prompts containing escapes.
  o  The `r' command does not work inside `$(...)' or ``...`'
     expansions. 
  o  `typeset' handling is non-optimal, particularly with regard to
     flags, and is ksh-incompatible in unpredictable ways. 

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes after zsh 3.0 (3.1.x is still currently in beta):

  o  history-search-{forward,backward} (bound to \M-n, \M-p)
     now only find previous lines where the first word is the same as the
     current one.  For example,

      comp<ESC>p

     will find lines in the history like `comp -edit emacs', but not
     `compress file' any more.  For an approximation to the old
     behaviour, use history-beginning-search-{forward,backward} which
     search for a line with the same prefix up to the cursor position.
  o  In vi insert mode, the cursor keys no longer work.  The following
     will bind them:

       bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \ 
                      '^[[A' up-line-or-history '^[[B' down-line-or-history

     (unless your terminal requires `^[O' instead of `^[[').  The
     rationale is that the insert mode and command mode keymaps for
     keys with prefixes are now separate.

  Changes since zsh 2.5:

  o  The left hand of an assignment is no longer substituted.  Thus,
     `$1=$2' will not work.  You can use something like `eval
     "$1=\$2"', which should have the identical effect.
  o  Signal traps established with the `trap' builtin are now called with
     the environment of the caller, instead of as a new function level,
     as in ksh.  Traps established as functions (e.g. `TRAPINT()
     {...}') work as before.
  o  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
     to be the other way around.  (Use of names rather than letters is
     generally recommended.)
  o  `[[' is a reserved word, hence must be separated from
     other characters by whitespace; `{' and `}' are also reserved
     words if the IGNORE_BRACES option is set.
  o  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
     always does what it looks like it does, so `if ( ... ) ...'
     executes the code in parentheses in a subshell.  To make this
     useful, the syntax expected after an `if', etc., is less strict
     than in other shells.
  o  On the other hand, `foo=*' does not perform globbing immediately on
     the right hand side of the assignment; the old behaviour now
     requires the option GLOB_ASSIGN.  (`foo=(*)' is and has always
     been the consistent way of doing this.)
  o  <> performs redirection of input and output to the specified file.
     For numeric globs, you now need <->.
  o  The command line qualifiers exec, noglob, command,
     - are now treated more like builtin commands:  previously they were
     syntactically special.  This should make it easier to perform tricks with
     them (disabling, hiding in parameters, etc.).
  o  The pushd builtin has been rewritten for compatibility with other
     shells.  The old behavour can be achieved with a shell function.
  o  The current version now uses ~'s for directory stack substitution
     instead of ='s.  This is for consistency:  all other directory
     substitution (~user, ~name, ~+, ...) used a tilde, while
     =<number> caused problems with =program substitution.
  o  The `HISTLIT' option was broken in various ways and has been removed:
     the rewritten history mechanism doesn't alter history lines, making
     the option unnecessary.
  o  History expansion is disabled in single-quoted strings, like other
     forms of expansion -- hence exclamation marks there should not be
     backslashed.
  o  The `$HISTCHARS' variable is now `$histchars'.  Currently both
     are tied together for compatibility.
  o  The PROMPT_SUBST option now performs backquote expansion -- hence
     you should quote these in prompts.  (SPROMPT has changed as a result.)
  o  Quoting in prompts has changed: close parentheses inside ternary
     expressions should be quoted with a %; history is now %!, not
     !.  Backslashes are no longer special.

5.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@math.gatech.edu

  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.

  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@math.gatech.edu

  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,

    zsh-announce@math.gatech.edu

  (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@math.gatech.edu

  with the *subject* line (this is a change from the old list)

    subscribe <your-email-address>

  e.g.

    Subject:  subscribe P.Stephenson@swansea.ac.uk

  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
  coleman@math.gatech.edu.

  The list from May 1992 to May 1995 is archived in
    ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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.

5.3: What's on the wish-list?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  o  Loadable module support (will be in 3.1 but much work still needs doing).
  o  Ksh compatibility could be improved.
  o  Option for glob qualifiers to follow perl syntax (now a traditional item).
  o  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.
  o  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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.peak.org/zsh/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1997-07-28 10:00 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1997-07-28 10:00 UTC (permalink / raw)
  To: zsh-announce


Archive-Name: unix-faq/shell/zsh
Last-Modified: 1997/07/28
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zshfaq.yo,v 1.8 1997/07/28 09:58:28 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996, 1997 (see end of document)

Changes since last issue:

1.5:      Latest versions.
3.6:      Rewritten to make clearer.
5.2:      Improved description of zsh-workers list.

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?

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. What is the difference between `export' and the ALL_EXPORT option?
3.3. How do I turn off spelling correction/globbing for a single command?
3.4. How do I get the meta key to work on my xterm?
3.5. How do I automatically display the directory in my xterm title bar?
3.6. How do I make the completion list use eight bit characters?
3.7. Why does my terminal act funny in some way?
3.8. Why does zsh not work in an Emacs shell mode any more?
3.9. Why do my autoloaded functions not autoload [the first time]?
3.10. How does base arithmetic work?
3.11. How do I get a newline in my prompt?
3.12. Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
3.13. Why can't I bind \C-s and \C-q any more?
3.14. How do I execute command `foo' within function `foo'?
3.15. Why do history substitutions with single bangs do something funny?
3.16. Why does zsh kill off all my background jobs when I logout?
3.17. How do I list all my history entries?
3.18. How does the alternative loop syntax, e.g. `while {...} {...}' work?

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 get started with programmable completion?
4.5. And if programmable completion isn't good enough?

Chapter 5:  The future of zsh
5.1. What bugs are currently known and unfixed? (Plus recent important changes)
5.2. Where do I report bugs, get more info / who's working on zsh?
5.3. What's on the wish-list?

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://www.peak.org/zsh/ (note the change of address from the
  end of April 1997).  The server provides this FAQ and much else and is
  now maintained by Timothy Luoma.  The FAQ is at http://www.peak.org/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 1.6.

  (As a 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 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); it's 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 globbing (compctl -g),
    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,
    o  variable, editing function and option name completion,
    o  inline expansion of variables, 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 arithmetic.
  o  Manipulation of arrays (including reverse subscripting).
  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 Etc/MACHINES in the distribution has more details.

  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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question
  5.2).  Changes based on version 2.5 are very unlikely to
  be useful.

  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 Etc/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 make 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 3.0.4 has now been released. The new major number 3.0 largely
  reflects the considerable internal changes in zsh to make it more
  reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of 5.1.  This is longer
  than usual due to enhanced sh, ksh and POSIX compatibility.

  The beta version 3.1.2 has also been 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 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 (most recently) to provide POSIX compliancy.

1.6: Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.  The
  following are known mirrors (kept frequently up to date); the first
  is the official archive site.  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.

    Hungary   ftp://ftp.cs.elte.hu/pub/zsh/
              (also http://www.cs.elte.hu/pub/zsh/ )
    Australia ftp://ftp.ips.gov.au/mirror/zsh/
    Finland   ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France    ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany   ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
              ftp://ftp.gmd.de/packages/zsh/
              ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Japan     ftp://ftp.tohoku.ac.jp/mirror/zsh/
              ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway    ftp://ftp.uit.no/pub/unix/shells/zsh/
    Slovenia  ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden    ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK        ftp://ftp.net.lut.ac.uk/zsh/
              (also by FSP at port 21)
    USA       ftp://ftp.math.gatech.edu/pub/zsh/
              ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
              ftp://ftp.sterling.com/zsh/
              ftp://ftp.rge.com/pub/shells/zsh/

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 with 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 --- 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 commands
     `emulate sh; setopt localoptions' in a shell function will
     turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in 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_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_BUILTINS,
  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 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', 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.
        The KSH_ARRAYS option is now available.
    o   Coprocesses are established by `coproc'; `|&' behaves like
        csh. 

  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.
        (GLOB_SUBST has been added to fix this.)
    o   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.)
    o * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    o   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.

      [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 `**'.
    o   Unquoted assignments do file expansion after `:'s (intended for
        PATHs). 
    o   `integer' does not allow `-i'.

  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  Traps and signals:

    o   Traps are not local to functions.
    o   TRAPERR has become TRAPZERR (this was forced by UNICOS which
        has SIGERR).

  o  Editing:

    o   The options emacs, gmacs, viraw are not supported.
        Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
        becomes `bindkey -{e,v}'; 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' will not be in the next ksh
        release either.)
    o   Management of histories in multiple shells is different:
        the history list is not saved and restored after each command.
    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  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   `read' has no `-s' flag.
    o   In `let "i = foo"', foo is evaluated as a number, not an
        expression (although in `let "i = $foo"' +it is treated as an
        expression). 

  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" 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 shwordsplit and ksharrays 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         "$@"            ($*: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.

  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.

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,
  $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 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.

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.

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.

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.)  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 `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 shwordsplit.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.

3.2: 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.3: 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.4: 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.

3.5: 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 a sun-cmd.

  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) 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.6: How do I make the completion list use eight bit characters?

  A traditional UNIX environment (character terminal and ASCII
  character sets) is not sufficient to be able to handle non-ASCII
  characters, and there are so many possible enhancements that in
  general this is hard.  However, if you have something like an xterm
  using a standard character set like ISO-8859-1 (which is often the
  default for xterm), read on.  You should also note question
  3.4 on the subject of eight bit characters.

  You are probably creating files with names including non-ASCII
  accented characters, and find they show up in the completion list as
  \M-i or something such.  This is because the library routines
  (not zsh itself) which test whether a character is printable have
  replied that it is not; zsh has simply found a way to show them
  anyway.

  The answer, under a modern POSIXy operating system, is to find a
  locale where these are treated as printable characters.  Zsh has
  handling for locales built in and will recognise when you set a
  relevant variable. You need to look in /usr/lib/locale to find one
  which suits you; the subdirectories correspond to the locale names.
  The simplest possibility is likely to be en_US, so that the simplest
  answer to your problem is to set

    LC_CTYPE=en_US

  when your terminal is capable of showing eight bit characters.  If
  you only have a default domain (called C), you may need to have some
  additional files installed on your system.

3.7: 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.

3.8: 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" "~/bin/eshell")

  to ~/.emacs.

3.9: Why do my autoloaded functions not autoload [the first time]?

  (Before version 3.0, autoloading in the Korn shell way was not
  allowed; this article is now a historical artefact and will
  eventually be removed.  Note, however, that the old form of
  autoloading is still allowed and there are no plans to remove it.)

  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.)

3.10: 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 now supported).  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.

3.11: 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 :-).  Otherwise, you can use

    PROMPT=$(print "Hi Joe,\nwhat now?%# ")

  in your initialisation file.

3.12: 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.13: 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.

3.14: 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.15: 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.16: 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.

3.17: 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.18: 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.

Chapter 4: 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.

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.

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 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
  (or something else you can execute, like a builtin comman, a
  function or an alias) and tries 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 4.4.)

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 your 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 nobeep set, that annoying beep goes away
   o  with nolistbeep, beeping is only turned off for ambiguous completions
   o  with autolist set, when the completion is ambiguous you get a
      list without having to type \C-D
   o  with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
   o  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
   o  with automenu, you only get the menu behaviour when you hit TAB
      again on the ambiguous completion.

  Combinations of these are possible; for example, autolist and
  automenu together give an intuitive combination. 

4.4: 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 4.2),
  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):

   1) 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',
   2) 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 `-',
   3) 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.

4.5: 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.

Chapter 5: The future of zsh

5.1: What bugs are currently known and unfixed? (Plus recent important changes)

  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 2.1; 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.

  o  Special variables won't be unset after e.g. `PATH=... read ...',
     i.e. if used with a builtin command or shell function.
     (According to POSIX, this is not a bug with `special' builtins.)
  o  `time' is ignored with builtins and can't be used with `{...}'.
  o  `set -x' (`setopt xtrace') still has a few glitches.
  o  The `:q' and `:x' modifiers don't work for variables.
  o  In vi mode, `u' can go past the original modification point.
  o  The singlelinezle option has problems with prompts containing escapes.
  o  The `r' command does not work inside `$(...)' or ``...`'
     expansions. 
  o  `typeset' handling is non-optimal, particularly with regard to
     flags, and is ksh-incompatible in unpredictable ways. 

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes after zsh 3.0 (3.1.x is still currently in beta):

  o  history-search-{forward,backward} (bound to \M-n, \M-p)
     now only find previous lines where the first word is the same as the
     current one.  For example,

      comp<ESC>p

     will find lines in the history like `comp -edit emacs', but not
     `compress file' any more.  For an approximation to the old
     behaviour, use history-beginning-search-{forward,backward} which
     search for a line with the same prefix up to the cursor position.
  o  In vi insert mode, the cursor keys no longer work.  The following
     will bind them:

       bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \ 
                      '^[[A' up-line-or-history '^[[B' down-line-or-history

     (unless your terminal requires `^[O' instead of `^[[').  The
     rationale is that the insert mode and command mode keymaps for
     keys with prefixes are now separate.

  Changes since zsh 2.5:

  o  The left hand of an assignment is no longer substituted.  Thus,
     `$1=$2' will not work.  You can use something like `eval
     "$1=\$2"', which should have the identical effect.
  o  Signal traps established with the `trap' builtin are now called with
     the environment of the caller, instead of as a new function level,
     as in ksh.  Traps established as functions (e.g. `TRAPINT()
     {...}') work as before.
  o  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
     to be the other way around.  (Use of names rather than letters is
     generally recommended.)
  o  `[[' is a reserved word, hence must be separated from
     other characters by whitespace; `{' and `}' are also reserved
     words if the IGNORE_BRACES option is set.
  o  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
     always does what it looks like it does, so `if ( ... ) ...'
     executes the code in parentheses in a subshell.  To make this
     useful, the syntax expected after an `if', etc., is less strict
     than in other shells.
  o  On the other hand, `foo=*' does not perform globbing immediately on
     the right hand side of the assignment; the old behaviour now
     requires the option GLOB_ASSIGN.  (`foo=(*)' is and has always
     been the consistent way of doing this.)
  o  <> performs redirection of input and output to the specified file.
     For numeric globs, you now need <->.
  o  The command line qualifiers exec, noglob, command,
     - are now treated more like builtin commands:  previously they were
     syntactically special.  This should make it easier to perform tricks with
     them (disabling, hiding in parameters, etc.).
  o  The pushd builtin has been rewritten for compatibility with other
     shells.  The old behavour can be achieved with a shell function.
  o  The current version now uses ~'s for directory stack substitution
     instead of ='s.  This is for consistency:  all other directory
     substitution (~user, ~name, ~+, ...) used a tilde, while
     =<number> caused problems with =program substitution.
  o  The `HISTLIT' option was broken in various ways and has been removed:
     the rewritten history mechanism doesn't alter history lines, making
     the option unnecessary.
  o  History expansion is disabled in single-quoted strings, like other
     forms of expansion -- hence exclamation marks there should not be
     backslashed.
  o  The `$HISTCHARS' variable is now `$histchars'.  Currently both
     are tied together for compatibility.
  o  The PROMPT_SUBST option now performs backquote expansion -- hence
     you should quote these in prompts.  (SPROMPT has changed as a result.)
  o  Quoting in prompts has changed: close parentheses inside ternary
     expressions should be quoted with a %; history is now %!, not
     !.  Backslashes are no longer special.

5.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@math.gatech.edu

  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.

  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@math.gatech.edu

  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,

    zsh-announce@math.gatech.edu

  (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@math.gatech.edu

  with the *subject* line (this is a change from the old list)

    subscribe <your-email-address>

  e.g.

    Subject:  subscribe P.Stephenson@swansea.ac.uk

  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
  coleman@math.gatech.edu.

  The list from May 1992 to May 1995 is archived in
    ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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.

5.3: What's on the wish-list?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  o  Loadable module support (will be in 3.1 but much work still needs doing).
  o  Ksh compatibility could be improved.
  o  Option for glob qualifiers to follow perl syntax (now a traditional item).
  o  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.
  o  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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.peak.org/zsh/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1997-06-25 13:49 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1997-06-25 13:49 UTC (permalink / raw)
  To: zsh-announce

[Note new question 3.6 on displaying eight bit characters in
completion lists etc., comments welcome --- pws]

Archive-Name: unix-faq/shell/zsh
Last-Modified: 1997/06/25
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zshfaq.yo,v 1.7 1997/06/25 13:45:35 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996, 1997 (see end of document)

Changes since last issue:

1.5:      Latest versions.
3.6:      New question on displaying eight bit characters.

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?

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. What is the difference between `export' and the ALL_EXPORT option?
3.3. How do I turn off spelling correction/globbing for a single command?
3.4. How do I get the meta key to work on my xterm?
3.5. How do I automatically display the directory in my xterm title bar?
3.6. How do I make the completion list use eight bit characters?
3.7. Why does my terminal act funny in some way?
3.8. Why does zsh not work in an Emacs shell mode any more?
3.9. Why do my autoloaded functions not autoload [the first time]?
3.10. How does base arithmetic work?
3.11. How do I get a newline in my prompt?
3.12. Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
3.13. Why can't I bind \C-s and \C-q any more?
3.14. How do I execute command `foo' within function `foo'?
3.15. Why do history substitutions with single bangs do something funny?
3.16. Why does zsh kill off all my background jobs when I logout?
3.17. How do I list all my history entries?
3.18. How does the alternative loop syntax, e.g. `while {...} {...}' work?

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 get started with programmable completion?
4.5. And if programmable completion isn't good enough?

Chapter 5:  The future of zsh
5.1. What bugs are currently known and unfixed? (Plus recent important changes)
5.2. Where do I report bugs, get more info / who's working on zsh?
5.3. What's on the wish-list?

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://www.peak.org/zsh/ (note the change of address from the
  end of April 1997).  The server provides this FAQ and much else and is
  now maintained by Timothy Luoma.  The FAQ is at http://www.peak.org/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 1.6.

  (As a 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 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); it's 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 globbing (compctl -g),
    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,
    o  variable, editing function and option name completion,
    o  inline expansion of variables, 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 arithmetic.
  o  Manipulation of arrays (including reverse subscripting).
  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 Etc/MACHINES in the distribution has more details.

  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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question
  5.2).  Changes based on version 2.5 are very unlikely to
  be useful.

  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 Etc/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 make 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 3.0.4 has now been released. The new major number 3.0 largely
  reflects the considerable internal changes in zsh to make it more
  reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of 5.1.  This is longer
  than usual due to enhanced sh, ksh and POSIX compatibility.

  The beta version 3.1.2 has also been 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 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 (most recently) to provide POSIX compliancy.

1.6: Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.  The
  following are known mirrors (kept frequently up to date); the first
  is the official archive site.  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.

    Hungary   ftp://ftp.cs.elte.hu/pub/zsh/
              (also http://www.cs.elte.hu/pub/zsh/ )
    Australia ftp://ftp.ips.gov.au/mirror/zsh/
    Finland   ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France    ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany   ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
              ftp://ftp.gmd.de/packages/zsh/
              ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Japan     ftp://ftp.tohoku.ac.jp/mirror/zsh/
              ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway    ftp://ftp.uit.no/pub/unix/shells/zsh/
    Slovenia  ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden    ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK        ftp://ftp.net.lut.ac.uk/zsh/
              (also by FSP at port 21)
    USA       ftp://ftp.math.gatech.edu/pub/zsh/
              ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
              ftp://ftp.sterling.com/zsh/
              ftp://ftp.rge.com/pub/shells/zsh/

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 with 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 --- 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 commands
     `emulate sh; setopt localoptions' in a shell function will
     turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in 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_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_BUILTINS,
  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 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', 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.
        The KSH_ARRAYS option is now available.
    o   Coprocesses are established by `coproc'; `|&' behaves like
        csh. 

  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.
        (GLOB_SUBST has been added to fix this.)
    o   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.)
    o * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    o   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.

      [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 `**'.
    o   Unquoted assignments do file expansion after `:'s (intended for
        PATHs). 
    o   `integer' does not allow `-i'.

  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  Traps and signals:

    o   Traps are not local to functions.
    o   TRAPERR has become TRAPZERR (this was forced by UNICOS which
        has SIGERR).

  o  Editing:

    o   The options emacs, gmacs, viraw are not supported.
        Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
        becomes `bindkey -{e,v}'; 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' will not be in the next ksh
        release either.)
    o   Management of histories in multiple shells is different:
        the history list is not saved and restored after each command.
    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  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   `read' has no `-s' flag.
    o   In `let "i = foo"', foo is evaluated as a number, not an
        expression (although in `let "i = $foo"' +it is treated as an
        expression). 

  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" 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 shwordsplit and ksharrays 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         "$@"            ($*: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.

  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.

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,
  $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 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.

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.

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.

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.)  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 `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 shwordsplit.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.

3.2: 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.3: 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.4: 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.

3.5: 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 a sun-cmd.

  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) 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.6: How do I make the completion list use eight bit characters?

  You are probably creating files with non-ASCII characters, such as
  accented characters, and find they show up in the completion list as
  \M-i or something such.  This is because the library routines
  (not zsh itself) which test whether a character is printable have
  replied that it is not; zsh has simply found a way to show them
  anyway.

  The answer, under a modern POSIXy operating system, is to find a
  locale where these are treated as printable characters.  Zsh has
  handling for locales built in and will recognise when you set a
  relevant variable. You need to look in /usr/lib/locale to find one
  which suits you; the subdirectories correspond to the locale names.
  The simplest possibility is likely to be en_US, so that the simplest
  answer to your problem is to set

    LC_CTYPE=en_US

  when your terminal is capable of showing eight bit characters.  If
  you only have a default domain (called C), you may need to have some
  additional files installed on your system.

3.7: 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.

3.8: 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" "~/bin/eshell")

  to ~/.emacs.

3.9: Why do my autoloaded functions not autoload [the first time]?

  (Before version 3.0, autoloading in the Korn shell way was not
  allowed; this article is now a historical artefact and will
  eventually be removed.  Note, however, that the old form of
  autoloading is still allowed and there are no plans to remove it.)

  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.)

3.10: 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 now supported).  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.

3.11: 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 :-).  Otherwise, you can use

    PROMPT=$(print "Hi Joe,\nwhat now?%# ")

  in your initialisation file.

3.12: 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.13: 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.

3.14: 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.15: 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.16: 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.

3.17: 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.18: 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.

Chapter 4: 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.

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.

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 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
  (or something else you can execute, like a builtin comman, a
  function or an alias) and tries 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 4.4.)

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 your 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 nobeep set, that annoying beep goes away
   o  with nolistbeep, beeping is only turned off for ambiguous completions
   o  with autolist set, when the completion is ambiguous you get a
      list without having to type \C-D
   o  with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
   o  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
   o  with automenu, you only get the menu behaviour when you hit TAB
      again on the ambiguous completion.

  Combinations of these are possible; for example, autolist and
  automenu together give an intuitive combination. 

4.4: 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 4.2),
  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):

   1) 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',
   2) 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 `-',
   3) 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.

4.5: 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.

Chapter 5: The future of zsh

5.1: What bugs are currently known and unfixed? (Plus recent important changes)

  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 2.1; 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.

  o  Special variables won't be unset after e.g. `PATH=... read ...',
     i.e. if used with a builtin command or shell function.
     (According to POSIX, this is not a bug with `special' builtins.)
  o  `time' is ignored with builtins and can't be used with `{...}'.
  o  `set -x' (`setopt xtrace') still has a few glitches.
  o  The `:q' and `:x' modifiers don't work for variables.
  o  In vi mode, `u' can go past the original modification point.
  o  The singlelinezle option has problems with prompts containing escapes.
  o  The `r' command does not work inside `$(...)' or ``...`'
     expansions. 
  o  `typeset' handling is non-optimal, particularly with regard to
     flags, and is ksh-incompatible in unpredictable ways. 

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes after zsh 3.0 (3.1.x is still currently in beta):

  o  history-search-{forward,backward} (bound to \M-n, \M-p)
     now only find previous lines where the first word is the same as the
     current one.  For example,

      comp<ESC>p

     will find lines in the history like `comp -edit emacs', but not
     `compress file' any more.  For an approximation to the old
     behaviour, use history-beginning-search-{forward,backward} which
     search for a line with the same prefix up to the cursor position.
  o  In vi insert mode, the cursor keys no longer work.  The following
     will bind them:

       bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \ 
                      '^[[A' up-line-or-history '^[[B' down-line-or-history

     (unless your terminal requires `^[O' instead of `^[[').  The
     rationale is that the insert mode and command mode keymaps for
     keys with prefixes are now separate.

  Changes since zsh 2.5:

  o  The left hand of an assignment is no longer substituted.  Thus,
     `$1=$2' will not work.  You can use something like `eval
     "$1=\$2"', which should have the identical effect.
  o  Signal traps established with the `trap' builtin are now called with
     the environment of the caller, instead of as a new function level,
     as in ksh.  Traps established as functions (e.g. `TRAPINT()
     {...}') work as before.
  o  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
     to be the other way around.  (Use of names rather than letters is
     generally recommended.)
  o  `[[' is a reserved word, hence must be separated from
     other characters by whitespace; `{' and `}' are also reserved
     words if the IGNORE_BRACES option is set.
  o  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
     always does what it looks like it does, so `if ( ... ) ...'
     executes the code in parentheses in a subshell.  To make this
     useful, the syntax expected after an `if', etc., is less strict
     than in other shells.
  o  On the other hand, `foo=*' does not perform globbing immediately on
     the right hand side of the assignment; the old behaviour now
     requires the option GLOB_ASSIGN.  (`foo=(*)' is and has always
     been the consistent way of doing this.)
  o  <> performs redirection of input and output to the specified file.
     For numeric globs, you now need <->.
  o  The command line qualifiers exec, noglob, command,
     - are now treated more like builtin commands:  previously they were
     syntactically special.  This should make it easier to perform tricks with
     them (disabling, hiding in parameters, etc.).
  o  The pushd builtin has been rewritten for compatibility with other
     shells.  The old behavour can be achieved with a shell function.
  o  The current version now uses ~'s for directory stack substitution
     instead of ='s.  This is for consistency:  all other directory
     substitution (~user, ~name, ~+, ...) used a tilde, while
     =<number> caused problems with =program substitution.
  o  The `HISTLIT' option was broken in various ways and has been removed:
     the rewritten history mechanism doesn't alter history lines, making
     the option unnecessary.
  o  History expansion is disabled in single-quoted strings, like other
     forms of expansion -- hence exclamation marks there should not be
     backslashed.
  o  The `$HISTCHARS' variable is now `$histchars'.  Currently both
     are tied together for compatibility.
  o  The PROMPT_SUBST option now performs backquote expansion -- hence
     you should quote these in prompts.  (SPROMPT has changed as a result.)
  o  Quoting in prompts has changed: close parentheses inside ternary
     expressions should be quoted with a %; history is now %!, not
     !.  Backslashes are no longer special.

5.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@math.gatech.edu

  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.

  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@math.gatech.edu

  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,

    zsh-announce@math.gatech.edu

  (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@math.gatech.edu

  with the *subject* line (this is a change from the old list)

    subscribe <your-email-address>

  e.g.

    Subject:  subscribe P.Stephenson@swansea.ac.uk

  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
  coleman@math.gatech.edu.

  The list from May 1992 to May 1995 is archived in
    ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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.

5.3: What's on the wish-list?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  o  Loadable module support (will be in 3.1 but much work still needs doing).
  o  Ksh compatibility could be improved.
  o  Option for glob qualifiers to follow perl syntax (now a traditional item).
  o  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.
  o  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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.peak.org/zsh/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1997-05-29  9:18 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1997-05-29  9:18 UTC (permalink / raw)
  To: zsh-announce


Archive-Name: unix-faq/shell/zsh
Last-Modified: 1997/05/29
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zshfaq.yo,v 1.6 1997/05/29 09:15:00 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996 (see end of document)

Changes since last issue:

1.5:      Latest versions.
1.6:      Mention test versions.

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?

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. What is the difference between `export' and the ALL_EXPORT option?
3.3. How do I turn off spelling correction/globbing for a single command?
3.4. How do I get the meta key to work on my xterm?
3.5. How do I automatically display the directory in my xterm title bar?
3.6. Why does my terminal act funny in some way?
3.7. Why does zsh not work in an Emacs shell mode any more?
3.9. Why do my autoloaded functions not autoload [the first time]?
3.9. How does base arithmetic work?
3.10. How do I get a newline in my prompt?
3.11. Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
3.12. Why can't I bind \C-s and \C-q any more?
3.13. How do I execute command `foo' within function `foo'?
3.14. Why do history substitutions with single bangs do something funny?
3.15. Why does zsh kill off all my background jobs when I logout?
3.16. How do I list all my history entries?
3.17. How does the alternative loop syntax, e.g. `while {...} {...}' work?

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 get started with programmable completion?
4.5. And if programmable completion isn't good enough?

Chapter 5:  The future of zsh
5.1. What bugs are currently known and unfixed? (Plus recent important changes)
5.2. Where do I report bugs, get more info / who's working on zsh?
5.3. What's on the wish-list?

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://www.peak.org/zsh/ (note the change of address from the
  end of April 1997).  The server provides this FAQ and much else and is
  now maintained by Timothy Lumoa.  The FAQ is at http://www.peak.org/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 1.6.

  (As a 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 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); it's 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 globbing (compctl -g),
    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,
    o  variable, editing function and option name completion,
    o  inline expansion of variables, 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 arithmetic.
  o  Manipulation of arrays (including reverse subscripting).
  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 Etc/MACHINES in the distribution has more details.

  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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question
  5.2).  Changes based on version 2.5 are very unlikely to
  be useful.

  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 Etc/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 make 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 3.0.2 has now been released. The new major number 3.0 largely
  reflects the considerable internal changes in zsh to make it more
  reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of 5.1.  This is longer
  than usual due to enhanced sh, ksh and POSIX compatibility.
  Version 3.0.3 is currently in test.

  The beta version 3.1.1 has also been released; 3.1.2 is in test.
  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 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 (most recently) to provide POSIX compliancy.

1.6: Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.  The
  following are known mirrors (kept frequently up to date); the first
  is the official archive site.  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.

    Hungary   ftp://ftp.cs.elte.hu/pub/zsh/
              (also http://www.cs.elte.hu/pub/zsh/ )
    Australia ftp://ftp.ips.gov.au/mirror/zsh/
    Finland   ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France    ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany   ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
              ftp://ftp.gmd.de/packages/zsh/
              ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Japan     ftp://ftp.tohoku.ac.jp/mirror/zsh/
              ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway    ftp://ftp.uit.no/pub/unix/shells/zsh/
    Slovenia  ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden    ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK        ftp://ftp.net.lut.ac.uk/zsh/
              (also by FSP at port 21)
    USA       ftp://ftp.math.gatech.edu/pub/zsh/
              ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
              ftp://ftp.sterling.com/zsh/
              ftp://ftp.rge.com/pub/shells/zsh/

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 with 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 --- 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 commands
     `emulate sh; setopt localoptions' in a shell function will
     turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in 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_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_BUILTINS,
  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 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', 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.
        The KSH_ARRAYS option is now available.
    o   Coprocesses are established by `coproc'; `|&' behaves like
        csh. 

  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.
        (GLOB_SUBST has been added to fix this.)
    o   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.)
    o * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    o   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.

      [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 `**'.
    o   Unquoted assignments do file expansion after `:'s (intended for
        PATHs). 
    o   `integer' does not allow `-i'.

  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  Traps and signals:

    o   Traps are not local to functions.
    o   TRAPERR has become TRAPZERR (this was forced by UNICOS which
        has SIGERR).

  o  Editing:

    o   The options emacs, gmacs, viraw are not supported.
        Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
        becomes `bindkey -{e,v}'; 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' will not be in the next ksh
        release either.)
    o   Management of histories in multiple shells is different:
        the history list is not saved and restored after each command.
    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  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   `read' has no `-s' flag.
    o   In `let "i = foo"', foo is evaluated as a number, not an
        expression (although in `let "i = $foo"' +it is treated as an
        expression). 

  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" 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 shwordsplit and ksharrays 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         "$@"            ($*: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.

  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.

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,
  $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 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.

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.

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.

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.)  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 `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 shwordsplit.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.

3.2: 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.3: 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.4: 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.

3.5: 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 a sun-cmd.

  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) 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.6: 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.

3.7: 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" "~/bin/eshell")

  to ~/.emacs.

3.8: Why do my autoloaded functions not autoload [the first time]?

  (Before version 3.0, autoloading in the Korn shell way was not
  allowed; this article is now a historical artefact and will
  eventually be removed.  Note, however, that the old form of
  autoloading is still allowed and there are no plans to remove it.)

  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.)

3.9: 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 now supported).  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.

3.10: 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 :-).  Otherwise, you can use

    PROMPT=$(print "Hi Joe,\nwhat now?%# ")

  in your initialisation file.

3.11: 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.12: 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.

3.13: 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.14: 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.15: 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.

3.16: 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.17: 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.

Chapter 4: 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.

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.

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 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
  (or something else you can execute, like a builtin comman, a
  function or an alias) and tries 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 4.4.)

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 your 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 nobeep set, that annoying beep goes away
   o  with nolistbeep, beeping is only turned off for ambiguous completions
   o  with autolist set, when the completion is ambiguous you get a
      list without having to type \C-D
   o  with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
   o  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
   o  with automenu, you only get the menu behaviour when you hit TAB
      again on the ambiguous completion.

  Combinations of these are possible; for example, autolist and
  automenu together give an intuitive combination. 

4.4: 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 4.2),
  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):

   1) 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',
   2) 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 `-',
   3) 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.

4.5: 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.

Chapter 5: The future of zsh

5.1: What bugs are currently known and unfixed? (Plus recent important changes)

  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 2.1; 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.

  o  Special variables won't be unset after e.g. `PATH=... read ...',
     i.e. if used with a builtin command or shell function.
     (According to POSIX, this is not a bug with `special' builtins.)
  o  `time' is ignored with builtins and can't be used with `{...}'.
  o  `set -x' (`setopt xtrace') still has a few glitches.
  o  The `:q' and `:x' modifiers don't work for variables.
  o  In vi mode, `u' can go past the original modification point.
  o  The singlelinezle option has problems with prompts containing escapes.
  o  The `r' command does not work inside `$(...)' or ``...`'
     expansions. 
  o  `typeset' handling is non-optimal, particularly with regard to
     flags, and is ksh-incompatible in unpredictable ways. 

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes after zsh 3.0 (3.1.x is still currently in beta):

  o  history-search-{forward,backward} (bound to \M-n, \M-p)
     now only find previous lines where the first word is the same as the
     current one.  For example,

      comp<ESC>p

     will find lines in the history like `comp -edit emacs', but not
     `compress file' any more.  For an approximation to the old
     behaviour, use history-beginning-search-{forward,backward} which
     search for a line with the same prefix up to the cursor position.
  o  In vi insert mode, the cursor keys no longer work.  The following
     will bind them:

       bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \ 
                      '^[[A' up-line-or-history '^[[B' down-line-or-history

     (unless your terminal requires `^[O' instead of `^[[').  The
     rationale is that the insert mode and command mode keymaps for
     keys with prefixes are now separate.

  Changes since zsh 2.5:

  o  The left hand of an assignment is no longer substituted.  Thus,
     `$1=$2' will not work.  You can use something like `eval
     "$1=\$2"', which should have the identical effect.
  o  Signal traps established with the `trap' builtin are now called with
     the environment of the caller, instead of as a new function level,
     as in ksh.  Traps established as functions (e.g. `TRAPINT()
     {...}') work as before.
  o  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
     to be the other way around.  (Use of names rather than letters is
     generally recommended.)
  o  `[[' is a reserved word, hence must be separated from
     other characters by whitespace; `{' and `}' are also reserved
     words if the IGNORE_BRACES option is set.
  o  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
     always does what it looks like it does, so `if ( ... ) ...'
     executes the code in parentheses in a subshell.  To make this
     useful, the syntax expected after an `if', etc., is less strict
     than in other shells.
  o  On the other hand, `foo=*' does not perform globbing immediately on
     the right hand side of the assignment; the old behaviour now
     requires the option GLOB_ASSIGN.  (`foo=(*)' is and has always
     been the consistent way of doing this.)
  o  <> performs redirection of input and output to the specified file.
     For numeric globs, you now need <->.
  o  The command line qualifiers exec, noglob, command,
     - are now treated more like builtin commands:  previously they were
     syntactically special.  This should make it easier to perform tricks with
     them (disabling, hiding in parameters, etc.).
  o  The pushd builtin has been rewritten for compatibility with other
     shells.  The old behavour can be achieved with a shell function.
  o  The current version now uses ~'s for directory stack substitution
     instead of ='s.  This is for consistency:  all other directory
     substitution (~user, ~name, ~+, ...) used a tilde, while
     =<number> caused problems with =program substitution.
  o  The `HISTLIT' option was broken in various ways and has been removed:
     the rewritten history mechanism doesn't alter history lines, making
     the option unnecessary.
  o  History expansion is disabled in single-quoted strings, like other
     forms of expansion -- hence exclamation marks there should not be
     backslashed.
  o  The `$HISTCHARS' variable is now `$histchars'.  Currently both
     are tied together for compatibility.
  o  The PROMPT_SUBST option now performs backquote expansion -- hence
     you should quote these in prompts.  (SPROMPT has changed as a result.)
  o  Quoting in prompts has changed: close parentheses inside ternary
     expressions should be quoted with a %; history is now %!, not
     !.  Backslashes are no longer special.

5.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@math.gatech.edu

  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.

  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@math.gatech.edu

  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,

    zsh-announce@math.gatech.edu

  (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@math.gatech.edu

  with the *subject* line (this is a change from the old list)

    subscribe <your-email-address>

  e.g.

    Subject:  subscribe P.Stephenson@swansea.ac.uk

  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
  coleman@math.gatech.edu.

  The list from May 1992 to May 1995 is archived in
    ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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.

5.3: What's on the wish-list?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  o  Loadable module support (will be in 3.1 but much work still needs doing).
  o  Ksh compatibility could be improved.
  o  Option for glob qualifiers to follow perl syntax (now a traditional item).
  o  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.
  o  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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.peak.org/zsh/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1997-04-24 10:24 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1997-04-24 10:24 UTC (permalink / raw)
  To: zsh-announce


Archive-Name: unix-faq/shell/zsh
Last-Modified: 1997/04/24
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zshfaq.yo,v 1.5 1997/04/24 10:19:15 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996 (see end of document)

Changes since last issue:

1.1:      New WWW site (at www.peak.org).
3.2:      New item on ALL_EXPORT option.

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?

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. What is the difference between `export' and the ALL_EXPORT option?
3.3. How do I turn off spelling correction/globbing for a single command?
3.4. How do I get the meta key to work on my xterm?
3.5. How do I automatically display the directory in my xterm title bar?
3.6. Why does my terminal act funny in some way?
3.7. Why does zsh not work in an Emacs shell mode any more?
3.9. Why do my autoloaded functions not autoload [the first time]?
3.9. How does base arithmetic work?
3.10. How do I get a newline in my prompt?
3.11. Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
3.12. Why can't I bind \C-s and \C-q any more?
3.13. How do I execute command `foo' within function `foo'?
3.14. Why do history substitutions with single bangs do something funny?
3.15. Why does zsh kill off all my background jobs when I logout?
3.16. How do I list all my history entries?
3.17. How does the alternative loop syntax, e.g. `while {...} {...}' work?

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 get started with programmable completion?
4.5. And if programmable completion isn't good enough?

Chapter 5:  The future of zsh
5.1. What bugs are currently known and unfixed? (Plus recent important changes)
5.2. Where do I report bugs, get more info / who's working on zsh?
5.3. What's on the wish-list?

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://www.peak.org/zsh/ (note the change of address from the
  end of April 1997). The server provides this FAQ and much else (thanks
  to Mark Borges for this).  The FAQ is at http://www.peak.org/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 1.6.

  (As a 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 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); it's 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 globbing (compctl -g),
    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,
    o  variable, editing function and option name completion,
    o  inline expansion of variables, 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 arithmetic.
  o  Manipulation of arrays (including reverse subscripting).
  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 Etc/MACHINES in the distribution has more details.

  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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question
  5.2).  Changes based on version 2.5 are very unlikely to
  be useful.

  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 Etc/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 make 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 3.0.2 has now been released. The new major number 3.0 largely
  reflects the considerable internal changes in zsh to make it more
  reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of 5.1.  This is longer
  than usual due to enhanced sh, ksh and POSIX compatibility.

  The beta version 3.1.0 has also been 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 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 (most recently) to provide POSIX compliancy.

1.6: Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.  The
  following are known mirrors (kept frequently up to date); the first
  is the official archive site.  All are available by anonymous FTP.

    Hungary   ftp://ftp.cs.elte.hu/pub/zsh/
              (also http://www.cs.elte.hu/pub/zsh/ )
    Australia ftp://ftp.ips.gov.au/mirror/zsh/
    Finland   ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France    ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany   ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
              ftp://ftp.gmd.de/packages/zsh/
              ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Japan     ftp://ftp.tohoku.ac.jp/mirror/zsh/
              ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway    ftp://ftp.uit.no/pub/unix/shells/zsh/
    Slovenia  ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden    ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK        ftp://ftp.net.lut.ac.uk/zsh/
              (also by FSP at port 21)
    USA       ftp://ftp.math.gatech.edu/pub/zsh/
              ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
              ftp://ftp.sterling.com/zsh/
              ftp://ftp.rge.com/pub/shells/zsh/

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 with 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 --- 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 commands
     `emulate sh; setopt localoptions' in a shell function will
     turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in 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_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_BUILTINS,
  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 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', 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.
        The KSH_ARRAYS option is now available.
    o   Coprocesses are established by `coproc'; `|&' behaves like
        csh. 

  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.
        (GLOB_SUBST has been added to fix this.)
    o   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.)
    o * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    o   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.

      [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 `**'.
    o   Unquoted assignments do file expansion after `:'s (intended for
        PATHs). 
    o   `integer' does not allow `-i'.

  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  Traps and signals:

    o   Traps are not local to functions.
    o   TRAPERR has become TRAPZERR (this was forced by UNICOS which
        has SIGERR).

  o  Editing:

    o   The options emacs, gmacs, viraw are not supported.
        Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
        becomes `bindkey -{e,v}'; 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' will not be in the next ksh
        release either.)
    o   Management of histories in multiple shells is different:
        the history list is not saved and restored after each command.
    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  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   `read' has no `-s' flag.
    o   In `let "i = foo"', foo is evaluated as a number, not an
        expression (although in `let "i = $foo"' +it is treated as an
        expression). 

  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" 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 shwordsplit and ksharrays 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         "$@"            ($*: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.

  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.

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,
  $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 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.

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.

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.

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.)  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 `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 shwordsplit.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.

3.2: 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.3: 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.4: 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.

3.5: 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 a sun-cmd.

  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) 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.6: 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.

3.7: 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" "~/bin/eshell")

  to ~/.emacs.

3.8: Why do my autoloaded functions not autoload [the first time]?

  (Before version 3.0, autoloading in the Korn shell way was not
  allowed; this article is now a historical artefact and will
  eventually be removed.  Note, however, that the old form of
  autoloading is still allowed and there are no plans to remove it.)

  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.)

3.9: 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 now supported).  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.

3.10: 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 :-).  Otherwise, you can use

    PROMPT=$(print "Hi Joe,\nwhat now?%# ")

  in your initialisation file.

3.11: 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.12: 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.

3.13: 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.14: 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.15: 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.

3.16: 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.17: 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.

Chapter 4: 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.

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.

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 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
  (or something else you can execute, like a builtin comman, a
  function or an alias) and tries 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 4.4.)

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 your 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 nobeep set, that annoying beep goes away
   o  with nolistbeep, beeping is only turned off for ambiguous completions
   o  with autolist set, when the completion is ambiguous you get a
      list without having to type \C-D
   o  with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
   o  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
   o  with automenu, you only get the menu behaviour when you hit TAB
      again on the ambiguous completion.

  Combinations of these are possible; for example, autolist and
  automenu together give an intuitive combination. 

4.4: 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 4.2),
  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):

   1) 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',
   2) 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 `-',
   3) 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.

4.5: 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.

Chapter 5: The future of zsh

5.1: What bugs are currently known and unfixed? (Plus recent important changes)

  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 2.1; 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.

  o  Special variables won't be unset after e.g. `PATH=... read ...',
     i.e. if used with a builtin command or shell function.
     (According to POSIX, this is not a bug with `special' builtins.)
  o  `time' is ignored with builtins and can't be used with `{...}'.
  o  `set -x' (`setopt xtrace') still has a few glitches.
  o  The `:q' and `:x' modifiers don't work for variables.
  o  In vi mode, `u' can go past the original modification point.
  o  The singlelinezle option has problems with prompts containing escapes.
  o  The `r' command does not work inside `$(...)' or ``...`'
     expansions. 
  o  `typeset' handling is non-optimal, particularly with regard to
     flags, and is ksh-incompatible in unpredictable ways. 

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes after zsh 3.0 (3.1.x is still currently in beta):

  o  history-search-{forward,backward} (bound to \M-n, \M-p)
     now only find previous lines where the first word is the same as the
     current one.  For example,

      comp<ESC>p

     will find lines in the history like `comp -edit emacs', but not
     `compress file' any more.  For an approximation to the old
     behaviour, use history-beginning-search-{forward,backward} which
     search for a line with the same prefix up to the cursor position.
  o  In vi insert mode, the cursor keys no longer work.  The following
     will bind them:

       bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \ 
                      '^[[A' up-line-or-history '^[[B' down-line-or-history

     (unless your terminal requires `^[O' instead of `^[[').  The
     rationale is that the insert mode and command mode keymaps for
     keys with prefixes are now separate.

  Changes since zsh 2.5:

  o  The left hand of an assignment is no longer substituted.  Thus,
     `$1=$2' will not work.  You can use something like `eval
     "$1=\$2"', which should have the identical effect.
  o  Signal traps established with the `trap' builtin are now called with
     the environment of the caller, instead of as a new function level,
     as in ksh.  Traps established as functions (e.g. `TRAPINT()
     {...}') work as before.
  o  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
     to be the other way around.  (Use of names rather than letters is
     generally recommended.)
  o  `[[' is a reserved word, hence must be separated from
     other characters by whitespace; `{' and `}' are also reserved
     words if the IGNORE_BRACES option is set.
  o  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
     always does what it looks like it does, so `if ( ... ) ...'
     executes the code in parentheses in a subshell.  To make this
     useful, the syntax expected after an `if', etc., is less strict
     than in other shells.
  o  On the other hand, `foo=*' does not perform globbing immediately on
     the right hand side of the assignment; the old behaviour now
     requires the option GLOB_ASSIGN.  (`foo=(*)' is and has always
     been the consistent way of doing this.)
  o  <> performs redirection of input and output to the specified file.
     For numeric globs, you now need <->.
  o  The command line qualifiers exec, noglob, command,
     - are now treated more like builtin commands:  previously they were
     syntactically special.  This should make it easier to perform tricks with
     them (disabling, hiding in parameters, etc.).
  o  The pushd builtin has been rewritten for compatibility with other
     shells.  The old behavour can be achieved with a shell function.
  o  The current version now uses ~'s for directory stack substitution
     instead of ='s.  This is for consistency:  all other directory
     substitution (~user, ~name, ~+, ...) used a tilde, while
     =<number> caused problems with =program substitution.
  o  The `HISTLIT' option was broken in various ways and has been removed:
     the rewritten history mechanism doesn't alter history lines, making
     the option unnecessary.
  o  History expansion is disabled in single-quoted strings, like other
     forms of expansion -- hence exclamation marks there should not be
     backslashed.
  o  The `$HISTCHARS' variable is now `$histchars'.  Currently both
     are tied together for compatibility.
  o  The PROMPT_SUBST option now performs backquote expansion -- hence
     you should quote these in prompts.  (SPROMPT has changed as a result.)
  o  Quoting in prompts has changed: close parentheses inside ternary
     expressions should be quoted with a %; history is now %!, not
     !.  Backslashes are no longer special.

5.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@math.gatech.edu

  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.

  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@math.gatech.edu

  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,

    zsh-announce@math.gatech.edu

  (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@math.gatech.edu

  with the *subject* line (this is a change from the old list)

    subscribe <your-email-address>

  e.g.

    Subject:  subscribe P.Stephenson@swansea.ac.uk

  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
  coleman@math.gatech.edu.

  The list from May 1992 to May 1995 is archived in
    ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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.

5.3: What's on the wish-list?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  o  Loadable module support (will be in 3.1 but much work still needs doing).
  o  Ksh compatibility could be improved.
  o  Option for glob qualifiers to follow perl syntax (now a traditional item).
  o  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.
  o  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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.peak.org/zsh/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1997-03-24  8:57 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1997-03-24  8:57 UTC (permalink / raw)
  To: zsh-announce


Archive-Name: unix-faq/shell/zsh
Last-Modified: 1997/03/24
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zshfaq.yo,v 1.4 1997/03/24 08:44:15 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996 (see end of document)

Changes since last issue:

General:  Converted to YODL format to make HTML and LaTeX as well
  as text versions available.
2.4:      Expanded note on running commands in the middle of
  editing lines.
New 3.6:  Why does zsh not work in an Emacs shell mode any more?
New 3.16: How does the alternative loop syntax, e.g.
  `while {...} {...}' work?

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?

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. How do I turn off spelling correction/globbing for a single command?
3.3. How do I get the meta key to work on my xterm?
3.4. How do I automatically display the directory in my xterm title bar?
3.5. Why does my terminal act funny in some way?
3.6. Why does zsh not work in an Emacs shell mode any more?
3.7. Why do my autoloaded functions not autoload [the first time]?
3.8. How does base arithmetic work?
3.9. How do I get a newline in my prompt?
3.10. Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
3.11. Why can't I bind \C-s and \C-q any more?
3.12. How do I execute command `foo' within function `foo'?
3.13. Why do history substitutions with single bangs do something funny?
3.14. Why does zsh kill off all my background jobs when I logout?
3.15. How do I list all my history entries?
3.16. How does the alternative loop syntax, e.g. `while {...} {...}' work?

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 get started with programmable completion?
4.5. And if programmable completion isn't good enough?

Chapter 5:  The future of zsh
5.1. What bugs are currently known and unfixed? (Plus recent important changes)
5.2. Where do I report bugs, get more info / who's working on zsh?
5.3. What's on the wish-list?

Acknowledgments

Copyright
--- End of Contents ---

Chapter 1: Introducing zsh and how to install it

1.1: 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 1.6.

  (As a 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 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); it's 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 globbing (compctl -g),
    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,
    o  variable, editing function and option name completion,
    o  inline expansion of variables, 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 arithmetic.
  o  Manipulation of arrays (including reverse subscripting).
  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 Etc/MACHINES in the distribution has more details.

  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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question
  5.2).  Changes based on version 2.5 are very unlikely to
  be useful.

  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 Etc/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 make 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 3.0.2 has now been released. The new major number 3.0 largely
  reflects the considerable internal changes in zsh to make it more
  reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of 5.1.  This is longer
  than usual due to enhanced sh, ksh and POSIX compatibility.

  The beta version 3.1.0 has also been 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 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 (most recently) to provide POSIX compliancy.

1.6: Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.  The
  following are known mirrors (kept frequently up to date); the first
  is the official archive site.  All are available by anonymous FTP.

    Hungary   ftp://ftp.cs.elte.hu/pub/zsh/
              (also http://www.cs.elte.hu/pub/zsh/ )
    Australia ftp://ftp.ips.gov.au/mirror/zsh/
    Finland   ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France    ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany   ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
              ftp://ftp.gmd.de/packages/zsh/
              ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Japan     ftp://ftp.tohoku.ac.jp/mirror/zsh/
              ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway    ftp://ftp.uit.no/pub/unix/shells/zsh/
    Slovenia  ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden    ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK        ftp://ftp.net.lut.ac.uk/zsh/
              (also by FSP at port 21)
    USA       ftp://ftp.math.gatech.edu/pub/zsh/
              ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
              ftp://ftp.sterling.com/zsh/
              ftp://ftp.rge.com/pub/shells/zsh/

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 with 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 --- 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 commands
     `emulate sh; setopt localoptions' in a shell function will
     turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in 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_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_BUILTINS,
  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 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', 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.
        The KSH_ARRAYS option is now available.
    o   Coprocesses are established by `coproc'; `|&' behaves like
        csh. 

  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.
        (GLOB_SUBST has been added to fix this.)
    o   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.)
    o * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    o   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.

      [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 `**'.
    o   Unquoted assignments do file expansion after `:'s (intended for
        PATHs). 
    o   `integer' does not allow `-i'.

  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  Traps and signals:

    o   Traps are not local to functions.
    o   TRAPERR has become TRAPZERR (this was forced by UNICOS which
        has SIGERR).

  o  Editing:

    o   The options emacs, gmacs, viraw are not supported.
        Use bindkey to change the editing behaviour: `set -o {emacs,vi}'
        becomes `bindkey -{e,v}'; 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' will not be in the next ksh
        release either.)
    o   Management of histories in multiple shells is different:
        the history list is not saved and restored after each command.
    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  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   `read' has no `-s' flag.
    o   In `let "i = foo"', foo is evaluated as a number, not an
        expression (although in `let "i = $foo"' +it is treated as an
        expression). 

  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" 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 shwordsplit and ksharrays 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               "$@"            ($*: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.

  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.

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,
  $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 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.

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.

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.

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.)  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 `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 shwordsplit.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.

3.2: 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.3: 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.

3.4: 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 a sun-cmd.

  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) 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.5: 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.

3.6: 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" "~/bin/eshell")

  to ~/.emacs.

3.7: Why do my autoloaded functions not autoload [the first time]?

  (Before version 3.0, autoloading in the Korn shell way was not
  allowed; this article is now a historical artefact and will
  eventually be removed.  Note, however, that the old form of
  autoloading is still allowed and there are no plans to remove it.)

  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.)

3.8: 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 now supported).  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.

3.9: 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 :-).  Otherwise, you can use

    PROMPT=$(print "Hi Joe,\nwhat now?%# ")

  in your initialisation file.

3.10: 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.11: 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.

3.12: 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.13: 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.14: 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.

3.15: 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.16: 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.

Chapter 4: 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.

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.

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 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
  (or something else you can execute, like a builtin comman, a
  function or an alias) and tries 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 4.4.)

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 your 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 nobeep set, that annoying beep goes away
   o  with nolistbeep, beeping is only turned off for ambiguous completions
   o  with autolist set, when the completion is ambiguous you get a
      list without having to type \C-D
   o  with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
   o  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
   o  with automenu, you only get the menu behaviour when you hit TAB
      again on the ambiguous completion.

  Combinations of these are possible; for example, autolist and
  automenu together give an intuitive combination. 

4.4: 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 4.2),
  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):

   1) 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',
   2) 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 `-',
   3) 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.

4.5: 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.

Chapter 5: The future of zsh

5.1: What bugs are currently known and unfixed? (Plus recent important changes)

  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 2.1; 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.

  o  Special variables won't be unset after e.g. `PATH=... read ...',
     i.e. if used with a builtin command or shell function.
     (According to POSIX, this is not a bug with `special' builtins.)
  o  `time' is ignored with builtins and can't be used with `{...}'.
  o  `set -x' (`setopt xtrace') still has a few glitches.
  o  The `:q' and `:x' modifiers don't work for variables.
  o  In vi mode, `u' can go past the original modification point.
  o  The singlelinezle option has problems with prompts containing escapes.
  o  The `r' command does not work inside `$(...)' or ``...`'
     expansions. 
  o  `typeset' handling is non-optimal, particularly with regard to
     flags, and is ksh-incompatible in unpredictable ways. 

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes after zsh 3.0 (3.1.x is still currently in beta):

  o  history-search-{forward,backward} (bound to \M-n, \M-p)
     now only find previous lines where the first word is the same as the
     current one.  For example,

      comp<ESC>p

     will find lines in the history like `comp -edit emacs', but not
     `compress file' any more.  For an approximation to the old
     behaviour, use history-beginning-search-{forward,backward} which
     search for a line with the same prefix up to the cursor position.
  o  In vi insert mode, the cursor keys no longer work.  The following
     will bind them:

       bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \ 
                      '^[[A' up-line-or-history '^[[B' down-line-or-history

     (unless your terminal requires `^[O' instead of `^[[').  The
     rationale is that the insert mode and command mode keymaps for
     keys with prefixes are now separate.

  Changes since zsh 2.5:

  o  The left hand of an assignment is no longer substituted.  Thus,
     `$1=$2' will not work.  You can use something like `eval
     "$1=\$2"', which should have the identical effect.
  o  Signal traps established with the `trap' builtin are now called with
     the environment of the caller, instead of as a new function level,
     as in ksh.  Traps established as functions (e.g. `TRAPINT()
     {...}') work as before.
  o  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
     to be the other way around.  (Use of names rather than letters is
     generally recommended.)
  o  `[[' is a reserved word, hence must be separated from
     other characters by whitespace; `{' and `}' are also reserved
     words if the IGNORE_BRACES option is set.
  o  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
     always does what it looks like it does, so `if ( ... ) ...'
     executes the code in parentheses in a subshell.  To make this
     useful, the syntax expected after an `if', etc., is less strict
     than in other shells.
  o  On the other hand, `foo=*' does not perform globbing immediately on
     the right hand side of the assignment; the old behaviour now
     requires the option GLOB_ASSIGN.  (`foo=(*)' is and has always
     been the consistent way of doing this.)
  o  <> performs redirection of input and output to the specified file.
     For numeric globs, you now need <->.
  o  The command line qualifiers exec, noglob, command,
     - are now treated more like builtin commands:  previously they were
     syntactically special.  This should make it easier to perform tricks with
     them (disabling, hiding in parameters, etc.).
  o  The pushd builtin has been rewritten for compatibility with other
     shells.  The old behavour can be achieved with a shell function.
  o  The current version now uses ~'s for directory stack substitution
     instead of ='s.  This is for consistency:  all other directory
     substitution (~user, ~name, ~+, ...) used a tilde, while
     =<number> caused problems with =program substitution.
  o  The `HISTLIT' option was broken in various ways and has been removed:
     the rewritten history mechanism doesn't alter history lines, making
     the option unnecessary.
  o  History expansion is disabled in single-quoted strings, like other
     forms of expansion -- hence exclamation marks there should not be
     backslashed.
  o  The `$HISTCHARS' variable is now `$histchars'.  Currently both
     are tied together for compatibility.
  o  The PROMPT_SUBST option now performs backquote expansion -- hence
     you should quote these in prompts.  (SPROMPT has changed as a result.)
  o  Quoting in prompts has changed: close parentheses inside ternary
     expressions should be quoted with a %; history is now %!, not
     !.  Backslashes are no longer special.

5.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@math.gatech.edu

  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.

  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@math.gatech.edu

  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,

    zsh-announce@math.gatech.edu

  (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@math.gatech.edu

  with the *subject* line (this is a change from the old list)

    subscribe <your-email-address>

  e.g.

    Subject:  subscribe P.Stephenson@swansea.ac.uk

  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
  coleman@math.gatech.edu.

  The list from May 1992 to May 1995 is archived in
    ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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.

5.3: What's on the wish-list?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  o  Loadable module support (will be in 3.1 but much work still needs doing).
  o  Ksh compatibility could be improved.
  o  Option for glob qualifiers to follow perl syntax (now a traditional item).
  o  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.
  o  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1997-02-25 10:45 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1997-02-25 10:45 UTC (permalink / raw)
  To: zsh-announce

Archive-Name: unix-faq/shell/zsh
Last-Modified: 1997/02/25
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zsh.FAQ,v 2.24 1997/02/25 10:45:30 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996 (see end of document)

Changes since last issue:
in Z1)  zle changes between 3.0 and 3.1: history-search-{forward,backward}
  and cursor bindings in vi insert mode (not).

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 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 it 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) Why does `$var' where var="foo bar" not do what I expect?
C2) How do I turn off spelling correction/globbing for an individual command?
C3) How do I get the meta key to work on my xterm?
C4) How do I automatically display the directory in my xterm title bar?
C5) Why does my terminal act funny in some way?
C6) Why do my autoloaded functions not autoload [the first time]?
C7) How does base arithmetic work?
C8) How do I get a newline in my prompt?
C9) Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
C10) Why can't I bind \C-s and \C-q any more?
C11) How do I execute command `foo' within function `foo'?
C12) Why do history substitutions with single bangs do something funny?
C13) Why does zsh kill off all my background jobs when I logout?
C14) How do I list all my history entries?

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? (Plus recent important changes)
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).

  (As a 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); it's 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 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 interactive feature
  in any other freely-available shell which zsh does not also have
  (except smallness).

  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?

  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 Etc/MACHINES in the distribution has more details.

  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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question Z2).
  Changes based on version 2.5 are very unlikely to be useful.

  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.  Also read the Etc/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 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 3.0.2 has now been relased. The new major number 3.0 largely
  reflects the considerable internal changes in zsh to make it more
  reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of Z1).  This is longer
  than usual due to enhanced sh, ksh and POSIX compatibility.

  The beta version 3.1.0 has also been 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, or (most recently) to provide POSIX compliancy.


A5) Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.
  The following are known mirrors (kept frequently up to date); the
  first is the official archive site.  All are available by anonymous
  FTP.

    Hungary     ftp://ftp.cs.elte.hu/pub/zsh/
                (also http://www.cs.elte.hu/pub/zsh/ )
    Australia   ftp://ftp.ips.gov.au/mirror/zsh/
    Finland     ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France      ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany     ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
                ftp://ftp.gmd.de/packages/zsh/
                ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Japan       ftp://ftp.tohoku.ac.jp/mirror/zsh/
                ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway      ftp://ftp.uit.no/pub/unix/shells/zsh/
    Slovenia    ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden      ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK          ftp://ftp.net.lut.ac.uk/zsh/
                (also by FSP at port 21)
    USA         ftp://ftp.math.gatech.edu/pub/zsh/
                ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
                ftp://ftp.sterling.com/zsh/
                ftp://ftp.rge.com/pub/shells/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.  You
  can supply these directly to a Web browser.  If you're reading this
  with a recent Web browser, you may just have to click on them.)

  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.


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).

  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.


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.  See also the article `UNIX shell differences and how to change
your shell' posted frequently to the USENET goupr comp.unix.shell.

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; differences with ksh93 will be more
  substantial.

  As a summary of the status:
    i) 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;
   ii) 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);
  iii) 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;
   iv) 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 --- see the detailed
       list below;
    v) 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 commands
       `emulate sh; setopt localoptions' in a shell function will
       turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in C1); 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_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_BUILTINS,
  SH_FILE_EXPANSION, SH_GLOB, SH_OPTION_LETTERS, SH_WORD_SPLIT (see
  question C1) 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 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', or
  if `emulate ksh' is in effect.  Capitalised words with underlines
  refer to shell options. 

  Syntax:
  * Shell word splitting: see question C1).
  * 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.
      The KSH_ARRAYS option is now available.
    Coprocesses are established by `coproc'; `|&' behaves like csh.
  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 been added to fix this.)
    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.)
  * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    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.
      [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 `**'.
    Unquoted assignments do file expansion after `:'s (intended for PATHs).
    `integer' does not allow -i.
  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'.
  * 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).
  Traps and signals:
    Traps are not local to functions.
    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.
      (Note that `>file 2>&1' is the standard Bourne shell command for
      csh's `>&file'.)
    foreach ... loops; alternative syntax for other loops.
    Alternative syntax `if ( ... ) ...', though this still doesn't
      work like csh: it expects a command in the parentheses.  Also
      `for', `which').
    $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 and ksharrays 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               "$@"            ($*: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.

  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.


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 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.


B5) 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.


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.
    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.


Section C:  How to get various things to work

C1) 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 `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 shwordsplit.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.


C2) How do I turn off spelling correction/globbing for an individual 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).

  Two notes: 1) a shell function won't work, the no... directives must
  be expanded before the rest of the command line is parsed 2) nocorrect
  must come earlier than noglob if both appear, since it is needed by the
  line editor, while noglob is only handled when the command is examined.


C3) 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.


C4) 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 a sun-cmd.
  
  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) 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.


C5) 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.


C6) Why do my autoloaded functions not autoload [the first time]?

  (Before version 3.0, autoloading in the Korn shell way was not
  allowed; this article is now a historical artefact and will
  eventually be removed.  Note, however, that the old form of
  autoloading is still allowed and there are no plans to remove it.)

  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.)


C7) 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 now supported).  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.


C8) 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 :-).  Otherwise, you can use
        PROMPT=$(print "Hi Joe,\nwhat now?%# ")
  in your initialisation file.


C9) 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.


C10) 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.


C11) 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'.


C12) 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.


C13) 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.


C14) 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.


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.  (You can
  see if the word would be expanded --- not completed --- by TAB by
  typing "CTRL-x g", which lists expansions.)  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
  (or something else you can execute, like a builtin comman, a
  function or an alias) and tries 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 its 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.
  (That's assuming your at the end of the line, otherwise ^D will
  delete the next character and you have to use Esc-^D.)  This can be
  changed by the following options, among others:
    - with nobeep set, that annoying beep goes away
    - with nolistbeep, beeping is only turned off for ambiguous completions
    - with autolist set, when the completion is ambiguous you get a
      list without having to type ^D
    - with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
    - 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
    - with automenu, you only get the menu behaviour when you hit TAB
      again on the ambiguous completion.  
  Combinations of these are possible; for example, autolist and
  automenu together give an intuitive combination. 


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? (Plus recent important changes)

  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.
    (According to POSIX, this is not a bug with `special' builtins.)
  `time' is ignored with builtins and can't be used with {...}.
  `set -x' (`setopt xtrace') still has a few glitches.
  The :q and :x modifiers don't work for variables.
  In vi mode, `u' can go past the original modification point.
  The singlelinezle option has problems with prompts containing escapes.
  The `r' command does not work inside $(...) or `...` expansions.
  `typeset' handling is non-optimal, particularly with regard to flags,
    and is ksh-incompatible in unpredictable ways. 

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes after zsh 3.0 (3.1.x is still currently in beta):
  history-search-{forward,backward} (bound to M-n, M-p) now only find
    previous lines where the first word is the same as the current
    one.  For example,
      comp<ESC>p
    will find lines in the history like `comp -edit emacs', but not
    `compress file' any more.  For an approximation to the old
    behaviour, use history-beginning-search-{forward,backward} which
    search for a line with the same prefix up to the cursor position.
  In vi insert mode, the cursor keys no longer work.  The following
    will bind them:
      bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \
                       '^[[A' up-line-or-history '^[[B' down-line-or-history
    (unless your terminal requires `^[O' instead of `^[[').  The
    rationale is that the insert mode and command mode keymaps for
    keys with prefixes are now separate.

  Changes since zsh 2.5:
  The left hand of an assignment is no longer substituted.  Thus,
    `$1=$2' will not work.  You can use something like `eval
    "$1=\$2"', which should have the identical effect.
  Signal traps established with the `trap' builtin are now called with
    the environment of the caller, instead of as a new function level,
    as in ksh.  Traps established as functions (e.g. `TRAPINT()
    {...}') work as before.
  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
    to be the other way around.  (Use of names rather than letters is
    generally recommended.)
  `[[' is a reserved word, hence must be separated from
    other characters by whitespace; `{' and `}' are also reserved
    words if the IGNORE_BRACES option is set.
  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
    always does what it looks like it does, so `if ( ... ) ...'
    executes the code in parentheses in a subshell.  To make this
    useful, the syntax expected after an `if', etc., is less strict
    than in other shells.
  On the other hand, `foo=*' does not perform globbing immediately on
    the right hand side of the assignment; the old behaviour now
    requires the option GLOB_ASSIGN.  (`foo=(*)' is and has always
    been the consistent way of doing this.)
  <> performs redirection of input and output to the specified file.
    For numeric globs, you now need <->.
  The command line qualifiers exec, noglob, command, - are now treated
    more like builtin commands:  previously they were syntactically
    special.  This should make it easier to perform tricks with them
    (disabling, hiding in parameters, etc.).
  The pushd builtin has been rewritten for compatibility with other
    shells.  The old behavour can be achieved with a shell function.
  The current version now uses ~'s for directory stack substitution
    instead of ='s.  This is for consistency:  all other directory
    substitution (~user, ~name, ~+, ...) used a tilde, while =<number>
    caused problems with =program substitution.
  The `HISTLIT' option was broken in various ways and has been removed:
    the rewritten history mechanism doesn't alter history lines, making
    the option unnecessary.
  History expansion is disabled in single-quoted strings, like other
    forms of expansion -- hence exclamation marks there should not be
    backslashed.
  The `HISTCHARS' variable is now `histchars'.  Currently both are
    tied together for compatibility.
  The PROMPT_SUBST option now performs backquote expansion -- hence
    you should quote these in prompts.  (SPROMPT has changed as a result.)
  Quoting in prompts has changed: close parentheses inside ternary
    expressions should be quoted with a %; history is now %!, not !.
    Backslashes are no longer special.


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,
        zsh-workers@math.gatech.edu
  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.

  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@math.gatech.edu
  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,
        zsh-announce@math.gatech.edu
  (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@math.gatech.edu
  with the *subject* line (this is a change from the old list)
        subscribe <your-email-address>
  e.g.
        Subject:  subscribe P.Stephenson@swansea.ac.uk
  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
        coleman@math.gatech.edu

  The list from May 1992 to May 1995 is archived in
        ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  Loadable module support (will be in 3.1 but much work still needs doing).
  Ksh compatibility could be improved.
  Option for glob qualifiers to follow perl syntax (now a traditional item).
  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.
  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1997-01-24 13:29 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1997-01-24 13:29 UTC (permalink / raw)
  To: zsh-announce

Archive-Name: unix-faq/shell/zsh
Last-Modified: 1997/01/24
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zsh.FAQ,v 2.23 1997/01/24 13:21:16 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996 (see end of document)

Changes since last issue:
B): note existence of `UNIX shell differences' posting
B3): extra note about functions and aliases
new C4):  how to put the directory in the xterm title bar (entry long
          overdue, sorry)
Z3): mention future zle changes

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 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 it 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) Why does `$var' where var="foo bar" not do what I expect?
C2) How do I turn off spelling correction/globbing for an individual command?
C3) How do I get the meta key to work on my xterm?
C4) How do I automatically display the directory in my xterm title bar?
C5) Why does my terminal act funny in some way?
C6) Why do my autoloaded functions not autoload [the first time]?
C7) How does base arithmetic work?
C8) How do I get a newline in my prompt?
C9) Why does `bindkey ^a command-name' or 'stty intr ^-' do something funny?
C10) Why can't I bind \C-s and \C-q any more?
C11) How do I execute command `foo' within function `foo'?
C12) Why do history substitutions with single bangs do something funny?
C13) Why does zsh kill off all my background jobs when I logout?
C14) How do I list all my history entries?

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? (Plus recent important changes)
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).

  (As a 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); it's 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 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 interactive feature
  in any other freely-available shell which zsh does not also have
  (except smallness).

  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?

  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 Etc/MACHINES in the distribution has more details.

  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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question Z2).
  Changes based on version 2.5 are very unlikely to be useful.

  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.  Also read the Etc/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 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 3.0.2 has now been relased. The new major number 3.0 largely
  reflects the considerable internal changes in zsh to make it more
  reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of Z1).  This is longer
  than usual due to enhanced sh, ksh and POSIX compatibility.

  The beta version 3.1.0 has also been 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, or (most recently) to provide POSIX compliancy.


A5) Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.
  The following are known mirrors (kept frequently up to date); the
  first is the official archive site.  All are available by anonymous
  FTP.

    Hungary     ftp://ftp.cs.elte.hu/pub/zsh/
                (also http://www.cs.elte.hu/pub/zsh/ )
    Australia   ftp://ftp.ips.gov.au/mirror/zsh/
    Finland     ftp://ftp.funet.fi/pub/unix/shells/zsh/
    France      ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany     ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
                ftp://ftp.gmd.de/packages/zsh/
                ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
    Japan       ftp://ftp.tohoku.ac.jp/mirror/zsh/
                ftp://ftp.nis.co.jp/pub/shells/zsh/
    Norway      ftp://ftp.uit.no/pub/unix/shells/zsh/
    Slovenia    ftp://ftp.siol.net/pub/unix/shells/zsh/
    Sweden      ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK          ftp://ftp.net.lut.ac.uk/zsh/
                (also by FSP at port 21)
    USA         ftp://ftp.math.gatech.edu/pub/zsh/
                ftp://uiarchive.uiuc.edu/pub/packages/shells/zsh/
                ftp://ftp.sterling.com/zsh/
                ftp://ftp.rge.com/pub/shells/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.  You
  can supply these directly to a Web browser.  If you're reading this
  with a recent Web browser, you may just have to click on them.)

  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.


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).

  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.


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.  See also the article `UNIX shell differences and how to change
your shell' posted frequently to the USENET goupr comp.unix.shell.

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; differences with ksh93 will be more
  substantial.

  As a summary of the status:
    i) 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;
   ii) 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);
  iii) 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;
   iv) 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 --- see the detailed
       list below;
    v) 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 commands
       `emulate sh; setopt localoptions' in a shell function will
       turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in C1); 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_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_BUILTINS,
  SH_FILE_EXPANSION, SH_GLOB, SH_OPTION_LETTERS, SH_WORD_SPLIT (see
  question C1) 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 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', or
  if `emulate ksh' is in effect.  Capitalised words with underlines
  refer to shell options. 

  Syntax:
  * Shell word splitting: see question C1).
  * 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.
      The KSH_ARRAYS option is now available.
    Coprocesses are established by `coproc'; `|&' behaves like csh.
  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 been added to fix this.)
    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.)
  * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    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.
      [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 `**'.
    Unquoted assignments do file expansion after `:'s (intended for PATHs).
    `integer' does not allow -i.
  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'.
  * 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).
  Traps and signals:
    Traps are not local to functions.
    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.
      (Note that `>file 2>&1' is the standard Bourne shell command for
      csh's `>&file'.)
    foreach ... loops; alternative syntax for other loops.
    Alternative syntax `if ( ... ) ...', though this still doesn't
      work like csh: it expects a command in the parentheses.  Also
      `for', `which').
    $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 and ksharrays 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               "$@"            ($*: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.

  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.


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 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.


B5) 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.


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.
    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.


Section C:  How to get various things to work

C1) 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 `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 shwordsplit.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.


C2) How do I turn off spelling correction/globbing for an individual 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).

  Two notes: 1) a shell function won't work, the no... directives must
  be expanded before the rest of the command line is parsed 2) nocorrect
  must come earlier than noglob if both appear, since it is needed by the
  line editor, while noglob is only handled when the command is examined.


C3) 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.

  You don't need the `bindkey' to be able to define your own sequences
  with the meta key, though you still need the `stty'.


C4) 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 a sun-cmd.
  
  chpwd() {
    [[ -t 1 ]] || return
    case $TERM in
      sun-cmd) print -Pn "\e]l%~\e\\"
        ;;
      xterm) print -Pn "\e]2;%~\a"
        ;;
    esac
  }

  Change `%~' if you want the message to be different.  (The `-P'
  option to print causes this to be interpreted as the current
  directory.)  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.


C5) 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: from 2.5,
  the shell is less susceptible to mode changes inherited from
  programmes than it used to be.


C6) Why do my autoloaded functions not autoload [the first time]?

  (Before version 3.0, autoloading in the Korn shell way was not
  allowed; this article is now a historical artefact and will
  eventually be removed.  Note, however, that the old form of
  autoloading is still allowed and there are no plans to remove it.)

  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.)


C7) 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 now supported).  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.


C8) 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 :-).  Otherwise, you can use
        PROMPT=$(print "Hi Joe,\nwhat now?%# ")
  in your initialisation file.


C9) 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.


C10) 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.


C11) 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'.


C12) 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.


C13) 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.


C14) 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.


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.  (You can
  see if the word would be expanded --- not completed --- by TAB by
  typing "CTRL-x g", which lists expansions.)  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
  (or something else you can execute, like a builtin comman, a
  function or an alias) and tries 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 its 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.
  (That's assuming your at the end of the line, otherwise ^D will
  delete the next character and you have to use Esc-^D.)  This can be
  changed by the following options, among others:
    - with nobeep set, that annoying beep goes away
    - with nolistbeep, beeping is only turned off for ambiguous completions
    - with autolist set, when the completion is ambiguous you get a
      list without having to type ^D
    - with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
    - 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
    - with automenu, you only get the menu behaviour when you hit TAB
      again on the ambiguous completion.  
  Combinations of these are possible; for example, autolist and
  automenu together give an intuitive combination. 


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? (Plus recent important changes)

  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.
    (According to POSIX, this is not a bug with `special' builtins.)
  `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.
  The singlelinezle option has problems with prompts containing escapes.
  The `r' command does not work inside $(...) or `...` expansions.
  `typeset' handling is non-optimal, particularly with regard to flags,
    and is ksh-incompatible in unpredictable ways. 

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes since zsh 2.5:
  The left hand of an assignment is no longer substituted.  Thus,
    `$1=$2' will not work.  You can use something like `eval
    "$1=\$2"', which should have the identical effect.
  Signal traps established with the `trap' builtin are now called with
    the environment of the caller, instead of as a new function level,
    as in ksh.  Traps established as functions (e.g. `TRAPINT()
    {...}') work as before.
  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
    to be the other way around.  (Use of names rather than letters is
    generally recommended.)
  `[[' is a reserved word, hence must be separated from
    other characters by whitespace; `{' and `}' are also reserved
    words if the IGNORE_BRACES option is set.
  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
    always does what it looks like it does, so `if ( ... ) ...'
    executes the code in parentheses in a subshell.  To make this
    useful, the syntax expected after an `if', etc., is less strict
    than in other shells.
  On the other hand, `foo=*' does not perform globbing immediately on
    the right hand side of the assignment; the old behaviour now
    requires the option GLOB_ASSIGN.  (`foo=(*)' is and has always
    been the consistent way of doing this.)
  <> performs redirection of input and output to the specified file.
    For numeric globs, you now need <->.
  The command line qualifiers exec, noglob, command, - are now treated
    more like builtin commands:  previously they were syntactically
    special.  This should make it easier to perform tricks with them
    (disabling, hiding in parameters, etc.).
  The pushd builtin has been rewritten for compatibility with other
    shells.  The old behavour can be achieved with a shell function.
  The current version now uses ~'s for directory stack substitution
    instead of ='s.  This is for consistency:  all other directory
    substitution (~user, ~name, ~+, ...) used a tilde, while =<number>
    caused problems with =program substitution.
  The `HISTLIT' option was broken in various ways and has been removed:
    the rewritten history mechanism doesn't alter history lines, making
    the option unnecessary.
  History expansion is disabled in single-quoted strings, like other
    forms of expansion -- hence exclamation marks there should not be
    backslashed.
  The `HISTCHARS' variable is now `histchars'.  Currently both are
    tied together for compatibility.
  The PROMPT_SUBST option now performs backquote expansion -- hence
    you should quote these in prompts.  (SPROMPT has changed as a result.)
  Quoting in prompts has changed: close parentheses inside ternary
    expressions should be quoted with a %; history is now %!, not !.
    Backslashes are no longer special.


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,
        zsh-workers@math.gatech.edu
  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.

  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@math.gatech.edu
  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,
        zsh-announce@math.gatech.edu
  (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@math.gatech.edu
  with the *subject* line (this is a change from the old list)
        subscribe <your-email-address>
  e.g.
        Subject:  subscribe P.Stephenson@swansea.ac.uk
  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
        coleman@math.gatech.edu

  The list from May 1992 to May 1995 is archived in
        ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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?

  With version 3, the code is much cleaner than before, but still
  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.

  An improved line editor, with user-definable functions and binding
  of multiple functions to keystrokes, is being developed.

  Loadable module support (will be in 3.1 but much work still needs doing).
  Ksh compatibility could be improved.
  Option for glob qualifiers to follow perl syntax (now a traditional item).
  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.
  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1996-11-25  9:13 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1996-11-25  9:13 UTC (permalink / raw)
  To: zsh-announce

Archive-Name: unix-faq/shell/zsh
Last-Modified: 1996/11/25
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zsh.FAQ,v 2.21 1996/11/25 09:13:28 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996 (see end of document)

Changes since last issue:
in intro: change unnecessarily provocative statement
in A4): latest versions are 3.0.1 (production), 3.1.0 (test)
in B5) and B6): avoid hostages to fortune
in Z1): note about typeset
in Z2): note about reporting bugs
in Z3): rewrite code cleanup bit, mention modules, delete the 'trap'
        note (no longer applies).

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 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 it 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/globbing 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?
C13) How do I list all my history entries?

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? (Plus recent important changes)
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).

  (As a 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); it's 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 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 interactive feature
  in any other freely-available shell which zsh does not also have
  (except smallness).

  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?

  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 Etc/MACHINES in the distribution has more details.

  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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question Z2).
  Changes based on version 2.5 are very unlikely to be useful.

  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.  Also read the Etc/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 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 3.0.1 has now been relased. The new major number 3.0 largely
  reflects the considerable internal changes in zsh to make it more
  reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of Z1).  This is longer
  than usual due to enhanced sh, ksh and POSIX compatibility.

  Version 3.1.0 is under test, though an intermediate bugfix release
  3.0.2 is also expected.  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, or (most recently) to provide POSIX compliancy.


A5) Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.
  The following are known mirrors (kept frequently up to date); the
  first is the official archive site.  All are available by anonymous
  FTP.

    Hungary     ftp://ftp.cs.elte.hu/pub/zsh/
    Australia   ftp://ftp.ips.gov.au/mirror/zsh/
    France      ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany     ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
                ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
                ftp://ftp.prz.tu-berlin.de/pub/unix/shells/zsh
    Japan       ftp://ftp.tohoku.ac.jp/mirror/zsh/
                ftp://ftp.iij.ad.jp/pub/misc/zsh/
    Norway      ftp://ftp.uit.no/pub/unix/shells/zsh/
    Sweden      ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK          ftp://ftp.net.lut.ac.uk/zsh/
                (also by FSP at port 21)
    USA         ftp://ftp.math.gatech.edu/pub/zsh/
                ftp://uiarchive.cso.uiuc.edu/pub/packages/shells/zsh/
                ftp://ftp.sterling.com/zsh/
                ftp://ftp.rge.com/pub/shells/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.  You
  can supply these directly to a Web browser.  If you're reading this
  with a recent version of Netscape Navigator, you may just have to
  click on them.)

  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.


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).

  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.


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; differences with ksh93 will be more
  substantial.

  As a summary of the status:
    i) 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;
   ii) 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);
  iii) 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;
   iv) 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 --- see the detailed
       list below;
    v) 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 commands
       `emulate sh; setopt localoptions' in a shell function will
       turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in C4); 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_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_BUILTINS,
  SH_FILE_EXPANSION, SH_GLOB, SH_OPTION_LETTERS, SH_WORD_SPLIT (see
  question C4) 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 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', or
  if `emulate ksh' is in effect.  Capitalised words with underlines
  refer to shell options. 

  Syntax:
  * Shell word splitting: see question C4).
  * 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.
      The KSH_ARRAYS option is now available.
    Coprocesses are established by `coproc'; `|&' behaves like csh.
  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 been added to fix this.)
    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.)
  * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    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.
      [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 `**'.
    Unquoted assignments do file expansion after `:'s (intended for PATHs).
    `integer' does not allow -i.
  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'.
  * 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).
  Traps and signals:
    Traps are not local to functions.
    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.
      (Note that `>file 2>&1' is the standard Bourne shell command for
      csh's `>&file'.)
    foreach ... loops; alternative syntax for other loops.
    Alternative syntax `if ( ... ) ...', though this still doesn't
      work like csh: it expects a command in the parentheses.  Also
      `for', `which').
    $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 and ksharrays 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               "$@"            ($*: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 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.


B5) 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.


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.
    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.


Section C:  How to get various things to work

C1) How do I turn off spelling correction/globbing for an individual 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 nglob, if you like).


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: from 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 `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 shwordsplit.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.


C5) Why do my autoloaded functions not autoload [the first time]?

  (Before version 3.0, autoloading in the Korn shell way was not
  allowed; this article is now a historical artefact and will
  eventually be removed.  Note, however, that the old form of
  autoloading is still allowed and there are no plans to remove it.)

  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.)


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 now supported).  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 :-).  Otherwise, you can use
        PROMPT=$(print "Hi Joe,\nwhat now?%# ")
  in your initialisation file.


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.


C13) 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.


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.  (You can
  see if the word would be expanded --- not completed --- by TAB by
  typing "CTRL-x g", which lists expansions.)  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
  (or something else you can execute, like a builtin comman, a
  function or an alias) and tries 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 its 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.
  (That's assuming your at the end of the line, otherwise ^D will
  delete the next character and you have to use Esc-^D.)  This can be
  changed by the following options, among others:
    - with nobeep set, that annoying beep goes away
    - with nolistbeep, beeping is only turned off for ambiguous completions
    - with autolist set, when the completion is ambiguous you get a
      list without having to type ^D
    - with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
    - 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
    - with automenu, you only get the menu behaviour when you hit TAB
      again on the ambiguous completion.  
  Combinations of these are possible; for example, autolist and
  automenu together give an intuitive combination. 


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? (Plus recent important changes)

  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.
    (According to POSIX, this is not a bug with `special' builtins.)
  `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.
  The singlelinezle option has problems with prompts containing escapes.
  The `r' command does not work inside $(...) or `...` expansions.
  `typeset' handling is non-optimal, particularly with regard to flags,
    and is ksh-incompatible in unpredictable ways. 

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes since zsh 2.5:
  Signal traps established with the `trap' builtin are now called with
    the environment of the caller, instead of as a new function level,
    as in ksh.  Traps established as functions (e.g. `TRAPINT()
    {...}') work as before.
  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
    to be the other way around.  (Use of names rather than letters is
    generally recommended.)
  `[[' is a reserved word, hence must be separated from
    other characters by whitespace; `{' and `}' are also reserved
    words if the IGNORE_BRACES option is set.
  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
    always does what it looks like it does, so `if ( ... ) ...'
    executes the code in parentheses in a subshell.  To make this
    useful, the syntax expected after an `if', etc., is less strict
    than in other shells.
  On the other hand, `foo=*' does not perform globbing immediately on
    the right hand side of the assignment; the old behaviour now
    requires the option GLOB_ASSIGN.  (`foo=(*)' is and has always
    been the consistent way of doing this.)
  <> performs redirection of input and output to the specified file.
    For numeric globs, you now need <->.
  The command line qualifiers exec, noglob, command, - are now treated
    more like builtin commands:  previously they were syntactically
    special.  This should make it easier to perform tricks with them
    (disabling, hiding in parameters, etc.).
  The pushd builtin has been rewritten for compatibility with other
    shells.  The old behavour can be achieved with a shell function.
  The current version now uses ~'s for directory stack substitution
    instead of ='s.  This is for consistency:  all other directory
    substitution (~user, ~name, ~+, ...) used a tilde, while =<number>
    caused problems with =program substitution.
  The `HISTLIT' option was broken in various ways and has been removed:
    the rewritten history mechanism doesn't alter history lines, making
    the option unnecessary.
  History expansion is disabled in single-quoted strings, like other
    forms of expansion -- hence exclamation marks there should not be
    backslashed.
  The `HISTCHARS' variable is now `histchars'.  Currently both are
    tied together for compatibility.
  The PROMPT_SUBST option now performs backquote expansion -- hence
    you should quote these in prompts.  (SPROMPT has changed as a result.)
  Quoting in prompts has changed: close parentheses inside ternary
    expressions should be quoted with a %; history is now %!, not !.
    Backslashes are no longer special.


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,
        zsh-workers@math.gatech.edu
  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.

  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@math.gatech.edu
  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,
        zsh-announce@math.gatech.edu
  (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@math.gatech.edu
  with the *subject* line (this is a change from the old list)
        subscribe <your-email-address>
  e.g.
        Subject:  subscribe P.Stephenson@swansea.ac.uk
  and you can unsubscribe in the same way.
  The list maintainer, Richard Coleman, can be reached at
        coleman@math.gatech.edu

  The list from May 1992 to May 1995 is archived in
        ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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?

  With version 3, the code is much cleaner than before, but still
  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.

  Loadable module support (will be in 3.1 but much work still needs doing).
  Ksh compatibility could be improved.
  Option for glob qualifiers to follow perl syntax (now a traditional item).
  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.
  `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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1996-10-24  9:15 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1996-10-24  9:15 UTC (permalink / raw)
  To: zsh-announce

Archive-Name: unix-faq/shell/zsh
Last-Modified: 1996/10/24
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zsh.FAQ,v 2.20 1996/10/24 09:15:18 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996 (see end of document)

Changes since last issue:
- in Z1: removed =(...) bug again
         mention pushd change

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 it 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/globbing 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?
C13) How do I list all my history entries?

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? (Plus recent important changes)
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).

  (As a 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); it's 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 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 (except smallness).

  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?

  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 Etc/MACHINES in the distribution has more details.

  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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question Z2).
  Changes based on version 2.5 are very unlikely to be useful.

  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.  Also read the Etc/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 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 3.0.0 has now been relased; 3.0.1 is under test.  The new major
  number 3.0 largely reflects the considerable internal changes in zsh
  to make it more reliable, consistent and (where possible)
  compatible.  Those planning on upgrading their zsh installation
  should take a look at the list of incompatibilities at the end of
  Z1).  This is longer than usual due to enhanced sh, ksh and POSIX
  compatibility.

  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, or (most recently) to provide POSIX compliancy.


A5) Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.
  The following are known mirrors (kept frequently up to date); the
  first is the official archive site.  All are available by anonymous
  FTP.

    Hungary     ftp://ftp.cs.elte.hu/pub/zsh/
    Australia   ftp://ftp.ips.gov.au/mirror/zsh/
    France      ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany     ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
                ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
                ftp://ftp.prz.tu-berlin.de/pub/unix/shells/zsh
    Japan       ftp://ftp.tohoku.ac.jp/mirror/zsh/
                ftp://ftp.iij.ad.jp/pub/misc/zsh/
    Norway      ftp://ftp.uit.no/pub/unix/shells/zsh/
    Sweden      ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK          ftp://ftp.net.lut.ac.uk/zsh/
                (also by FSP at port 21)
    USA         ftp://ftp.math.gatech.edu/pub/zsh/
                ftp://uiarchive.cso.uiuc.edu/pub/packages/shells/zsh/
                ftp://ftp.sterling.com/zsh/
                ftp://ftp.rge.com/pub/shells/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.  You
  can supply these directly to a Web browser.  If you're reading this
  with a recent version of Netscape Navigator, you may just have to
  click on them.)

  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.


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).

  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.


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; differences with ksh93 will be more
  substantial.

  As a summary of the status:
    i) 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;
   ii) 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);
  iii) 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;
   iv) 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 --- see the detailed
       list below;
    v) 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 commands
       `emulate sh; setopt localoptions' in a shell function will
       turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in C4); 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_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_BUILTINS,
  SH_FILE_EXPANSION, SH_GLOB, SH_OPTION_LETTERS, SH_WORD_SPLIT (see
  question C4) 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 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', or
  if `emulate ksh' is in effect.  Capitalised words with underlines
  refer to shell options. 

  Syntax:
  * Shell word splitting: see question C4).
  * 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.
      The KSH_ARRAYS option is now available.
    Coprocesses are established by `coproc'; `|&' behaves like csh.
  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 been added to fix this.)
    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.)
  * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    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.
      [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 `**'.
    Unquoted assignments do file expansion after `:'s (intended for PATHs).
    `integer' does not allow -i.
  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'.
  * 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).
  Traps and signals:
    Traps are not local to functions.
    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.
      (Note that `>file 2>&1' is the standard Bourne shell command for
      csh's `>&file'.)
    foreach ... loops; alternative syntax for other loops.
    Alternative syntax `if ( ... ) ...', though this still doesn't
      work like csh: it expects a command in the parentheses.  Also
      `for', `which').
    $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 and ksharrays 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               "$@"            ($*: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 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.


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 :-).

  On the other hand, zsh is not strictly POSIX compliant --- though
  the latest beta version is and production version 3 will be very
  much more so than the last production version, with the appropriate
  options set or when invoked as sh or ksh --- 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 [[ ... ]],
  or (yet) arrays, for example.  Of course, they're working on bash,
  too.  Some zsh-like features are suggested for future versions.


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.
    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 --- 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/globbing for an individual 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 nglob, if you like).


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: from 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 `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 shwordsplit.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.


C5) Why do my autoloaded functions not autoload [the first time]?

  (Before version 3.0, autoloading in the Korn shell way was not
  allowed; this article is now a historical artefact and will
  eventually be removed.  Note, however, that the old form of
  autoloading is still allowed and there are no plans to remove it.)

  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.)


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 now supported).  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 :-).  Otherwise, you can use
        PROMPT=$(print "Hi Joe,\nwhat now?%# ")
  in your initialisation file.


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.


C13) 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.


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.  (You can
  see if the word would be expanded --- not completed --- by TAB by
  typing "CTRL-x g", which lists expansions.)  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 tries 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:
    - with nobeep set, that annoying beep goes away
    - with nolistbeep, beeping is only turned off for ambiguous completions
    - with autolist set, when the completion is ambiguous you get a
      list without having to type ^D
    - with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
    - 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
    - with automenu, you only get the menu behaviour when you hit TAB
      again on the ambiguous completion.  
  Combinations of these are possible; for example, autolist and
  automenu together give an intuitive combination. 


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? (Plus recent important changes)

  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.
    (According to POSIX, this is not a bug with `special' builtins.)
  `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.
  The singlelinezle option has problems with prompts containing escapes.
  The `r' command does not work inside $(...) or `...` expansions.

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes since zsh 2.5:
  Signal traps established with the `trap' builtin are now called with
    the environment of the caller, instead of as a new function level,
    as in ksh.  Traps established as functions (e.g. `TRAPINT()
    {...}') work as before.
  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
    to be the other way around.  (Use of names rather than letters is
    generally recommended.)
  `[[' is a reserved word, hence must be separated from
    other characters by whitespace; `{' and `}' are also reserved
    words if the IGNORE_BRACES option is set.
  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
    always does what it looks like it does, so `if ( ... ) ...'
    executes the code in parentheses in a subshell.  To make this
    useful, the syntax expected after an `if', etc., is less strict
    than in other shells.
  On the other hand, `foo=*' does not perform globbing immediately on
    the right hand side of the assignment; the old behaviour now
    requires the option GLOB_ASSIGN.  (`foo=(*)' is and has always
    been the consistent way of doing this.)
  <> performs redirection of input and output to the specified file.
    For numeric globs, you now need <->.
  The command line qualifiers exec, noglob, command, - are now treated
    more like builtin commands:  previously they were syntactically
    special.  This should make it easier to perform tricks with them
    (disabling, hiding in parameters, etc.).
  The pushd builtin has been rewritten for compatibility with other
    shells.  The old behavour can be achieved with a shell function.
  The current version now uses ~'s for directory stack substitution
    instead of ='s.  This is for consistency:  all other directory
    substitution (~user, ~name, ~+, ...) used a tilde, while =<number>
    caused problems with =program substitution.
  The `HISTLIT' option was broken in various ways and has been removed:
    the rewritten history mechanism doesn't alter history lines, making
    the option unnecessary.
  History expansion is disabled in single-quoted strings, like other
    forms of expansion -- hence exclamation marks there should not be
    backslashed.
  The `HISTCHARS' variable is now `histchars'.  Currently both are
    tied together for compatibility.
  The PROMPT_SUBST option now performs backquote expansion -- hence
    you should quote these in prompts.  (SPROMPT has changed as a result.)
  Quoting in prompts has changed: close parentheses inside ternary
    expressions should be quoted with a %; history is now %!, not !.
    Backslashes are no longer special.


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,
        zsh-workers@math.gatech.edu
  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@math.gatech.edu
  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,
        zsh-announce@math.gatech.edu
  (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@math.gatech.edu
  with the *subject* line (this is a change from the old list)
        subscribe <your-email-address>
  e.g.
        Subject:  subscribe P.Stephenson@swansea.ac.uk
  and you can unsubscribe in the same way.

  The list maintainer, Richard Coleman, can be reached at
        coleman@math.gatech.edu

  The list from May 1992 to May 1995 is archived in
        ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1996-09-25  7:32 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1996-09-25  7:32 UTC (permalink / raw)
  To: zsh-announce

Archive-Name: unix-faq/shell/zsh
Last-Modified: 1996/09/25
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zsh.FAQ,v 2.19 1996/09/25 07:32:16 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996 (see end of document)

Changes since last issue:
- in A4: 3.0.0 actually released, 3.0.1 under test
- in C4: fixed `eval' splitting example, whoops
-    D3: added to and rewritten
- in Z1: added =(...) bug

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 it 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/globbing 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?
C13) How do I list all my history entries?

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? (Plus recent important changes)
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).

  (As a 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); it's 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 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 (except smallness).

  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?

  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 Etc/MACHINES in the distribution has more details.

  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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question Z2).
  Changes based on version 2.5 are very unlikely to be useful.

  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.  Also read the Etc/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 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 3.0.0 has now been relased; 3.0.1 is under test.  The new major
  number 3.0 largely reflects the considerable internal changes in zsh
  to make it more reliable, consistent and (where possible)
  compatible.  Those planning on upgrading their zsh installation
  should take a look at the list of incompatibilities at the end of
  Z1).  This is longer than usual due to enhanced sh, ksh and POSIX
  compatibility.

  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, or (most recently) to provide POSIX compliancy.


A5) Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.
  The following are known mirrors (kept frequently up to date); the
  first is the official archive site.  All are available by anonymous
  FTP.

    Hungary     ftp://ftp.cs.elte.hu/pub/zsh/
    Australia   ftp://ftp.ips.oz.au/pub/packages/zsh/
    France      ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany     ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
                ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
                ftp://ftp.prz.tu-berlin.de/pub/unix/shells/zsh
    Japan       ftp://ftp.tohoku.ac.jp/mirror/zsh/
                ftp://ftp.iij.ad.jp/pub/misc/zsh/
    Norway      ftp://ftp.uit.no/pub/unix/shells/zsh/
    Sweden      ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK          ftp://ftp.net.lut.ac.uk/zsh/
                (also by FSP at port 21)
    USA         ftp://ftp.math.gatech.edu/pub/zsh/
                ftp://uiarchive.cso.uiuc.edu/pub/packages/shells/zsh/
                ftp://ftp.sterling.com/zsh/
                ftp://ftp.rge.com/pub/shells/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.  You
  can supply these directly to a Web browser.  If you're reading this
  with a recent version of Netscape Navigator, you may just have to
  click on them.)

  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.


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).

  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.


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; differences with ksh93 will be more
  substantial.

  As a summary of the status:
    i) 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;
   ii) 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);
  iii) 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;
   iv) 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 --- see the detailed
       list below;
    v) 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 commands
       `emulate sh; setopt localoptions' in a shell function will
       turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in C4); 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_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_BUILTINS,
  SH_FILE_EXPANSION, SH_GLOB, SH_OPTION_LETTERS, SH_WORD_SPLIT (see
  question C4) 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 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', or
  if `emulate ksh' is in effect.  Capitalised words with underlines
  refer to shell options. 

  Syntax:
  * Shell word splitting: see question C4).
  * 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.
      The KSH_ARRAYS option is now available.
    Coprocesses are established by `coproc'; `|&' behaves like csh.
  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 been added to fix this.)
    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.)
  * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    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.
      [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 `**'.
    Unquoted assignments do file expansion after `:'s (intended for PATHs).
    `integer' does not allow -i.
  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'.
  * 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).
  Traps and signals:
    Traps are not local to functions.
    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.
      (Note that `>file 2>&1' is the standard Bourne shell command for
      csh's `>&file'.)
    foreach ... loops; alternative syntax for other loops.
    Alternative syntax `if ( ... ) ...', though this still doesn't
      work like csh: it expects a command in the parentheses.  Also
      `for', `which').
    $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 and ksharrays 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               "$@"            ($*: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 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.


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 :-).

  On the other hand, zsh is not strictly POSIX compliant --- though
  the latest beta version is and production version 3 will be very
  much more so than the last production version, with the appropriate
  options set or when invoked as sh or ksh --- 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 [[ ... ]],
  or (yet) arrays, for example.  Of course, they're working on bash,
  too.  Some zsh-like features are suggested for future versions.


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.
    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 --- 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/globbing for an individual 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 nglob, if you like).


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: from 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 `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 shwordsplit.
  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 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',
  or (entirely equivalent) when `emulate ksh' or `emulate sh' is in
  effect.


C5) Why do my autoloaded functions not autoload [the first time]?

  (Before version 3.0, autoloading in the Korn shell way was not
  allowed; this article is now a historical artefact and will
  eventually be removed.  Note, however, that the old form of
  autoloading is still allowed and there are no plans to remove it.)

  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.)


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 now supported).  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 :-).  Otherwise, you can use
        PROMPT=$(print "Hi Joe,\nwhat now?%# ")
  in your initialisation file.


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.


C13) 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.


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.  (You can
  see if the word would be expanded --- not completed --- by TAB by
  typing "CTRL-x g", which lists expansions.)  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 tries 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:
    - with nobeep set, that annoying beep goes away
    - with nolistbeep, beeping is only turned off for ambiguous completions
    - with autolist set, when the completion is ambiguous you get a
      list without having to type ^D
    - with listambigous, this is modified so that nothing is listed if
      there is an unambiguous prefix or suffix to be inserted
    - 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
    - with automenu, you only get the menu behaviour when you hit TAB
      again on the ambiguous completion.  
  Combinations of these are possible; for example, autolist and
  automenu together give an intuitive combination. 


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? (Plus recent important changes)

  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.
    (According to POSIX, this is not a bug with `special' builtins.)
  `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.
  The singlelinezle option has problems with prompts containing escapes.
  The `r' command does not work inside $(...) or `...` expansions.
  The file produced by =(...) substitution is removed too early if
     the substitution appears as an argument to a shell function.

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes since zsh 2.5:
  Signal traps established with the `trap' builtin are now called with
    the environment of the caller, instead of as a new function level,
    as in ksh.  Traps established as functions (e.g. `TRAPINT()
    {...}') work as before.
  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
    to be the other way around.  (Use of names rather than letters is
    generally recommended.)
  `[[' is a reserved word, hence must be separated from
    other characters by whitespace; `{' and `}' are also reserved
    words if the IGNORE_BRACES option is set.
  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
    always does what it looks like it does, so `if ( ... ) ...'
    executes the code in parentheses in a subshell.  To make this
    useful, the syntax expected after an `if', etc., is less strict
    than in other shells.
  On the other hand, `foo=*' does not perform globbing immediately on
    the right hand side of the assignment; the old behaviour now
    requires the option GLOB_ASSIGN.  (`foo=(*)' is and has always
    been the consistent way of doing this.)
  <> performs redirection of input and output to the specified file.
    For numeric globs, you now need <->.
  The command line qualifiers exec, noglob, command, - are now treated
    more like builtin commands:  previously they were syntactically
    special.  This should make it easier to perform tricks with them
    (disabling, hiding in parameters, etc.).
  The current version now uses ~'s for directory stack substitution
    instead of ='s.  This is for consistency:  all other directory
    substitution (~user, ~name, ~+, ...) used a tilde, while =<number>
    caused problems with =program substitution.
  The `HISTLIT' option was broken in various ways and has been removed:
    the rewritten history mechanism doesn't alter history lines, making
    the option unnecessary.
  History expansion is disabled in single-quoted strings, like other
    forms of expansion -- hence exclamation marks there should not be
    backslashed.
  The `HISTCHARS' variable is now `histchars'.  Currently both are
    tied together for compatibility.
  The PROMPT_SUBST option now performs backquote expansion -- hence
    you should quote these in prompts.  (SPROMPT has changed as a result.)
  Quoting in prompts has changed: close parentheses inside ternary
    expressions should be quoted with a %; history is now %!, not !.
    Backslashes are no longer special.


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,
        zsh-workers@math.gatech.edu
  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@math.gatech.edu
  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,
        zsh-announce@math.gatech.edu
  (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@math.gatech.edu
  with the *subject* line (this is a change from the old list)
        subscribe <your-email-address>
  e.g.
        Subject:  subscribe P.Stephenson@swansea.ac.uk
  and you can unsubscribe in the same way.

  The list maintainer, Richard Coleman, can be reached at
        coleman@math.gatech.edu

  The list from May 1992 to May 1995 is archived in
        ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1996-08-15 16:17 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1996-08-15 16:17 UTC (permalink / raw)
  To: Zsh announcements list

[This is early due to my being about to go on holiday for two weeks in
about ten minutes' time.  References to 3.0 are therefore a few hours
premature --- pws]

Archive-Name: unix-faq/shell/zsh
Last-Modified: 1996/08/15
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zsh.FAQ,v 2.18 1996/08/15 16:15:34 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996 (see end of document)

Changes since last issue:
- in A4: 3.0 (almost) released!
         remove remark about even-numbered minor versions
- in B1: clearer summary of sh/ksh compatibility
         removed <> incompatibility note (now see under Z1)
         ditto GLOB_ASSIGN
- in C5: note this problem is now historical
- in Z1: PRINT_EXIT_VALUE and NO_CLOBBER swapped
         changes in calling of traps
         changes now reflect 3.0; changes up to 2.5 deleted

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/globbing 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?
C13) How do I list all my history entries?

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? (Plus recent important changes)
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).

  (As a 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); it's 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 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 (except smallness).

  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?

  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 Etc/MACHINES in the distribution has more details.

  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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question Z2).
  Changes based on version 2.5 are very unlikely to be useful.

  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.  Also read the Etc/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 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 3.0 is about to be relased.  The new major number 3.0 largely
  reflects the considerable internal changes in zsh to make it more
  reliable, consistent and (where possible) compatible.  Those
  planning on upgrading their zsh installation should take a look at
  the list of incompatibilities at the end of Z1).  This is longer
  than usual due to enhanced sh, ksh and POSIX compatibility.

  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, or (most recently) to provide POSIX compliancy.


A5) Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.
  The following are known mirrors (kept frequently up to date); the
  first is the official archive site.  All are available by anonymous
  FTP.

    Hungary     ftp://ftp.cs.elte.hu/pub/zsh/
    Australia   ftp://ftp.ips.oz.au/pub/packages/zsh/
    France      ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany     ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
                ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
                ftp://ftp.prz.tu-berlin.de/pub/unix/shells/zsh
    Japan       ftp://ftp.tohoku.ac.jp/mirror/zsh/
                ftp://ftp.iij.ad.jp/pub/misc/zsh/
    Norway      ftp://ftp.uit.no/pub/unix/shells/zsh/
    Sweden      ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK          ftp://ftp.net.lut.ac.uk/zsh/
                (also by FSP at port 21)
    USA         ftp://ftp.math.gatech.edu/pub/zsh/
                ftp://uiarchive.cso.uiuc.edu/pub/packages/shells/zsh/
                ftp://ftp.sterling.com/zsh/
                ftp://ftp.rge.com/pub/shells/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.  You
  can supply these directly to a Web browser.  If you're reading this
  with a recent version of Netscape Navigator, you may just have to
  click on them.)

  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.


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).

  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.


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; differences with ksh93 will be more
  substantial.

  As a summary of the status:
    i) 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;
   ii) 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);
  iii) 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;
   iv) 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 --- see the detailed
       list below;
    v) 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 commands
       `emulate sh; setopt localoptions' in a shell function will
       turn on sh emulation for that function only.

  The classic difference is word splitting, discussed in C4); 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_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_BUILTINS,
  SH_FILE_EXPANSION, SH_GLOB, SH_OPTION_LETTERS, SH_WORD_SPLIT (see
  question C4) 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 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', or
  if `emulate ksh' is in effect.  Capitalised words with underlines
  refer to shell options. 

  Syntax:
  * Shell word splitting: see question C4).
  * 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.
      The KSH_ARRAYS option is now available.
    Coprocesses are established by `coproc'; `|&' behaves like csh.
  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 been added to fix this.)
    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.)
  * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    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.
      [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 `**'.
    Unquoted assignments do file expansion after `:'s (intended for PATHs).
    `integer' does not allow -i.
  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'.
  * 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).
  Traps and signals:
    Traps are not local to functions.
    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.
      (Note that `>file 2>&1' is the standard Bourne shell command for
      csh's `>&file'.)
    foreach ... loops; alternative syntax for other loops.
    Alternative syntax `if ( ... ) ...', though this still doesn't
      work like csh: it expects a command in the parentheses.  Also
      `for', `which').
    $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 and ksharrays 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               "$@"            ($*: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 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.


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 :-).

  On the other hand, zsh is not strictly POSIX compliant --- though
  the latest beta version is and production version 3 will be very
  much more so than the last production version, with the appropriate
  options set or when invoked as sh or ksh --- 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 [[ ... ]],
  or (yet) arrays, for example.  Of course, they're working on bash,
  too.  Some zsh-like features are suggested for future versions.


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.
    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 --- 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/globbing for an individual 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 nglob, if you like).


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: from 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 `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 shwordsplit.
  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, 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',
  or when `emulate ksh' or `emulate sh' is in effect.


C5) Why do my autoloaded functions not autoload [the first time]?

  (Before version 3.0, autoloading in the Korn shell way was not
  allowed; this article is now a historical artefact and will
  eventually be removed.  Note, however, that the old form of
  autoloading is still allowed and there are no plans to remove it.)

  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.)


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 now supported).  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 :-).  Otherwise, you can use
        PROMPT=$(print "Hi Joe,\nwhat now?%# ")
  in your initialisation file.


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.


C13) 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.


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.  (You can
  see if the word would be expanded --- not completed --- by TAB by
  typing "CTRL-x g", which lists expansions.)  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 tries 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; for example,
  autolist and automenu together give an intuitive combination.


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? (Plus recent important changes)

  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.
    (According to POSIX, this is not a bug with `special' builtins.)
  `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.
  The singlelinezle option has problems with prompts containing escapes.
  The `r' command does not work inside $(...) or `...` expansions.

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes since zsh 2.5:
  Signal traps established with the `trap' builtin are now called with
    the environment of the caller, instead of as a new function level,
    as in ksh.  Traps established as functions (e.g. `TRAPINT()
    {...}') work as before.
  The NO_CLOBBER option is now -C and PRINT_EXIT_VALUE -1; they used
    to be the other way around.  (Use of names rather than letters is
    generally recommended.)
  `[[' is a reserved word, hence must be separated from
    other characters by whitespace; `{' and `}' are also reserved
    words if the IGNORE_BRACES option is set.
  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
    always does what it looks like it does, so `if ( ... ) ...'
    executes the code in parentheses in a subshell.  To make this
    useful, the syntax expected after an `if', etc., is less strict
    than in other shells.
  On the other hand, `foo=*' does not perform globbing immediately on
    the right hand side of the assignment; the old behaviour now
    requires the option GLOB_ASSIGN.  (`foo=(*)' is and has always
    been the consistent way of doing this.)
  <> performs redirection of input and output to the specified file.
    For numeric globs, you now need <->.
  The command line qualifiers exec, noglob, command, - are now treated
    more like builtin commands:  previously they were syntactically
    special.  This should make it easier to perform tricks with them
    (disabling, hiding in parameters, etc.).
  The current version now uses ~'s for directory stack substitution
    instead of ='s.  This is for consistency:  all other directory
    substitution (~user, ~name, ~+, ...) used a tilde, while =<number>
    caused problems with =program substitution.
  The `HISTLIT' option was broken in various ways and has been removed:
    the rewritten history mechanism doesn't alter history lines, making
    the option unnecessary.
  History expansion is disabled in single-quoted strings, like other
    forms of expansion -- hence exclamation marks there should not be
    backslashed.
  The `HISTCHARS' variable is now `histchars'.  Currently both are
    tied together for compatibility.
  The PROMPT_SUBST option now performs backquote expansion -- hence
    you should quote these in prompts.  (SPROMPT has changed as a result.)
  Quoting in prompts has changed: close parentheses inside ternary
    expressions should be quoted with a %; history is now %!, not !.
    Backslashes are no longer special.


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,
        zsh-workers@math.gatech.edu
  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@math.gatech.edu
  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,
        zsh-announce@math.gatech.edu
  (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@math.gatech.edu
  with the *subject* line (this is a change from the old list)
        subscribe <your-email-address>
  e.g.
        Subject:  subscribe P.Stephenson@swansea.ac.uk
  and you can unsubscribe in the same way.

  The list maintainer, Richard Coleman, can be reached at
        coleman@math.gatech.edu

  The list from May 1992 to May 1995 is archived in
        ftp://ftp.sterling.com/zsh/zsh-list/YY-MM
  where YY-MM are the year and month in digits.

  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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. 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/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1996-07-25  8:12 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1996-07-25  8:12 UTC (permalink / raw)
  To: zsh-announce

Archive-Name: unix-faq/shell/zsh
Last-Modified: 1996/07/25
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zsh.FAQ,v 2.16 1996/07/25 08:08:47 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996 (see end of document)

Changes since last issue:
- in A3: updated configuration information;  deleted some machine-
         specific information more useful contained in Etc/MACHINES;
         referred to that.
- in A4: new version; note coming 3.0 release.
- in B1: mention `emulate' command to emulate ksh.
- in C7: another way of getting a newline into a prompt.
- in D1: mention ^xg.
         Other minor wording changes in section D.
- in Z1: most recent shell changes (mainly for POSIX), mention quoting
         in prompts, separate 2.5 and 3.0 changes.

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/globbing 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?
C13) How do I list all my history entries?

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? (Plus recent important changes)
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).

  (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 (except smallness).

  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?

  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 Etc/MACHINES in the distribution has more details.

  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 config.h.in to configure zsh automatically,
  then send the required context diffs to the list (see question Z2).
  Changes based on version 2.5 are very unlikely to be useful.

  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.  Also read the Etc/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 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).

  The release of zsh 3.0 is imminent; currently 3.0-pre3 is available.
  Major zsh sites are particularly encouraged to download this and
  report any bugs.  The new major number 3.0 largely reflects the
  considerable internal changes in zsh to make it more reliable,
  consistent and (where possible) compatible.  Those planning on
  upgrading their zsh installation when 3.0 appears should take a look
  at the list of incompatibilities at the end of Z1).  This is longer
  than usual due to enhanced sh, ksh and POSIX compatibility.

  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, or (most recently) to provide POSIX compliancy.


A5) Where do I get it?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.
  The following are known mirrors (kept frequently up to date); the
  first is the official archive site.  All are available by anonymous
  FTP.

    Hungary     ftp://ftp.cs.elte.hu/pub/zsh/
    Australia   ftp://ftp.ips.oz.au/pub/packages/zsh/
    France      ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany     ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
                ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
                ftp://ftp.prz.tu-berlin.de/pub/unix/shells/zsh
    Japan       ftp://ftp.tohoku.ac.jp/mirror/zsh/
                ftp://ftp.iij.ad.jp/pub/misc/zsh/
    Norway      ftp://ftp.uit.no/pub/unix/shells/zsh/
    Sweden      ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK          ftp://ftp.net.lut.ac.uk/zsh/
                (also by FSP at port 21)
    USA         ftp://ftp.math.gatech.edu/pub/zsh/
                ftp://uiarchive.cso.uiuc.edu/pub/packages/shells/zsh/
                ftp://ftp.sterling.com/zsh/
                ftp://ftp.rge.com/pub/shells/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.  You
  can supply these directly to a Web browser.  If you're reading this
  with a recent version of Netscape Navigator, you may just have to
  click on them.)

  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.


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).

  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.


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.

  The classic difference is word splitting, discussed in C4); 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_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, SH_GLOB, SH_WORD_SPLIT
  (see question C4) 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 and set suitable options.
  
  From 3.0, the command `emulate' is also available: `emulate ksh' and
  `emulate sh' set various options as well as changing the effect of
  single-letter option flags.

  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; those marked - have recently (i.e.,
  between the release and the beta version) become ksh-compatible.
  Capitalised words with underlines refer to shell options.

  Syntax:
  * Shell word splitting: see question C4).
  * 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.
      The KSH_ARRAYS option is available from version 2.6-beta17; note
      even in this case $array[2] with no braces refers to element 2
      of $array, etc.
    Coprocesses are established by `coproc'; `|&' behaves like csh.
  - Opening for both input and output via <> is only available from
      2.6-beta21; before it performed globbing of any sequence of
      decimal digits.  For the latter, you now need <->.
  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 (this has changed from 2.6-beta17;
      the old behaviour now requires the option GLOB_ASSIGN).
    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.)
  * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    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.
      [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 `**'.
    Unquoted assignments do file expansion after `:'s (intended for PATHs).
    `integer' does not allow -i.
  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'.
  * 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). 
  - Up to version 2.5, autoloaded functions just contained the body of
      the function: see C5).
  Traps and signals:
    Traps are not local to functions, are not reset automatically when
      called, and 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.
      (Note that `>file 2>&1' is the standard Bourne shell command for
      csh's `>&file'.)
    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 and ksharrays 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               "$@"            ($*: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 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.


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 :-).

  On the other hand, zsh is not strictly POSIX compliant --- though
  the latest beta version is and production version 3 will be very
  much more so than the last production version, with the appropriate
  options set or when invoked as sh or ksh --- 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 [[ ... ]],
  or (yet) arrays, for example.  Of course, they're working on bash,
  too.  Some zsh-like features are suggested for future versions.


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.
    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 --- 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/globbing for an individual 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 nglob, if you like).


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 `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 shwordsplit.
  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, 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',
  or when `emulate ksh' or `emulate sh' are in effect.


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 :-).  Otherwise, you can use
        PROMPT=$(print "Hi Joe,\nwhat now?%# ")
  in your initialisation file.


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.


C13) 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.


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.  (You can
  see if the word would be expanded --- not completed --- by TAB by
  typing "CTRL-x g", which lists expansions.)  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 tries 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; for example,
  autolist and automenu together give an intuitive combination.


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? (Plus recent important changes)

  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.
    (According to POSIX, this is not a bug with `special' builtins.)
  `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.
  The singlelinezle option has problems with prompts containing escapes.
  The `r' command does not work inside $(...) or `...` expansions.

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):

  Changes since zsh 2.5:
  From 3.0-pre3, [[, { and } are reserved words, hence must be
    separated from other characters by whitespace.  (This change may
    be partially backed out since it breaks many scripts.)
  The option CSH_JUNKIE_PAREN has been removed:  csh-like code now
    always does what it looks like it does, so `if ( ... ) ...'
    executes the code in parentheses in a subshell.  To make this
    useful, the syntax expected after an `if', etc., is less strict
    than in other shells.
  From 2.6.beta21, <> performs redirection of input and output to the
    specified file.  For numeric globs, you now need <->.
  From 2.6.beta20, the command line qualifiers exec, noglob, command,
    - are now treated more like builtin commands:  previously they
    were syntactically special.  This should make it easier to perform
    tricks with them (disabling, hiding in parameters, etc.).
  The current beta version now uses ~'s for directory stack
    substitution instead of ='s.  This is for consistency:  all other
    directory substitution (~user, ~name, ~+, ...) used a tilde, while
    =<number> caused problems with =program substitution.
  The `HISTLIT' option was broken in various ways and has been removed:
    the rewritten history mechanism doesn't alter history lines, making
    the option unnecessary.
  History expansion is disabled in single-quoted strings, like other
    forms of expansion -- hence exclamation marks there should not be
    backslashed.
  The `HISTCHARS' variable is now `histchars'.  Currently both are
    tied together for compatibility.
  The PROMPT_SUBST option now performs backquote expansion -- hence
    you should quote these in prompts.  (SPROMPT has changed as a result.)
  Quoting in prompts has changed: close parentheses inside ternary
    expressions should be quoted with a %; history is now %!, not !.
    Backslashes are no longer special.

  Changes present in zsh 2.5:
  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.  (Note the same is true for globbing, as mentioned
    in B1) above.)
  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.)
  The corresponding one-time switches ${~...}, ${^.,.} and ${=...},
    now force the corresponding options on for the evaluation, rather
    than toggling (double the character to force off).
  "${#foo}" (with the quotes) now gives an array length if `foo' is an
    array.  ("${(c)#foo}" gives the total character length.)
  


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,
        zsh-workers@math.gatech.edu
  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@math.gatech.edu
  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,
        zsh-announce@math.gatech.edu
  (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@math.gatech.edu
  with the *subject* line (this is a change from the old list)
        subscribe <your-email-address>
  e.g.
        Subject:  subscribe P.Stephenson@swansea.ac.uk
  and you can unsubscribe in the same way.

  The list maintainer, Richard Coleman, can be reached at
        coleman@math.gatech.edu

  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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 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/".


^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1996-06-25  7:44 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1996-06-25  7:44 UTC (permalink / raw)
  To: Zsh announcements list

Archive-Name: unix-faq/shell/zsh
Last-Modified: 1996/06/25
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zsh.FAQ,v 2.14 1996/06/25 07:41:33 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996 (see end of document)

Changes since last issue:
- in A4: new beta version
- in A5: updated archive list
- in A6: extended 'exec zsh' for login files from Bart Schaefer
- in B1: added more prominent note on word splitting; other entries updated
- in C1: mention globbing
- in Z1: <> now does redirection, not numeric globbing. *NB!*,
         exec, noglob etc. behaviour changed

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/globbing 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?
C13) How do I list all my history entries?

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? (Plus recent important changes)
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 (except smallness).

  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-beta21 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?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.
  The following are known mirrors (kept frequently up to date); the
  first is the official archive site.  All are available by anonymous
  FTP.

    Hungary     ftp://ftp.cs.elte.hu/pub/zsh/
    Australia   ftp://ftp.ips.oz.au/pub/packages/zsh/
    France      ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/
    Germany     ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
                ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
                ftp://ftp.prz.tu-berlin.de/pub/unix/shells/zsh
    Japan       ftp://ftp.tohoku.ac.jp/mirror/zsh/
                ftp://ftp.iij.ad.jp/pub/misc/zsh/
    Norway      ftp://ftp.uit.no/pub/unix/shells/zsh/
    Sweden      ftp://ftp.lysator.liu.se/pub/unix/zsh/
    UK          ftp://ftp.net.lut.ac.uk/zsh/
                (also by FSP at port 21)
    USA         ftp://ftp.math.gatech.edu/pub/zsh/
                ftp://uiarchive.cso.uiuc.edu/pub/packages/shells/zsh/
                ftp://ftp.sterling.com/zsh/
                ftp://ftp.rge.com/pub/shells/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.  You
  can supply these directly to a Web browser.  If you're reading this
  with a recent version of Netscape Navigator, you may just have to
  click on them.)

  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.


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).

  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.


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.

  The classic difference is word splitting, discussed in C4); 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_ARRAY, 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, SH_WORD_SPLIT (see
  question C4) 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 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'; those
  marked - have recently (i.e., between the release and the beta
  version) become ksh-compatible.  Capitalised words with underlines
  refer to shell options. 

  Syntax:
  * Shell word splitting: see question C4).
  * 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.
      The KSH_ARRAYS option is available from version 2.6-beta17; note
      even in this case $array[2] with no braces refers to element 2
      of $array, etc.
    Coprocesses are established by `coproc'; `|&' behaves like csh.
  - Opening for both input and output via <> is only available from
      2.6-beta21; before it performed globbing of any sequence of
      decimal digits.  For the latter, you now need <->.
  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 (this has changed from 2.6-beta17;
      the old behaviour now requires the option GLOB_ASSIGN).
    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.)
  * $PSn do not do parameter substitution by default (use PROMPT_SUBST).
    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.
      [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 `**'.
    Unquoted assignments do file expansion after `:'s (intended for PATHs).
    `integer' does not allow -i.
  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'.
  * 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). 
  Traps and signals:
    Traps are not local to functions, are not reset automatically when
      called, and 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.
      (Note that `>file 2>&1' is the standard Bourne shell command for
      csh's `>&file'.)
    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 and ksharrays 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               "$@"            ($*: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 :-).

  On the other hand, 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 [[ ... ]], or (yet) arrays, for example.  Of course, they're
  working on bash, too.  Some zsh-like features are suggested for
  future versions.


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.
    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 --- 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/globbing for an individual 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 nglob, if you like).


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 `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 shwordsplit.
  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, 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.


C13) 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.


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? (Plus recent important changes)

  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.
  `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.
  The singlelinezle option has problems with prompts containing escapes.
  The `r' command does not work inside $(...) or `...` expansions.

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):
  From 2.6.beta21, <> performs redirection of input and output to the
    specified file.  For numeric globs, you now need <->.
  From 2.6.beta20, the command line qualifiers exec, noglob, command,
    - are now treated more like builtin commands:  previously they
    were syntactically special.  This should make it easier to perform
    tricks with them (disabling, hiding in parameters, etc.).
  The current beta version now uses ~'s for directory stack
    substitution instead of ='s.  This is for consistency:  all other
    directory substitution (~user, ~name, ~+, ...) used a tilde, while
    =<number> caused problems with =program substitution.
  The keys for forward/reverse search in vi mode, / and ?, have been
    reversed: the intention is to provide vi rather than ksh compatibility.
    (This change still appears to be controversial.)
  The `HISTLIT' option was broken in various ways and has been removed:
    the rewritten history mechanism doesn't alter history lines, making
    the option unnecessary.
  History expansion is disabled in single-quoted strings, like other
    forms of expansion -- hence exclamation marks there should not be
    backslashed.
  The `HISTCHARS' variable is now `histchars'.  Currently both are
    tied together for compatibility.
  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.  (Note the same is true for globbing, as mentioned
    in B1) above.)
  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.)
  The corresponding one-time switch ${~...}, together with ${^.,.}
    and ${=...}, now force the corresponding options on for the
    evaluation, rather than toggling (double the character to force off).
  "${#foo}" (with the quotes) now gives an array length if `foo' is an
    array.  ("${(c)#foo}" gives the total character length.)
  The PROMPT_SUBST option now performs backquote expansion -- hence
    you should quote these in prompts.  (SPROMPT has changed as a result.)
  


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,
        zsh-workers@math.gatech.edu
  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@math.gatech.edu
  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,
        zsh-announce@math.gatech.edu
  (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@math.gatech.edu
  with the *subject* line (this is a change from the old list)
        subscribe <your-email-address>
  e.g.
        Subject:  subscribe P.Stephenson@swansea.ac.uk
  and you can unsubscribe in the same way.

  The list maintainer, Richard Coleman, can be reached at
        comeman@math.gatech.edu

  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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 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/".

# Local Variables: 
# xref-1:(t 3244 49 0) 
# xref-2:(t 3295 26 1) 
# xref-3:(t 5151 15 2) 
# xref-4:(t 6024 23 3) 
# xref-5:(t 7481 33 4) 
# xref-6:(t 9741 29 5) 
# xref-7:(t 10818 22 6) 
# xref-8:(t 12535 63 7) 
# xref-9:(t 15186 40 8) 
# xref-10:(t 15377 31 9) 
# xref-11:(t 16644 20 10) 
# xref-12:(t 17198 6 11) 
# xref-13:(t 18183 21 12) 
# xref-14:(t 19427 1 13) 
# xref-15:(t 19520 12 14) 
# xref-16:(t 22216 25 15) 
# xref-17:(t 22899 10 16) 
# xref-18:(t 23470 35 17) 
# xref-19:(t 27255 38 18) 
# xref-20:(t 27785 27 19) 
# xref-21:(t 28721 26 20) 
# xref-22:(t 29504 15 21) 
# xref-23:(t 29641 47 22) 
# xref-24:(t 30993 45 23) 
# xref-25:(t 31040 77 24) 
# xref-26:(t 31657 50 25) 
# xref-27:(t 32407 47 26) 
# xref-28:(t 34169 61 27) 
# xref-29:(t 36595 65 28) 
# xref-30:(t 38035 34 29) 
# xref-31:(t 38702 40 30) 
# xref-32:(t 39068 40 31) 
# xref-33:(t 39547 76 32) 
# xref-34:(t 39896 44 33) 
# xref-35:(t 40465 58 34) 
# xref-36:(t 40814 71 35) 
# xref-37:(t 41189 64 36) 
# xref-38:(t 42014 42 37) 
# xref-39:(t 42189 39 38) 
# xref-40:(t 42566 23 39) 
# xref-41:(t 43467 42 40) 
# xref-42:(t 45744 49 41) 
# xref-43:(t 46661 54 42) 
# xref-44:(t 51610 53 43) 
# xref-45:(t 52328 29 44) 
# xref-46:(t 52359 78 45) 
# xref-47:(t 53369 17 46) 
# xref-48:(t 54710 16 47) 
# xref-49:(t 56807 65 48) 
# xref-50:(t 58231 39 49) 
# xref-51:(t 58734 28 50) 
# xref-52:(369 2 (8)) 
# xref-53:(395 2 (6)) 
# xref-54:(425 2 (7)) 
# xref-55:(489 2 (9)) 
# xref-56:(565 2 (24)) 
# xref-57:(591 2 (45)) 
# xref-58:(1211 12 (6)) 
# xref-59:(1287 3 (48)) 
# xref-60:(1426 10 (6)) 
# xref-61:(1476 3 (1)) 
# xref-62:(1503 3 (2)) 
# xref-63:(1519 3 (8)) 
# xref-64:(1540 3 (8)) 
# xref-65:(1610 3 (8)) 
# xref-66:(1641 3 (6)) 
# xref-67:(1664 3 (7)) 
# xref-68:(1729 10 (8)) 
# xref-69:(1770 3 (9)) 
# xref-70:(1786 3 (15)) 
# xref-71:(1795 3 (48)) 
# xref-72:(1833 26 (18)) 
# xref-73:(1861 3 (19)) 
# xref-74:(1871 3 (20)) 
# xref-75:(1881 3 (22)) 
# xref-76:(1930 10 (23)) 
# xref-77:(1976 3 (24)) 
# xref-78:(2054 3 (25)) 
# xref-79:(2105 3 (26)) 
# xref-80:(2153 3 (27)) 
# xref-81:(2215 3 (28)) 
# xref-82:(2281 3 (29)) 
# xref-83:(2316 3 (31)) 
# xref-84:(2357 3 (32)) 
# xref-85:(2434 3 (33)) 
# xref-86:(2479 4 (34)) 
# xref-87:(2538 4 (35)) 
# xref-88:(2610 4 (36)) 
# xref-89:(2675 4 (37)) 
# xref-90:(2719 10 (38)) 
# xref-91:(2759 3 (39)) 
# xref-92:(2783 3 (40)) 
# xref-93:(2826 3 (41)) 
# xref-94:(2876 3 (42)) 
# xref-95:(2931 3 (43)) 
# xref-96:(2986 10 (44)) 
# xref-97:(3016 3 (45)) 
# xref-98:(3095 3 (48)) 
# xref-99:(3161 3 (50)) 
# xref-100:(4521 3 (6)) 
# xref-101:(5144 3 (48)) 
# xref-102:(5745 11 (48)) 
# xref-103:(8303 15 (48)) 
# xref-104:(8392 3 (6)) 
# xref-105:(10566 18 (46)) 
# xref-106:(15715 3 (27)) 
# xref-107:(16445 12 (27)) 
# xref-108:(17180 12 (27)) 
# xref-109:(20325 12 (48)) 
# xref-110:(23124 16 (47)) 
# xref-111:(23462 3 (11)) 
# xref-112:(45732 7 (42)) 
# xref-113:(52605 12 (10)) 
# xref-114:(55707 13 (12)) 
# End: 



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1996-05-24  8:01 Peter Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: Peter Stephenson @ 1996-05-24  8:01 UTC (permalink / raw)
  To: Zsh announcements list

[note list of incompatibilities in Z1 which I've extended a bit.
also changed `Frequently-Asked' to `Frequently Asked' because of what
it says in the Oxford guide to English.  still not convinced -- pws]

Archive-Name: unix-faq/shell/zsh
Last-Modified: 1996/04/25
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zsh.FAQ,v 2.12 1996/05/24 07:55:05 pws Exp $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995, 1996 (see end of document)

Changes since last issue:
- in A4: new beta version
- in A5: new archive maintainer and site (and changed acknowledgments);
         changed lut archive address
- in B1: correct typo **/foo~bar -> **/foo~*bar*;
         non-decimal integers now do have base# prefixed;
         note KSH_ARRAYS, GLOB_ASSIGN options.
- in B2: note about >& and 2>&1.
- in B5: mention bash doesn't currently have arrays :-).
- in B6: turned csh-whynot location into URL & made it http.
- in C4: mention IFS in article on splitting; correct `$var/$vble' typo.
- new C13: how to list all history entries.
- in Z1: note ~ to = change for references to directory stack;
         also vi keys for history search reversed;
         added to name of item;
         deleted bugs fixed in new version;
         added several new incompatibilities.
- in Z2: coleman@math.gatech.edu

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?
C13) How do I list all my history entries?

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? (Plus recent important changes)
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 (except smallness).

  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-beta17 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?

  The archive is now run by Zoltan Hidvegi <hzoli@cs.elte.hu>.
  The following are known mirrors (kept frequently up to date); the
  first is the official archive site.  All are available by anonymous
  FTP.

    Hungary     ftp://ftp.cs.elte.hu/pub/zsh/
    USA		ftp://ftp.math.gatech.edu/pub/zsh/
                ftp://uiarchive.cso.uiuc.edu/pub/packages/shells/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://ftp.net.lut.ac.uk/zsh/
		(also by FSP at port 21)
    Germany	ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/
                fpt://ftp.uni-trier.de/pub/unix/shell/zsh/
    Norway	ftp://ftp.uit.no/pub/unix/shells/zsh/
    Australia	ftp://ftp.ips.oz.au/pub/packages/zsh/
    Japan       ftp://ftp.tohoku.ac.jp/mirror/zsh-hzoli/

  (If you don't understand URL's, the first thing after the ftp:// is
  the hostname and the remainder after the / is the directory.  You
  can supply these directly to a Web browser.  If you're reading this
  with a recent version of Netscape Navigator, you may just have to
  click on them.)

  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.


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 (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.
      The KSH_ARRAYS option is available from version 2.6-beta17; note
      even in this case $array[2] with no braces refers to element 2
      of $array, 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 (this has changed from 2.6-beta17;
      the old behaviour now requires the option GLOB_ASSIGN).
    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.
  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.
      (Note that `>file 2>&1' is the standard Bourne shell command for
      csh's `>&file'.  If you define a function incorporating the
      latter, then look at it with the `functions' command or `which',
      you will see it has been converted to the former.)
    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 :-).

  On the other hand, 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 [[ ... ]], or (yet) arrays, for example.  Of course, they're
  working on bash, too.  Some zsh-like features are suggested for
  future versions.


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.
    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 --- 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 `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 shwordsplit.
  Arrays are also much more versatile than single strings.

  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, 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.


C13) 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.


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? (Plus recent important changes)

  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.
  `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.
  The `r' command does not work inside $(...) or `...` expansions.

  Note that a few recent changes introduce incompatibilities (these
  are not bugs):
  The current beta version now uses ~'s for directory stack
    substitution instead of ='s.  This is for consistency:  all other
    directory substitution (~user, ~name, ~+, ...) used a tilde, while
    =<number> caused problems with =program substitution.
  The keys for forward/reverse search in vi mode, / and ?, have been
    reversed: the intention is to provide vi rather than ksh compatibility.
  The `HISTLIT' option was broken in various ways and has been removed:
    the rewritten history mechanism doesn't alter history lines, making
    the option unnecessary.
  History expansion is disabled in single-quoted strings, like other
    forms of expansion -- hence exclamation marks there should not be
    backslashed.
  The `HISTCHARS' variable is now `histchars'.
  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.  (Note the same is true for globbing, as mentioned
    in B1) above.)
  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.)
  The corresponding one-time switch ${~...}, together with ${^.,.}
    and ${=...}, now force the corresponding options on for the
    evaluation, rather than toggling (double the character to force off).
  "${#foo}" (with the quotes) now gives an array length if `foo' is an
    array.  ("${(c)#foo}" gives the total character length.)
  The PROMPT_SUBST option now performs backquote expansion -- hence
    you should quote these in prompts.  (SPROMPT has changed as a result.)
  


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,
	zsh-workers@math.gatech.edu
  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@math.gatech.edu
  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,
	zsh-announce@math.gatech.edu
  (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@math.gatech.edu
  with the *subject* line (this is a change from the old list)
	subscribe <your-email-address>
  e.g.
	Subject:  subscribe P.Stephenson@swansea.ac.uk
  and you can unsubscribe in the same way.

  The list maintainer, Richard Coleman, can be reached at
	comeman@math.gatech.edu

  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.  Zsh has been in the hands of archivists Jim
Mattson, Bas de Bakker, Richard Coleman and Zoltan Hidvegi, and the
mailing list has been run by Peter Gray, Rick Ohnemus and Richard
Coleman, 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 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/".
 



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Z-Shell Frequently Asked Questions (monthly posting)
@ 1995-08-31 17:12 P.Stephenson
  0 siblings, 0 replies; 30+ messages in thread
From: P.Stephenson @ 1995-08-31 17:12 UTC (permalink / raw)
  To: Zsh announcements List

sorry this is late... you know how it is, conferences, holidays,
workshops, holidays...  it hasn't changed, anyway.

pws

Archive-Name: unix-faq/shell/zsh
Last-Modified: 1995/7/18
Submitted-By: pws@amtp.liv.ac.uk (Peter Stephenson)
Version: $Id: zsh.FAQ,v 2.5 1995/07/18 15:26:20 pypeters Exp pypeters $
Frequency: Monthly
Copyright: (C) P.W. Stephenson, 1995 (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.
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 way x?
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 Berkelely 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 recently 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).  Make sure you compile
  without any reference to /usr/ucblib in (e.g.) your LD_LIBRARY_PATH.
  The symptom of this is that globbed filenames will be missing the
  first two letters.

  *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, copy it to the
  current directory, modify that copy, and put a `-I.' argument into
  CFLAGS in Makefile for the Src subdirectory when compiling.


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-beta9 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@math.gatech.edu> 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/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.


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 $((...)) 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.
      @(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.
    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 way x?

  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, multi-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'.

  Note also the "$@" method of word splitting is always available in zsh
  functions and scripts (though strictly this does array splitting, not
  word splitting), also the substitution ${=foo} to turn on word
  splitting on variable `foo'.

  Shwordsplit is set when zsh is invoked with the name `ksh'.


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.

  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 adds newlines to lines in the history (and is
    broken in several other ways, e.g. !:x word selection; it may be
    removed).
  `time' is ignored with builtins and can't be used with {...} or (...);
    in shells with no job control the command name is blank.
  `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@math.gatech.edu 
  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@math.gatech.edu
  and one just containing announcements:  about releases, about major
  changes in the shell, or this FAQ, for example,
	zsh-announce@math.gatech.edu
  (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@math.gatech.edu
  with the *subject* line (this is a change from the old list)
	subscribe <your-email-address>
  e.g.
	Subject:  subscribe P.Stephenson@swansea.ac.uk
  and you can unsubscribe in the same way.

  The list maintainer, Richard Coleman, can be reached at
	zsh@math.gatech.edu
  (his own e-mail address is coleman@math.gatech.edu).

  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.

  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/".

-- 
Peter Stephenson <P.Stephenson@swansea.ac.uk>  Tel: +44 1792 205678 extn. 4461
WWW:  http://python.swan.ac.uk/~pypeters/      Fax: +44 1792 295324
Department of Physics, University of Wales, Swansea,
Singleton Park, Swansea, SA2 8PP, U.K.

# Local Variables: 
# xref-1:(t 2931 49 0) 
# xref-2:(t 2982 26 1) 
# xref-3:(t 4839 15 2) 
# xref-4:(t 5713 23 3) 
# xref-5:(t 7153 33 4) 
# xref-6:(t 9053 30 5) 
# xref-7:(t 10131 22 6) 
# xref-8:(t 11209 63 7) 
# xref-9:(t 13331 40 8) 
# xref-10:(t 13523 31 9) 
# xref-11:(t 14482 20 10) 
# xref-12:(t 15004 6 11) 
# xref-13:(t 19217 25 12) 
# xref-14:(t 20377 35 13) 
# xref-15:(t 24102 38 14) 
# xref-16:(t 24632 27 15) 
# xref-17:(t 25561 26 16) 
# xref-18:(t 26349 47 17) 
# xref-19:(t 27683 45 18) 
# xref-20:(t 27730 68 19) 
# xref-21:(t 28178 50 20) 
# xref-22:(t 28914 44 21) 
# xref-23:(t 30652 61 22) 
# xref-24:(t 32663 65 23) 
# xref-25:(t 34103 34 24) 
# xref-26:(t 34750 40 25) 
# xref-27:(t 35108 40 26) 
# xref-28:(t 35576 76 27) 
# xref-29:(t 35925 44 28) 
# xref-30:(t 36843 71 29) 
# xref-31:(t 37218 64 30) 
# xref-32:(t 38043 39 31) 
# xref-33:(t 38420 23 32) 
# xref-34:(t 39321 42 33) 
# xref-35:(t 41570 49 34) 
# xref-36:(t 42487 54 35) 
# xref-37:(t 47268 53 36) 
# xref-38:(t 47986 29 37) 
# xref-39:(t 48017 46 38) 
# xref-40:(t 49358 17 39) 
# xref-41:(t 49412 16 40) 
# xref-42:(t 50952 65 41) 
# xref-43:(t 52363 28 42) 
# xref-44:(t 52731 28 43) 
# xref-45:(982 12 (6)) 
# xref-46:(1058 3 (41)) 
# xref-47:(1197 10 (6)) 
# xref-48:(1247 3 (1)) 
# xref-49:(1274 3 (2)) 
# xref-50:(1290 3 (8)) 
# xref-51:(1311 3 (8)) 
# xref-52:(1381 3 (8)) 
# xref-53:(1412 3 (6)) 
# xref-54:(1435 3 (7)) 
# xref-55:(1501 10 (8)) 
# xref-56:(1542 3 (9)) 
# xref-57:(1559 3 (12)) 
# xref-58:(1568 3 (13)) 
# xref-59:(1606 26 (14)) 
# xref-60:(1634 3 (15)) 
# xref-61:(1645 3 (16)) 
# xref-62:(1655 3 (25)) 
# xref-63:(1704 10 (18)) 
# xref-64:(1750 3 (19)) 
# xref-65:(1819 3 (20)) 
# xref-66:(1870 3 (21)) 
# xref-67:(1915 3 (22)) 
# xref-68:(1977 3 (23)) 
# xref-69:(2043 3 (24)) 
# xref-70:(2078 3 (26)) 
# xref-71:(2119 3 (27)) 
# xref-72:(2196 3 (28)) 
# xref-73:(2241 4 (29)) 
# xref-74:(2300 4 (29)) 
# xref-75:(2372 4 (41)) 
# xref-76:(2438 10 (31)) 
# xref-77:(2478 3 (32)) 
# xref-78:(2502 3 (33)) 
# xref-79:(2545 3 (34)) 
# xref-80:(2595 3 (35)) 
# xref-81:(2650 3 (36)) 
# xref-82:(2705 10 (37)) 
# xref-83:(2735 3 (38)) 
# xref-84:(2782 3 (41)) 
# xref-85:(2848 3 (43)) 
# xref-86:(4208 3 (6)) 
# xref-87:(4832 3 (41)) 
# xref-88:(5433 11 (41)) 
# xref-89:(7986 17 (41)) 
# xref-90:(8077 3 (6)) 
# xref-91:(9879 18 (39)) 
# xref-92:(14183 12 (22)) 
# xref-93:(14913 12 (22)) 
# xref-94:(17485 11 (13)) 
# xref-95:(20031 16 (40)) 
# xref-96:(20369 3 (11)) 
# xref-97:(41558 7 (35)) 
# xref-98:(48231 12 (10)) 
# End: 


^ permalink raw reply	[flat|nested] 30+ messages in thread

end of thread, other threads:[~1998-10-26 11:23 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1996-12-19  9:55 Z-Shell Frequently Asked Questions (monthly posting) Peter Stephenson
  -- strict thread matches above, loose matches on Subject: below --
1998-10-26 10:09 Peter Stephenson
1998-09-24  9:46 Peter Stephenson
1998-08-21  8:33 Peter Stephenson
1998-07-27 13:54 Peter Stephenson
1998-06-25 16:32 Richard Coleman
1998-04-24 17:40 Peter Stephenson
1998-03-24  8:55 Peter Stephenson
1998-03-02  9:16 Peter Stephenson
1998-01-26  9:06 Peter Stephenson
1997-12-19 10:45 Peter Stephenson
1997-11-25  8:45 Peter Stephenson
1997-10-27 16:08 Peter Stephenson
1997-09-25 12:36 Peter Stephenson
1997-09-03  8:09 Peter Stephenson
1997-07-28 10:00 Peter Stephenson
1997-06-25 13:49 Peter Stephenson
1997-05-29  9:18 Peter Stephenson
1997-04-24 10:24 Peter Stephenson
1997-03-24  8:57 Peter Stephenson
1997-02-25 10:45 Peter Stephenson
1997-01-24 13:29 Peter Stephenson
1996-11-25  9:13 Peter Stephenson
1996-10-24  9:15 Peter Stephenson
1996-09-25  7:32 Peter Stephenson
1996-08-15 16:17 Peter Stephenson
1996-07-25  8:12 Peter Stephenson
1996-06-25  7:44 Peter Stephenson
1996-05-24  8:01 Peter Stephenson
1995-08-31 17:12 P.Stephenson

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).