[comp.unix.wizards] skeleton sys.login and sys.cshrc

geeb@caen.engin.umich.edu (Mark A Gebert) (11/09/89)

This is a 3 part question:

1) How far should a system administrator go in setting up a users enviroment? Should is include "neat"
things? What belongs in the sys.login besides a tset? What belongs in a sys.cshrc? (I know what the bsd
manuals say but I want to hear your idea's).

2) Should there exist sys.profile's for ksh and sh? (Since there is growing user demand for them) What
about a tcsh? Does anyone have this set up?

3) By now your thinking I'm a little loony or stupid. But this has been part of a debate at U of M over
the last month. But now for a real question:

We have a diverse base of computers here (Sun's, Dec's and Apollo's). And users rlogin from one
architecture to another frequently. Here's the problem: when a user logs in the following tset is used.

       eval `/usr/ucb/tset -s -Q -m "dialup:${TERM_DIALUP}" -m "unknown:?${TERM_NETWORK}"
             -m "network:?${TERM_NETWORK}"`

This works nice and dandy on the first machine the user logs into. But rlogging in another machine and
doing this tset causes vt100 mode to be locked into an 80x24 screen size rather than using the real
size of the window. But doing the following tset.

                                  eval `tset -Q -I -s`
                                  
The remote host recognizes the screen size no prob. But dialing in from home or using an IBM PS/2 or XT
causes the term variable to be undefined. Question: Is there anyway to determine if it is the users 
inital login to the network and do tset #1. Then on every subsequent rlogin from the inital login
tset #2 is used. Or is there a bizarre combination of options in tset that would solve this prob?

Thanx. And no flames (please!!). I wouldn't have posted but I've tried alot of different things that
haven't worked. 

--geeb

erlkonig@walt.cc.utexas.edu (Christopher North-Keys) (11/22/89)

(part of the genesis of the scripts collectively called the "elfshell")

The problem we had goes as follows:
	csh user logs in.
	.cshrc runs (cannot use env settings in .login)
	.login runs (should contain the env settings)
	user calls subshell
	.cshrc runs (*CAN* use env settings from .login)

The user wanted to put all the setenv things in the .login, and all the 
aliases and suchlike in the .cshrc.  The problem is that all .cshrc's *save*
the first had the user's full environ, and could depend on them in subsequent
aliases like:  alias p $PAGER .  The first run of the .cshrc alone had to
be independent of the environment.

The idea we had was that every shells .cshrc should be as small as possible,
and thus putting everything possible into the .login and running all the env
stuff first JUST ONCE would be a nice speed improvement.

This, of course, doesn't work, as the .login runs second---perfect for
checking mail and suchlike, but at best a jury-rigged substitute for what
we wanted.

We added a new file, .cshlc (C-sh login commands), in which we placed all
the setenv commands and suchlike along with the command:

	setenv LOGGED $USER

we then altered the .cshrc to source this file if $LOGGED didn't equal $USER:
(near very beginning of .cshrc)

	if!($?LOGGED) setenv LOGGED
	if ("$LOGGED" != "$user") source ~/.cshlc

(it looks strange, but it's as few lines as we could manage)
and finished the job by reducing the .login to the level of commands like
from, quota, and logging.

This made everything run quite nicely.

------------------------------------/\----------------------------------------
Seo:  Harp[@Mcc.Com]               /  \/\ ^*^           Christopher North-Keys
Tha mi gu trang a'cluich.         /    \ \         Assoc. Systems Analyst, MCC
--------------------------------(disclaimer)----------------------------------