Skip Menu |

This queue is for tickets about the Config-Std CPAN distribution.

Report information
The Basics
Id: 33847
Status: stalled
Priority: 0/
Queue: Config-Std

People
Owner: Nobody in particular
Requestors: aryehk [...] iskoot.co.il
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.0.5
Fixed in: (no value)



Subject: bug, and feature requests
Date: Thu, 6 Mar 2008 10:41:31 +0200
To: <bug-config-std [...] rt.cpan.org>
From: Aryeh Koenigsberg <aryehk [...] iskoot.co.il>
Dear Config-std maintainers, I am very happy with your perl package for config files. The software I am developing makes heavy use of config files, so we use Config::Std for accessing and parsing them. Until now, we used your package for reading only. Lately, we are adding functionality for upgrading config files at customer sites, so we have begun to use the write capabilities of the package as well: In order to merge an existing config file at a customer's site with a template config file from our software upgrade, we read both these files into our merge script, manipulate the template's hash by overwriting some config values from the existing hash, and then write out a new config file with the merged hash. The write capability of the Std package is *very* handy! During testing of our merge code, we've found the following issues: 1) Deleted section survives and gets written: If we delete an entire section from a hash (for example, "[cluster0]", and then create a new section in the hash (for example, "[cluster5]"), with keys and values inside the created section, the written config file contains the added cluster5 section in its entirety (as expected), but it also contains an empty [cluster0] section (not expected). Why is the deleted section "cluster0" included in the file? Note: a) When running the perl debugger on our merge script, we find that the deleted sub-hash "cluster0" is in fact no longer in the config hash structure, which is expected. So, if it is not in the config hash, why is it still written to the file? b) A hack: We achieve expected results (written config file contains added section and does NOT include deleted section) if we write the config file AFTER the section delete (cluster0) but before the new-section add (cluster5). In other words, an extra write_config (to /dev/null, for example) before the section-add-then-write_config step succeeds in writing this final config file *with* the added section, but *without* the deleted section. So, we are using this hack for now. 2) Added sections are written to file with newlines (gaps) Our own personal taste is to maintain our config files with newlines/gaps only between sections, and not inside sections. So, the package writing as is, is inconsistent with our config files. Suggestion: package could accept optional parameter governing use of gaps in added sections (similar mechanism to the existing "def_sep" parameter). 3) Added sections are appended at end of config file We would like some added sections to be added NOT at the end of the config file, but somewhere in the middle, interspersed between other similar sections. Is there some way that the write_config routine could be given some markers (or similar) to govern when/where added sections are written? Thanks again for your great package, and for considering these issues, above! -- Aryeh Koenigsberg Staff Programmer Iskoot, Inc. Bet Shemesh, Israel
Hi Aryeh, I'w a new maintainer on the project here, weeding the RT buglist. Your (1) re-appearing deleted section is interesting. Do you have a minimal test case handy? That's not unique to merging use-case, and would be more serious without a second template. Did 0.0.7 release and { def_gap => 0 } option solve your (2) Added sections are written to file with newlines (gaps)? Your (3) re new section orders when merging -- My thought would be to apply the keeper values from the old file's hash into the new template's hash , write that new template out, and then rename old active => backup and rename new => active. The above reversing of the template roles would solve the (1) and (2) problems as well, wouldn't it?