[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: profile.d [was Re: UMASK 002 or 022?]



On Thu, Jun 08, 2000 at 11:50:39AM +0300, Sami Haahtinen wrote:
> 
> this would ease the job of an maintainer, and help the newcomers. how
> many times have you missed the alias
> ls -> ls --color=auto -F 
> i have.. many times.. i like it.. it gives me an clear view about the
> system..

how many times have you come up to a redhat system for which the
environment is totally screwed up and you cannot make head or tail of
how the hell it gets that way, i have on every redhat system i have
the misfortune of having to deal with.  i would much rather just edit
the damn things separatly then deal with more redhat convoluted
`helpfullness' 

> on every system i set up i have to manually add that line, and few
> others to every single profile file (i use bash), but with this.. the
> package maintainer would just add it to lets say /etc/profile.d and all
> profile files would be created from the info in there.. all environments
> would be the same, no matter if it was tcsh ksh or bash (or whatever)
> if they support aliases i would get my So-Much-Wanted-And-Needed[tm]
> alias for ls..

i am of the opinion that stuff like alaises and other fancy
non-standardisms should not go into the global profiles at all, they
belong in ~/.fooshellrc and ~/.fooshell_profile.  you want that stuff
by default put it in /etc/skel/*  

some people afterall find colorized ls evil (namely all the BSD
people).

the only things i can think of that should be set on a systemwide
basis are the following:

PATH
MANPATH 
umask

that is about it.  everything else is user preference and does not
belong in system wide uneditable (by user) files.  it belongs in
/etc/skel/* which are copied to the users $HOME when they are
created.  at that point the user may change things as they please, and
more importantly they can see very clearly where the hell there
screwed up environment came from and can fix it easily.

on every system i have used that attempts to set too much user
specific environment stuff from the /etc/profiles i have had ended up
writing a ~/.profile to simply throw away the entire environment and
rewrite it myself.  annoying. 

> yes.. it is just a few config files, would you prefer to edit modules.conf
> or the modutils files, the files in /etc/modutils give you clear view
> where we are, and what is happening.. for me there are files for alsa,
> which holds all the configuration options for alsa, and one for wd (nic)
> and so on.. if i need to change the io of my nic, i just go there and
> edit the one file which i can figure out with one glance, the same thing
> in /etc/modules.conf woould first make me search for the right line,
> then if the options and aliases are scattered, i need to look for both
> of them separately..

you are mixing to very different things:

hardware settings and user settings

everything in /etc/profile except PATH and MANPATH is a user
PREFERENCE, it does not belong in /etc it belongs in $HOME, where they
can change it.  only a very minimal environment necessary for the
account to work properly should be defined in /etc/profile (or
csh.cshrc etc).  that brings the number of variables down so far that
kludges to unify the config files are plain silly.

> i think you can see my point. even if i don't like all of those
> *.d directories in /etc i still think they make things easier and
> clearer.. pam.d for example helps a LOT. although i don't think we should
> jump into any action before thinking this through with this one.

no it does not, all it does it make it a pain in the ass for the user
to customize thier environment cleanly, and to understand how the hell
it was setup in the first place.  i STILL cannot figure out how the
hell sbin is getting in my PATH on a couple redhat boxes i have
accounts on.  i don't want it there and the only way to get rid of it
is to throw away the PATH variable altogether and write my own.  which
is lame given if the admin adds a new entry to the global PATH that is
useful to me i won't get it automatically as i will with the
following:

PATH=${PATH}:$HOME/bin

granted if PATH is set bogus in /etc/profile im screwed anyway, but
s/PATH/whateveruserpref/ and you get my point.

as far as dealing with changing a variable like say PATH in one file
why not juse use pam_env or /etc/environment?  won't work for aliases
but like i said aliases don't belong in the system wide config files.

> > and IMNSHO config files in XML is an evil idea.
> 
> yes, i have to agree with this..

there are plenty of much nicer config file formats that are computer
editable too, emacs lisp is not bad and {x}emacs does not seem to have
problems editing it even when i mess with it.  WindowMaker/Libproplist
is not bad either. 

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

Attachment: pgp_vgRr_Xxh2.pgp
Description: PGP signature


Reply to: