global .login/.cshrc without modify the user copy

global .login/.cshrc without modify the user copy

Post by lili.. » Thu, 29 Sep 1994 22:17:31



It's quite a long time we are running SUNOS 4.1.3 and we still didn't find a way
to set a master .login file that will be executed at login time before user's
login file. Or other way of exporting environment to users globaly to support
variety of applications.

regards

    \||/
   ( .. )
 ___)  (___
(___    ___)
    )  (
   /    \
 _/  /\  \_
(___/  \___)

--
NAME Liliana  Windver

VOICE:+972-4-646724/31

 
 
 

global .login/.cshrc without modify the user copy

Post by System Admin (Mike Peters » Fri, 30 Sep 1994 02:09:22



>It's quite a long time we are running SUNOS 4.1.3 and we still didn't find a way
>to set a master .login file that will be executed at login time before user's
>login file. Or other way of exporting environment to users globaly to support
>variety of applications.

What we do is give the user .cshrc and .login files that look like:

#
# .cshrc file - run for every C shell started.
# Version: 1992/11/24.
#
# Do the /usr/local/Master.cshrc file stuff first.
# Look there first to see what is being set automatically
# before making lots of additions here.
#
source /usr/local/Master.cshrc
#
# Optional (user-selectable) parameters - remove the '#' to activate.
#
#set noclobber          # activate to avoid overwriting files
#alias rm rm -i         # activate to confirm each file deletion
#setenv LIBDIR ~/lib    # set user-supplied library directory

#
# .login file - run for every C shell interactive login.
# Version: 1992/05/09.
#
# Do the /usr/local/Master.login file stuff first.
# Look there first to see what is being set automatically
# before making lots of additions here.
#
# Set terminal type - the user may insert their favorite terminal type
# on the line after 'set favterm ='.
#
set favterm = vt100
source /usr/local/Master.login
unset favterm
#
# Optional (user-selectable) parameters and commands.
#
uptime

so I can modify /usr/local/Master.* as necessary, and never touch
the user's files. If the user chooses not to call my Master.*
scripts, then they are on their own, and I will not try very hard
to resolve problems with their environment.

I know this does not satisfy your request to not modify the user's
files, but once it is done, you won't need to do it again.
--
When the chips are down, switch to pretzels.       |  Mike Peterson, SysAdmin
                                                   |  U/Toronto Chemistry


 
 
 

global .login/.cshrc without modify the user copy

Post by Michael Callag » Fri, 30 Sep 1994 04:35:48



> :
> : It's quite a long time we are running SUNOS 4.1.3 and we still didn't find a way
> : to set a master .login file that will be executed at login time before user's
> : login file. Or other way of exporting environment to users globaly to support
> : variety of applications.
> :
> :
> : regards
> :
> :     \||/
> :    ( .. )
> :  ___)  (___
> : (___    ___)
> :     )  (
> :    /    \
> :  _/  /\  \_
> : (___/  \___)
> :
> : --
> : NAME Liliana  Windver

> : VOICE:+972-4-646724/31
> Liliana,

Why do you not modify the installation .login that is placed in each users
account at creation time such that it contains a call to the master
login (ie source /somepath/.login).  Additionally, you will have to prepend
to each existing users .login file the same line.  We do something similar
here to setup our global environment for everyone.

Hope that helps.

--------------------------------------------------------------------------
    Michael Callagan     Programmer Analyst            \ VISUALIZE /
    ADP Dealer Services  Opus - APC                     \ WHIRLED /
    Portland, Oregon     (503) 294-4200 x2124            \ PEAS  /

--------------------------------------------------------------------------

 
 
 

global .login/.cshrc without modify the user copy

Post by Nick Hillia » Fri, 30 Sep 1994 03:56:18


: It's quite a long time we are running SUNOS 4.1.3 and we still didn't find a way
: to set a master .login file that will be executed at login time before user's
: login file. Or other way of exporting environment to users globaly to support
: variety of applications.

/etc/csh.login is what you need.

Nick
--
Thought for the day:
"Don't worry about people stealing your ideas.  If your ideas are any
good, you'll have to ram them down people's throats."
                -- Howard Aiken

 
 
 

global .login/.cshrc without modify the user copy

Post by Tobin Matthew Cre » Sat, 01 Oct 1994 04:46:53




>: It's quite a long time we are running SUNOS 4.1.3 and we still didn't find a way
>: to set a master .login file that will be executed at login time before user's
>: login file. Or other way of exporting environment to users globaly to support
>: variety of applications.
>/etc/csh.login is what you need.

Note that this only works if the shell is a login shell.  The default for
xterm is not to use a login shell.  The /etc/csh.login will not get read
on these, only a .login in the user's directory.
 
 
 

global .login/.cshrc without modify the user copy

Post by Mike O'Conno » Sat, 01 Oct 1994 11:06:29



:It's quite a long time we are running SUNOS 4.1.3 and we still didn't find a way
:to set a master .login file that will be executed at login time before user's
:login file. Or other way of exporting environment to users globaly to support
:variety of applications.

Have your users use tcsh instead of csh as their shell, to provide
this functionality.  You can preserve the .cshrc and .login inits
of your users in this fashion.

                                                ...Mike

--

 http://www.msen.com/~mjo/

"What kind of world is this?!  You only get five years to be a kid??"  -Calvin

 
 
 

global .login/.cshrc without modify the user copy

Post by Maarten Litmaa » Sat, 01 Oct 1994 11:29:56






>>It's quite a long time we are running SUNOS 4.1.3 and we still didn't find a
>>way
>>to set a master .login file that will be executed at login time before user's
>>login file. Or other way of exporting environment to users globaly to support
>>variety of applications.

>What we do is give the user .cshrc and .login files that look like:

>#
># .cshrc file - run for every C shell started.
># Version: 1992/11/24.
>#
># Do the /usr/local/Master.cshrc file stuff first.
># Look there first to see what is being set automatically
># before making lots of additions here.
>#
>source /usr/local/Master.cshrc
>[...]
>so I can modify /usr/local/Master.* as necessary, and never touch
>the user's files. If the user chooses not to call my Master.*
>scripts, then they are on their own, and I will not try very hard
>to resolve problems with their environment.

In environments in which I have worked before, the sysadmins really
pissed me off by defining all kinds of "neat" aliases, stty settings
etc. in such master files...

But here are the real problems:

        1. You have to make a "Master" file for _each_ different
           shell: csh, sh, ...

           At one point you will forget to update one of them.

        2. The user can easily*up, by deleting the "source"
           line in his .cshrc.

The "Startup Package", recently posted to comp.sources.unix, solves
these issues, portably.  From the documentation:

        Advantages of using the Startup Package:
        ----------------------------------------

                - the user's ".login"/".profile" need not be prepared to
                  consult system-wide initialization files

                - there is only 1 system-wide startup file, independent of
                  the user's actual shell

                - the package works with "login", "rsh" and "su"

                - it does not require system sources

                - it offers flexibility for the system administrator to:

                        - set environment variables
                        - print a message of the day
                        - run programs
                        - control access/nice/limits/...

                - it allows for host- and group-dependent initialization

Of course the original problem lies with the inflexibility of the
"login" program...

 
 
 

global .login/.cshrc without modify the user copy

Post by System Admin (Mike Peters » Sun, 02 Oct 1994 03:36:17



>In environments in which I have worked before, the sysadmins really
>pissed me off by defining all kinds of "neat" aliases, stty settings
>etc. in such master files...

Most users never know about aliases, or which commands are in fact
aliases to repair vendor brain damage. The "neat" aliases very
occasionally trip new users, but stty settings are usually required
to make keyboards behave in a reasonable and consistent way across
all platforms.

Quote:>But here are the real problems:

>    1. You have to make a "Master" file for _each_ different
>       shell: csh, sh, ...

>       At one point you will forget to update one of them.

Not yet, but it will happen. I also have separate Master.* files
for each vendor, but next time, I'll merge the new vendor with the
existing HP-UX ones. This should get easier as the world COSE's up.

Quote:>    2. The user can easily*up, by deleting the "source"
>       line in his .cshrc.

Over 95% of our users don't even know they have the files, or
that 'ls' has a "-A" option (or that 'ls' will show them their files
in many cases :-( ).
--
Computer system adminstrator:                      |  Mike Peterson, SysAdmin
   a fire chief doing a fireman's job.             |  U/Toronto Chemistry

 
 
 

global .login/.cshrc without modify the user copy

Post by Maarten Litmaa » Sun, 02 Oct 1994 06:52:36






>>In environments in which I have worked before, the sysadmins really
>>pissed me off by defining all kinds of "neat" aliases, stty settings
>>etc. in such master files...

>Most users never know about aliases, or which commands are in fact
>aliases to repair vendor brain damage. The "neat" aliases very
>occasionally trip new users, but stty settings are usually required
>to make keyboards behave in a reasonable and consistent way across
>all platforms.

In my case it was exactly the opposite: the aliases etc. were exactly
for the new (inexperienced) users; it is not funny for the experienced
user to discover one day that e.g. "rm" has suddenly become an alias
for "rm -i".  Of course one could make the first statement of the
private part of one's .cshrc "unalias *", but you get the picture...

Quote:>>        2. The user can easily*up, by deleting the "source"
>>           line in his .cshrc.

>Over 95% of our users don't even know they have the files, or
>that 'ls' has a "-A" option (or that 'ls' will show them their files
>in many cases :-( ).

In our case it is again different: our users _think_ they know how
things work, so one user will show another how he made these neat
modifications in his .login, and the end of the story is that both
of them complain that some tool suddenly behaves strange, and it is
for the sysadmin to figure out why.  Of course with the incomplete
scheme of the Startup Package a user can still*up, but having
a shell-independent automatic global login script for free, is already
something.
 
 
 

global .login/.cshrc without modify the user copy

Post by Mike O'Conno » Tue, 04 Oct 1994 06:32:19



:But here are the real problems:
:
:       1. You have to make a "Master" file for _each_ different
:          shell: csh, sh, ...
:
:          At one point you will forget to update one of them.

There usually isn't a requirement to support multiple shells at
that level.  If I say that I support tcsh and someone wants to
run bash, I may be able to say "Have fun, you're on your own.".

:       2. The user can easily*up, by deleting the "source"
:          line in his .cshrc.

With shells that automagically sour "master" files that may reside in
/etc or some system place, I've made sure those master files test for
the existence of a .hushinits file, so that if someone wants to
implement their own set of login inits for a shell, they can do so.

                                                ...Mike

--

 http://www.veryComputer.com/~mjo/

"The living dead don't NEED to solve word problems."  -Calvin

 
 
 

global .login/.cshrc without modify the user copy

Post by Jeff Blai » Tue, 04 Oct 1994 07:55:02


I highly recommend you look into Soft 1.1, from Northeastern University
done by Remy Evard and Robert Leslie.  A paper was recently presented at
LISA VIII in San Deigo on it.  It's very easy to setup.  I think you'll
find it may be what you want.

--

Jeff Blaine         le0 ni0 et0 en0 ie0 lan0 de0 ec0 ex0 il0 ix0 enet0 ae0 eth0
CIESIN Operations   Standardize UNIX

 
 
 

1. global cshrc/login file?

On a Sun4, SunOS 4.1.3:
I'm changing the way mail will be delivered to users.  Instead of
going into the usual spool directory, I'm getting Procmail to deliver
it into the ~/.mail for each user.
However, I need a way to get mail, pine, mh, etc to look at the
$HOME/.mail file instead of /usr/spool/mail/$USER.  
Pine, MH can be modified globally, however, I want to have the MAIL
environment variable set for each user.  How do I do this for users
with csh?  
Replies emailed directly to me are appreciated.  I will post a summary
of useful responses.
Thanks,
-sahir
--
Sahir N. Siddiqui         Res: (201) 217-0952
PO Box 5176, Hoboken NJ 07030                       ))))
                                                   oo-)

2. INSTALL HELP !!!

3. Wups, forgot something -- Re: [Q] global .login/.cshrc

4. Wow...Windows actually did something right for a change!

5. Login without sourcing .cshrc?

6. RPC port & X11 Ports

7. Update every user's .login and .cshrc

8. Adaptec & Power-Saving

9. efficient copy to user and copy from user routines in Linux

10. global cshrc files ?

11. How to terminate a global cshrc-file