Add the equivalent of postconf(1)

[Barry Warsaw]

Postfix has a very handy command called postconf(1) which lets you dump all or one Postfix configuration variable. It would be very handy for Mailman 3 to have something similar.

[Barry Warsaw (barry)]

This one would be relatively easy for someone wanting to start contributing to Mailman.

[bernard Keimel (bernie-bill)]

please around unstructions, thanks!

[Barry Warsaw (barry)]

bernard, why did you attach that image? It looks like you're spamming us. :(

[Barry Warsaw (barry)]

Bernard, I'm really glad you're so enthusiastic about helping out the Mailman project, but please don't assign the issue to yourself until you've contacted the Mailman developers and introduced yourself. Assignment of the bug is not necessary to *work* on the bug.

The preferred workflow is for you to upload a branch to Launchpad and link it to this bug. Then you can do a merge proposal for your branch, at which point, one of the core developers will review your branch and help you land it, if appropriate.

Also, please explain what the image is supposed to be in comment #3.

[David Soto (david-soto)]

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.
>

[Barry Warsaw (barry)]

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.