Basic Concepts

A shell is a specialized Solaris command that provides an interface between the user and the operating system kernel. The kernel is the central core of the operating system and controls all basic aspects of a computer's operation. The kernel coordinates all of the executing commands and manages the system's resources. The shell is a special command interpreter that invokes and interacts with the kernel to provide a way for users to execute commands and other programs.

Each user is assigned a default shell that starts each time the user logs in to a system or opens a new Command Tool, Shell Tool, or CDE Terminal window. The shell interprets the commands that it reads. You can type those commands directly into the shell at the prompt, or the shell can read the commands from a file. A file that contains shell commands is called a shell script.

Shell scripts are interpreted, not compiled: The commands are read and executed one by one, in sequence. A compiled program, on the other hand, is initially read and converted to a form that can be directly executed by the CPU and thereafter executed all at once. Because shell scripts are interpreted, even the fastest shell script always runs more slowly than an equivalent program written in a compiled language such as C.

Introducing the Bourne, Korn, and C Shells

The Bourne, Korn, and C shells each have their own environment and syntax. Table 79 compares the initialization files that define the shell environment at startup.

Table 79. Shell Initialization Files
Feature Bourne Korn C
Read at login .profile .profile .login
Read at invocation of shell N/A Any file specified in .profile with ENV=file. By convention, file is usually .kshrc. .cshrc

The initialization files contain environment variables and other settings that configure the user's environment when a shell starts. Refer to the section “Environment Variables” for more information. The .profile (Bourne and Korn shells) and .login (C shell) files execute when a user logs in to a system. The Korn shell and .cshrc (C shell) environment files execute each time a new shell starts. Use these environment files to define aliases and functions for interactive use and to set variables that you want to apply to the current shell.

Bourne Shell

The Bourne shell, written by Steve Bourne when he was at AT&T Bell Laboratories, is the original UNIX shell. This shell is preferred for shell programming because of its programming capabilities and its universal availability. It lacks features for interactive use, such as built-in arithmetic and recall of previous commands (history). The Bourne shell is the default login shell for the root account, and it serves as the default user login shell if you do not specify another shell in the user's passwd file. The Bourne shell is used for all system-supplied administration scripts.

