In this section, we will look at some of the more advanced things you can do with your trusty shell, the Linux command-line interpreters.
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:
iflist
thencommands
eliflist
thencommands
elsecommands
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
) thencommands
else if (expression
) thencommands
elsecommands
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:
whilelist
docommands
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.
Get Running Linux, 5th Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.