Comment 7 for bug 518517

On Jan 22, 2013, at 05:25 PM, David Soto wrote:

>I would like to work on this. I was wondering whether it would be a good
>approach to return the results as I'll explain below and to pass the
>section and key names to the command by the use of options:
>
>/bin/mailconf -s section -k key
>
>Both options would be optional. If you don't specify a key you would get a
>list of all the keys and their values of a given section and, if you don't
>specify a section, you would get a list of all the keys and values matching
>the given key name. If both options are provided, it would just print the
>value and if only one of the two is provided, it would return the "full path"
>of the keys, as suggested by Barry
>(http://mail.python.org/pipermail/mailman-developers/2012-February/021725.html).
>
>Some examples of usage:
>
>>> /bin/mailconf -s mailman -k site_owner
>> <email address hidden>
>
>>> /bin/mailconf -s shell
>> [shell] prompt : >>>
>> [shell] banner : Welcome to the GNU Mailman shell
>> [shell] use_ipython : no
>
>>> /bin/mailconf -k path
>> [runner.master] path: $QUEUE_DIR/$name
>> [logging.template] path : mailman.log
>> etc.

I like this. The alternative is to accept the `[section]variable` syntax for
the key, so that the retrieval syntax would match a hypothetical (i.e. not
part of this bug) setting syntax. postconf can set values too, but I propose
we don't worry about that for mailmanconf now.

Of course the extended syntax can always be added later, so the -s and -k
semantics you describe above seem reasonable.

(Note that these days, this would be implemented as a bin/mailman subcommand,
probably `config`.)

Feel free to follow up on mailman-developers if you have further questions.