Thank you very much to all who replied. Most managers suggested using tcsh.
Aline...
Original question:
> Dear Sun Managers,
>
> Is there a way to define system wide variables that users don't have to specify
> the path in their .cshrc file. What I mean is all users will get that
> variable when they login i.e. vi...
>
> Any help is very appreciated,
>
> Aline...
>
-------------------------------------------------------------------------------
From: SMTP%"CIGAS%RCKHRST1.bitnet@vm42.cso.uiuc.edu" 24-JUN-1993 16:21:35.19
We have some system wide declarations that we change and want the users
to always have the most current. We do it by putting the following
at the end of each user's .cshrc:
if (-r /usr/local/src/.cshrc) then
source /usr/local/src/.cshrc
end if
This gives everyone the same settings, and we have control over what is
current.
J. Cigas
------------------------------------------------------------------------------
From: SMTP%"John.D.Barlow@arp.anu.edu.au" 24-JUN-1993 17:22:47.02
Install bash and tcsh, replace all users shells by bash and tcsh,
when you install bash/tcsh follow the instructions for "global
initialisation files".
Works great for me (I can send you more details, but your probably
flooded :-)
------------------------------------------------------------------------------
From: SMTP%"fetrow@biostat.washington.edu" 24-JUN-1993 17:35:37.39
I'm guessing here about what you really want but would something like this
work?
~/.cshrc, owned and write protected by root containing:
source /usr/share/lib/std.cshrc
source ~/.cshrc.user
... so that users always get the std.cshrc (with whatever it is you want to
do in there) but can still add stuff of their own.
-------------------------------------------------------------------------------
From: SMTP%"dna@math.ufl.edu" 24-JUN-1993 19:30:28.06
Two ways: Fist, add a line to each person's .cshrc to "source" some
standard file. The problem with this is that they can comment the
line out. Thus, you will want a version of csh that will
automagically source the file.
Sun's default csh has no such built-in ability. Instead, you will
need to build another version of a csh-like shell which does allow
sourcing of a common file. I personally use tcsh for this purpose.
Tcsh is currently on version 6.0.3 and has alot of extra cruft in it.
You may want to disable some of it. One very handy addition (besides
the common source file) is that it supports command-line editing.
I snagged it from:
tesla.ee.cornell.edu:/pub/tcsh/
Hope this helps.
Dallas Antley
dna@{clas,math}.ufl.edu
---------------------------------------------------------------------
From: SMTP%"frankm@shadow.cna.tek.com" 24-JUN-1993 20:13:16.43
Well ... in SYSV there is the /etc/profile ... but what I've done is
create a login.skel and cshrc.skel that is sourced from all users
environment *first* ... then the users do their own stuff afterwords.
Frank
----------------------------------------------------------------------
From: SMTP%"unruh@physics.ubc.ca" 24-JUN-1993 21:36:50.68
Not for csh as far as I know without telling all your users to include
a line like
source /etc/global.login
in thier own .login file. In sh, bash, and I think ksh they go to an
/etc/profile file first, before running the users files.
If you find out differently for csh pls let me know.
Bill Unruh
unruh@physics.ubc.ca
-----------------------------------------------------------------------
From: SMTP%"ballisti@ifh.ee.ethz.ch" 25-JUN-1993 00:22:05.95
Hallo Aline,
what we do here is to put a compulsory line in the .cshrc file of each user:
{deneb:ballisti:[ray]:33}% head .cshrc
# next line is compulsory for every user ==> do not delete it:
source /usr/share/lib/adm/cshell.1
#----------------------------------------------------------------
# you can edit what follows as you like:
...
In /usr/share/lib/adm/cshell.1 I can put all the environment variables
needed on our network.
For the same reason the .login file is compulsory for every user and
also sources some system files. This is to allow user to automatically
switch to a choosen environment (SunView, OpenwWindows, X11) at login
and change it during the session.
Bye Ray
------------------------------------------------------------------
From: SMTP%"Halvard.Halvorsen@trd.sdata.no" 25-JUN-1993 02:06:00.85
under SunOS 4.1.x something like this :
personal .cshrc file for every "supported" user :
source /usr/local/adm/Cshrc
# your own stuff below
# setenv LC_CTYPE iso_8859_1
# stty pass8
# tset
setenv PRINTER lp5
...
personal .login file for "supported users"
source /usr/local/adm/Login
and then you setup environment variables and PATH,MANPATH and possible start of
window systems in /usr/local/adm/Login.
system wide aliases and prompt etc is put in /usr/local/adm/Cshrc.
i have also modified the add_user script to suit my local user setup -
works quite well.
under SunOS 5.x you have a global /etc/.login but i prefer to leave this
unchanged and use the same setup as for 4.1.x (source lines).
----------------------------------------------------------------------------
From: SMTP%"brian@arthur.melpar.esys.com" 25-JUN-1993 04:58:37.08
Tcsh-6.03 provides that functionality via system-wide .login and
.cshrc files. The system-wide .login ( as /etc/csh.login ) and
.cshr ( as /etc/csh.cshrc ) are sourced during user login.
I believe tcsh-6.03 can be found on sunsite.unc.edu or
export.lcs.mit.edu
Cheers,
Brian
----------------------------------------------------------------------------
From: SMTP%"adam%bwnmr4@harvard.harvard.edu" 25-JUN-1993 05:22:16.11
The tcsh allows this, in the form of a system wide
/etc/csh.cshrc and /etc/cs.login file that are read on startup. It
also has 30 or 40 other enhancements over the csh.
You can get it from tesla.ee.cornel.edu.
Adam
----------------------------------------------------------------------------
From: SMTP%"shandelm@jpmorgan.com" 25-JUN-1993 05:32:05.75
It's not really clear to me whay you are asking but I'll make a suggestion
anyway. I have a file called system_wide_login and system_wide_cshrc
which are called from each persons .login and .cshrc respectively.
In the .login file put the line:
source /pathname/system_wide_login
to have the default stuff set at login. cshrc would work the same way.
I hope this helps.
-- Joel
-----------------------------------------------------------------------------
From: SMTP%"plord@pioneer.uspto.gov" 25-JUN-1993 05:40:39.41
I don't think you can do this in csh. I have all of my users using tcsh
6.03 as their login shell, and tcsh has /etc/csh.login and /etc/csh.cshrc
for just the purpose you describe; I set up a few dozen aliases and
environment variables in these files for all users. The files in /etc are
read before the ones in the users home dir, so a given user could still
override the variable, but I don't have a problem with this.
tcsh 6.03 is available for anonymous FTP from all over; try world.std.com
Hope this helps.
Paul
---------------------------------------------------------------------------
From: SMTP%"poc@usb.ve" 25-JUN-1993 05:42:51.19
This may be overkill, but I recommend the "modules" package, available
by FTP from I-can't-remember-where-sorry (use archie). The user then
types things like "module add whizzo" to configure his environment to
use the "whizzo" subsystem. You can set up as many subsystems as you
like. We're very happy with it.
----------------------------------------------------------------------------
From: SMTP%"ajs6143@eerpf001.ca.boeing.com" 25-JUN-1993 06:09:41.93
We keep a common login file mounted from a fileserver. In every users
.login we source the common login file.
file USER/.login
source /usr2/bin/common/login
in this file we set common environment variables and paths that all users
get when they log in.
the mount is
lopez:/usr2/bin on /a/lopez/usr2/bin type nfs (rw)
-----------------------------------------------------------------------------
From: SMTP%"stevem@csdc02.orl.mmc.com" 25-JUN-1993 06:42:54.47
Yes, we use an appproach that works great, and its really quite simple.
Each starts with the same .login and .cshrc. He / She can later modify
them if need be, but they shouldn't for software packages or other commonly
used features or funtions.
They key to this strategy, is both .login and .cshrc source public ones;
Here are the beginnings of all my users .login and .cshrc files:
% more .login
# @(#)Login 1.4 88/03/03 SMI
##################################################################
#
# .login file
#
# Read in after the .cshrc file when you log in.
# Not read in for subsequent shells. For setting up
# terminal and global environment characteristics.
#
##################################################################
# environment variables
setenv SUNDESK '/usr/sundesk'
# *********** DO NOT CHANGE OR REMOVE ANY LINES BELOW THIS POINT **************
# Source the system default .login file
source /pub/local/lib/system_default/.login
<rest deleted ...>
% more .cshrc
###########################################################################
#
# .cshrc file
#
# initial setup file for both interactive and noninteractive
# C-Shells
#
###########################################################################
# Set up search path
set path = (. ~ ~/bin ~/scr /usr/local/bin /usr/ucb /usr/bin /usr/etc)
# ************* DO NOT REMOVE OR CHANGE THE FOLLOWING LINE *******************
source /pub/local/lib/system_default/.cshrc
<rest deleted ...>
Now, in the /pub/local/lib/system_default/.cshrc and .login files, they have
a series of if then else statements checking for flags (empty files) in the
user's home directory.
if ( -f ~/.USEOO1 ) then
set path = ($path ~oo1)
source /lic/oo1/oo1v2/hti_logicals
endif
Therefore, if a user wants to use 001 software, they simply need to
touch .USE001 in their home directoy. Then next time they login or resource,
they'll incorporate 001's environments variables, paths, and man pages in
the /pub/local/lib/system_default/.login file.
Difficult for me to describe, but piece of cake to implement!
Send me email for anyother questions or examples - glad to help!
_/_/_/ Stephen Miller
--------------------------------------------------------------------------------
From: SMTP%"chris@invmms.worldbank.org" 25-JUN-1993 06:50:01.76
Not in csh, but there is a very compatible variant called tcsh. It
supports the idea of a system login and system tcshrc. Tcsh is
completely backwards compatible except for two things. One is the
prompt. Tcsh doesn't handle the ! for history. The second is that
tcsh doesn't have the bind command. I love the command-line editing.
I have included the manual. It's free software that can be picked up
from most anonymous ftp-sites.
Chris
If anybody is interested in the manual, please send me mail and I will mail it
to you, the size of the manual is about 245 blocks.
-------------------------------------------------------------------------------
From: SMTP%"strombrg@hydra.acs.uci.edu" 25-JUN-1993 07:38:01.75
Early (and not all that early, up through 4.4) BSD csh's had no
facility for doing this conveniently. That is, there wasn't, and
isn't in SunOS, a facility for setting up some file that is sourced by
all csh's upon login and/or startup.
Most admin's have given users "standard" .cshrc's and .login's. Some
of the better approaches have involved minimal .cshrc's and .login's,
that do nothing but source a file in /etc or /usr/local/etc, with a
comment indicating that users can add their customizations, but
shouldn't remove the source'ing.
My preferred solution, is to forget about csh. My favorite shell is
bash, but I'd hate to re-educate everyone about something as tedious
as the differences between the two primary shell families. So what I
really like to do is (to use bash myself, and :) to provide everyone a
tcsh, will will source /etc/csh.login and /etc/csh.cshrc at the
appropriate times. Having the source, this could easily be changed to
source /usr/local/etc/csh.* instead, or in addition to, those more
standard files.
Just for completeness: as you may know, environment variables are
generally inherited from parent to child, as processes are spawned.
The environment doesn't -have- to be passed, but it requires special
arrangements to avoid it. So if you get your variables set "up high",
everything from that point down will generally have those same
variables.
Dan Stromberg - OAC/DCS strombrg@uci.edu
-------------------------------------------------------------------------------
From: SMTP%"bshaw@spdc.ti.com" 25-JUN-1993 08:14:34.87
Hi Aline
If you use tcsh, you can use the "builtin" /etc/csh.cshrc concept.
This works great!!!!
It simply sources this global file before the users login files.
Hope this helps
Bob
-------------------------------------------------------------------------------
From: SMTP%"gedetil@silver.cs.UManitoba.CA" 25-JUN-1993 08:45:12.62
The C shell in SunOS doesn't have any system-wide startup files that are
read before the user's .cshrc (& possibly .login) files. The trick we use
here is to have each user's .cshrc file start with the following:
# Pick up global setup:
if ( -r /usr/local/script/.cshrc.global ) then
source /usr/local/script/.cshrc.global # Do not remove.
endif
We also use a similar trick in the user's .login file. The global files can
then be set up to contain whatever initial setup we want, including setting
environment variables, options, and aliases, and running initial commands.
It's a pain to set this up in the first place (especially if you've got a
lot of users, with vastly different .cshrc and .login files), but it's very
useful to have this in place. We've found that very few users take the
above lines out of their files (this is usually done if they copy their
.cshrc or .login from another site), and it relieves the less experienced
users of the hassle of setting up their PATH, MANPATH, etc.
--
Gilbert E. Detillieux Internet: <gedetil@cs.umanitoba.ca>
Dept. of Computer Science or <Gilbert_Detillieux@umanitoba.ca>
University of Manitoba Phone: (204)474-8161 (or Intercom 32)
Winnipeg, MB, CANADA R3T 2N2 Fax: (204)269-9178
"The earth is like a tiny grain of sand, only much, much heavier."
------------------------------------------------------------------------------
From: SMTP%"adiron!tro@uunet.UU.NET" 25-JUN-1993 09:02:22.17
If you mean an environment variable, you can set it in /etc/rc.local
so that the init process has it. All subsequent processes will then
inherit it. However, be sure to get it right or everybody will be
screwed up.
If you mean a csh variable, no. csh variables are not inherited.
However, you can have a system.cshrc file somewhere and have everybody
source it in their .cshrc files. You can use the same file (or a
different one) to set environment variables. Of course, this approach
gives users the ability to easily opt out if they so choose.
Note that csh imports its $path variable from the environment's $PATH
variable, and exports $path to $PATH when it's set, so the two are
essentially the same variable.
Tom Olin (tro@partech.com)
--------------------------------------------------------------------------------
From: SMTP%"valdes@geosun.uchicago.edu" 25-JUN-1993 09:42:32.72
Unfortunately, under SunOS 4.X this is no builtin mechanism for doing this.
What I do whenever I add a user to the system is to create a .login in
his home dir that begins with:
######################################################
# #
# This is your .login file. It executed whenever #
# you log in, after your .cshrc file. Add to this #
# file any commands which you want executed only #
# when you log in. #
######################################################
#
# The following line sets up system defaults,
# such as default command and manaul page paths,
# terminal characteristics, etc.
#
# DO NOT DELETE THIS LINE!!
#
source /usr/local/lib/system.login
#
# Make your additions below. Please note when adding
# directories to search paths, include the old path,
# using the format: set path = ($path /new/directory)
#
Of course, he is free to delete the line that source's in the
system wide login file, but then things usually break and it gets
added again. You can set your variable (or whatever) in
the file that gets source'd.
Under SunOS 5.x, csh will source the contents of /etc/.login
whenever a user logs in. You can make your settings in this file.
Similarly, sh and ksh (Bourne and Korn shell) read in the contents
of /etc/profile on login.
John Valdes
valdes@geosun.uchicago.edu
-------------------------------------------------------------------------------
From: SMTP%"ups!uniq.com.au!kevin@warrane.connect.com.au" 25-JUN-1993 20:19:10.71
In bash, ksh, and some sh implementations, /etc/profile is used for this.
I think the csh is still out on that one.
l & h,
kev
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:59 CDT