There are many excellent templating modules around. If you need to expand your script later to do more complicated things you might regret that you didn't use one of those from the beginning

Since you have about 12 replacement patterns it might be worthwhile to combine them into one regex. Using the regex switch e and an array to store the input list you could do something like this:

my @input = split(/,/,$_);
my $file_out= pop @input;
...
foreach ...
...
  $_=~ s/<<<Variable_(\d+)>>>/$input[$1]/ge;
[download]

Untested. Also will give out warnings if there are fewer input parameters on the command line than in the file. A solution would be to change regexp line to

$_=~ s/<<<Variable_(\d+)>>>/if ($1>=@input) {''} else {$input[$1]}/ge;
[download]

use HTML::Template;

my $TEMPLATE = HTML::Template->new_file($path_to_template);

open my $CSVIN, '<', $file;
foreach (<$CSVIN>) {

    #split CSV into usable format
    #the real script has about ten variables
    (my $input1, $input2, $input3, $file_out) = split(/,/, $_);

    open my $FHOUT, '>', $file_out;
    $TEMPLATE->param({$var1 => $input1,
                      $var2 => $input2,
                      $var3 => $input3, 
                      # ...
                     });
    print $FHOUT $TEMPLATE->output();
    close($FHOUT);

}    # end iteration through CSV
[download]

Faster, and less code too!

-sam

The code itself looks fine.

PBP will tell you to:

• Use for instead of foreach
• Leave out the parentheses from functions, e.g. use split /,/, $_ instead of split(/,/,$_)
• And use msx on your regexes

Update: You should have use strict; and use warnings; at the top of your code. I realise this is just a code fragment and you may have those lines in the complete script - but you did ask :-)

Unless I am actually processing millions of files, I care very little for what is thought to be “most efficient.”   But I always care very much for what is“cleanest to read.”

A very good rule of thumb for this is, “separation of concerns.”   In the code-snippet you show us, it is hard to immediately see how “input processing and preparation” is cleanly separated from “templating and output.”   But if you look at the later reply which shows the use of a templating-engine, it is much more clear.   That’s because the template describes what data is used and how that data is formed into an output string.   I’m really not terribly concerned which templating system you use.

I am also keenly sensitive to, “how maintainable will this thing be?”   When (not “if”) a change is needed, how quickly and confidently can a total stranger make that change?   How likely is it that an “isolated” change to one aspect of the software will have not-isolated (i.e. “suh-prize! it’s two o’clock in the morning and your beeper’s going off...”) consequences?

You want to use Template-Toolkit. That's what pretty much everyone uses these days. Only choose something else if you have a compelling reason to do so.