Re: Using Data::Dumper to dump an array of hashes to a file

[kyle]

Here's a little demo:

use strict;
use warnings;

use Data::Dumper;

my @aoh = ( { a => 1 } );
my $file = 'diskstats.perldata';

out( $file, \@aoh );
undef @aoh;
@aoh = in( $file );

sub out {
    my ( $file, $aoh_ref ) = @_;
    open my $fh, '>', $file
        or die "Can't write '$file': $!";
    local $Data::Dumper::Terse = 1;   # no '$VAR1 = '
    local $Data::Dumper::Useqq = 1;   # double quoted strings
    print $fh Dumper $aoh_ref;
    close $fh or die "Can't close '$file': $!";
}

sub in {
    my ( $file ) = @_;

    open my $fh, '<', $file
        or die "Can't read '$file': $!";
    local $/ = undef;  # read whole file
    my $dumped = <$fh>;
    close $fh or die "Can't close '$file': $!";
    return @{ eval $dumped };
}

Notes:

• I don't check here whether the eval succeeded, but that would be a good idea.
• These are bad sub names.
• These are not general dump/save subs. They're meant just for arrays.
• Consider using YAML or Storable instead since it doesn't have the possibility of executing things if someone hostile gets a hold of the dump file.

[wishartz]

Thanks for your reply.

One thing that I don't understand, is why do I have to include the subroutine 'in' in my program for it to dump out the contents of the array? I thought the subroutine 'in' was what I was just using in my other program to read the file?

And it only seems to dump it, if I press <crtl+c> and kill the program? Unless, it is just taking a long time to write the contents to disk?

[wishartz]

Sorry, my mistake. I had put the subroutines in the middle of my code, when they needed to be at the end, when I had finished with the array.

Thanks again

[alexm]

sub in {
    my ( $file ) = @_;

    open my $fh, '<', $file
        or die "Can't read '$file': $!";
    local $/ = undef;  # read whole file
    my $dumped = <$fh>;
    close $fh or die "Can't close '$file': $!";
    return @{ eval $dumped };
}

Wouldn't do or require accomplish just the same task, but more succinctly?

[kyle]

Mostly, yes.

I wouldn't use require because it would decline to load the same file twice (unless you monkey with %INC). Also, I don't know if it would return the value returned by the file (I think it doesn't).

Using do is a better choice, but the error handling is different. Here's some code I wrote a while back after examining the docs for a while:

    if ( ! defined do $rc_file ) {
        die "Error in '$rc_file': $@"    if $@;
        die "Can't read '$rc_file': $!"  if $!;
        warn "'$rc_file' returned undef as last value";
    }

It's not as easy as just "return @{ do $file }", but I admit I like it better. Using do has some other differences noted by the documentation, but nothing I'd expect to trip us up in this case.

[alexm]

I wouldn't use require because it would decline to load the same file twice (unless you monkey with %INC). Also, I don't know if it would return the value returned by the file (I think it doesn't).

It actually does :)

I've been using require for a while to read simple config files: it does syntax error checking and the fact that it only loads once was not a big deal. However, I agree that YAML (or Config::IniFiles et al.) are safer and should be preferred.