A shell provides many mechanisms to customize your work environment. As mentioned above, a shell is more than a command interpreter--it is also a powerful programming language. Although writing shell scripts is an extensive subject, we'd like to introduce you to some of the ways that you can simplify your work on a Linux system by using these advanced features of the shell.

As mentioned before, different shells use different syntaxes when executing shell scripts. For example, Tcsh uses a C-like syntax, while Bourne shells use another type of syntax. In this section, we won't be encountering many differences between the two, but we will assume that shell scripts are executed using the Bourne shell syntax

1 Shell scripts

Let's say that you use a series of commands often and would like to save time by grouping all of them together into a single ``command''. For example, the three commands

concatenates the files chapter1 , chapter2 , and chapter3 and places the result in the file book . The second command displays a count of the number of lines in book , and the third command lp book prints book .

Rather than type all these commands, you can group them into a shell script . The shell script used to run all these commands might look like this:

Let's look at this shell script. The first line, `` #!/bin/sh '', identifies the file as a shell script and tells the shell how to execute the script. It instructs the shell to pass the script to /bin/sh for execution, where /bin/sh is the shell program itself. Why is this important? On most Linux systems, /bin/sh is a Bourne-type shell, like bash . By forcing the shell script to run using /bin/sh , you ensure that the script will run under a Bourne-syntax shell (rather than a C shell). This will cause your script to run using the Bourne syntax even if you use tcsh (or another C shell) as your login shell.

  The second line is a comment . Comments begin with the character `` # '' and continue to the end of the line. Comments are ignored by the shell--they are commonly used to identify the shell script to the programmer and make the script easier to understand.

The rest of the lines in the script are just commands, as you would type them to the shell directly. In effect, the shell reads each line of the script and runs that line as if you had typed it at the shell prompt.

    Permissions are important for shell scripts. If you create a shell script, make sure that you have execute permission on the script in order to run it. When you create text files, the default permissions usually don't include execute permission, and you must set them explicitly. Briefly, if this script were saved in the file called makebook , you could use the command

to give yourself execute permission for the shell script makebook .

You can use the command

to run all the commands in the script.

2 Shell variables and the environment.

A shell lets you define variables , as do most programming languages. A variable is just a piece of data that is given a name.

tcsh , as well as other C-type shells, use a different mechanism for setting variables than is described here. This discussion assumes the use of a Bourne shell like bash . See the tcsh manual page for details.

When you assign a value to a variable (using the `` = '' operator), you can access the variable by prepending a `` $ '' to the variable name, as demonstrated below.

The variable foo is given the value hello there . You can then refer to this value by the variable name prefixed with a `` $ '' character. For example, the command

produces the same results as

These variables are internal to the shell, which means that only the shell can access them. This can be useful in shell scripts; if you need to keep track of a filename, for example, you can store it in a variable, as above. Using the set command displays a list of all defined shell variables.

However, the shell lets you export variables to the environment . The environment is the set of variables that are accessible by all commands that you execute. Once you define a variable inside the shell, exporting it makes the variable part of the environment as well. Use the export command to export a variable to the environment.

Again, here we differ between bash and tcsh . If you use tcsh , another syntax is used for setting environment variables (the setenv command is used). See the tcsh manual page for more information.

The environment is very important to the UNIX system. It lets you configure certain commands just by setting variables which the commands know about.

Here's a quick example. The environment variable PAGER is used by the man command and it specifies the command to use to display manual pages one screenful at a time. If you set PAGER to the name of a command, it uses that command to display the man pages, instead of more (which is the default).

Set PAGER to `` cat ''. This causes output from man to be displayed to the screen all at once, without pausing between pages.

Now, export PAGER to the environment.

Try the command man ls . The man page should fly past your screen without pausing for you.

Now, if we set PAGER to `` more '', the more command is used to display the man page.

Note that we don't have to use the export command after we change the value of PAGER . We only need to export a variable once; any changes made to it thereafter will automatically be propagated to the environment.

It is often necessary to quote strings in order to prevent the shell from treating various characters as special. For example, you need to quote a string in order to prevent the shell from interpreting the special meaning of characters such as ``*'', ``?'' or a space. There are many other characters that may need to be protected from interpretation. A detailed explanation and desription of quoting is described in SSC's Bourne Shell Tutorial .

The manual pages for a particular command tell you if the command uses any environment variables. For example, the man man page explains that PAGER is used to specify the pager command.

Some commands share environment variables. For example, many commands use the EDITOR environment variable to specify the default editor to use when one is needed.

The environment is also used to keep track of important information about your login session. An example is the HOME environment variable, which contains the name of your home directory.

Another interesting environment variable is PS1 , which defines the main shell prompt. For example,

To set the prompt back (which contains the current working directory followed by a `` # '' symbol),

The bash manual page describes the syntax used for setting the prompt.

The PATH environment variable.

When you use the ls command, how does the shell find the ls executable itself? In fact, ls is in /bin on most systems. The shell uses the environment variable PATH to locate executable files for commands you type.

For example, your PATH variable may be set to

This is a list of directories for the shell to search, each directory separated by a `` : ''. When you use the command ls , the shell first looks for /bin/ls , then /usr/bin/ls , and so on.

Note that the PATH has nothing to do with finding regular files. For example, if you use the command

the shell does not use PATH to locate the files foo and bar --those filenames are assumed to be complete. The shell only uses PATH to locate the cp executable.

This saves you time, and means that you don't have to remember where all the command executables are stored. On many systems, executables are scattered about in many places, such as /usr/bin , /bin , or /usr/local/bin . Rather than give the command's full pathname (such as /usr/bin/cp ), you can set PATH to the list of directories that you want the shell to automatically search.

Notice that PATH contains `` . '', which is the current working directory. This lets you create a shell script or program and run it as a command from your current directory without having to specify it directly (as in ./makebook ). If a directory isn't in your PATH , then the shell will not search it for commands to run; this also includes the current directory.

3 Shell initialization scripts.

In addition to the shell scripts that you create, there are a number of scripts that the shell itself uses for certain purposes. The most important of these are initialization scripts , which are scripts executed by the shell when you log in.

The initialization scripts themselves are simply shell scripts. However, they initialize your environment by executing commands automatically when you log in. If you always use the mail command to check your mail when you log in, you place the command in the initialization script so it will execute automatically.

Both bash and tcsh distinguish between a login shell and other invocations of the shell. A login shell is a shell invoked when you log in. Usually, it's the only shell you'll use. However, if you ``shell out'' of another program like vi , you start another instance of the shell, which isn't your login shell. In addition, whenever you run a shell script, you automatically start another instance of the shell to execute the script.

The initialization files used by bash are: /etc/profile (set up by the system administrator and executed by all bash users at login time), $HOME/.bash_profile (executed by a login bash session), and $HOME/.bashrc (executed by all non- login instances of bash ). If .bash_profile is not present, .profile is used instead.

 etch uses the following initialization scripts: /etc/csh.login (executed by all tcsh users at login time), $HOME/.tcshrc (executed at login time and by all new instances of tcsh ), and $HOME/.login (executed at login time, following .tcshrc ). If .tcshrc is not present, .cshrc is used instead.