setterm is a command that sets various characteristics of your terminal (say, each virtual console), such as the keyboard repeat rate, tab stops, and text colors.

Most people use this command to change the colors for each virtual console. In this way, you can tell which virtual console you’re currently looking at based on the text color. (Notice that this only applies to the virtual consoles in text mode. X11 windows with shells in them are configured differently.)

For example, to change the color of the current terminal to white text on a blue background, use the command:

$ setterm -foreground white -background blue

Some programs and actions cause the terminal attributes to be reset to their default values. In order to store the current set of attributes as the default, use:

$ setterm -store

setterm provides many options (most of which you will probably never use). See the setterm(1) manual page or use setterm -help for more information.

If your terminal settings get really messed up (as happens, for example, if you try to look at the contents of a binary file with cat), you can try typing setterm -reset blindly, which should reset your terminal to reasonable settings.

In "Shells,” earlier in this chapter, we discussed the various shells available for Linux, but shells can also be powerful and consummately flexible programming tools. The differences come through most clearly when it comes to writing shell scripts . The Bourne shell and C shell command languages are slightly different, but the distinction is not obvious with most normal interactive use. The Z shell command language is a superset of the Bourne shell. Many of the distinctions arise only when you attempt to use bizarre, little-known features of either shell, such as word substitution or some of the more oblique parameter expansion functions.

The most notable difference between Bourne and C shells is the form of the various flow-control structures, including if ...then and while loops. In the Bourne shell, an if ...then takes the following form:

if list
then
  commands
elif list
then
  commands
else
  commands
fi

where list is just a sequence of commands to be used as the conditional expression for the if and elif (short for “else if”) commands. The conditional is considered to be true if the exit status of the list is zero (unlike Boolean expressions in C, in shell terminology an exit status of zero indicates successful completion). The commands enclosed in the conditionals are simply commands to execute if the appropriate list is true. The then after each list must be on a new line to distinguish it from the list itself; alternately, you can terminate the list with a ;. The same holds true for the commands.

An example is:

if [ "$PS1" ]; then
  PS1="\h:\w% "
fi

This sequence checks to see whether the shell is a login shell (that is, whether the prompt variable PS1 is set), and if so, it resets the prompt to \h:\w%, which is a prompt expansion standing for the hostname followed by the current working directory. For example:

loomer:/home/loomer/mdw%

The [...] conditional appearing after the if is a bash built-in command, shorthand for test. The test command and its abbreviated equivalent provide a convenient mechanism for testing values of shell variables, string equivalence, and so forth. Instead of using [...], you could call any set of commands after the if, as long as the last command’s exit value indicates the value of the conditional.

Under tcsh, an if ...then compound statement looks like the following:

if (expression) then
  commands
else if (expression) then
  commands
else
  commands
endif

The difference here is that the expression after the if is an arithmetic or logical expression evaluated internally by tcsh, whereas with bash the conditional expression is a command, and the expression returns true or false based on the command’s exit status. Within bash, using test or [...] is similar to an arithmetic expression as used in tcsh.

With tcsh, however, if you wish to run external commands within the expression, you must enclose the command in braces: {command}.

The equivalent of the previous bash sequence in tcsh is:

if ($?prompt) then
  set prompt="%m:%/%% "
endif

where tcsh’s own prompt special characters have been used. As you can see, tcsh boasts a command syntax similar to the C language, and expressions are arithmetically and logically oriented. In bash, however, almost everything is an actual command, and expressions are evaluated in terms of exit-status values. There are analogous features in either shell, but the approach is slightly different.

A similar change exists with the while loop. In bash, this takes the following form:

while list
do
  commands
done

You can negate the effect by replacing the word while with until. Again, list is just a command sequence to be executed, and the exit status determines the result (zero for success and nonzero for failure). Under tcsh the loop looks like this:

while (expression)
  commands
end

where expression is a logical expression to be evaluated within tcsh.

This example should be enough to get a head start on understanding the overall differences of shell scripts under bash and tcsh. We encourage you to read the bash(1) and tcsh(1) manual pages (although they serve more as a reference than a tutorial) and Info pages, if you have them available. Various books and tutorials on using these two shells are available as well; in fact, any book on shell programming will do, and you can interpolate the advanced features of bash and tcsh into the standard Bourne and C shells using the manual pages. Learning the bash Shell by Cameron Newham and Bill Rosenblatt and Using csh and tcsh by Paul DuBois (both from O’Reilly) are also good investments.

The Z shell (zsh) is particularly appreciated for its many features that make you more efficient on the command line. To start with, zsh does not have one command prompt, but rather two: one for the lefthand side, and one for the righthand side. The lefthand one is set as usual by assigning to the environment variable PROMPT; for the righthand side, the environment variable RPROMPT is used. For example:

export PROMPT="%n@%m"
export RPROMPT="%~%"

gives you your username and hostname to the left of the entry line, and the current directory to the right. The smart thing about the right prompt is that it disappears when you “need the space”; that is, it gets out of the way when your typing comes close.

An interesting thing about zsh is the many, many options that you can set with the setopt command. The manual page zshoptions will list all of them, but we’d like to mention at least one very useful one here, the ALL_EXPORT option. By specifying:

setopt ALL_EXPORT

any environment variable that you set will automatically be exported. This is very useful if you, like us, keep setting environment variables for processes other than the shell and then forget to export them, and wonder why they are not picked up by the processes started from the shell. You can turn this off with setopt noALL_EXPORT.

You have already seen how to use the cd command. Of course, zsh knows about cd as well, but it does some other interesting stuff. For example, if you specify -- (a dash) as the argument, you will be returned to the working directory that was your working directory before the last cd command (for the following example, we have moved the display of the current directory back to the lefthand side):

      ~%> cd kdesvn/kdelibs/kdecore
      ~/kdesvn/kdelibs/kdecore> pwd
/home/kalle/kdesvn/kdelibs/kdecore
      ~/kdesvn/kdelibs/kdecore> cd /usr/local
      /usr/local> cd -
~/kdesvn/kdelibs/kdecore
~/kdesvn/kdelibs/kdecore>

Also, if you type in a command that zsh does not recognize (i.e., it is neither an executable in your PATH nor a built-in command), but there is a directory with the name of that command, zsh will interpret that as a request to change the working directory to that directory:

~> Documents
~/Documents>

Another neat feature is the autocorrection of commands. If you, like us, keep typing mroe instead of more, turn on the autocorrection by issuing:

setopt CORRECT

Now zsh will come up with suggestions if it cannot understand your command:

      ~/Documents> mroe /etc/motd
      zsh: correct 'mroe' to 'more' [nyae]? y
Welcome to tigger...

Even when it comes to completion, zsh has a number of features that sets it apart from other shells. There are few things that it does not attempt completion on. You know already that you can press the Tab key half way during typing a command or filename, and most shells will attempt to complete what you have started. But zsh also has the following features:

rpm --erase <TAB> # shows installed packages

rpm -q<TAB> # shows suboptions of the 'q' option

fg % <TAB> # shows the names of background processes that could be
            promoted to foreground processes

cvs checkout <TAB> # shows possible modules to check out

make -f Makefile <TAB> # shows the targets in Makefile

cd <TAB> # shows directories only

There are many, many more completions built into zsh, and you can even program your own. The manual page zshcompctl tells you all about this.