Path: utzoo!attcan!uunet!husc6!uwvax!dogie!uwmcsd1!bbn!mit-eddie!bu-cs!purdue!decwrl!labrea!csli!gandalf
From: gandalf@csli.STANFORD.EDU (Juergen Wagner)
Newsgroups: comp.unix.questions
Subject: Re: A csh question ...
Message-ID: <3995@csli.STANFORD.EDU>
Date: 22 May 88 03:16:42 GMT
References: <636@fxgrp.UUCP> <7953@brl-smoke.ARPA>
Reply-To: gandalf@csli.UUCP (Juergen Wagner)
Organization: Center for the Study of Language and Information, Stanford U.
Lines: 74

After my posting I have received a number of responses of the form 
	"I am doing ... in my .cshrc, and also ... in .login, and
	 for that I need .login executed before .cshrc."

I don't believe there is the need to run .login before .cshrc. .cshrc
is intended to initialize *EVERY* csh fired up (except those invoked with
-f option), so subsequent programs run well. There is a clear distinction
between things which are typically done in .cshrc and .login:

.cshrc:
	setting umask
	setting up some environment variables like USER/LOGNAME/...
		which are supposed to be there in every environment.
	setting a (probably preliminary path/cdpath)
	setting csh variables
	providing aliases
	setting a (probably also preliminary) prompt.

    Never put in something setting the terminal, doing biff, echoing
    some text, etc. Remember: .cshrc is run every time a csh is fired
    up (by mail, emacs, X windows, LISP compilers, Prolog, ...) and
    should be as simple as possible (for obvious reasons). The case in
    which an interactive shell is started, can be recognized by using
    $?prompt conditionals. Oh, yes, and of course, the .cshrc *CAN*
    contain aliases and ways to set the prompt in a terminal dependent
    way. You just must not call them there.

.login:
	set the terminal type and initialize the terminal
	set some globally defined environment variables like (EXINIT, EDITOR,
		VISUAL, EMACSLIB, EMACSLOADPATH, TEXLIB, ...) which should
		be accessible for all programs run interactively.

    You now may say "what if one needs these variables in a rsh, too". Well,
    in that case, execute a "source .login" before you actually run the
    desired program, and be sure your .login also does the $?prompt business.

    In my .login, all the machine/terminal/UNIX-version dependent things
    are done. This includes computing/fetching host/...-dependent values
    for some environment variables. Then, 

    If you'd like to set your prompt depending on the terminal type (e.g.
    highlight some portions of it with terminal-specific control sequences),
    why don't you do this here. I can't remember the last time when I've
    exchanged the terminal just before running a new csh, so I don't see
    a need to do this in a fashion requiring to execute .login first. Either
    you are running with $?prompt==1, i.e. you can set the terminal-specific
    prompt wherever you want to, or you have $?prompt==0 and you don't have
    a terminal at all.

Apologies for this message being so long but I have a final comment on my
.login. The last two steps in my .login are 
    o  source a location-dependent .login (location=institute or something
       similar), and
    o  read a host type dependent .login (host type is sun, vax, ...).
This allows me to have the same rc files on all machines I'm working on, even
if one is a Bobcat (HP-UX), one is a Sun 3, one is a Sun 4, another one is 
a VAX, ...

A small configuration database consisting of some attribute lists and a couple
of shell scripts provides this functionality, and I've been pretty happy with
it. Of course, this doesn't claim to be an ideal solution to all problems but
has been working fine.

I'd love to hear of instances where it is impossible or unreasonable (i.e.
requiring too much efforts) to get along with the .cshrc .login order of
execution.

All opinions expressed herein, even the most arbitrary, are defended by my
employer with religious fervor.

-- 
Juergen "Gandalf" Wagner,		   gandalf@csli.stanford.edu
Center for the Study of Language and Information (CSLI), Stanford CA