Geoffrey Young wrote:

Stas Bekman wrote:

Geoff, why did you make APACHE_TEST_NO_STICKY_PREFERENCES prevent from
saving autoconfig?


however it's done, I want an option wereby absolutely nothing sticky is ever
generated or used.  the "don't touch my system" option was my goal, which
really isn't unreasonable.


Granted, instead of using APACHE_TEST_NO_STICKY_PREFERENCES one could go
and delete the custom config files, but one needs to find them first and
it's error prone for testing. I'd like to see
APACHE_TEST_NO_STICKY_PREFERENCES do its job w/o getting on the way of
things that we need to test.


so you're arguing that we should write out the sticky files, even if the
user doesn't ever want them interfering?

I'm not arguing at all. It's just when APACHE_TEST_NO_STICKY_PREFERENCES=1 and no arguments passed, the logic is broken. The program gets into a loop it can't break out of. I've suggested a fix, if you don't like it, please suggest a different one. For example do not run interactive config if APACHE_TEST_NO_STICKY_PREFERENCES=1. But it's a pity, since we could suggest users this technique to override older saved config (in addition to -save). May be we need a more granular approach and have two variables, one for NO_READ and another NO_WRITE, e.g.:


APACHE_TEST_CUSTOM_CONFIG=0 # read/write (00)
APACHE_TEST_CUSTOM_CONFIG=1 # no read    (01)
APACHE_TEST_CUSTOM_CONFIG=2 # no write   (10)
APACHE_TEST_CUSTOM_CONFIG=3 # no read and no write (01 | 10)

or anything else you'd like, preferrably with less typing then the current variable. if you prefer words, may be:

APACHE_TEST_CUSTOM_CONFIG=0
APACHE_TEST_CUSTOM_CONFIG=NO_READ
APACHE_TEST_CUSTOM_CONFIG=NO_WRITE
APACHE_TEST_CUSTOM_CONFIG=NO_RDWR

In case of 'no_write' (interactive config should disabled to fix the logic).

--
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Reply via email to