[Bug 518517] Re: Add the equivalent of postconf(1)

Barry Warsaw 518517 at bugs.launchpad.net
Wed Jan 23 00:04:37 CET 2013

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
>Some examples of usage:
>>> /bin/mailconf -s mailman -k site_owner
>> changeme at example.com
>>> /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

You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.

  Add the equivalent of postconf(1)

To manage notifications about this bug go to:

More information about the Mailman-coders mailing list