My Original question was:
>
>Hi,
>
>In establishing a new user environment I am currently considering setup csh
>login scripts. I know that csh processes the global system /etc/csh.login
>then $home/.cshrc then $home/.login.
>
>Does anyone have any advise or experiences that may help in organizing csh
>login scripts to minimize future modifications?
>
>Does anyone have preferences as to where certain things are put. ie what
>would go in .cshrc verses .login and why?
>
>Examples welcome.
>
>This may seem a simple question, but I would like to do it right the first
>time.
>
>Regards,
>Phil Pidgeon.
>ppidgeon_at_omc.otis.utc.com
>
>
----------------------------------------------------------------------------
------------------------------------------------
RESPONSE 1:
I always have the following in any .cshrc:
set history=200
alias ls ls -sFa
alias h history
The first one saves commands to be referenced later during
the execution of THIS shell.
The second one shows the user the size of her/his files,
shows all of the dot files, and also shows the type of
file for each file. I can't get along without this one.
The third is just a shorthand because it's hard to type the
word "history".
I won't overload you with a bunch more.
At 01:31 AM 1/18/96 -0800, you wrote:
/\/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/\
Julie O'Shaughnessy Battle jab_at_elmo.pgh.wec.com
Westinghouse Communications and Information Systems
(412) 247 - 6214 Pittsburgh, Pennsylvania
----------------------------------------------------------------------------
------------------------------------------------
RESPONSE 2:
Phillip Pidgeon scripsit:
|Does anyone have any advise or experiences that may help in organizing csh
|login scripts to minimize future modifications?
Of course you want to place here anything which is generic to your
systems like path statements and LD_LIBRARY_PATHS if you ahve shared
libs built somewhere different than the standard places. You shouldn't
run anything which isn't strictly necessary, only stuff you want all
users to source. I only have a default path and stuff like MANPATH
WWW_HOME so that they don't all shoot off to netscape, etc. Basically:
defaults which you want to make sure all users have.
|Does anyone have preferences as to where certain things are put. ie what
|would go in .cshrc verses .login and why?
Simple: .login is sourced only on an interactive shell, so no terminal
i/o should occure in .cshrc and it shouldn't assume and interactive
session. My .login is virtually empty whereas my .cshrc is quite
large.
Ciao,
Arrigo
--
Arrigo Triulzi <arrigo_at_lpac.ac.uk> - +44-171-775-3247
London Parallel Applications Centre - London E1 4NS - UK
----------------------------------------------------------------------------
------------------------------------------------
RESPONSE 3:
On 18 Jan 1996, Pidgeon, Phillip wrote:
>
> Does anyone have preferences as to where certain things are put. ie what
> would go in .cshrc verses .login and why?
.cshrc gets executed whenever you fire up a new shell. .login gets executed
only when the shell is marked as a login shell (e.g.
your first login, an xterm marked with -ls, etc.
i'd say put all of the environment stuff into .cshrc, .login
should only have stuff that needs to be DIFFERENT for a
login window from a standard window/shell.
An interesting thing that i have seen (for environments
with lots of different machines which have all sorts of applications)
is as follows:
the /etc/csh.login (or profile for the borne shells)
would setup basic paths then would source the files in
/local/environment/shell/csh/*
where that directory would have a sequence of scripts -
setup paths/whatnot for that OS, then for that specific machine,
then for any specific applicatoins that need environment settings
(e.g. ingres, oracle, etc)
so you would see something like this:
(bear with me, i am a bourne shell/bash user so my csh syntax
_WILL_ be off -- go for concepts)
/etc/csh.login:
#
# setup network wide stuff
# note here: you may wnat to have some way
# of verifying that your network filesystem
# is up and happy before doing this so that you
# don't get blocked.
#
foreach f (/share/environment/shell/csh/*) {
source $f
}
#
# setup local applications
#
foreach f (/local/environment/shell/csh/*) {
source $f
}
then those directories would have stuff like
II_SYSTEM=/usr/local/ingres/bin
II_WHATEVER=something
PATH=$PATH:/share/bin
-- craig
___ ____ __ Craig I. Hagan, Pencom System Administration
| _ \/ __/| \ Pencom Office: hagan_at_psa.pencom.com
| _/\__ \| \ \ At home: hagan_at_cih.com
|_|__/___/|_|__\ "True hackers don't die, their ttl expires"
________________________________________________________
RESPONSE 4:
Your csh shell must be a later version. Mine does not process any system
wide files, only the $HOME/.cshrc and $HOME/.login. In order to make it
process the system files, I have to insert a source /etc/csh.xxxx to get
it to insert the system settings.
Here are some points from experience:
(1) I avoid the csh entirely and have replaced it with tcsh which is
a much better csh variant.
We have a mixed bag of machines and do not wish to rely on whether
csh sources the system-wide /etc files or not.
(2) the system-wide .cshrc, .login, and .profile files in /etc are all
links to a common NFS mount point for all machines, ie,
/etc/csh.cshrc -> /common/adm/csh.cshrc
...
You get the idea. Any changes are made only to the common files and
appear on all machines. A minor downside to this is that when
booting the machine single-user, you lose your system settings. This
is pretty minor since booting single-user means you have something
serious to fix and should not rely on any system settings.
(3) I've rewritten the /common/adm/csh.cshrc, etc. files so that they
case on /bin/uname. /bin/uname returns the OS, so you can set up the
appropriate settings based on the value /bin/uname returns. This
is pretty handy in an heterogenous environment and can be easily
extended if additional Unix flavors join your cluster of machines.
Good luck
----------------------------------------------------------------------------
------------------------------------------------
RESPONSE 5:
Well, what I did was create a common .cshrc, and when I create a new user,
his/her .cshrc a link to the common one. Then I can make corrections and
additions to all users by editing one file. This file has 'hooks' for
setting the environment, csh-defaults, aliases etc. I also tries to
take care of different PATH, MANPATH etc settings on different platforms.
(I support about 10 different unixes).
Anyway, here's my common .cshrc:
--- clip ---
# MTYP is a script that describes the platform you run on, so the script
# *must* be installed on all machines.
if (! $?MTYP) then
# login or rsh mach cmd (this is the ".login" part of .cshrc
# this part will only be executed once for a pty
setenv MTYP `/usr/local/bin/mtyp`
set path=(/usr/local/bin /usr/ucb /bin /usr/bin /usr/bin/X11 .)
setenv MANPATH /usr/local/man:/usr/man
switch ($MTYP)
case sparc_solaris2:
setenv MANPATH
/usr/man:/usr/share/man:/usr/openwin/share/man:/usr/local/man
setenv PATH /usr/ccs/bin:$PATH
breaksw
case osf1:
setenv MANPATH /usr/man:/usr/share/man:/usr/local/man:
breaksw
case clipper:
setenv MANPATH /usr/ip32/sysvdoc/catman/i_man:/usr/local/man
breaksw
case unixware:
setenv MANPATH
/usr/flib/books/man:/usr/X11R6/man:/usr/local/man
set path=(/usr/ccs/bin /usr/X11R6/bin $path)
breaksw
case sgi:
setenv MANPATH
/usr/share/catman/a_man:/usr/share/catman/g_man:/usr/share/catman/local:/usr
/sh
hare/catman/p_man:/usr/share/catman/u_man
set path=($path /usr/bsd)
breaksw
case hp700_ux10:
set path=(/opt/ansic/bin /usr/ccs/bin /usr/local/bin /bin
/usr/bin /usr/bin/X11 /usr/contrib/bin /usr/contrib/bin/X11
/opt/langtools/bin /opt/fortran/bin .)
setenv MANPATH `cat /etc/MANPATH`
endsw
# now a hook for env. variables like PRINTER, EDITOR, LESS
if (-f ~/.environment) source ~/.environment
# you may also set PROD which can source a project's common
definitions
# all projects are in /prod/$PROD/...
if ($?PROD) then
if (-f /prod/$PROD/.environment) source
/prod/$PROD/.environment
if (-f /prod/$PROD/src/.environment) source
/prod/$PROD/src/.environment
endif
umask 02
endif
# now the following part will be executed everytime, but only for an
# interactive shell, not for scripts etc.
set tty=`tty|&cat -`
if ("$tty" =~ /dev/* & $?prompt) then # do we have a tty
if ($?user) then
setenv USER $user
else
setenv USER $LOGNAME
endif
set prompt="$USER_at_%m> "
set cdpath=(~ /prod /users ..)
set history=100
set savehist=100
if ($?PROD) then
if (-f /prod/$PROD/.aliases) source /prod/$PROD/.aliases
if (-f /prod/$PROD/src/.aliases) source
/prod/$PROD/src/.aliases
endif
if (-f ~/.aliases) source ~/.aliases
# personal aliases
if (-f ~/.csh-defaults) source ~/.csh-defaults
# personal shell settings, like clobber, ignoreeof....
if (-f ~/.hushlogin) then
msgs -q
else
msgs -f
from
endif
if ($MTYP =~ hp700*) then
setenv LINES # well...
endif
endif
--- clip ---
All our projects are rooted under /prod (which actually is an rdisted
symlink-tree... This has worked extremely well for us. You might have to
do some editiong, though
>
> Regards,
> Phil Pidgeon.
> ppidgeon_at_omc.otis.utc.com
>
--harald
Harald Lundberg <hl_at_tekla.fi>;Tekla Oy,Koronakatu 1,FIN-02210,ESPOO,FINLAND
tel +358-{0-8879449work,0-8039489fax,0-8026752,11-2418013res,50-5578303mob)
----------------------------------------------------------------------------
------------------------------------------------
RESPONSE 6:
We channel all of our users through scripts in /usr/local/skel. Here's a
typical .cshrc:
#
setenv group `groups|cut -d" " -f1`
#
source /usr/local/skel/.cshrc.$group
and a typical .login:
source /usr/local/skel/.login
#
# Start menu
#
/usr/local/bin/menu
logout
In /usr/local/skel we have the following:
./ .cshrc.csc* .cshrc.other* .login*
../ .cshrc.emp* .cshrc.stu*
The user hits the .cshrc that corresponds to his/her primary group. This
made life simpler for us since we just switched 2500 VMS users to Digital
Unix last summer. If there was something we missed in the login
sequence, we could change it in one place rather than modifying thousands
of files (which we DID have to do once).
For now we drop everyone into a home-brewed menu program. There is an
option to logout which simply exits the program and causes the .login to
hit the 'logout' command.
Hope this helps.
============================================================================
===
==
Don Newcomer Dickinson
College
newcomer_at_dickinson.edu P.O. Box 1773
Carlisle, PA
17013
"If God is your co-pilot, switch seats!"
----------------------------------------------------------------------------
------------------------------------------------
Best Regards,
Phil Pidgeon
OTIS Engineering Center
ppidgeon_at_omc.otis.utc.com
Received on Wed May 29 1996 - 07:00:43 NZST