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