Re: Should we implement a /etc/profile.d?
On Thu, 1 May 1997, Lars Wirzenius wrote:
> > I think we should just use the ". /etc/profile.d/*" approach.
> If that is used at all, then it should be some implementation of
> ". /etc/profile.d/*.<syntax>", just like Red Hat does (as we were
> told). Also, there _must_ be a way for each user to allow them or
But every maintainer would need to know other shells. I only know sh like
And... we could have a ~/.nodefprofile (?) so we:
test -f ~/.nodefprofile && ...... (. profile.d/*)
> But before we continue the discussion, perhaps someone could list
> examples of what this would be used for, so that we can see if it
> really would be useful. Otherwise this is just wishful thinking.
It would be used to set default settings for naive users. But, as I've
said, it should only be used by very standard utilities.
e. g.: fileutils would set color settings for ls, less would set
I think this is ideal for these because: user can easily change their
settings, sysadmin can easily configure defaults, packages can easily
change defaults and the conffiles handling takes care of local
> > If somebody uses a shell that doesn't allow environment variable
> > declaration in a standard/posic way... then that user is probably
> > somebody that can live without this feature.
> Er, I don't think that is a good idea.
So.. what should we do? Again: All this is for naive users... (it's
important to look nice to them to =) ).
> > and probably the other flavours I don't know much about... csh? ksh?
> csh and tcsh do not understand Bourne shell syntax. ksh does. Of
> course, there's minor deviations between all shells based on
> the Bourne shell, meaning that, for example, a hypothetical
> /etc/profile.d/fancy-bash-prompt would need a ".bash" as the
> extension, so that only Bash would use it.
I'd say that all sh-like shells should be grouped.. and we should require
only basic sh syntax...
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to email@example.com .