Skip Menu |

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

Report information
The Basics
Id: 27225
Status: resolved
Priority: 0/
Queue: Config-General

People
Owner: tlinden [...] cpan.org
Requestors: dguilder [...] atg.com
Cc:
AdminCc:

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



Subject: Config::General 2.33 Interpolation Problems
Date: Mon, 21 May 2007 16:11:49 -0400
To: Bugs in Config-General via RT <bug-Config-General [...] rt.cpan.org>
From: Daniel Guilderson <dguilder [...] atg.com>
I'm having trouble with Config::General 2.33. There seems to be a bug in the interpolation code. It can be reproduced with the following simple config file (also attached): <outer b1> test = foo <inner> ivar = $test </inner> </outer> <outer b2> test = bar <inner> ivar = $test </inner> </outer> The above config is parsed into the following structure: $VAR1 = { 'outer' => { 'b1' => { 'test' => 'foo', 'inner' => { 'ivar' => 'foo' } }, 'b2' => { 'test' => 'bar', 'inner' => { 'ivar' => 'foo' } } } }; I used the following code to do this: my %copts = (-ConfigFile => "example.cfg", -InterPolateEnv => 1, -AutoTrue => 1); my $cfg = new Config::General(%copts); %conf = $cfg->getall(); print Dumper(\%conf); As you can see, the ivar in the inner block of the second outer block ("b2") is incorrectly set to "foo". It should be "bar". For some reason the $test variable is being interpolated in the scope of the "b1" block rather than the "b2" block.
<outer b1> test = foo <inner> ivar = $test </inner> </outer> <outer b2> test = bar <inner> ivar = $test </inner> </outer>
Subject: [rt.cpan.org #27225] Config::General 2.33 Interpolation Problems
Date: Tue, 22 May 2007 11:24:52 -0400
To: bug-Config-General [...] rt.cpan.org
From: Daniel Guilderson <dguilder [...] atg.com>
I'm attaching a context diff which I think fixes the problem. The _interpolate function looks in the variable stack for previous definitions of the variable being interpolated. The problem is that it checks to make sure that the variable isn't already defined in the current scope but the stack is structured such that a previous out-of-scope definition of the same name and level as the current block still exists on the stack. I believe the solution is that when entering a new block, any definitions at the same level as this new block can be cleared. Actually, any at the same level or lower can be cleared but just clearing the same level is enough to prevent this bug.
--- General.pm.orig 2007-05-22 10:26:42.000000000 -0400 +++ General.pm 2007-05-22 11:13:13.000000000 -0400 @@ -726,6 +726,11 @@ } } if ($this->{InterPolateVars}) { + # Clear everything from the next level + if (defined $this->{stack} + and defined $this->{stack}->{$this->{level} + 1}) { + $this->{stack}->{$this->{level} + 1} = {}; + } # interpolate block(name), add "<" and ">" to the key, because # it is sure that such keys does not exist otherwise. $block = $this->_interpolate("<$block>", $block);
fixed in 2.34, applied the patch. thx.
From: ville . skytta [...] iki . fi
On Mon Oct 15 09:03:02 2007, TLINDEN wrote: Show quoted text
> fixed in 2.34, applied the patch.
This change breaks setting default values for non-toplevel variables, see bug 30063.
Hello, bug #30063 has been updated, there is a fix available. Perhaps you're interested to test it. http://rt.cpan.org/Ticket/Display.html?id=30063
Fixed in 2.37.