Re: Login Shell/Profile: Stop the Madness
On Thu, 17 Jun 2004, Michael B Allen wrote:
> > Although, I hope you never do this on a machine you sysadmin where you
> > have other people using it.
> >
> > I have to contend with a stupid SuSE system at work where the
> > /etc/profile* scripts are so absolutely full of cruft
>
> Well we're not talking about SuSE. Debian /etc/profile set's PATH and PS1
> and that's it.
What I am saying, is if you make Debian go down the SuSE path, there will
be pissed off people. But at lesat Debian doesn't unconditionally
overwrite config files, so it won't be all bad.
> > (and cruft that
> > actually sets undesirable behaviour in some thing - I think the LESS
> > environment variable was set to something about 80 columns long) that
> > they take quite some time to execute. Not only that, they don't care
> > about overriding variables that are already set -- I start up my
> > xterms with bash as a login shell
>
> Then it's ironic that you complain about inefficencies in /etc/profile
> because starting all of your xterm's as login shells will source the
> /etc/profile and ~/.bash_profile every single time whereas doing it once
Yes, but as a non-priveleged user, I am capable of modifying my startup
scripts to not reset certain variables if a certain environment variable
is already set. I can't do that when /etc/profile unconditionally
overwrites *everything*.
> when you actually *login* will allow all shells to simply inherit what was
> already set.
>
>
> > The correct place to put in all of this cruft that not everybody will
> > want is in the skeleton directory, so they can remove or edit the
> > files once they are installed in their home direcory. I tried to
> > suggest this to SuSE, but alas my bugreport of course went completely
> > unnoticed.
>
> And with good reason. A good sysadmin doesn't force the responsibility of
> administering the system to the users. Anything like JAVA_HOME,
> http_proxy, etc belongs in /etc/profile or on SuSE /etc/profile.local.
A good sysadmin knows what /etc/skel is for. If they make a change to a
locally installed variable, the user's startup scripts can source a
*small* file somewhere in /etc/ -- eg /etc/bash.localrc. (or simply, as in
my undergrad days, symlink each users file to /etc/skel/..., and if the
user wants to change those files, it then becomes their responsibility if
any infrastructure changes require changes of environment variables.
People who leave things alone get changes automatically)
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
Heisenberg may have been here.
Reply to: