A csh question ...

[Juergen Wagner]

In article <636 at fxgrp.UUCP> ljz%fx.com at ames.arc.nasa.gov (Lloyd Zusman) writes:
>A question concerning csh:
>
>Can anyone explain why .login gets sourced *after* .cshrc?  I am constantly
>running into situations where I'd like .login to get sourced first, and I
>cannot see any good reasons for why it should get sourced after .cshrc.

I don't see why you would like to read .login first. Basically, .cshrc has
the job of setting up things you'd like to have in *every* csh. Typically,
you will have a unconditional section, and a section depending on the value
of $?prompt. Everything else should go into .login.

>I end up doing things like the following hack to get around this:
>
>    # This resides at the top of a hypothetical .cshrc file ...
>
>    if (! ${?FIRST_TIME_THROUGH}) then
>    	setenv FIRST_TIME_THROUGH
>    	# do all sorts of startup stuff that I would prefer to put
>    	# into .login if it were only sourced before .cshrc
>    endif

What makes you think something gets executed twice? The csh reads .cshrc,
i.e. sets up an environment suitable for your interactive needs, as well as
for mail or the Liszt LISP compiler who fire up cshs. Then, your .login
is source'd, thereby establishing all the things you need for a (now
definitely interactive) session, like biff, stty, tset, ... Since environment
variables are inherited from the parent's shell, you can set environment
variables once in .login.

So, I don't see any reason why you may want to have .login executed first.
Maybe you could elaborate your point a bit.

>Are there any csh's out there that do this differently, perhaps if some
>command-line flag is set?

As far as I can tell, all cshs do it this way (i.e. read .cshrc, then .login)
because it makes sense.


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