<html>
<head>
<title>A User's Guide to the Z-Shell </title>
</head>
<body >
<hr>
<ul>
<li> <a href="zshguide02.html">Next chapter</a>
<li> <a href="zshguide.html">Table of contents</a>
</ul>
<hr>
<a name="intro"></a><a name="l1"></a>
<h1>Chapter 1: A short introduction</h1>
<p>The Z-Shell, or `zsh' for short, is a command interpreter for UNIX systems,
or in UNIX jargon, a `shell', because it wraps around the commands you use.
More than that, however, zsh is a particularly powerful shell --- and it's
free, and under regular maintenance --- with lots of interactive features
allowing you to do the maximum work with the minimum fuss. Of course, for
that you need to know what the shell can do and how, and that's what this
guide is for.
<p>The most basic basics: I shall assume you have access to a UNIX system,
otherwise the rest of this is not going to be much use. Actually, there
are ports of zsh to Windows, and versions which compile under Windows/NT in
an appropriate environment, but I won't be talking about those as I don't
use them. I'll also assume some basic knowledge of UNIX; you should know
how the filesystem works, i.e. what <code>/home/users/pws/.zshrc</code> and
(../file) mean, and some basic commands, for example <code>ls</code>, and you should
have experience with using <code>rm</code> to delete completely the wrong file by
accident, and that sort of thing. In something like `<code>rm file</code>', I will
often refer to the `command' (<code>rm</code>, of course) and the `argument(s)'
(anything else coming after the command which is used by it), and to the
complete thing you typed in one go as the `command line'.
<p>You're also going to need zsh itself; if you're reading this, you may well
already have it, but if you don't, you or your system administrator should
read <a href="zshguide08.html#appa">Appendix A</a>. For now, we'll suppose you're sitting in
front of a terminal with zsh already running.
<p>Now to the shell. After you log in, you probably see some prompt (a
serious of symbols on the screen indicating that you can input a command),
such as `<code>$</code>' or `<code>%</code>', possibly with some other text in front ---
later, we'll see how you can change that text in intersting ways. That
prompt comes from the shell. Type `<code>print hello</code>', then backspace over
`<code>hello</code>' and type `<code>goodbye</code>'. Now hit the `Return' key (or `Enter'
key, I'll just say <code><RET></code> from now on, likewise <code><TAB></code> for the tab
key, <code><SPC></code> for the space key); unless you have a serious
practical-joker problem on your system, you get `<code>goodbye</code>', and then the
shell comes back with another prompt. All of the time up to when you hit
<code><RET></code>, you were interacting with the shell and its editor, called
`Z-Shell Line Editor' or `zle' for short; only then did the shell go away
and tell the <code>print</code> command to print out a message. So you can see that
the shell is important.
<p>However, if all you're doing is typing simple commands like that, why do
you need anything complicated? In that case, you don't; but real life's
not that simple. In the rest of this guide, I'll describe how, with zsh's
help, you can:
<p><dl>
<p></p><dt><strong></strong><dd> customise the environment in which you work, by using startup files,
<p></p><dt><strong></strong><dd> write your own commands to shorten tasks and store things in
shell variables (`parameters') so you don't have to remember them,
<p></p><dt><strong></strong><dd> use zle to minimise the amount of typing you have to do ---
in zsh, you can even edit small files that way,
<p></p><dt><strong></strong><dd> pick the files you want to use for a particular command such
as <code>mv</code> or <code>ls</code> using zsh's very sophisticated filename generation
(known colloquially as `globbing') system,
<p></p><dt><strong></strong><dd> tell the editor what sort of arguments you use with particular
commands, so that you only need to type part of the name and it will
complete the rest, using zsh's unrivalled programmable completion
system,
<p></p><dt><strong></strong><dd> use the extra add-ons (`modules') supplied with the latest version
of zsh to do other things you usually can't do in a shell at all.
</dl>
<p>That's only a tiny sample. Since there's so much to say, this guide will
concentrate on the things zsh does best, and in particular the things it
has which other shells don't. The next chapter gives a few of the basics,
by trying to explain how to set the shell up the way you want it. Like the
rest of the guide, it's not intended to be exhaustive, for which you should
look at the shell manual.
<p>Some other things you should probably know straight away. First, the shell
is always running, even when the command you typed is running, too; the
shell simply hangs around waiting for it to finish: you may know from other
shells about putting commands in the <strong>background</strong> by putting an `<code>&</code>'
after the command, which means that the shell doesn't wait for them to
finish. The shell is there even if the command's in the foreground, but in
this case doing nothing.
<p>Second, it doesn't just run other people's commands, it has some of its
own, called <strong>builtin commands</strong> or just <strong>builtins</strong>, and you can even add
your own commands as lists of instructions to the shell called
<strong>functions</strong>; builtins and functions always run in the shell itself.
That's important to know, because things which don't run in the shell
itself can't affect it, and hence can't alter parameters, functions,
aliases, and all the other things I shall talk about.
<p><a name="l2"></a>
<h2>1.1: Other shells and other guides</h2>
<p>If you want a basic grounding in how shells work, what their syntax is
(i.e. how to write commands), and how to write scripts and functions, you
should read one of the many books on the subject. In particular, you will
get most out of a book that describes the Korn shell (ksh), as zsh is very
similar to this --- so similar that it will be worth my while pointing out
differences as we go along, since they can confuse ksh users. Recent
versions of zsh can emulate ksh (strictly, the 1988 version of ksh,
although there are increasingly features from the 1993 version) quite
closely, although it's not perfect, and less perfect the more closely you
look. However, it's important to realise that if you just start up any old
zsh there's is no guarantee that it is set up to work like ksh. I will
talk about emulation a bit more later on.
<p>A few other shells are worth mentioning. The grandfather of all UNIX
shells is sh, now known as the Bourne shell but originally just referred to
as `the shell'. The story is similar to ksh: zsh can emulate sh quite
closely (much more closely than ksh, since sh is considerably simpler), but
in general you need to make sure it's set up to do that before you can be
sure it will emulate sh.
<p>You may also come across the `Bourne-Again Shell', bash. This is a
freely-available enhancement of sh --- but it is not always enhanced along
the lines of ksh, and hence in many ways it is very different from zsh. On
some free UNIX-like systems such as Linux, the command sh is really bash,
so there you should be extra careful when trying to ensure that something
which runs under the so-called `sh' will also run under zsh.
<p>Some more modern operating systems talk about `the POSIX shell'. This is
an attempt to standardize UNIX shells; it's most like the Korn shell,
although, a bit confusingly, it's often just called sh, because the
standard says that it should be. Usually, this just means you get a bit
extra free with your sh and it still does what you expect. Zsh has made
some attempts to fit the standard, but you have to tell it to --- again,
simply starting up `zsh' will not have the right settings for that.
<p>There is another common family of shells with, unfortunately, incompatible
syntax. The source of this family is the C-Shell, csh, so called because
its syntax looks more like the C programming language. This became
widespread when the only other shell available was sh because it had better
interactive features, such as job control. It was then enhanced to make
tcsh, which has many of the interactive features you will also find in zsh,
and so became very popular. Despite these common features, the syntax of
zsh is very different, so you should not try and use csh/tcsh commands
beyond the very simplest in zsh; but if you are a tcsh user, you will find
virtually every capability you are used to in zsh somewhere, plus a lot
more.
<p><a name="l3"></a>
<h2>1.2: Versions of zsh</h2>
<p>At the time of writing, the most recent version of zsh available for
widespread use was 3.0.7. There are also versions of zsh 3.1 up to 3.1.6
and beyond; these are considered `in beta', in other words not yet fully
tested. However, there are many new features beyond version 3.0, and some
which will appear only in 3.1.7, so that it seems important to mention them
here. I will try to make clear which these new features are. Otherwise,
you can assume everything I talk about works in version 3.0.7, and probably
in 3.0.5 since the two subsequent releases were mainly concerned with
fixing bugs.
<p>One notable feature of zsh is the completion of command line arguments.
The system has changed in 3.1.6 and 3.1.7 to make it a lot more
configurable, and (provided you keep your wits about you) a little less
obscure. I therefore won't describe the old completion system, which used
the `compctl' command, in any detail. See the chapter `Completion, old and
new' for more.
<p><a name="c2"></a>
<hr>
<ul>
<li> <a href="zshguide02.html">Next chapter</a>
<li> <a href="zshguide.html">Table of contents</a>
</ul>
<hr>
</body>
</html>
