in reply to Re^2: BackupPC or Data::Dumper playing foul...?
in thread BackupPC or Data::Dumper playing foul...?

Well this all depends on how the output from Dump (or Dumper) is going to be used, which you don't show; but yes, if the intent is to eval() the output to store in a scalar, passing [*value] is exactly the wrong thing to do.

Even if \[*value] works for you now, it is an invalid parameter for Data::Dumper, so it's likely that another future version will actually check that and complain about it. The correct fix, as I mentioned in my original reply, is to remove the second parameter to new() altogether: just make it Data::Dumper->new([$newConf->{$var}]).

Replies are listed 'Best First'.
Re^4: BackupPC or Data::Dumper playing foul...?
by Krambambuli (Curate) on Apr 08, 2022 at 21:55 UTC
    Took me a while to understand and check. Indeed, omitting the second argument entirely seems to be the correct patch.

    I'm not fully sure yet how the output is used; BackupPC's source is not necessarily easy to read/follow and I'm not at all 'fluent' in it. But as the changes to config values (done via CGI) are merged with the values read in from the old config files, as strings into executable files, there sure is some later eval() somewhere.

    Thank you!

      I haven't dug into the BackupPC code to verify the exact method used, but it has to be using either do or eval, because the config files aren't limited to variable assignments. If you hand-edit them, they're also able to run arbitrary perl code.

      The overall setup, for those unfamiliar with BackupPC, is that there's a main file containing a bunch of perl variable assignments representing the global configuration, and then each individual host that's backed up can, optionally, have a [hostname].pl file with additional variable assignments to override the global settings. Both and the [hostname].pl files can be edited through the CGI interface, which then uses Data::Dumper to overwrite the files with the new values.