Re^4: redacting from config hash

I cobbled together an example for using your %config as a hash as you used it rather than as a hashref.

#!/usr/bin/env perl
use 5.011; # implies strict + feature 'say'
use warnings;

use Data::Dumper;
use Config::Tiny;

use constant {
    INIFILE  => 'example.ini',
    ENCODING => 'encoding(Windows-1252)'
};

sub create {
    my %config = (
        my_sftp =>  {
            domain   =>  'example.com',
            username =>  'myname',
            password =>  'topsecret',
        },
        my_github =>  {
            email    =>  "me\@example.com",
            password =>  "confidential",
        },
    );

    say Dumper \%config;

    my $ini = bless \%config, 'Config::Tiny';
    $ini->write(INIFILE, ENCODING);
    say 'created ', INIFILE;
}

sub show {
    say 'reading ', INIFILE;
    my $ini = Config::Tiny->read(INIFILE, ENCODING);
    my %config = %$ini;
    say Dumper \%config;
}

create() unless -e INIFILE;
show()
[download]

There are two configuration values which don't belong into the config file :-) which I defined using constant.

If you don't want to mess with Config::Tiny's internals, you could replace the my $ini = bless \%config, 'Config::Tiny'; line with

    my $ini = Config::Tiny->new;
    $ini->{$_} = $config{$_} for keys %config;
[download]

Edit: Sorry, this was meant as a reply to Re^2: redacting from config hash...

Update: changed 'example.ini' to INIFILE in line 40 🤦

Comment on Re^4: redacting from config hash Select or Download Code

Replies are listed 'Best First'.
Re^5: redacting from config hash by Aldebaran (Curate) on Aug 02, 2018 at 07:02 UTC
I am very pleased to have 2 more excellent responses from the same sources. I hope I'm not trying anyone's patience for not latching on quicker, but we really are in the thick of it now and gaining ground. I present with an error that I don't understand after redesigning what I'm doing to be more descriptive. The questions that haukex raised were partially dealt with by code that soonix wrote. What he wrote first worked, but the one where `my $ini = Config::Tiny->new; $ini->{$_} = $config{$_} for keys %config;` [download] were substituted for the line used to instantiate the object, I got an error on line 38, which I marked. I'd be curious to know why, but having one way to do things is enough for now. It's probably the first time I've blessed anything in the world of bits and bytes, maybe appropriate to my future friar status I won't be "redacting" anything at all now. I'm gonna use Config::Tiny to create and then draw values from an .ini file that is not in the filespace to be copied. It's better data hygiene and really the path forward if the goal is to share with others in ways where they can recreate their own critical values without need to be aware of the internals. Redaction will occur by not copying anything of the form configx.pm . Then I'm gonna alter my script to read in the values from that other location. As it's written, that will be indicated by the return value in the current caller. What follow are 3 listings. The first is a working script that created an ini file successfully. The second is the current driver, 1.initialize.pl which calls the module that I'm writing to capture these functions, the third listing, called utils2.pm. What used to be called "redact" is being renamed "archive", and isn't even being called yet, because I have an error with "make_ini". Read more... (3 kB) Where I seem to have stumbled is combining the Path::Tiny and the Config::Tiny techniques: `$ ./1.initialize.pl Global symbol "$ini_path" requires explicit package name (did you forg +et to declare "my $ini_path"?) at template_stuff/utils2.pm line 47. BEGIN not safe after errors--compilation aborted at template_stuff/uti +ls2.pm line 53. Compilation failed in require at ./1.initialize.pl line 5. BEGIN failed--compilation aborted at ./1.initialize.pl line 5. $` [download] To my eye, I have declared "my $ini_path" in the presence of the appropriate modules in the create() function. Maybe fresh eyes in the morning will help....	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^5: redacting from config hash
by Aldebaran (Curate) on Aug 02, 2018 at 07:02 UTC

I am very pleased to have 2 more excellent responses from the same sources. I hope I'm not trying anyone's patience for not latching on quicker, but we really are in the thick of it now and gaining ground. I present with an error that I don't understand after redesigning what I'm doing to be more descriptive.

The questions that haukex raised were partially dealt with by code that soonix wrote. What he wrote first worked, but the one where

    my $ini = Config::Tiny->new;
    $ini->{$_} = $config{$_} for keys %config;
[download]

were substituted for the line used to instantiate the object, I got an error on line 38, which I marked. I'd be curious to know why, but having one way to do things is enough for now. It's probably the first time I've blessed anything in the world of bits and bytes, maybe appropriate to my future friar status

I won't be "redacting" anything at all now. I'm gonna use Config::Tiny to create and then draw values from an .ini file that is not in the filespace to be copied. It's better data hygiene and really the path forward if the goal is to share with others in ways where they can recreate their own critical values without need to be aware of the internals. Redaction will occur by not copying anything of the form configx.pm . Then I'm gonna alter my script to read in the values from that other location. As it's written, that will be indicated by the return value in the current caller.

What follow are 3 listings. The first is a working script that created an ini file successfully. The second is the current driver, 1.initialize.pl which calls the module that I'm writing to capture these functions, the third listing, called utils2.pm. What used to be called "redact" is being renamed "archive", and isn't even being called yet, because I have an error with "make_ini".