The Bourne shell command is /bin/sh. The default prompt for the Bourne shell is a dollar sign ($). The root prompt is a pound sign (#).

Korn Shell

The Korn shell, written by David Korn of AT&T Bell Laboratories, was designed to be compatible with the Bourne shell and to offer interactive features comparable to the C shell. The Korn shell includes convenient programming features such as built-in integer arithmetic, arrays, and string-manipulation facilities. The Korn shell runs faster than the C shell and runs virtually all scripts that are written for the Bourne shell.

The Korn shell command is /bin/ksh. The default prompt for the Korn shell is a dollar sign ($). The root prompt is a pound sign (#).

C Shell

The C shell, written by Bill Joy when he was at the University of California at Berkeley, was designed to incorporate features such as aliases and command history for interactive use. The syntax for its programming features is similar to that for the C programming language.

The C shell command is /bin/csh. The default prompt for the C shell is the system name followed by a percent sign (%). The root prompt is the system name followed by a pound sign (#).

NOTE

For many reasons, you should use the C shell only as a login shell. For more information, see Chapter 47, "C Shell Programming…NOT," in UNIX Power Tools, Second Edition.


Understanding How Shells Process Commands

Each shell creates subshells and child processes—subordinate shells and processes that are under the control of the originating, or parent, shell—to interpret and execute commands. For example, the following list shows a simplified version of the order in which the Korn shell processes commands. The shell parses (divides up) the command into units—such as words, keywords, I/O redirectors, and semicolons—separated by the fixed set of metacharacters: Space Tab Newline ; ( ) < > | &.

  1. Checks the first part of each unit for shell keywords, such as function or if statements, with no quotes or backslashes. When it finds a keyword, the shell processes the compound command.

  2. Searches the list of aliases.

  3. Expands any tilde (~) expressions.

  4. Substitutes variables.

  5. Substitutes commands.

  6. Substitutes arithmetic expressions.

  7. Splits the items that result from parameter, command, and arithmetic substitution and splits them into words again.

  8. Expands wildcards.

  9. Looks up built-in commands, functions, and executable files.

  10. Sets up I/O redirection.

  11. Runs the command.

The Bourne shell interprets commands similarly but does not check for aliases, tildes, or arithmetic. The C shell interprets commands in a different order.

Naming Shell Scripts

When you assign a name to a shell script, follow the general rule for naming Solaris files. Make a script name as descriptive as possible so that you can easily remember its designated function. Be careful to avoid names that the Solaris Operating Environment itself uses for its own programs unless you intend to replace those commands with your own scripts.

Each shell has a list of built-in commands. You should also avoid using built-in shell commands as script names. If you name a file with one of the shell built-in commands—such as alias, break, case, cd, continue, echo, else, exit, or history for the C shell—the shell interprets the script name as one of its own built-in commands and runs the built-in command instead of executing the script. For example, with the Bourne or Korn shell, you will run into trouble if you name a script test—which you might easily do if you are testing something—because test is a built-in Bourne and Korn shell command. Refer to “Reference Tables” starting and to the sh(1), ksh(1), and csh(1) manual pages for a complete list of built-in commands.

Identifying the Shell

The first line of each shell script determines the shell that runs—or interprets—the script. Always identify the interpreting shell on the first line of the script, using the information from Table 80.

Table 80. First Line of Script
Shell Syntax
Bourne #!/bin/sh
Korn #!/bin/ksh
C #!/bin/csh -f

The -f (fast) option to /bin/csh runs the script without sourcing the .cshrc file.

If you do not specify the shell in the first line of the script and it is an executable script, the current shell interprets the contents of the script.

After the first line of a script, any line beginning with a pound sign (#) is treated as a comment line and is not executed as part of the script.

Making Scripts Executable

Before you can run a shell script, it is customary to change its permissions so that it has at least read and execute permissions (chmod 555). When you write and debug the script, give yourself write permission to the file (chmod 755) so that you can edit it and, subsequently, execute it. When assigning permissions to a completed shell script, consider the scope of access that you want to permit to this script. Use restrictive permissions if the script is proprietary or individual, and use more relaxed permissions if many users who are not in the same group will use the script.

Storing Shell Scripts

After you create a shell script, you can execute it only from the directory in which it resides or by using the full path name, unless you set your PATH variable to include the directory that contains the script.

If you write many scripts, you may want to create a ~/bin directory in your home directory and update your search path to include this directory. In this way, your scripts are available to you regardless of where you are working in the directory hierarchy. If you provide scripts for more general use, be sure to debug them before you put them in a directory where they are more accessible.

Writing Shell Scripts: The Process

The following checklist describes the process to follow when writing any shell script.

  1. Decide what you want the script to do. Establish a list of the commands you need to use to accomplish the desired task.

  2. Use an editor to put the commands into a file. Give the file a name that indicates what the script does.

  3. Identify the shell in the first line of the script.

  4. Include comments at the beginning of the script to describe its purpose and to annotate each individual part of the script. These comments can aid in debugging the script and in interpreting a script that may be used only occasionally. Comments are also invaluable in helping others to interpret scripts that you have written.

  5. Save the file and quit the editor.

  6. Change the permissions so that the file has, at a minimum, read and execute permissions.

  7. Check your path or the PATH variable to make sure that the directory that contains the script is in the search path.

  8. Type the name of the script as a command. The script executes one line at a time.

  9. If errors occur, debug the script.

  10. When the script is complete, decide where you want to store the command (for example, in your home directory, your local ~/bin directory, or in a more globally available directory).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.15.229.143