Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

mapping dynamic fields to options

by shads (Novice)
on Oct 22, 2012 at 00:22 UTC ( [id://1000250]=perlquestion: print w/replies, xml ) Need Help??

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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1000250]
Front-paged by tye
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (7)
As of 2024-04-19 09:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found