Re: Bug#364319: base-files: PS1 setting for *ksh (PROPOSAL: /etc/profile.d/)
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 <firstname.lastname@example.org> 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:
> > > 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
> - 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
> 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
> (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.
Imagine a large red swirl here.