note tospo not really. The crucial point is that the entire content of that csv file can be auto-generated in a few linew unless I'm missing something important here. Take this as a simple example: <code> my @combinations = ( "1,1","1,2","2,1","2,2") </code> vs. <code> my @combinations; for my $i (1..2){ for my $j (1..2) { push @combinations, "$i,$j"; } } </code> I'm generating an array in this case with strings that are combinations of elements, in this case simply the number 1 and 2 but you can easily substitute that with "THIS", "THAT" and "This Evaluation", "That Evalutation" etc, which is what you have (if I remember your other thread correctly). In the first example, I harcode the array by typing all the combinations in my script. I could also save them to a file in csv format, as dump of the array (using Data::Dumper), or whatever format you can think of - the problem remains: I'm hardcoding all possible but entirely predictabe and therefore scriptable combinations of elements. In the second example, I generate all possible combinations on the fly. Again, if I remember correctly, you only need to do that to generate a file name. For that reason you don't even need to save the data to an array or a hash - you just generate the string as a combination of all the elements and then use that to open your file - job done. Of course, in my simple example, the second version is longer than the first, but you can easily see how that changes quickly with more elements and more combinations. So, if the data can be generated on the fly, do it - that's the whole point of scripting. If not, i.e. sometimes you want the scale for a "THIS" plot to be "0:" and sometimes ":100" and tehre is no way to predict it, then you have to resort to a config file (for which you can use a number of options, such as YAML or simple config format - have a look around on the CPAN). Hope this helps. 931485 931540