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

Re: .bash_profile, the empty /etc/skel, and the first user

On Tue, 17 Dec 1996, Lars Wirzenius wrote:

> Ah, yes. IMHO, in case I've left anyone confused, is that
> this is a good reason for not putting anything into /etc/skel,
> unless there are really heavy arguments for it. It's better
> to find other solutions to the problems, especially by adding
> global configuration file support to programs.

Are you saying that programs should _always_ consult a global
config file?  Isn't it more common for a program to only consult
a global config file in the absence of a local config file?  I
realize that Xresources work differently (perhaps this is the
behavior your suggesting we implement across the board?), but
most apps I've seen don't.

In order fot this kind of setup to work, we would need to set an
explicit order of consultation.  For example, the Global config
could get read first, followed by perhaps a site config, and
finally a local config (and maybe an end user's config in
addition).  The LAST instance of a config paramter would then be
the active one.  Alternaltively we could do it in reverse order,
keeping the first instance of a config parameter.  

Does the FHS address this complexity at all?  The best (most
flexable) software I've used is from TibCO and they have a three
point hierarchy: rel - (global options set here), int -
(international options that differ from the global config go
here), site - (options local to a particular site that differ
from int and rel go here), and ~user/somedir for configs local to
a user (only stuff that differs from the previous three points
need to go here).  These directories get traversed in reverse
order though (~user/somedir, site, int, rel) and the first
instance ordering is enforced.  I think I prefer it the other
way though.

We could (while we're defining this stuff) use something
similar.  Perhaps global/, national/, local/, ~user/? read in
that order keeping the last instance?  I missed the begginning of
the iscussion, so maybe I've drifted off topic?  Maybe I didn't
but this is overkill?

No excuses, its early here and I overslept this morning :-)

Richard G. Roberto
011-81-3-3437-7967 - Tokyo, Japan

Attachment: pgpzbeg8saYFT.pgp
Description: PGP signature

Reply to: