[Raleigh-talk] Issues after converting bash to Perl - way to call a config file that contains if/then logic
Trevor Little
trevormg19 at gmail.com
Tue Feb 22 06:28:51 PST 2011
If you really want to use require you have to declare the variables in your
main script first with 'our' like this:
our ($var1, $var2, $var3);
require $configfile;
# now $var1, etc will have whatever values were set in the config file
However, I hesitate to even point that out since logic in the config file is
probably a bad idea as was pointed out. If you're hash of all possible
options is not super big (megabytes) I'd just go that route and not worry
about the memory. You may be optimizing prematurely.
Trevor
On Tue, Feb 22, 2011 at 2:50 AM, John Ricker <sephtin+pm-talk at gmail.com>wrote:
> On Tue, Feb 22, 2011 at 2:08 AM, Mike South <msouth at gmail.com> wrote:
>
>>
>>
>> On Mon, Feb 21, 2011 at 10:21 PM, John Ricker <sephtin at gmail.com> wrote:
>>
>>> Just having converted a bash script to Perl, ran across a couple issues,
>>> and thought maybe sending to the list might obtain a nudge in the right
>>> direction.. :)
>>>
>>> The issue I'm currently trying to tackle is pulling in config info.
>>> I have a config information I want to include, but it's dependent on a
>>> variable(s) set in my script. In bash, I'd just source the file, and it'd
>>> go through the if statements, and all is well. In Perl, I can't seem to
>>> tackle it...
>>>
>>> Example:
>>> #main.pl
>>> if (stuff) {
>>> $varsneeded = "first";
>>> }
>>> elsif (otherstuff) {
>>> $varsneeded = "second";
>>> }
>>> else {
>>> $varsneeded = "last";
>>> }
>>>
>>> <need to read in variables here>
>>> <then do stuff with variables>
>>>
>>> ---x---
>>> #configFile:
>>> if ($varsneeded eq "first") {
>>> $var1 = "1";
>>> $var2 = "2";
>>> ...
>>> }
>>> elseif ($varsneeded eq "second") {
>>> $var1 = "somethingelse1";
>>> $var2 = "somethingelse2";
>>> ...
>>> }
>>>
>>> You get the idea.
>>>
>>> So, I've tried:
>>> --use: Did testing with use, and thought it was my answer, but
>>> unfortunately the directory that I need to grab the config file(s) from is
>>> set from a variable... which isn't defined until after compile time, so use
>>> doesn't seem to be an option.
>>> --do/require: Can't seem to find a way to pass the $varsneeded variable
>>> into the config file(s) (.pl, .pm, .whatever) when using do or require. If
>>> there's an example out there of this, then somehow google has not been kind
>>> enough to enlighten me. :P
>>> --eval `config file`: variable to the config file, same issue as
>>> do/require attempts.
>>>
>>> Obviously I've oversimplified the example. The script is over 1200
>>> lines, so simplified for good reason. Looking for best practice kind of
>>> thing here.. if more detail is needed (I expect it may come to that).. I can
>>> fill in a lot of blanks, just need to know what info might be helpful.
>>>
>>> More info--
>>> After some thought, and after re-reading my question.. thought some
>>> additional info might be helpful.
>>>
>>> The script is for creating custom themes. I'm taking choices made on a
>>> php page that are passed to the script, and the script is pulling in
>>> variables based on those choices... and some other factors.. :P
>>> Each section is approx. 26 variables right now, and there are 19
>>> different possible options with another dozen or two coming soon.
>>>
>>> MY answer to this all, is to break up the config file into a file for
>>> each option, and just pull in the appropriate file... But as this beast
>>> grows, I'd REALLY like the convenience of a find/replace in ONE file when
>>> something changes, instead of 50 or more!
>>>
>>
>> I don't understand what you're saying here--do you mean that you would
>> like all the configuration to be in one file?
>>
>> You could have one single perl data structure with all the data:
>>
>> my $config={
>> theme1=>{
>> option1=>{
>> var1=>'theme1option1var1',
>> var2=>'theme1option1var2',
>> var3=>'theme1option1var3',
>> },
>> option2=>{
>> var1=>'theme1option2var1',
>> var2=>'theme1option2var2',
>> var3=>'theme1option2var3',
>> },
>> },
>> theme2=>{
>> option1=>{
>> var1=>'theme2option1var1',
>> var2=>'theme2option1var2',
>> var3=>'theme2option1var3',
>> },
>> option2=>{
>> var1=>'theme2option2var1',
>> var2=>'theme2option2var2',
>> var3=>'theme2option2var3',
>> },
>> },
>> };
>>
>> my $theme_choice = shift;
>> my $option_choice = shift;
>> my $theme_key = 'theme'.$theme_choice;
>> my $option_key = 'option'.$option_choice;
>>
>> my $config_to_use = $config->{$theme_key}{$option_key};
>>
>> foreach my $var_name (qw/var1 var2 var3/) {
>> print "var1: $config_to_use->{$var_name}\n";
>> }
>>
>> msmbp:~ msouth$ perl glurg.pl 1 a
>> var1: theme1,optiona,var1
>> var1: theme1,optiona,var2
>> var1: theme1,optiona,var3
>> msmbp:~ msouth$ perl glurg.pl 2 b
>> var1: theme2,optionb,var1
>> var1: theme2,optionb,var2
>> var1: theme2,optionb,var3
>>
>> That would give you one config file to edit.
>>
>> If you want to do it per your original description, bash-ish-ly (I don't
>> recommend this), below is how (I used the environment (accessed via %ENV) to
>> simulate data coming in that you don't know until runtime--should have used
>> "shift" to make it easier). There are some techniques (requiring a file you
>> didn't know the location of until runtime, sharing a variable via "our")
>> that might be of interest.
>>
>> mike
>>
>> msmbp:~ msouth$ cat bob.pl
>> use strict;
>> use warnings;
>>
>> our $which_config;
>>
>> our $var1;
>>
>> our $which_dir = 'bob';
>>
>> $which_config = 'one';
>> #$which_config = 'two';
>>
>> my $theme_sub_dir = $ENV{theme} || die "set theme in the env like this:
>> theme='test' $0\n";
>>
>> my $full_path_to_require = "/Users/msouth/$theme_sub_dir";
>> die "there is not a directory called $full_path_to_require" unless -d
>> $full_path_to_require;
>> push @INC, $full_path_to_require;;
>>
>> require "$which_dir/set_up_bob.pl";
>>
>> print $var1,$/;
>> msmbp:~ msouth$ cat bob/set_up_bob.pl
>> use strict;
>> use warnings;
>>
>> our $which_config;
>> our $var1;
>>
>> if ($which_config eq 'one') {
>> $var1='the one version of var1';
>> }
>> elsif ($which_config eq 'two' ) {
>> $var1='the two version of var1';
>> }
>> else {
>> die "you didn't tell me which config in the 'which_config' variable,
>> or maybe you didn't declare it with 'our'";
>> }
>> msmbp:~ msouth$ theme=bob perl bob.pl
>> the one version of var1
>>
>>
> After seeing both of you (Matt/Mike) suggesting the same thing.. I may need
> to revisit a config file that just loads everything (hash most likely), but
> wouldn't that keep everything in memory? (While maybe not that much
> memory... but it would add up.. no?).
> I guess I assumed that the "cleaner" way to do it, was to only load the
> variables I was going to use, while ignoring those that I'm not interested
> in... I'm fairly new to Perl, so clueless about best practices.
>
> Re: the "bash'ish" way... was the only way I could come up with that didn't
> load everything regardless of what I needed... other than splitting up each
> theme into separate files, which I'm trying to avoid.
> My failure was with use(), since it required path at runtime (using lib)
> which I couldn't provide at compile time as the path is a variable defined
> in the file.
> I DID attempt require, but wasn't able to pass the variable to the config
> file. I must have been doing something wrong because after checking Mike's
> example and switching things back for require, it seems to be working...
> I'll probably comment it out, and try what seems to be the most recommended
> method... just hashing everything, and reading it that way... good learning
> experience at the very least... :)
>
> Thanks for the quick feedback. Have somewhere to start from at least...
>
> -John
>
> _______________________________________________
> Raleigh-talk mailing list
> Raleigh-talk at pm.org
> http://mail.pm.org/mailman/listinfo/raleigh-talk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/raleigh-talk/attachments/20110222/bbde8e3c/attachment-0001.html>
More information about the Raleigh-talk
mailing list