|
|
In Solaris, the shell functions both as a command interpreter and a high-level programming language. When you type a command at the command line, the shell processes the command and responds appropriately. Used as a programming language, various commands can be grouped together into what's known as a shell script. You can then run the script (which might be just multiple commands) by executing a single command. Although users can use whichever shell they prefer, only one shell can be used at a time.
The default shell for Solaris 9 is the Bourne shell (sh). Other shells supported by Solaris 9 are the Bourne Again shell (bash), C shell (csh), Korn shell (ksh), TC shell (tcsh), and Z shell (zsh). Each of these shells has unique features. Although all these shells are available, this chapter focuses mainly on three shells: Bourne, C, and Korn. These three shells are perhaps the most common and the most commonly tested.
We will examine features of the three most common shells and look at configuration files for these shells.
Because each shell is its own command interpreter, some commands work in one shell but not another. The Bourne shell is considered the most basic of all the shells and is therefore the default shell. Many other shells are described in terms of Bourne compatibility. Table 4.6 lists some basic features of the Bourne, C, and Korn shells.
|
Feature |
Bourne |
C |
Korn |
|---|---|---|---|
|
Default prompt |
$ |
% |
$ |
|
Bourne-compatible syntax |
N/A |
No |
Yes |
|
Job control |
Yes |
Yes |
Yes |
|
Command history list |
No |
Yes |
Yes |
|
Command line editing |
No |
Yes |
Yes |
|
Repeat last command |
No |
!! |
Yes |
|
Supports aliases |
No |
Yes |
Yes |
|
Single-character abbreviation for login directory |
No |
Yes |
Yes |
|
Protection from file overwriting |
No |
Yes |
Yes |
|
Supports enhanced cd |
No |
Yes |
Yes |
|
Initialization file separate from .profile |
No |
Yes |
Yes |
|
Logout file |
No |
Yes |
No |
The Korn shell is highly compatible with the Bourne shell. This makes sense, considering that the Korn shell was developed from the Bourne shell. Also, the Bourne Again shell is, as you might expect, highly Bourne-compatible. The C shell was developed separately and is based on the C programming language. Therefore, it tends to work a bit differently than Bourne. The TC and Z shells tend to act a lot like the C shell.
When you log in to Solaris, the default system profile file, /etc/profile, is run. After the system profile executes, the user profile is run. Your user profile can have one or more files, known as initialization files, and is dependent upon the shell you are using. Table 4.7 shows the profile initialization files based on the shell.
|
Initialization File(s) |
|
|---|---|
|
Bourne and Korn | |
|
C |
.login and .cshrc |
|
TC |
.tcshrc and .cshrc |
|
Z |
.zlogin and .zshrc |
|
Bourne Again |
.bash_profile |
The initialization files are essentially a shell script. However, their primary purpose is to set up the user's work environment, including the home directory, path, and other environment variables.
Solaris 9 provides default initialization files for each profile in the /etc/skel directory. These files are local.cshrc, local.login, and local.profile. As an administrator, you can customize these files to your liking.
When a user account is created, the appropriate files in the /etc/skel directory are copied to the user's home directory. For users with the Bourne and Korn shells, the /etc/skel/local.profile file is copied as $HOME/.profile. For users using the C shell, /etc/skel/local.cshrc is copied as $HOME/.cshrc, and /etc/skel/local.login is copied as $HOME/.login. In most cases, users have read and write access to their local profile files and can adapt them as necessary.
One way to affect all user profiles on a network is to introduce a site initialization file. Site initialization files must be located on a server that is accessible to all users on your network, and are called from within the user's local initialization file. Therefore, if you want to make network-wide changes, you can make the change in the site initialization file, and all users will receive the change when they log in.
Place the following variable at the beginning of a Bourne or Korn initialization file to reference a site initialization file:
./net/machine_name/init_file
The machine_name and init_file variables must point to the physical location of the site initialization file. If you are configuring the C shell initialization file (.cshrc), you will need the following variable:
source /net/machine_name/init_file
The previous two variables are a great example of the differences between the Bourne and Korn initialization files and the C shell initialization file. Both types of files can accomplish the same goals, but require different syntax.
When adding variables to initialization files, you need to know which shell your user is using.
In the Bourne and Korn shells, you use an uppercase value name and a value parameter to specify a new variable. You also have to use the export command to finish setting the environment variable. As an example, to set a user's mail directory, you could execute the following command:
# MAIL=/var/mail/qdocter;export MAIL
To set variables for C shell users, you use one of two commands. To set shell variables (local variables known only within the shell), use the set command with lowercase variable names. To set environment variables (global variables, available in subshells), use the setenv command with uppercase variable names. If you set a shell variable, the shell automatically sets the environment variable, and vice versa. To set the MAIL variable, you would execute the following:
# setenv MAIL /var/mail/qdocter
Both of the preceding examples set the same environment variable to the same value, but in different shells. Table 4.8 lists some of the more common variables you will set.
Generally speaking, it's best to refer to all shell and environment variables by their uppercase names.
|
|
| This HTML Help has been published using the chm2web software. |