Previous Page
Next Page

Setting Up Shell Initialization Files

Objective:

When you set up user accounts, you can customize each user's session by using initialization files that are referenced each time the user logs in. This chapter describes how to administer each initialization file.

As a system administrator, when you're setting up a user's home directory, you need to set up the shell initialization files for the user's login shell (also called user initialization files). A shell initialization file is a shell script that runs automatically each time the user logs in. The initialization file sets up the work environment and customizes the shell environment for the user. The primary job of the shell initialization file is to define the user's shell environment, such as the search path, environment variables, and windowing environment. Each Unix shell has its own shell initialization file (or files), located in the user's home directory, as described in the following sections.

C Shell Initialization Files

C shell initialization files run in a particular sequence after the user logs in to the system. For the C shell, initialization files are run in the following sequence:

1.
Commands in /etc/.login are executed.

2.
Commands from the $HOME/.cshrc file (located in the user's home directory) are executed. In addition, each time the user starts a new shell or opens a new window in the CDE, commands from $HOME/.cshrc are run.

3.
The shell executes commands from the $HOME/.login file (located in the user's home directory). Typically, the $HOME/.login file contains commands to specify the terminal type and environment.

4.
When startup processing is complete, the C shell begins reading commands from the default input device, the terminal.

Although it is not part of the initialization of the shell, when the C shell terminates, it performs commands from the $HOME/.logout file (if that file exists in the home directory).

Bourne Shell Initialization Files

Bourne shell initialization files run in a particular sequence after the user logs in to the system. For the Bourne shell, initialization files are run in the following sequence:

1.
Commands in /etc/profile are executed.

2.
Commands from the $HOME/.profile file (located in the user's home directory) are executed. Typically, the $HOME/.profile file contains commands to specify the terminal type and environment.

3.
When startup processing is complete, the Bourne shell begins reading commands from the default input device, the terminal.

Korn Shell Initialization Files

Korn shell initialization files run in a particular sequence after the user logs in to the system. For the Korn shell, initialization files are run in the following sequence:

1.
Commands in /etc/profile are executed.

2.
Commands from the $HOME/.profile file (located in the user's home directory) are executed. Typically, the $HOME/.profile file contains commands to specify the terminal type and environment.

3.
If the $HOME/.kshrc file is present, commands located in this file are executed. In addition, this initialization file gets read (and the commands get executed) every time a new Korn shell is started after login.

4.
When startup processing is complete, the Korn shell begins reading commands from the default input device, the terminal.

Additional Shells Included with Solaris 10

Solaris 10 also includes, as part of the operating environment, the bash, zsh, and tcsh shells. These shells, especially bash and tcsh, are gaining popularity with system administrators and contain extra options and functions. You can find further details about these shells and their additional functionality by consulting the man pages for them.

Note

The Effect of CDE on Shell Initialization Files Initialization files are executed in the order specified for each of the shells, except when you're logging in to the CDE, where the $HOME/.dtprofile file is also run. If the DTSOURCEPROFILE variable is not set to TRUE in the .dtprofile file, the $HOME/.profile file will not be run.

When you're using CDE, it may be necessary to add the following lines in the $HOME/.profile to get the .kshrc file to work properly in the Korn shell:

set -ha
ENV=$HOME/.kshrc

Without this entry, aliases and environment variables might not get passed to subshells (that is, additional shells spawned by the Korn shell). Therefore, when you open a new window in the CDE, alias and environment variables are set in the initial shell but are not set in subsequent shells, even though they are listed in the $HOME/.kshrc file. The preceding entries fix this problem.


Default Initialization Files

When a user logs in to the system, the user's login shell is invoked. The shell program looks for its initialization files in the correct order for the shell. The shell program then executes the commands contained in each file and, when it is finished, displays the shell prompt on the user's screen.

Default user initialization files (such as .cshrc, .profile, and .login) are created automatically in the user's home directory when a new user account is added. You can predefine the contents of these files, or you can choose to use the system default files. The Solaris 10 system software provides default user initialization files for each shell in the /etc/skel directory on each system. These files are listed in Table 4.10.

Table 4.10. Default Initialization Files

Filename

Description

local.cshrc

The default .cshrc file for the C shell

local.login

The default .login file for the C shell

local.profile

The default .profile file for the Bourne and Korn shells


You can use these initialization files as a starting point and modify them to create a standard set of files that provides a work environment that is common to all users. You can also modify them to provide a working environment for different types of users.

Customizing User Initialization Files

When a user logs in to a system, the shell initialization files determine the work environment. The shell startup scripts can be modified to set environment variables and directory paths that are needed by a specific user. These startup scripts are located in the user's home directory.

When you are setting up user initialization files, it might be important to allow the users to customize their own initialization files. You can do this by having centrally located and globally distributed user initialization files called site initialization files. With these files, you can continually introduce new functionality to all the user work environments by editing one initialization file.

The local initialization file, located in the user's home directory, allows user-specific configuration. A local initialization file lets users further customize their own work environment.

Site initialization files are located in the /etc directory and can be edited only by root. They are designed to distribute sitewide changes to all user work environments. Individual user initialization files are located in each user's home directory and can be customized by the owner of the directory. When a user logs in, the site initialization file is run first, and then the initialization file located in the user's home directory is run.

Note

Sitewide Shell Initialization Files You should not use system initialization files located in the /etc directory (/etc/profile, /etc/.login) to manage an individual user's work environment. Files in that folder are site initialization files, which are considered to be global files and are meant to be generic and used to set work environments for all users. The system runs these startup files first and then runs each user's startup files, located in the home directories.


The most commonly customized aspects of shell startup scripts are environment variables. Table 4.11 describes the most common environment and shell variables, including some that you might want to customize in user initialization files.

Table 4.11. Shell and Environment Variables

Variable

Description

LOGNAME

Defines the user's login name. This variable is set by the login program and wouldn't normally be modified.

HOME

Defines the path to the user's home directory. The cd command uses this variable when an argument is not specified. This variable is set by the login program and wouldn't normally be modified.

SHELL

Defines the path to the default shell. This variable normally isn't modified manually by the user.

LPDEST

Sets the user's default printer.

PWD

Is set to the current working directory. This variable changes automatically each time the user changes directories. This variable isn't modified manually by the user.

PS1

Defines the shell prompts for the Bourne and Korn shells.

PATH (or path in the C shell)

Lists, in order, the directories that the shell searches to find the program to run when the user enters a command. If the directory is not in the search path, users must enter the complete pathname of a command.

The default PATH variable is automatically defined in .profile (Bourne or Korn shell) or .cshrc (C shell) as part of the login process.

The order of the search path is important. When identical commands exist in different locations, the first command found with that name is used. For example, suppose PATH is defined (in Bourne and Korn shell syntax) as PATH=/bin:/usr/bin:/usr/sbin:$HOME/bin and a file named sample resides in both /usr/bin and $HOME/bin. If the user enters the command sample without specifying its full pathname, the version found in /usr/bin is used.

prompt

Defines the shell prompt for the C shell.

TERM (or term in the C shell)

Defines the terminal. This variable should be reset in /etc/profile or /etc/.login. When the user invokes a program that uses advanced terminal properties such as an editor, the system looks for a file with the same name as the definition of this environment variable. The system searches the directory /usr/share/lib/terminfo to determine the terminal characteristics.

MAIL

Sets the path to the user's mailbox.

MANPATH

Sets the search path for system man pages.

umask

Sets the default user mask. Although umask is a command and not a variable, it is used to set the file-mode creation mask of the current shell execution environment, as described in the section "The Default User Mask," later in this chapter.


Tip

Modifying the Shell Prompt Some users find it helpful to make their login name, the hostname, and the current directory part of the prompt. Here's how you set it up in the Korn shell:

     PS1="$(whoami)@$(hostname) [\$PWD] #"

The resulting prompt looks like this:

     root@ultra5 [/usr/bin] #


Step by Step 4.5 shows how to modify the shell environment by changing some of the variables in the shell startup file. It suggests some changes and shows the shell-specific syntax to use.

Step By Step 4.5: Verifying and Changing a User's Environment

1.
Log in as the user. This enables you to see the user's environment as the user would see it. You can use su- <username> to achieve this.

2.
Set the user's default path to include the home directory as well as directories or mount points for the user's windowing environment and applications. To change the path setting, add or modify the line for PATH.

For the Bourne or Korn shell, this is the syntax:

PATH=/<dirname1>:/<dirname2>:/<dirname3>:.; export PATH

For example, you could enter the following line in the user's $HOME/.profile file:

PATH=$PATH:/usr/bin:/$HOME/bin:/net/glrr/files1/bin:.;export PATH

For the C shell, notice that in the syntax, the colons are replaced with spaces:

set path =(/<dirname1>/<dirname2>/<dirname3> .)

For example, you could enter the following line in the user's $HOME/.cshrc file:

set path=($path /usr/bin $HOME/bin /net/glrr/files1/bin .)

Note

Modifying the PATH Variable Prefixing $PATH (Korn shell) or $path (C shell) appends changes to the user's path settings that are already set by the site initialization file. When you set the PATH variable with this procedure, initial path settings are not overwritten and are not lost. Also note the dot (.) at the end of the list to denote the current working directory. The dot should always be at the end of the path for users and should not be used in the path for root, as discussed in the section "Setting the Correct Path," later in this chapter.

3.
Make sure the environment variables are set to the correct directories for the user's windowing environments and third-party applications. To do so, enter env, and you see the following:

$env
HOME=/export/home
HZ=100
LOGNAME=bill
MAIL=/var/mail/bill
PATH=/usr/bin:
SHELL=/bin/sh
TERM=xterm
TZ=US/Michigan

4.
Add or change the settings of environment variables.

For the Bourne or Korn shell, the syntax is as follows:

VARIABLE=<value>;export VARIABLE

The following example sets the user's default mail directory:

MAIL=/var/mail/bcalkins;export MAIL

For the C shell, the syntax is as follows:

setenv VARIABLE <value>

The following example sets the history to record the last 100 commands in C shell:

set history = 100


The Home Directory

The home directory is the portion of a file system that is allocated to a user for storing private files. The amount of space you allocate for home directories depends on the kinds of files the user creates and the type of work performed. An entire file system is usually allocated specifically for home directories, and the users all share this space. As the system administrator, you need to monitor user home directories so that one user does not use more than his or her fair share of space. You can use disk quotas to control the amount of disk space a user can occupy. (Disk quotas are discussed in Chapter 1, "Managing File Systems.") Or you can use soft partitions, which are described in Chapter 10.

A home directory can be located either on the user's local system or on a remote file server. Although any directory name can be used for a home directory, it is customary that home directories are named using this convention: /export/home/<username>. When you put the home directory in /export/home, it is available across the network in case the user logs in from several different stations. For a large site, you should store home directories on a server.

Regardless of where their home directories are located, users usually access them through a mount point named /home/<username>. When AutoFS is used to mount home directories, you are not permitted to create any directories under the /home mount point on any system. The system recognizes the special status of /home when AutoFS is active. For more information about AutoFS and automounting home directories, see Chapter 9, "Virtual File Systems, Swap Space, and Core Dumps."

To access a home directory anywhere on the network, a user should always refer to it as $HOME, not as /export/home/<username>. The latter is machine specific, and its use should be discouraged. In addition, any symbolic links created in a user's home directory should use relative paths (for example, ../../../x/y/x) so that the links will be valid no matter where the home directory is mounted. The location of user home directories might change. By not using machine-specific names, you maintain consistency and reduce system administration.

Projects

The concept of projects was introduced in Solaris 8. Projects are included in Solaris 10, and they allow much-improved tracking of resources and usage. The project concept is extremely useful when multiple projects use the same system and are charged for their usage of the system. With projects, it is now simple to identify and subsequently charge each project based on the resources used. In addition, a system administrator supporting multiple projects can perform duties associated with those projects so that his or her time is also booked to the project requesting the service. The system administrator would do this by using the newtask command. (See the newtask man page for further details about this command.)

You establish projects by using the configuration file /etc/project. The following example shows the standard /etc/project file:

system:0::::
user.root:1::::
noproject:2::::
default:3::::
group.staff:10::::

As you can see from this example, all members of the staff group (GID 10) belong to the project group.staff.

You can edit this file to create new projects and assign users and groups of users to the projects. Accounting software can produce reports on usage based on the projects specified in the /etc/project file.

For further information on projects, see the man page entry for projects as well as the entry for the projects command, which lists the projects a user or group belongs to.

Name Services

If you are managing user accounts for a large site, you might want to consider using a name service such as Network Information Service (NIS), Network Information Service Plus (NIS+), or Lightweight Directory Access Protocol (LDAP). A name service lets you store user account information in a centralized manner instead of storing it in every system's /etc file. When you use a name service for user accounts, users can move from system to system, using the same user account without having sitewide user account information duplicated in every system's /etc file. Using a name service also promotes centralized and consistent user account information. NIS, NIS+, and LDAP are discussed in Chapter 12, "Naming Services."


Previous Page
Next Page