I was just thinking of a way to input the data into an array of hashes from one or more external files which would hold the data. The array is then used to provide some simple configuration options to a program. This script is intended to run both Linux and Windows, obviously changing the paths.

#!/usr/bin/env perl

use strict;
use warnings;

use autodie;

# For Windows
my $Subscriptions_Path = "G:/Subscriptions";
my $Phone_Sync = "G:/Sync/PHONE/Main/Music";
my $Temp_Files_Location = "G:/Subscriptions/tmp";


my $Wait_Time = 10;

# Subscription DATA sets

my @Subscription = ( 
     {
     Sub_Name               => "Morph",
     Archive_File           => "Morph Archive.txt",
     Lib_Sub_Path           => "$Subscriptions_Path/Morph",
     Phone_transfer         => 0
     },     
);

for (@Subscription) {
     print "Beginning Subscription Service for $_->{Sub_Name} \n";
     
     print "\nCompleting Subscription Service for $_->{Sub_Name} \n\n\
+n";
     sleep int(rand($Wait_Time));
}
[download]

Thanks for posting your sample code. Much clearer now!

In fact, it spookily reminded me of a node I wrote a while back: Data-driven Programming: fun with Perl, JSON, YAML, XML...

As you can see from that node, I faced a similar problem to what you are asking about.

Generally, I'm a fan of defining a table of properties, as you have done, because it helps to separate the code from the data. After asking my question, I ended up leaving the script alone with its table of properties hard-wired in the script. It was very flexible that way and proved to be easy to maintain over many years. Having the build script itself under version control was essential, of course, to allow us to examine changes to our automated builds over time.

Update: see also: Data Structure References