Skip Menu |

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

Report information
The Basics
Id: 31529
Status: resolved
Worked: 10 min
Priority: 0/
Queue: Config-General

People
Owner: tlinden [...] cpan.org
Requestors: ahulsbos [...] xs4all.nl
Cc:
AdminCc:

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



Subject: Interpolation forgets variable for array of blocks
My config file looks as follows: bar = "test" <block> foo1 = $bar </block> <block> foo2 = $bar </block> This used to work, but now fails with Config-General-2.37 with this code: 33: %config = ParseConfig( 34: -ConfigFile => $configFile, 35: -InterPolateVars => 1); and the following error: Use of uninitialized variable ($bar) while loading config entry: foo2 = $bar at /home/soc_admin/bin/file_ingest.pl line 33 I suppose this is related to the fix for bug #27225.
From: perl [...] daemon.de
Show quoted text
> bar = "test" > <block> > foo1 = $bar > </block> > <block> > foo2 = $bar > </block>
Well, the problem is that the two blocknames are identical, so after leaving the first block (in line 4), $bar is removed from the stack because it is out of scope then. Therefore it is unknown to the next block. It would work if the second block had another name or if the option -MergeDuplicateBlocks were turned on. In fact, I'm not sure to consider this as a bug. IMHO it is bad style to use the same blockname multiple times without further arrangements.
IMHO that's not a bug.
From: ahulsbos [...] xs4all.nl
Show quoted text
> In fact, I'm not sure to consider this as a bug. IMHO it is bad
style to Show quoted text
> use the same blockname multiple times without further arrangements.
There ARE further arrangements, and they are built into the module. See your documentation under "Identical Options". Maybe I should have given a slightly more elaborate example: dir = "/project/files" <file_type> extension = ".c" target = "$dir/sources" </file_type> <file_type> extension = ".h" target = "$dir/headers" </file_type> With this file you would get: %config = { dir => "/project/files", file_type => [ { mask = "*.h" target = "/project/files/headers" }, { mask = "*.c" target = "/project/files/sources" } ] }; So that you can say for example foreach my $file_type (@{$config{'file_type'}}) { for (glob($file_type->{'mask'})) { copy($_, $file_type->{'target'}); } } if you also take the precaution to check for the case with only one 'file_type' block. This used to be possible in version 2.31. If you decide that identical blocks should not be used to create an array, could you please update the documentation to say that its use is not supported? Cheers!
Well, it seems to be a problem with hash initialization if moving first item on new array. I attached a patch which seems to fix the problem, at least it parses your last example and outputs: $VAR1 = { 'file_type' => [ { 'target' => '/project/files/sources', 'extension' => '.c' }, { 'target' => '/project/files/headers', 'extension' => '.h' } ], 'dir' => '/project/files' }; I'll look a bit deeper into the issue, because I assume more such pitfals. Until new release you might try the patch and tell me if it works for you.
*** General.pm~ Sat Nov 24 22:07:36 2007 --- General.pm Wed Jan 30 14:21:27 2008 *************** *** 905,911 **** else { push @ar, $savevalue; } ! push @ar, $this->_parse( $this->_hashref(), \@newcontent); $config->{$block} = \@ar; } } --- 905,919 ---- else { push @ar, $savevalue; } ! ! # fixes rt#31529 ! my $tmphash = $this->_hashref(); ! if ($this->{InterPolateVars}) { ! # inherit current __stack to new block ! $tmphash->{__stack} = $config->{__stack}; ! } ! ! push @ar, $this->_parse( $tmphash, \@newcontent); $config->{$block} = \@ar; } }
From: ahulsbos [...] xs4all.nl
I can confirm that the patch fixes the problem. Thanks for your efforts!
fixed in 2.38