There is BIND::Conf_Parser which is a base class for parsing 8.x named.conf files. In a nutshell to retain bits of an existing conf file you first need to parse it so you can find the bits you want to keep, change the bits you want to change, then put Humpty Dumpty back together again....

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

I've looked at Bind::Conf, but it only reads named.conf files, it doesn't write them. :-(

Ah that's kinda the idea. You read in the current file and parse it using a parser module. *You* make your changes to this parsed data set. *You* print out the new file from your munged data set.

One significant problem with retaining comments is that they are only useful if the are relevant. Comments that relate to parts of the file which have been changed are worse than useless.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Another option would be to use something like Template Toolkit to process a skelleton file. If the user has any non-standard edits, they can place them in the skelleton file and they'll be preserved in the output. That of course requires some handwaving if the user expects something of theirs to override the generated output (perhaps use some sort of directive which sets a variable that the generated portion inspects).

Text::Template might be worth looking at, too. I use that one for Java Servlet configs.
One of these days, I'll get around to playing with Template Toolkit... I continue to hear much good about it.

Also worth looking into, for its simplicity if for no other reason, is CGI::FastTemplate. The "CGI" in its name can be misleading -- it's just a darn fine template parser. I use it all the time, and often for things that get nowhere near the web.

Config::IniFiles tries to preserve comments but I'm not sure how well this works.

Hope this helps...

gav^

Hmmm.. those are not bad ideas. I don't know why I didn't think of Algorithm::Diff. I'll look at Config::IniFiles first to see if I can steal any ideas, then checkout Algorithm::Diff and see if it can be of any help.

thanks!

yet another option would be to put and 'End of CGI config' tag at the end (or beginning) of the cgi-generated part, and then add some comments instructing the user making the hand edits to put his or her config directives in the proper section...

hope this helps,

use Config::IniFiles;
my $handle = Config::IniFiles->new(-file=>$filename);
my $setting = $handle->val ('sectionname','yoursetting')
print "I like chicken.\n";
[download]

Dear god I hope your kidding! If not, I hope you'll elaborate. That sounds complicated and roundabout as hell, but that could just be because of my lack of XML knowledge.

The code isn't as modular as one might like, but it is thoroughly readable in all of the modules I've studied. It is probably worth looking into as a working example.

It can be found here: http://www.webmin.com

While AppConfig is cool (used it myself several times), it doesn't read Bind config files and I don't think that it can output configurations (which was one of the points in the original question).

Outputting configs was the ENTIRE point of the original article. I'm already parsing the config just fine. And, as you said, Appconfig while awesome, won't read named.conf files.