.cshrc vs .login in csh

In csh, the files .cshrc and .login are used to set up the environment.

Which commands should be in which?

One opinion here is that the .cshrc should be kept as small as possible
to keep it fast and that as much as possible of the initial environment
setup should be put into the .login

The other opinion is the reverse.

Could anyone elucidate?

--
GARY WILLIAMS, Computing Services Section, Janet: G.Wil...@UK.AC.CRC
MRC-CRC & Human Genome Mapping Centre, Internet: G.Wil...@CRC.AC.UK
Watford Rd, HARROW, Middx, HA1 3UJ, UK
Tel 081-869 3294 Fax 081-423 1275

I always work under the following rules for setting up any interactive shell,
and I've never had any problems with them..

1) Anything that automatically gets exported to child processes (such as an
enviroment setting) should be done in your login script.

2) Anything that doesn't get exported to children should be done in the
.cshrc file.

I also find it helpful to use a different script for non-interactive sessions,
which I call by using.

if ($?prompt) then
source ~/.cshenv
exit
endif

in my .cshrc this may take longer but its more flexible, and since it should
only ever get executed from remote shells (rsh), it doesn't slow things down
too much

[stuff deleted]

:--

--
Brian Blackmore, Darwin College,
The University of Kent at Canterbury, United Kingdom.

Well ... it's a little bit unfortunate that things got divided in
that way. While there are some differences between a login session
(shell) and other sessions, the major differences are between
interactive and non-interactive shells.

Contributing to the wierdness is the fact that the .login file is read
_after_ the .cshrc file. As far as I'm concerned, the only commands
that needs to be in the .login file are those pertaining to setting
up the terminal. The rest can be handled in the .cshrc file.

Aliases and other interactive features like cdpath and command
completion can be conditionally set up to be active only in interactive
invocations of csh. Safety features like noclobber and aliases for rm
should probably be the same for all csh instances, interactive or
otherwise. I include specifications for the path and other commands
needed by all shells at the top of my .cshrc file. The following
line ends the global portion of the .cshrc. Lines following this
pertain only to interactive shells.

if ($?USER == 0 || $?prompt == 0) exit

If no username is present in the environment or no prompt has been
set, it is a noninteractive shell. There's no sense processing all
the aliases and such, so exit the .cshrc (but not the shell).

-r

This is a FAQ I put together... Comment welcome

---------------------
Csh Startup Summery
---------------------

This document contains a summized guide to the startup process for the
csh and tcsh unix shell. In this guide you will find:-

INDEX 1) Sections executed on startup under various conditions
INDEX 2) What should/could be perform in each startup section
INDEX 3) T/csh setup requiring no ``.login'' file.
INDEX 4) A solution to X Window environment initialization problem
INDEX 5) Small tricks, aliases and other bit 'n' pieces
INDEX 6) Disclamer: Csh Script Programming Considered Harmful

-- Anthony Thyssen (ant...@dragon.cit.gu.edu.au)
-- Paul Davey (p...@x.co.uk)

------------------------------------------------------------------------------
INDEX 1) Sections executed on startup under various conditions

Assuming that the .cshrc file is divided into two sections depending on
if the `prompt' was defined by the shell program.

* Interactive (prompt defined -- normal user session)
* Non-Interactive (prompt undefined -- script or rsh initialization)

EG:
#echo "Executing .cshrc script"
#----- non-interactive shell -----
if ( ! $?prompt ) then # test if non-interactive (script or remote)
...
...
exit 0
endif
#------- interactive shell --------
...
...

NOTE: The non-interactive section should be very small and fast, providing
the minimal anount of setup required to work. The only thing which must be
provided is a minimal `path', particularly containing the normal unix
binary directories and the X Windows directory.

EG:
set path = (/usr/ucb /usr/bin /usr/local/bin /usr/bin/X11)

This create three posible sections that can be executed on startup,(two
in .cshrc, and one in .login) and you may want to include a fourth section
with .logout (exit csh script)

