The login scripts(1) set up a UNIX user's environment, determine how commands are interpreted, and control various aspects of the user's interaction with the operating system.
In the Isis AFS cell, a user's files--including login scripts--are made available through a file system which is shared among many of the UNIX hosts on the UNC campus. Thus each user sees his own files regardless of which Isis host he logs into, and the same login scripts set up and control his environment throughout his session.
Isis user login scripts are designed to provide you with a familiar, customizable environment across all hosts you might login to while taking into account the differences between specific hosts, operating systems, and locally installed applications. Your scripts are actually a network of scripts, some of which are maintained by ATN, some by the system administrators of individual machines, and some by you.
The ATN-maintained scripts take care of general cell-wide user settings and operating system-specific settings. Most of the mundane things user's have to handle in their own scripts on other systems are already taken care of for you by these scripts.
The local system administrators' scripts make adjustments for locally installed programs and their own procedures and policies as they see fit.
The scripts you maintain--if you choose to have any--allow you to customize your environment any way you want, defining your own aliases, shell functions, adjusting your path, etc. You can even override any settings made by the other scripts.
In order to customize your own scripts, it is important to
understand how this little network of scripts operates. Most UNIX
books explain that your login scripts live in your home directory
and are called either `.cshrc' and `.login' (for
csh and tcsh users) or `.profile' and
`.kshrc' (for ksh and bash users), and it's
basically up to you, the user, to keep them working properly.
That's true enough for stand-alone UNIX systems where your home directory is not shared among groups of disparate hosts. But for Isis users, that simple model doesn't hold up very well when your home directory is shared by hundreds of hosts running a dozen different operating systems, any one of which you might have reason to login to.
If you examine your login scripts, you will find that your
`~/.xxx' (where xxx is any of cshrc,
kshrc, login, or profile) is actually a
symbolic link to
`/afs/isis/common/etc/scripts/xxx.USER'
which ATN maintains for you. These same scripts are used by every Isis user, and they take care of many details that a single user couldn't possibly hope to manage in his own login scripts. They take into account the various machine architectures and operating systems supported in the Isis AFS cell, as well as any host- and department-specific settings the system administrators think are appropriate.
Because your `~/.xxx' files are symbolic links to files which ATN maintains for you, you cannot edit them. However, the last thing each of these scripts does is to invoke your customizations (if you have any). This allows you to have the last word in how your environment is set up. Specifically, they will execute any `~/public/.xxx.personal' file you have created. This is where you can augment or override any settings made in the other scripts. See section 1.5 Examples, for specifics.
Several things the login scripts set up fall into the category of user
preferences, and they may vary from user to user. As these alternative
settings represent a limited set of choices, you can select among them
through the user-config program. This program maintains your
`~/public/.user-config' file which is used by the login scripts to
determine your preferences for several functions. The login scripts
merge your preferences with host-specific and cell-wide settings to
determine what actions to perform.
Without going into great detail about how to use the program (see
user-config --help for that), we'll just touch on some of
preferences you can set.
Most users prefer to have "." in their $PATH, and
unless you specify otherwise your $PATH will include
".". If you don't want "." included in you path,
you can use the command user-config --set DOT_IN_PATH=NO so
that on subsequent logins your path will not include ".".
The command user-config --set MESG=YES will cause the login
scripts to execute the command mesg y, which will allow your
session to receive system messages from other users on the system,
usually from the "talk" program. The default setting is to not allow
these messages.
Some hosts provide a menu as an alternative to your normal UNIX command shell. Whether you get the menu or your normal shell when you login depends on:
loginmenu program,
user-config --set LOGINMENU=YES) or against it (with the command
user-config --set LOGINMENU=NO).
If you prefer to get a menu instead of your command shell when you
login to hosts which provide a menu, the command user-config --set LOGINMENU=YES will arrange
that for you. On the other hand, if you don't want the menu and would
rather see a shell prompt when you log in, enter
user-config --set LOGINMENU=NO to arrange that.
You can always run the menu from a shell prompt by typing the command
loginmenu.
Note that lots of systems don't have a loginmenu. Those that do
should set HAS_LOGINMENU=YES in their `/etc/isis.cfg' file.
Some hosts (the Isis login nodes, for example) are set up so that the
menu is preferred by default, and they set LOGINMENU=YES by
default. However, your user-config settings will override those of the
host.
The bash shell behaves differently from ksh. ksh will
source (i.e., process the commands in) your
`$ENV' file
after it processes your `~/.profile', but bash does not. To make the login
process consistent across shells in the sh family (which
includes ksh and bash), the login scripts make
bash source `$ENV' unless the user has
chosen to preserve this difference by entering the command
user-config --set BE_BASHFUL=YES. This is not recommended, and
it only affects users who's default shell is bash.
"So what's with this `~/public' directory and why are my
customizable login scripts kept there?", you ask. The answer has to
do with AFS and who has permission to read what and when. When you
login to an Isis host, you get something called a token. This
token is only valid for a limited time. You have to have a valid
token to read files in various directories--including your home
directory. However, anybody can read files in your `~/public'
directory at any time, including you when your token has
expired. This is important if you need to execute a shell script and
you don't have a valid token. This would be the case, for example,
if your token had expired, or if you were trying to run an at
or cron job (which are executed without first getting a
token).
By the same token (no pun intended), every user on the system can read the files in your `~/public' directory, so be sure not to put sensitive information there--credit card numbers, passwords, home work, or anything you don't want printed in the Daily Tar Heel or published on the Web.
The following example is a `~/public/.kshrc.personal' file. It sets shell aliases and options, and it tries hard not to produce any output. Some things to note:
hostname command can be used to select
sections of code to make host-specific settings. However, on some
systems it returns the hostname with the domain; in others it just
yields the simple host name.
kshrc or cshrc files. They generally
should go in profile or login files where they are
executed only once, upon login, rather than every time a shell
starts.
kshrc or cshrc files because these things are not
inherited by child processes. If they are only in profile
or login files, then they will only be available to the top
level shell.
# ~/public/.kshrc.personal
# These commands are executed whenever a shell starts.
alias ll='ls -lF'
alias duh='find . -type f'
set +o noclobber
# some host-specific aliases and settings
case `hostname` in
alpha.plumb.unc.edu)
alias cgi='cd /opt/local/etc/httpd/cgi-bin/mine ; pwd'
alias html='cd /opt/local/etc/httpd/htdocs/mine ; pwd'
;;
beta.plumb.unc.edu)
alias cgi='cd /home/httpd/cgi-bin/local ; pwd'
alias html='cd /home/httpd/htdocs ; pwd'
alias err='tail -f /var/log/httpd/error_log'
;;
sunny)
# Avoid producing output!
~/bin/shell-counter >/dev/null 2>&1
;;
esac
This is an example of a `~/public/.profile.personal' file. Note that it sets environment variables and umask, and that it may produce output.
# ~/public/.profile.personal
# These commands are only executed once, upon login.
case `hostname` in
beta.plumb.unc.edu)
PATH=$PATH:/opt/charlie/bin
umask 2
;;
sunny)
# Output is okay.
~/bin/login-counter
;;
esac
The Isis user login/shell scripts are designed to provide users with a familiar environment across all hosts they login to, yet still take into account the differences between specific hosts, operating systems, and locally installed applications. Most of the dependencies in the scripts are in Isis' file space, so these should not be a concern to local system administrators.
Despite efforts to keep the scripts independent of host nuances, a few assumptions are made about the local host. For example, certain binaries are expected to be available and in known locations. Where possible, we have tried to follow the guidelines set forth in the Filesystem Hierarchy Standard (FHS).
It is assumed that a user's shell can execute the programs
stty, mesg, expr, and hostname from the
default path inherited from login. The FHS requires
that these programs be in `/bin', though we know some systems
are shipped with these programs in `/usr/bin'. (In fact, on many
larger systems, `/usr/bin' is a symbolic link to `/bin'.)
Hosts may also provide a program called `loginmenu' as an
alternative shell. The program will only be used if the user
specifies a preference for it (using user-config) and the
host specifies that it is available (in the `/etc/isis.cfg'
file). If both of these conditions are met, then the last step
performed by the login scripts is to exec loginmenu, thus
loginmenu becomes the user's shell. Exiting loginmenu
then effectively logs the user out of the system.
The login scripts set several environment variables. FROM is
set to email.unc.edu. This affects some programs
(pine for example) which use this value to build a return
address for email. EDITOR is set to pico.
SCRIPT_VER is set to some string that specifies which
version of the login script set we are using. ISIS_HOST is
the value returned from the hostname command, but with dots
and domains trimmed off. Finally, DEPT is set to atn
unless overridden by a setting in the `/etc/isis.cfg' file.
System administrators should provide a file called `/etc/isis.cfg' which should be world-readable. This file should consist of variable/value pairs, where the variable name and value are separated by an equal sign. The login scripts read this file along with a users' `~/public/.user-config' to create and initialize whatever variables are specified there.
Note that the `/etc/isis.cfg' is not sourced (i.e., processed as a
set of shell commands) by the shell, but
is parsed by the separate user-config program. Therefore it should
not contain anything other than "VAR=value" lines.
The `/etc/isis.cfg' file at least should contain a line of the following form:
DEPT=somename
The DEPT variable will be used to locate additional
scripts maintained on a departmental level in
the directory
`/afs/isis/depts/$DEPT/scripts'
Note that the value of the DEPT variable could be
hierarchical. That is, instead of the Exobiology department having
to share one set of scripts for all their hosts, they might
logically subdivide into Mars and Europa groups and manage their
respective hosts separately. Thus one group might set
DEPT=exobio/mars in their hosts' `/etc/isis.cfg' files,
while the other group might use DEPT=exobio/europa in theirs.
Another pair of variables some system administrators may want to specify
in `/etc/isis.cfg' is HAS_LOGINMENU and LOGINMENU.
Specify HAS_LOGINMENU=YES in your `/etc/isis.cfg' if your
host provides a loginmenu program which might function in place
of a user's shell. If this is the preferred shell for your host, you may
also specify LOGINMENU=YES, in which case the login scripts will
exec loginmenu as the last step in the login process, effectively
replacing the user's shell with loginmenu.
Only specify
HAS_LOGINMENU=YES if you provide such a program on your host,
and only specify LOGINMENU=YES if loginmenu is the
preferred shell for your host.
Users may override LOGINMENU=YES through the user-config
program if, for example, they prefer a normal shell prompt to a menu
across all systems.
The login scripts first set up the shell environment that is common
across all platforms and hosts. Then they determine which type of
OS they are running on (based on the output of the
`/usr/afsws/bin/sys' command) and execute any OS-specific script that
may exist. These will be found in
`/afs/isis/depts/atn/scripts/xxx.$SCRIPT_VER.@sys'.
Remember, SCRIPT_VER was set in the user's `~/.xxx', and
@sys is an AFS macro that will be turned into the output of
the sys command. The OS-specific scripts are kept in ATN's
scripts directory because ATN maintains them.
After the ATN-maintained cell-wide OS-specific xxx script is
executed, but before the user's `~/public/.xxx.personal' file
is executed, the departmental level `xxx' file is searched for
in the following places, and the first one found is the only one
executed:
`/afs/isis/depts/$DEPT/scripts/xxx.$SCRIPT_VER.$ISIS_HOST' `/afs/isis/depts/$DEPT/scripts/xxx.$ISIS_HOST' `/afs/isis/depts/$DEPT/scripts/xxx.$SCRIPT_VER.DEPT' `/afs/isis/depts/$DEPT/scripts/xxx.DEPT'
This gives the departmental administrators a great deal of flexibility over how they maintain the host-specific parts of a user's login scripts. However, because the `~/public/.xxx.personal' files are executed last, the users still have ultimate control over their environments.
Maintaining a set of host-specific login scripts can be a big job for a departmental administrator. Fortunately, most settings users need are taken care of for you before your departmental level scripts are invoked. In fact, many machines will not need any special setup.
Still, the following guidelines should be observed in order to make the user's environment consistent from host to host.
buildpath program to avoid duplicate path entries.
man program works before adding to or
creating a MANPATH environment variable. Some systems use a
"smart man" program that will find man pages relative to the
path. Setting an explicit MANPATH on these systems can actually
make man less able to find the correct documentation.
This section is in dire need of examples.
The feature of having one set of login scripts setting up and controlling your environment regardless of which host you may use comes at a price--complexity. Practically every host has unique features, programs, or strange qwerks that must be taken into account by your login scripts, and a set of login scripts which do the Right Thing on each of the hosts you may login to can be extremely complicated, especially as the application suite on each host can change without notice.
When the Isis cell was created in the mid 1990s, we provided a set of login scripts to each new user which allowed ATN to maintain the bulk of that complexity while still giving users a chance to customize their own environments. That scheme worked reasonably well as long as most of the Isis hosts were owned or maintained by ATN and the applications available didn't depend too closely on exactly how the users' environments were set up.
That scheme, however, is showing its age.
GCG for example) which depend
heavily on and interact closely with the user's environment.
The new scheme addresses each of these issues and provides a structure which should carry us well into the next century. It is ATN's intention, over the course of the Summer and Fall of 1999, to switch each user from the old scheme to the new scheme.
This means that we will replace your existing `~/.login', `~/.cshrc', `~/.profile', and `~/.kshrc' scripts with new ones. If your old scripts differ in any significant way from what you had when your userID was first created, your old scripts will be renamed with a `.old' extension (`~/.kshrc.old' for example) and replaced with new scripts.
These new scripts are actually symbolic links to scripts which ATN maintains for you. They take into account the various machine architectures and operating systems supported in the Isis cell, as well as any host- and department-specific settings the system administrators think is appropriate.
The last thing each of these scripts does is to invoke your customizations (if you have any). This allows you to have the last word in how your environment is set up. Specifically, they will execute any `~/public/.login.personal', `~/public/.cshrc.personal', `~/public/.profile.personal', and `~/public/.kshrc.personal' files you have created.
This probably won't affect you if you:
GCG on nun (in which case you are
probably already using the new scheme),
vanilla utility lately.
Users most likely to be affected are those who have customized their login scripts, and whose directory entries for `~/.login', `~/.cshrc', `~/.profile', or `~/.kshrc' are symbolic links to similarly named files in their `~/public' directories.
When your login scripts are switched to the new scheme, your customized scripts (now renamed with `.old' extensions) will not be executed. To get your customizations back, you will need to modify or create one or more of the files `~/public/.login.personal', `~/public/.cshrc.personal', `~/public/.profile.personal', and `~/public/.kshrc.personal'.
If you wait for us to change your login scripts, the change may hit
you at an inopportune time. you can change to the new scheme
yourself by running the vanilla program. With no options,
vanilla will quietly do the Right Thing, but you can use the
--test mode to have it tell you what it would do without
actually making any changes. ("vanilla --help" will show
you other parameters.)
Confusion abounds about which commands should go into which files. Environment variables are generally set once upon login, and thus should be set in `.login' or `.profile'. Aliases, shell functions, and things you want done each time a sub shell starts (and things not inherited from shell to subshell) should be done in `.cshrc' or `.kshrc'.
| ksh/bash files | csh/tcsh files | Description |
| `.profile' | `.login' | Executed once upon logging in. Set environment variables. May produce output. |
| `.kshrc' | `.cshrc' | Executed every time a shell starts. Set aliases and shell functions. Should never produce output. |
Shells in the ksh family
execute `~/.profile' on login and `~/.kshrc' whenever a
shell starts. The csh family shells execute `~/.cshrc'
on each shell invocation and `~/.login' on login. This document
refers to the these collectively as "login scripts". In examples,
`xxx' indicates any one of these files.
This document was generated on 2 September 1999 using texi2html 1.56k.