Return
|
You want to customize your shell environment whenever you start up a Korn shell instance.
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.
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 .procmailrcThe 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.
3.1 - Creating Shell Scripts;
Chapter 3 of Unix for OpenVMS Users
;
Chapter 2 of Unix Power Tools
.
  Return
|
|
Colophon: |
|
||||
|
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 |
|
||||