http://www.perlmonks.org?node_id=1000250

shads has asked for the wisdom of the Perl Monks concerning the following question:

Greetings monks, I am in need of some wisdom from the monastery. I'm creating a script that will look up an (unknown) set of fields from a data source and create a config file. Users will then use this config file to map the fields to either a static string or a variable that I want available as a switch/option when they run the script.

The file would look something like:
ds_field1="A normal string here"
ds_field2=$option1$
ds_field3=$option2$
ds_field4="More words here"

The user would then be able to execute the script as so: ./script --option1 "input for field2" --option2 "input for some other field"

The end game is that the user can customize how these fields map back to the data source, the reason the data source fields are dynamic is because different installs of the data source have potentially different available fields.

The question is: how do I handle dynamic options like this? Right now I'm struggling to think of a sane way to handle the user input/variable mapping aspect.

Edit: Oh! I almost forgot, $option1$ would in reality be some kind of meaningful name. I could just use generic $arg1$, $arg2$, etc type options but in the interest of preserving the sanity of the user I would prefer the names were meaningful (i.e. $hostname$) which is the crux of the problem.

Replies are listed 'Best First'.
Re: mapping dynamic fields to options
by NetWallah (Canon) on Oct 22, 2012 at 00:28 UTC
    If you segregate the option processing from the substitution, the following modules can help you do each well:
    Getopt::Long and Text::Template.

                 "By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest."           -Confucius

      I *could* segregate them which would immediately solve my problem, it just comes at the cost of readability and usability, unless I'm misunderstanding you.

      I feel like just general use of this will be challenging enough without introducing additional (hopefully unnecessary) hardships.
        Apologies for not being clear - what I meant was you could segregate THINKING about the problem, and use both those modules in a single program.

        GetOptions would process the option list, and Template would do the substitution.

        From the looks of your requirements, the program implementing this would be quite small, and completely flexible.

                     "By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest."           -Confucius

Re: mapping dynamic fields to options
by thargas (Deacon) on Oct 23, 2012 at 13:42 UTC