crontab for ordinary users

[Mark Poepping]

----
In article <FPB.90Oct21120952 at ittc.ittc.wec.com>, fpb at ittc.wec.com (Frank P. Bresz) writes:
|> 
|> 	PATH IMHO is something that should be set at login time only.  It
|> ...
|> 	Now for the question (flame request) of the day.  Do people in
|> general agree with me that .cshrc ought to not touch the path variable or
|> the PATH env and just inherit it?
|> --
|> | ()  ()  () | Frank P. Bresz   | Westinghouse Electric Corporation
|> |  \  /\  /  | fpb at ittc.wec.com | ITTC Simulators Department
|> |   \/  \/   | uunet!ittc!fpb   | Those who can, do. Those who can't, simulate.
|> | ---------- | (412)733-6749    | My opinions are mine, WEC don't want 'em.
----

I agree on point one, but disagree on point two.

Some years back, we instituted a conditional in the .cshrc to enable .login
functionality (execute only once) in the .cshrc.  Basically, the .cshrc looks
like this..

-------
# Standard style .cshrc

if ($?prompt) then
    # set aliases, prompts, etc. here.
    alias xs 'set noglob; eval `resize` ; unset noglob '
endif

# Run through this stuff only once (simulate .login style functionality)
if (0 == $?ENVSET) then
	setenv ENVSET "you bet"
	# set one-time environment stuff here..  just about anything but
	# stty's and interactive q/a, they should stay in .login
	setenv MANPATH ${MANPATH}:/usr/misc/man
	set path=(. $HOME/bin ${path} /usr/misc/bin)
	setenv MPATH $MANPATH
	setenv EDITOR 'vi'
	setenv PRINTER 34a
	umask 002
endif
-------

This lets you to have all the right environment variables set (even through
rsh - the main reason I did this) without getting them reset every time you
turn around.  We've had no problems with this and it basically allows us to
reduce .logins to the stty/tset calls, interactive questions, and the usual
window startup stuff.  These are all things you really and only want to do
when you log in (can't stty in .cshrc or you get 'not a typewriter' on rsh).

It might not be quite right for everybody, but it's worked quite well for us.

-- 
Mark Poepping				poepping at sei.cmu.edu
Software Engineering Institute
Pittsburgh, PA