Here are all the situations that I can find and the parts in the above
scheme which are are executed for that situation :-

csh script with a -f option no sections performed at all
csh script without -f option non-interactive .cshrc script only
remote command (rsh) non-interactive .cshrc script only
vi shell escapes / file manager non-interactive .cshrc script only
sub-shell (t/csh or plain xterm) interactive .cshrc only
full login or xterm -ls interactive .cshrc and .login
in that order (and .logout on exit).

-- Anthony Thyssen (ant...@dragon.cit.gu.edu.au)

------------------------------------------------------------------------------
INDEX 2) What should/could be perform in each startup section

non-interactive .cshrc (scripts, remote and shell escaped commands)
* set important environment variables if we are csh
(tcsh does this automatically) -- HOST and HOSTTYPE
* default path so the X11 commands can be found without a full path,
as well as for t/csh scripts without the (-f) flag
* small number of aliases for use in rsh, and from the Sun Open
Window File Manager user menu and as vi shell escapes.
* umask (for remote commands or they run with umask 0)

interactive .cshrc (All Csh and Tcsh related stuff should be here)
* set complete interactive path for normal usage. This could be in
.login but is here because the non-interactive test normally does not
exist. It also places both path definitions in the same file for
easier handling.
* csh/tcsh settings:- prompts, filec, cdpath, periodic(tcsh).
* full alias list for user's usage. I actually place this in a
.cshaliases file which I source.
* the cd-prompt hack for csh IE :-
alias cwdcmd 'set prompt="$cwd:t> "' alias cd 'chdir \!* && cwdcmd'

full session startup -- .login (stuff to be set up once only)
See also INDEX 3 for incorperating this into .cshrc
* complete environment variable initialization
* miscellanous commands umask, stty, mesg
* determine where we are logged in from (say for printer selection)
* start window system if nessary
* specialized terminal type setup. For example:-
+ dialin, network, or unknowen
terminal type correction for pc's, macs, and home computers (amiga)
+ xterm
determine DISPLAY and terminal size on remote machines
set the xterminal title (IE: to the current host name)
* checks for mail, news and other login notifications
* check on breakin / illegal account access
* opening messages

exiting full session -- .logout (script called on logout)
Remember .logout is called only if the shell exits normally:
This can lead to problems if your shell core dumps and then you have
to deal with a ``You are already logged in'' message 'cos .logout
didn't decrement a count.
* cleanup of account
* closing messages
* session summeries

NOTE: You do not need to do all the above. I myself do most of them except
for a couple which is not needed in my own setups.

If you have anything to add to this list please let me know.

-- Anthony Thyssen (ant...@dragon.cit.gu.edu.au)

------------------------------------------------------------------------------
INDEX 3) T/csh setup requiring no ``.login'' file.

I recently ceased using .login for anything. It's handy for setting the
environment once but since it is read after .cshrc you can not use its
variables in aliases etc. I now detect a login (or rsh job) by the fact
that the environment (actually just the environment variable ENVSET) is
not set.

EG: in .cshrc script (immediately after non-interactive checks)
# IS THE ENVIRONMENT SET?
if ( $?ENVSET == 0 ) setenv ENVSET -1 # insure ENVSET is defined
if ( $ENVSET != 1) then # is the environment set
# ---- normal login section ----
# do environment setup and terminal checks here
...
setenv ENVSET 1
endif # ENVSET != 1
-- Paul Davey (p...@x.co.uk)

------------------------------------------------------------------------------
INDEX 4) A solution to X Window environment initialization problem

For X it is convenient to have several clients (especially a window
manager) started at login and of course this can be done from scripts
such as .xsession run from xdm.

However clients started from .xsession do not inherit the users
(carefully tailored) environment from .cshrc/.login.

One way around this is to make .xsession a csh script which sources
.cshrc and/or .login but this is not particularly fast, reliable or
portable.

My solution is to make .xsession set a flag variable (XLOGIN) to 1 and
to start one xterm (with shell) only.

