"Linux Gazette...making Linux just a little more lovable!"

My first shell, though I didn't know it by that name, was command.com in DOS. It couldn't do much more than simply execute commands, but it served my needs at the time. Later on I discovered the commercial DOS command.com replacement 4DOS, by JP Software. This came as something of a revelation to this novice computer user. Suddenly I could do file-name completion, use aliases, and change to a directory on a different drive with simple keystrokes. Wow, I thought, how did those programmers at JP Software think of so many clever command-line functions and options!

I later learned that 4Dos (and its OS/2 sibling, 4OS/2) were influenced and inspired by the various shells used on unix systems. When I first began using Linux I was able to learn the rudiments of the Bash shell fairly quickly because of past experience with the JP Software products.

New users of Linux are encouraged (in part by distribution defaults) to use the GNU Bash shell. Bash has been polished over the years to the point that any remaining bugs probably affect only the skilled users who make use of its more arcane functions. Bash, and its reduced-function alias sh, work well as agents for executing shell scripts. As a command shell in a console or an xterm Bash provides many labor-saving shortcuts and functions, most of which beginning users don't use. Reading the voluminous Bash documentation I began to realize that using Bash the way most users do, i.e. as the default login and command shell, touches only a small fraction of its capabilities. O'Reilly has published a three-hundred-page book detailing Bash shell programming and usage !

Recently Chet Ramey, the maintainer of Bash, released version 2.00 to the FTP sites. After reading the list of changes and bug-fixes I concluded that advanced users will be more appreciative of the release than will common end-users, like myself. It's an odd feeling to learn of a feature by finding out that bugs have been fixed in it! The documentation for Bash is extensive; the man pages are available now in HTML format (in a separate file called bash-doc-2.0.tar.gz). Bash can be obtained both from Sunsite and its mirrors (in /pub/gnu) and from the main GNU site.

I remember the first time I navigated my way through the Slackware installation menus; being offered the option to install tcsh and zsh made me realize how little I knew. What were these alternative shells? Evidently some users preferred them to bash, but why?

All of the shells discussed in this article are extensively documented, but that very feature, as helpful as it is to advanced users, can make it difficult to get a rough idea of why one shell might be preferable to another. Luckily it isn't hard to install another shell just to try it out. Edit the file /etc/shells (logged in as root) and add a line with the path to the new shell. Then execute the command chsh; a default choice will be offered to you. Ignore it and type in the name (with path) of the new shell. You'll have to log out and log back in to activate the new shell.

In issue 12 of the Gazette wrote a good introductory article about Tcsh; this article also shows how Jesper's program Dotfile Generator can be used to help write Tcsh resource files without spending many hours reading the manual. Since that article appeared a new version of the Dotfile Generator has been released which includes a module to generate Bash resource files. I highly recommend this program, which is available from this site. The Dotfile Generator won't overwrite your existing files; it writes to another filename (such as .bashrc-dotfile) This file can then be edited; I usually transplant sections to my original files to try things out. The Dotfile Generator allows you to try various features of your shell without having to learn the precise rc-file syntax first. 1

A little resource-file editing will be necessary to change over to Tcsh. The aliases which you have defined can be transplanted from your ~/.bashrc to ~/.cshrc without alteration, but the environment variables are another matter. Bash (and other ``Bourne-compatible'' shells, such as Zsh) uses a different format for this than Tcsh. As an example, export INFODIR=/mt/info in the ~/.bash_profile would have to be changed to setenv INFODIR /mt/info in ~/.tcshrc. I recommend going to the trouble of transferring aliases and environment variables if you want to give Tcsh a try. If you don't you'll be continually distracted by commands which don't work, and you will tend to blame the shell.

The one feature which really stands out (if you're accustomed to Bash) is the spelling-correction. When either a filename or command is misspelled the shell pops up a suggested correction. If you tend to type commands quickly and press ``enter'' without rereading what you've typed you'll love this. Sometimes the shell is wrong, though, but pressing n rather than y will force the shell to try and execute what you actually typed.

After using Tcsh for a while, you may find yourself thinking, ``I really don't want to switch completely to Tcsh; if only Bash had that spelling correction built in!'' Zsh might be what you want.

Zsh is a Bourne-compatible shell like Bash but with several csh-like features added. It also resembles the proprietary Korn shell as well as Pdksh, a free Korn-shell clone. It's not at all difficult to adapt Bash configuration files so that Zsh can use them as the syntax is nearly identical. ~/.zshenv is analogous to ~/.bash_profile, while ~/.zshrc corresponds to ~/.bashrc.

The first thing you notice when using Zsh for the first time is the prompt, which by default looks like this:

<machine-name>#                               /usr/local/src

As you can see, the current directory is on the right hand side of the screen, giving more room for a command before the line breaks. When a typed command reaches the path on the right the path disappears to make room.

The spelling correction behavior seems to be identical to that of Tcsh. As with Bash and Tcsh, completion of paths and filenames is bound to the tab key. Zsh has an elaborate implementation of programmable completion, in which file-type specific behavior for completions can be set in the resource-files.

One helpful aspect of Zsh's completion behavior deserves notice. Often there will be a filename and a subdirectory with the same prefix, say if a file called sample-2.01.tar.gz is unarchived into the directory in which it resides, creating in the process a new subdirectory called sample-2.01. Try the command cd sam<TAB> with some shells and you will be asked if you want to change directory to sample-2.01.tar.gz or to sample-2.01. Zsh is smart enough to realize that directories don't normally have a tar.gz suffix, and changes to the directory without comment or question.

The Zsh distribution contains extensive help-files which are in the Info format, allowing them to be browsed from within Emacs or with a stand-alone Info reader. After reading these documents I came away with the impression that Zsh probably rivals Bash in the number of arcane features and programming abilities. If you would like to see examples of the complexity possible in Zsh configuration, take a look at The Next Level, a package of Linux configuration files with explanation which has become a part of recent Red Hat distributions. The Next Level's author, Greg J. Badros, has included an elaborate set of Zsh resource files. I found them to be quite informative as an example of what's possible with this shell.

Zsh seems to be under active development; version 3.00 was released last year, and there have been minor releases since then. There is a Zsh home-page here which can serve as a good introduction.

These shells certainly aren't hard to find; most distributions I've seen include preconfigured packages for all three of them. One caveat: if you decide to settle on Tcsh or Zsh as your login shell don't remove Bash, or its symlink /bin/sh. Many shell scripts rely on /bin/sh in order to run properly. Some packages, such as the Andrew User Interface System, like to have csh available, so if you have the disk-space Tcsh, along with its symlink /bin/csh may as well be retained even if it's not your login shell.

The choice of shells reminds me of the eternal debate between vi-users and emacs-users. A decision depends more on working-style and personality than logic; try them all and see which one fits!