Re: /etc/profile.d ?
> psu25682@odin.cc.pdx.edu (Karl M. Hegbloom):
> > What if we had an /etc/profile.d (not invented here) where packages
> > (like postgresql) could drop a startup file for /etc/profile to source
> > in a for f in /etc/profile.d/* loop?
> >
> > Pros and cons?
>
> - It's shell specific. Similar stuff would be needed for other shells.
>
> - If the package needs it, it's buggy and should be fixed. (The correct
> way in that case is to make it a script wrapper aound the actual
> program, not assume things are done in /etc/profile.)
>
> - If the package doesn't need it, it's unnecessary clutter that will
> fill up my root partition and slow up my logins needlessly. As sysadmin,
> I don't want to have to clean up stuff like that after every upgrade.
>
> - If it is meant just as an example, put it in /usr/doc/*/examples.
>
> In summary, I still (as on some earlier occasions when this has been
> suggested) that the idea is not worth it.
I have already a debian package doing this. It works fine for me. I have
an /etc/profile.d with specific subdirs for bash and csh shells and a
common directory for scripts which are not shell-specific.
I use it to setup a common shell environment and shell aliases which the
user is free to modify or delete if he wants to.
Pros:
it could be used by any package to add arbitrary login action,
for example to set environment variables or to run programs.
Currently there are packages which modify directly /etc/profile,
which is bad in my opinion. One of them is for example sendfile.
With the profile.d solution a package could just drop a file in
this directory and delete it when deinstalled. Simple and clean.
it could be used by system administrators to setup site-specific
policies about environment variables and login startup. Note
that these could still be overriden by user's .bash_profile, so
they are not guaranteed, but this could grealy simplify things
to sysadmins.
it can be done for each shell. I have only code for bash and csh
but it is easily expandable to other shells.
Cons:
it could add a small delay at login time and messages or actions
not wanted by the user, but the final responsability of these is
left to the sysadmin, which could do it anyway by modifying
directly /etc/profile. We should simply provide an empty framework
to doing things in an easier way.
With three pros, one con and a working package I vote for your proposal.
If someone is interested I can upload the package to my web site.
--
Massimo Dal Zotto
+----------------------------------------------------------------------+
| Massimo Dal Zotto email: dz@cs.unitn.it |
| Via Marconi, 141 phone: ++39-0461534251 |
| 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ |
| Italy pgp: finger dz@tango.cs.unitn.it |
+----------------------------------------------------------------------+
Reply to: