See the system command, or perlop's discussion of backticks. Either will allow you to execute a batch file.

As for whether it's better to compose a batch file, or handle all the work directly within perl, I would probably opt for the latter most of the time. However, without knowing more about your problem it's impossible to say definitively which approach is better. I generally find it less complex to just do the work in one scripting language instead of two. But that doesn't mean there are no cases where invoking a batch file is a good way to do it.

In particular, if the objective is just to get the job done, and you already happen to have a couple batch files written that are doing the job for you, there's nothing wrong with simply using perl as the glue to bind them together. If function is more important than fashion, use the tools you already have at your fingertips, and glue them together with Perl.

David's right. You are looking for the system command.

As to whether tis nobler in the hearts and minds to use Perl pure instead of systeming out to some batch files: Consider this. Your batch files are probably calling executables which, if re-written in perl, your perl program would have to system out to do anyway. Also, if your batch files are working just fine, there is no shame in using perl for process control (which is what we call it if perl is directing the other processes).

I'd probalby convert the batch apps to perl based on how much 'thinking' is done in the batch file. If the batch file is just

date /t > c:\temp\foo_export.log
time /t >> c:\temp\foo_export.log
export foo_database > c:\temp\foo_database_export >> c:\temp\foo_expor
+t.log
date /t >> c:\temp\foo_export.log
time /t >> c:\temp\foo_export.log
[download]