Within .cshrc a new section starts initial clients when XLOGIN is 1
after the environment has been initialized. It then sets XLOGIN to 0 to
prevent this happening again if the file is reread.

This allows the environment to be set in one file without having to
source .cshrc from a .xsession written in csh.

Of course if you are logging in and running startx or xinit from the
command line this approach is not needed as the X session inherits the
environment from the login shell; This method will however cope with that
case as well (my .xinitrc is a link to .xsession).

EG for .xsession script
#!/bin/sh
# .xsession file
HOST="@`hostname`"
xrdb $HOME/.Xdefaults
XLOGIN=1
export XLOGIN
exec xterm -ls -geometry 80x24+0-0 -T "LOGIN$HOST" -n "LOGIN$HOST"

AND in the .cshrc script (after the environment setup (see above) )
if ( $?XLOGIN ) then
unsetenv XLOGIN
# set a local csh variable for this critical xterm (started .xsession)
set ignoreeof

# ---- start other X clients ----
# Should really check xconsole exists (and works) before this bit
# wait for xconsole to fork before continuing
xconsole -daemon -geom 700x100-0-0

csh -f << EOF >& /dev/console
set verbose
twm &
xterm -name xterm-$HOST -geometry 80x45+0+0 &
xclock -g 100x100-0+0 &
xsetroot -fg red -bg black -mod 2 2 &
EOF
endif # XLOGIN
-- Paul Davey (p...@x.co.uk)

NOTE: I myself do not like this method, instead I opt'ed for sourcing a
bourne shell with the appropiate minimal environment required in the
.xsession file. It works for me.
--- Anthony Thyssen

------------------------------------------------------------------------------
INDEX 5) Csh Startup modularization
You may find it useful to actually split sections of your .cshrc into
separate files. These can be read in with the source command which reads
and evaluates a file in the current shell, ie without forking a subshell.
(It is the equivalent of the ``.'' command in sh).

Breaking the .cshrc file into smaller files to be sourced, has certain
advantages.
* Reading of the .cshrc programming stucture is easier
* All the aliases and environment variables are defined in the one place

For example:
i) Define your aliases in ~/.cshaliases
ii) In .cshrc give the command ``source ~/.cshaliases'' in the
interactive section defined above.

Some canidates for modurizations are
.cshaliases defines all your csh aliases
.cshenv environment variable definitions (sourced from .login)
.cshlogin a .login replacment to call from .cshrc ? (see INDEX 3)
.cshXstartup X window startup clients script (see INDEX 4)
.cshprompt script to set the csh prompt according to current directory

The above are only suggestions, the file names used for the sourced csh
scripts can be anything you like, or even stored in a .csh sub-directory.

Any sourcing of an external file will slow down evaluation, but only
very slighly.
-- Paul Davey & Anthony Thyssen

------------------------------------------------------------------------------
INDEX 6) Small tricks, aliases and other bit 'n' pieces
This is a list of small ``tricks'' that can be incorperated into your
own .cshrc/.login startup files.

i) Show only new MOTD (messages of the the day) on login

if (-f /etc/motd ) then
cmp -s /etc/motd ~/.hushlogin
if ($status) tee ~/.hushlogin < /etc/motd
endif

ii) Changing the prompt to reflect the current directory

alias setprompt 'set prompt = "`pwd` > "'
alias cd 'chdir \!* && setprompt'
alias pushd 'pushd \!* && setprompt'
alias popd 'popd \!* && setprompt'
setprompt

iii) Searching for a particular process (given as argument)

alias pf 'ps auxgw | cut -c1-15,36-99 |\\
awk "/\!:1/ && ! /(awk)/ || NR==1"'

-- miscellanous

------------------------------------------------------------------------------
INDEX 7) Disclamer: Csh Script Programming Considered Harmful

There are plenty of reasons not to use csh for script writing (see Csh
Programming Considered Harmful [anon ftp from convex.com /pub/csh.whynot])

This file is an attempt to explain how to make it easier and more
convenient to use it interactively. It does NOT provide a guide to using
csh as a general script writing language, and the authors recommend that
it not be used for that purpose.

