On 08 Feb 2000 13:06:05 CST, the world broke into rejoicing as
Rob Browning <[EMAIL PROTECTED]> said:
> Christopher Browne <[EMAIL PROTECTED]> writes:
>
> > I don't think it'll be too difficult to ask/answer the questions
> > relevant to making sure we know which ordering is most appropriate.
> >
> > In either case, we can have a reasonably logical way of either:
> > a) Sequencing which set of configuration to load in next, such as
> > /etc/gnucash.conf, /usr/local/etc/gnucash.conf,
> > $HOME/.gnucash/gnucash.conf, ./.gnucash/gnucash.conf
> > or
> >
> > b) Setting up a list like the above, and traversing it in reverse
> > order, stopping as soon as a config file is found.
>
> I had planned for us to have a setup like (a) rather than (b). I
> wanted the process to be (assuming /etc/ for
> sysconfigdir):
>
> (1) load "/etc/gnucash/config"
>
> (2) load-if-exists ~/.gnucash/config.user
> else load-if-exists ~/.gnucash/config.auto
>
> So the system config file is *always* loaded, and then the user's
> hand-wrought config file (like a .emacs) is loaded if it exists. If
> it doesn't exist, then the automatically generated config file is
> loaded, if it exists. This is how things were working last time I
> looked, and it's what I intended and documented in startup-design.txt.
>
> The reason to handle (2) in the way indicated is that this allows the
> user who decided to create their own config file to have control over
> where (if at all) the automatically generated stuff gets loaded. By
> default, most users should put a (gnc:load-auto-config) into their
> config.user, if they create a config.user.
I have no problem with the above; if the plan is to have some
hard-coded path information in the binary, I would *suggest* having
gnucash query a suitable environment variable as a possible override
to this.
Thus, if the default is to first look in /etc/gnucash/config, then
look for ~/.gnucash/config.auto, then ~/.gnucash/config.user, then
we'd set these values into an array.
Then, 'twould be nice to allow this to be overridden by a
colon-delimited list in GNC_CONFIG, where the equivalent would be:
export GNC_CONFIG=/etc/gnucash/config:~/.gnucash/config.auto:~/.gnucash/config.user
That gives us The Best of Both Worlds. Suitable defaults compiled in,
and the ability to override them from the command line if needed.
The one bit of strangeness to this, to my mind, is the notion that
multiple configuration sets would be simultaneously loaded. It seems
more sensible to me to go in the opposite order, and *not* layer
- If there's a ~/.gnucash/config.user, that's best.
- If there's not, then fall back to ~/.gnucash/config.auto, which an
intelligent distribution might set up.
- If there's not that, then fall back to /etc/gnucash/config
I'm not sure what is "won" by implicitly loading them all when I know
it's easy enough to explicitly load whatever is wanted via (gnc:load).
--
"I worry that the person who thought up Muzak may be thinking up
something else." -- Lily Tomlin
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/lsf.html>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
