Calling all regressions

[Jorey Bump]

Bron Gondwana wrote, at 03/12/2009 07:42 AM:
> On Thu, Mar 12, 2009 at 02:55:03AM -0700, Carson Gaspar wrote:
>> Bron Gondwana wrote:
>>
>>> AAA+++ to cyr_conf!  I'll write it up :)  I think we want it to have the
>>> following spec:
>>>
>>> * cyr_conf  - output all configuration variables and their current value
>>> * cyr_conf -C $file - as above with the following config file
>>> * cyr_conf -n $name - all configuration variables for process $name
>>>               (eg cyr_conf -n imapd => show imapd overrides where given)
>>> * cyr_conf -q - only show variables that are different than default
>>>
>>>   - those three can be mixed and matched
>>>
>>> * cyr_conf -D - show all the DEFAULT variables.  Obviously, ignores all
>>>                 other options!
>> Please include one of the most useful options that postconf has 
>> (postconf -n) - emit only those config key/value pairs that are not set 
>> to their default values. More often useful in real life than just 
>> emitting all config key/value pairs.
> 
> Yeah, I called that -q.  If we make it -n then we'll have to make the
> named process config a different character.  The spec isn't nailed down
> yet, I haven't even written anything!

Actually, postconf -n shows parameters that have been explicitly set,
even if they are the same as the default. This is a subtle (and IMHO
very useful) distinction.

Although many simply grep the output of postconf because they can't
remember the exact name of a parameter, another very useful feature of
postconf is the ability to directly query the value of one or more
parameters using postconf [parameter...]:

  postconf mynetworks

or:

  postconf mynetworks inet_interfaces

I realize that a variety of MTAs are used in conjunction with Cyrus
IMAPd, but Postfix is an extremely well thought-out application. As a
Postfix administrator, I'd be thrilled to see a utility like cyr_conf
modeled as closely after postconf as possible, if only to simplify any
new tricks this old dog has to learn.