if we're to imitate the syntax in my source it begins: our %config = (

You can get this kind of output from my code by changing Data::Dumper->new([$CONFIG],['$CONFIG']) to Data::Dumper->new([$CONFIG],['*config']) (change the variable names as you like); you'd just have to prepend the our yourself. See also the Data::Dumper docs.

What makes it very difficult is that we seem to be acting on perl syntax itself.

Yes, that's a pretty complex topic, so soonix's suggestion to use a different configuration file format is a good way to avoid that issue.

Variable "$config" is not imported at template_stuff/utils2.pm line 61
+.
Global symbol "$config" requires explicit package name (did you forget
+ to declare "my $config"?) at template_stuff/utils2.pm line 61.
[download]

Why is my syntax on the config hash clashing with that provided by man Config::Tiny and haukex?

You've done use config2;, which should give you a hash %config, which you can confirm if you comment out the line with ->write: do you see the output of print Dumper \%config;? Then, you're doing $config->write, which means "call the method write on the object $config" - not the hash %config! That's why Perl complains about the missing variable $config.

It's possible to create a new Config::Tiny object and then copy over the config from config2.pm's %config into that object. However, I am wondering what the goal of your code is here. Are you trying to automate the conversion from config2.pm into an INI format? If the config is long, I can understand that, but if it's as short as you showed, why not do that step once, by hand? You can then use a method similar to what I showed to create a redacted version, or, again, since that's something you'd probably only be doing once (?), you can do that by hand as well.

Taking a step back: My understanding so far is that you want to provide your code for download for others to use, is that right? And you're figuring out a way to disentangle the stuff you've written for yourself (config files etc.) from the general stuff that you want to distribute to everyone? That's pretty common, and a situation I've been in plenty of times. I've found the best approach is to look at it from a different angle and put yourself in the user's shoes, as if you knew nothing about the internals of the package: what steps would a user who downloads the package have to take to set it up? How would you describe those steps in your README for the user to follow? And then, what do you as the developer have to provide to make that as easy as possible?

what steps would a user who downloads the package have to take to set it up? How would you describe those steps in your README for the user to follow? And then, what do you as the developer have to provide to make that as easy as possible?

It seems to me that a user would want a one session experience to populate his/her critical data. Thus, I've been removing hard-coded values one by one. What remains is a hard-coded path to an ini file, which I think is on the verge of working, but vexingly, does not. This is an analog to what I've used before to instantiate the sftp object. Perl thinks this is illegal:

 

sub get_tiny{

use 5.011;
use warnings;
use Net::SFTP::Foreign;
use Config::Tiny;
use Data::Dumper;



my $ini_path = qw( /home/bob/Documents/html_template_data/3.values.ini
+ );
say "ini path is $ini_path";

my $sub_hash = "my_sftp";
my $Config = Config::Tiny->new;
$Config = Config::Tiny->read( $ini_path , 'utf8' );
say Dumper \%Config;
my $domain = $Config{$sub_hash}->{'domain'};
my $username = $Config{$sub_hash}->{'username'};
my $password = $Config{$sub_hash}->{'password'};
my $port = $Config{$sub_hash}->{'port'};


#dial up the server

say "values are $domain $username $password $port";
my $sftp = Net::SFTP::Foreign->new( $domain, user => $username,
port => $port, password => $password)
  or die "Can't connect: $!\n";
  return $sftp;
}
[download]

List of compiler complaints:

$ ./1.qy1.pl 
Global symbol "%Config" requires explicit package name (did you forget
+ to declare "my %Config"?) at template_stuff/html4.pm line 215.
Global symbol "%Config" requires explicit package name (did you forget
+ to declare "my %Config"?) at template_stuff/html4.pm line 216.
Global symbol "%Config" requires explicit package name (did you forget
+ to declare "my %Config"?) at template_stuff/html4.pm line 217.
Global symbol "%Config" requires explicit package name (did you forget
+ to declare "my %Config"?) at template_stuff/html4.pm line 218.
BEGIN not safe after errors--compilation aborted at template_stuff/htm
+l4.pm line 239.
Compilation failed in require at ./1.qy1.pl line 5.
BEGIN failed--compilation aborted at ./1.qy1.pl line 5.
$
[download]

I just don't see where I'm not correctly imitating the syntax shown on Config::Tiny.

I just don't see where I'm not correctly imitating the syntax shown on Config::Tiny

Part way through you've stopped using a hashref and started using a hash. Just stick with the hashref. eg:

my $Config = Config::Tiny->new;
$Config = Config::Tiny->read( $ini_path , 'utf8' );
say Dumper $Config;
my $domain    = $Config->{$sub_hash}->{'domain'};
my $username  = $Config->{$sub_hash}->{'username'};
my $password  = $Config->{$sub_hash}->{'password'};
my $port      = $Config->{$sub_hash}->{'port'};
[download]

HTH.

...
my $Config = Config::Tiny->new;
$Config = Config::Tiny->read( $ini_path , 'utf8' );
say Dumper \%Config;
my $domain = $Config{$sub_hash}->{'domain'};
my $username = $Config{$sub_hash}->{'username'};
my $password = $Config{$sub_hash}->{'password'};
my $port = $Config{$sub_hash}->{'port'};
...
Global symbol "%Config" requires explicit package name (did you forget
+ to declare "my %Config"?) at template_stuff/html4.pm line 215.
Global symbol "%Config" requires explicit package name (did you forget
+ to declare "my %Config"?) at template_stuff/html4.pm line 216.
Global symbol "%Config" requires explicit package name (did you forget
+ to declare "my %Config"?) at template_stuff/html4.pm line 217.
Global symbol "%Config" requires explicit package name (did you forget
+ to declare "my %Config"?) at template_stuff/html4.pm line 218.
...
[download]

Config::Tiny returns a (blessed) reference to a hash, which is stored in the scalar $Config, so there is no %Config hash available. Both \%Config and $Config{$sub_hash} are however attempting to access a hash named %Config. Instead of Dumper \%Config, do Dumper $Config, and instead of $Config{$sub_hash}, say $Config->{$sub_hash}, and it should work. See perlreftut and perlref.

#!/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.

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

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

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....