Christopher Browne <[EMAIL PROTECTED]> writes:
> Counterpoint:
>
> What if GnuCash is being deployed as an RPM or .deb package? In that
> case, the user is not building the package for a "given machine."
Yes, but Debian (or RedHat), should *already know* where they've
decided the system config dir is, and built the app to look there when
invoked without any special options.
> If we leave the options open, this is supportive even of users that
> set up fairly peculiar system configurations.
>
> It is supportive of responding to questions via: "OK. We can solve
> your problem by adding the following line to your .bashrc file."
>
> I'm not feeling dogmatic about it, though.
Well, I'm in favor of allowing the user to change the config-dir
settings from the command line or from their startup file (though
there's a little bit of a chicken and egg problem here), and in fact I
went through some gymnastics to try to keep as little as possible
about the startup process hard-coded, but what I'm a little
uncomfortable with is the idea of searching by default in a *bunch* of
locations until you find something that *might* be the right thing.
Having a broad default runtime startup search path seems potentially
confusing and/or dangerous. As a case in point, I'd argue against
putting any search for "./.gnucash/*" in the default setup for the
same reasons that putting "." in your shell path is a potentially
fairly dangerous thing to do. If the user wants to add "./.gnucash"
to their gnucash startup search path, then that's fine, but since
gnucash startup files can execute arbitrary code, including "rm -rf
~", I don't think it's wise to open up the search space too widely as
the norm.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