But why use csh interactively?

The aliases and history list alone make it worthwhile, extra features
such as file completion, tilde expansion, and job control make even more
useful. The tcsh command line editing and other interactive enhancements
make it one of the best interactive shells around.

There are arguablly `better' public domain shells avaliable (eg ksh,
bash, pdksh) that can be used, but I have found them lacking in some
important aspect or, generally not installed. A delivered vanilla machine
is almost certain to have csh. A .cshrc and .login setup can then be
easily copied and is available immediately.

Faced with the choice between plain sh and bad old csh I'll take csh any
day.

-- Paul Davey (p...@x.co.uk)
-- Anthony Thyssen (ant...@dragon.cit.gu.edu.au)

------------------------------------------------------------------------------

Anthony Thyssen - (SysProg @ Griffith University) ant...@cit.gu.edu.au
------------------------------------------------------------------------------
No-one knows why smoking boots always remain, no matter how big
the explosion. It seems to be just one of those things.
-- Terry Pratchett "Sourcery"
------------------------------------------------------------------------------

--

THE STONY BROOK PRESS
--------------------------
The State University of New York at Stony Brook Community's Feature Newspaper
" All the News That's Not Printed to Fit. "

Snailnet: The Stony Brook Press
S.U.N.Y. at Stony Brook
Stony Brook N.Y. 11794

e-mail : sbp...@ic.sunysb.edu
alternate e-mail : dgla...@ccmail.sunysb.edu
Voicenet : (516) 632-6451

I beg to differ! Here, we have a number of applications which can be set
up (added to $path and environment variables set) by sourcing a file for
each application. Unfortunately, the default user setup (which I have no
control over) sets the path in .cshrc. So the user adds all these source
commands to his/her .login, then enters SunView or OpenWindows and gets the
path reset again.

Personally, I use zsh for a number of reasons, one being the inclusion of
more startup files - .zshenv is always sourced (unless -f is specified),
.zshrc is only sourced in interactive shells and .zlogin only in login
shells. There's also a .zprofile but I don't use it.

-- neilski

--
RADIO CRACKER - 103.6 FM \--------------------------------------------------
----------------------------\ You come here to my daughter's wedding,
but you show me no respect. You ask me to listen to ... Radio Cracker.

What I have found is while login onto the console of an SVR4.2 (i386)
and running 'vtlmgr' which sets-up the virtual terminals the .login
isn't run for each virtual shell, but only the .cshrc.

Thus I have arranged my .cshrc & .login accordingly

That is I put the setenv 's in .cshrc & any if's, set's, case's, etc
in the .login.

Matt

--
Matthew Roderick : E.S.Team : m...@oasis.icl.co.uk || m...@dsbc.icl.co.uk
+44 [0]782 771000 x3270 MyDisclaimer:= StdDisclaimer
/\/\/\/\ kernel panic: AC Power Fai^[

This is a subject that causes religious debate! In the good old days
people would login and run shells under that login. No more. Window
managers don't necessarily login, people want to be able to type:

rsh host command

In other words, people's initial connection to a machine is no longer
necessarily a login or even interactive. On my machines I have a
generic setup mainly to set up environmental variables such as PATH,
MANPATH, LD_LIBRARY_PATH, DISPLAY, etc which also sets a dummy
environmental variable LPATH. This gets incorporated into /etc/cshrc
surrounded by an if test for $?LPATH. This seems to me to be the best
compromise. In /etc/login I put terminal identification (I use qterm)
and tty setup, message of-the-day printing (which also gets done in my
X setup), etc. Sheer force of habit also makes me put the environment
setup into /etc/login too!

John Rowe
Dept. Physics
Exeter University
U.K.

>rsh host command

Correct, and to add confusion to the whole thing, I have the following
list of files:

.cshaliases .login .tcshenv
.cshenv .tcshaliases .tcshrc
.cshrc .tcshcomplete

Obviously I've got tcsh in there just to complicate things... but this
is roughly how it goes:
calling order:
Login shell: Interactive subshell non-interactive shell
------------ -------------------- ---------------------
/usr/bin/csh /usr/bin/csh /usr/bin/csh
|.cshrc |.cshrc |.cshrc
||.cshenv ||.cshenv ||.cshenv
||.cshaliases ||.cshaliases
|.login
~/bin/tcsh -l
|.tcshrc
||.cshrc
|||.cshenv
|||.cshaliases
||.tcshenv
||.tcshaliases
||.tcshcomplete
|.login

If you are wondering WHY I go through the whole process twice for
login shells, thats because tcsh is not an official shell here, and so
I need to put some checks in my .login file to start up tcsh, and of
course it wants everything that csh got. oh well. (its no good to
have the check in the .cshrc because then shell escapes tend to get
stuffed up! so I suffer with csh for shell escapes (but its not that
bad, tcsh's main strong point is its interactive interface))

the .cshrc file is essentially 2 lines plus an if statement, (source
envs then if interactive source aliases).
.tcshrc is essentially the same.
.cshenv is all environment related stuff (ie: what I need to run
a shell escape for example)
.cshaliases is all the aliases
the .tcsh files are the same sort of thing, but only those things unique to
tcsh, (including some un-settings)
and .tcshcomplete is only interesting if you have a tcsh with programmable
completions.

Unfortunately csh always sources .login LAST during startup of a
login shell.

oh I almost forgot my golden rule. NO OUTPUT FROM ANYTHING BUT THE
.login file!! Reason: If you run a shell escape, for example in vi,
and want to catch the output, you will get any output from the .cshrc
file also. This is a real bitch if you try to access files like
~/myfile, cus vi calls the shell to expand the ~. What vi gets back
from the shell is all the output, and then it whinges about having too
many file names to contend with etc. BE WARNED!

hope that has helped someone.

-----------------------------------------------------------------
Stephen Riehm Configuration Management _-_|\
s...@pki-nbg.philips.de Philips Kommunikations Industrie / \
Work: +49 911 526 2975 Nu"rnberg, Germany \_.-.!/
Fax: +49 911 526 3678 "I was there, now I am here!" v
"My company speaks another language, I CAN'T speak on its behalf"

>JR...@cen.ex.ac.uk (J.Rowe) writes:

>Obviously I've got tcsh in there just to complicate things... but this

> /bin/csh /bin/csh /bin/csh

This sourcing of everything twice for interactive shells was due to a
stupid oversight on my behalf, I now have nothing in my .login file
(since I don't get anything printed anyway), and I have a check for:

if ( $prompt && ! $?tcsh && -x ~/bin/tcsh ) then
exec ~/bin/tcsh
endif

as the first thing in my .cshrc. Now the calling sequence looks like
this:
Login AND interactive shells:
-----------------------------
/bin/csh
|.cshrc
~/bin/tcsh
|.tcshrc
||.cshrc
... etc

Thanks to those who woke me up!

Ed

You should have read the rest of the thread before you wrote..

Because you sometimes get a shell *without* logging in. Such a shell
will source .cshrc but has no ancestor which has sourced .login. Like
all my xterms, for a start. No I don't want to start all my xterm
shells as login shells.

I always set an environment variable (not a shell variable, since they
don't propagate) which indicates whether or not my .cshrc has been
sourced yet. My .cshrc then checks the existence or value of this
variable to decide whether to set things like my path, etc. You can
also check whether the shell variable, prompt, has been set to decide
whether to do terminal setup.

Currently the variable I use for this purpose is SHELL, and the value
I look for ends with `Rc'. (It was `rc' but one vendor's /bin/sh
thinks that the environment variable SHELL set to such a value
indicates a restricted shell, breaking the few /bin/sh scripts I
haven't yet converted to rc.) The [t]csh is still my login shell
because I (infrequently) want to do job control in situations where I
have neither X nor screen available --- it's a not-very-satisfactory-
but-almost-passable window manager....