VMS-to-Unix Phrase Book
<=  Return           

1.6  Environment Initialization

Problem

You want to customize your shell environment whenever you start up a Korn shell instance.

Solution

Use the ksh .profile initialization file in your home directory for initializing your login shell. This is analogous to DCL's LOGIN.COM file. In addition, you can define the $ENV environment variable to further customize the login shell as well as any sub shells.

Discussion

When you first login, the Korn shell looks for the file .profile in your 'home' directory and sources it. That is, the commands contained in your .profile file are executed within the context of your login shell. You should place in this file all aliases, shell options, and variable definitions that you want both your interactive and batch shell instances.

In addition, you can define the environment variable $ENV to point to a second file which will also be sourced for all sub shells. One approach, demonstrated here, is to have this script perform different initializations for interactive use verses batch.

For the purposes of illustration, I have placed the following echo commands at the beginning

echo "<--- .profile"
and end
echo "---> .profile"
of my .profile file. When I log in, I see:

login: wfc
Password: xxxxxxx
Last   successful login for wfc: .....
Last unsuccessful login for wfc: .....

Compaq Tru64 UNIX V5.1 .....
You have mail.
---> .profile
<--- .profile
unix> ksh
unix> 

All of the commands in my .profile were executed between these two echo commands. When I created a subshell by entering the ksh command, notice that a my .profile was not re-executed.

Next I create a file named .kshrc for initialization of all ksh shells for my account. It's a common Unix convention that initialization files are named .app-namerc, where app-name is the name of the application or utility. Some examples include:

.chsrc
.bashrc
.pinerc
.procmailrc
The particular implementation of ksh supplied with Tru64 Unix does not happen to follow this convention, but some others do, so we'll define the $ENV variable to look for that file:
ENV='~wfc/.kshrc'; export ENV;
It does not matter where in the .profile this environment variable is defined since it will not be sourced by the shell until after the .profile has completed. We will also place echo commands at the top and bottom of our .kshrc file to illustrate when it is excuted:
login: wfc
Password: xxxxxxx
Last   successful login for wfc: .....
Last unsuccessful login for wfc: .....

Compaq Tru64 UNIX V5.1 .....
You have mail.
---> .profile
<--- .profile
---> .kshrc
<--- .kshrc
unix> ksh
---> .kshrc
<--- .kshrc
unix> 

When you login to the system, using ksh as your login shell, it is started with the -i or interactive option. It is possible to detect this setting in an initialization script as shown here:

unix> > cat .kshrc
#!/bin/ksh
#
#      File: ~wfc/.kshrc
#  Abstract: ~wfc/.profile defines $ENV to point to this file to
#            perform initializations desired for all interactive
#            shell instances.

echo "---> .kshrc";

#-------------------------------+
# Test to see if this is an     |
# interactive shell, and exit   |
# if it is not.                 |
#-------------------------------+

  case $- in
    *i*);;
    *) echo "<=== .kshrc"; return 0;;
  esac;

#-------------------------------+
# Interactive setup goes here.  |
#-------------------------------+

echo "<--- .kshrc";

#==[ EOF: ~wfc/.kshrc ]==
unix>

Notice that the 'batch exit' echo is different than the one at the bottom of the file. Because of this, we would expect to see in a batch job log:

---> .profile
<--- .profile
---> .kshrc
<=== .kshrc
   .....  job log here .....

confirming that our batch exit branch was taken.

There are advantages to establishing a separate .kshrc file and following different logic paths for interactive verses batch jobs. For example, skipping unneeded command and environment definitions can help speed up shell startup. Also consider that environment settings designed for interactive shells, in particular where prompting is involved can cause the script to fail when executed as a batch job.

One last note -- remember that initialization files are 'sourced' into your current shell. This means that you should not use the 'exit' command as a way of taking an early exit out of the initialization script unless your intent is to kill the calling shell! In particular, if the calling shell is your login shell, the 'exit' command will log you off the system! Use the 'return 0' command instead which is how to force a successful exit from a ksh/bourne function.

See Also

3.1 - Creating Shell Scripts;
Chapter 3 of Unix for OpenVMS Users ;
Chapter 2 of Unix Power Tools .


<=  Return           

Colophon:
Best Viewed With Any Browser
This page maintained by:
    Bill.Costa@unh.edu
    of the Enterprise Computing Group
    in the dept of Computing & Information Sevices
    at the University of New Hampshire

Typographical
Conventions

Created:  31-Jan-2001 BC
Revised:  27-Mar-2001 BC