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.htm...).
Some examples of usage:
/bin/mailconf -s mailman -k site_owner changeme@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 questions. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/518517 Title: Add the equivalent of postconf(1) To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/518517/+subscriptions