Because .login (supposed to contain basic important system setting) is
read in before .cshrc (to contain not so important user customisation),
using .login is basically a farce in my opinion. Putting teh contents
Actually, csh and tcsh, executes the .cshrc first, THEN if, and only
if it is the login shell (not a sub shell) it executes the .login.
Ooops, yes you're dead right. Writing mistake on my part, should have been
"read in after". That's why .login is useless as most of its settings
are often needed while running .cshrc. And, of course, one does the
basics first...
Actually, csh and tcsh, executes the .cshrc first, THEN if, and only
if it is the login shell (not a sub shell) it executes the .login.
correct
As for tcsh, the order in which the .login and .cshrc is sourced is a
compile time option which defaults to the .cshrc (or .tcshrc) before
the .login. There may be some wackos out there who change the default
in memory of the system(s) that they were raised on. I suggest
electroshock as the proper treatment.
seconded. :-)
If someone goes to the trouble to change the order,
I would love to know a valid reason for it.
If .login was sourced first, it would actually be useful. However, doing
it that way round is now too late. As it is, one has to put the .login
stuff into .cshrc/.tcshrc, properly surrounded by if .. endif. Also,
the distinction for running .login shouldn't be whether it's a login
shell, it should be whether it is an interactive shell. That would be
even more useful. However, ... see above.
Volker