On Thu, Apr 27, 2006 at 12:53:01PM +0200, cobaco (aka Bart Cornelis) wrote: > On Sunday 23 April 2006 20:26, Russ Allbery wrote: > > Jari Aalto <[EMAIL PROTECTED]> writes: > > > > What we need and what should have been done a long time ago, is to > > > modularize profile to /etc/profile.d/ where each program is resposible > > > for shipping reasonable defaults. Redhad has done this long time and > > > Cygwin does that too and it works very well.
I suggest the post below that detail how they use it and why this is not needed in Debian: <http://lists.debian.org/debian-policy/2004/06/msg00136.html> > > > This way all the other issues concerning configuration would be nicely > > > modularized. There would certainly be several packages that would > > > benefit from /etc/profile.d/ > > > > Please do not make the assumption that every shell reads /etc/profile or > > would read /etc/profile.d. > > here's the current situation for Debian shells regarding a modularized on > login-script: > - fish, psh, zoidberg: each have their own modularized on-login script > - tcsh and csh: share the on-login script, not currently modularized but see > bug #351652 which is marked pending > - zsh: not currently modularized, but see bug #351663 > - bourne compatible shells ((bash, dash, ksh, pdksh, mksh ) are all > using /etc/profile which is currently non-modularized and owned by > base-files. > Modularization has been requested repeatedly, see bugs #345921, #345921, > #285105, #283089, #170639, #163743, #129892, #114642, and now the bug > we're discussing. > As far as I can tell (note the qualifier, merely my impression) the > base-files maintainer is regarding any addition to /etc/profile as bloat, > and is opposed to modularizing the script. > > -> that's 3 out of 6 on-login files modularized, one that will be > modularized, one rejection of modularization, and 1 that's undecided > -> none of the currently modularized on-login files have raised any problems > as far as I'm aware, even though each of them has been there for at least > a couple of months now. > > > Policy does not make that assumption; that's > > one of the major benefits of the approach currently in Policy. > > Policy (in section 9.9) says: > > A program must not depend on environment variables to get reasonable > defaults. > > (are there any other relevant sections, if so which?) > > > If there are problems internal only to the ksh/bash family of shells that > > would be solved by /etc/profile.d, it may still be a good idea to create > > /etc/profile.d for their internal use, In that case, I would suggest to introduce a /etc/bashrc.d and /etc/kshrc.d rather than a /etc/profile.d. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]