luxAeterna has asked for the wisdom of the Perl Monks concerning the following question:

Oh, Wise Ones


I find myself for the first time developing Perl for Windows servers. It is an hostile, unknown jungle for me.

My question is quite philosophical and I know that there is always more than way to do it, but what would you recommend as a safe way to run a Windows batch?

A Windows batch will unmercifully exit if it fails, generally providing through console really generic message about the cause of the fail, that rarely will point to the real issue, but it is better than nothing.

I deduce that for my script to continue running, at least to inform that there was an error before dying, I must spawn a child to execute the batch.

Problem: I understand that a Windows batch does not provide an error code return, and since it simply dies at any failure, executing inside an eval is futile.

Which are the plus and minuses of executing a Windows batch with system or with exec?

Say I have a batch to set the environment variables (which in fact, I have: \dir00\exploit\script\dir_start.cmd) and it can not find some path in certain machines


Thank you in advance to the monks who wish to dedicate some time to provide their experience to give some light in the obscure Windows land

Replies are listed 'Best First'.
Re: Best ways to run a windows batch with Perl
by BrowserUk (Patriarch) on Nov 28, 2014 at 11:21 UTC
    Say I have a batch to set the environment variables (which in fact, I have: \dir00\exploit\script\dir_start.cmd) and it can not find some path in certain machines

    In order to run a windows batch script, you'll need to invoke it within a cmd.exe session. You can do this from Perl using system.

    But there is no point in doing so if all it does is set environment variables!

    Because, once the batch file ends; the cmd.exe session will also end; and all the changes that the .bat file made to the environment will be lost.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re: Best ways to run a windows batch with Perl
by Corion (Patriarch) on Nov 28, 2014 at 11:49 UTC

    Basically, the code in Get default login environment respectively its replies should allow you to read all the environment variables a shell script sets.

    You will need to learn about how your shell (cmd.exe) invokes batch files and how you can run your own code in the context of such a batch file, but it's not hard. The following code works for me to retrieve the environment for a batch file under Windows:

    my $batchfile= 'C:\\test.cmd'; my $cmd= qq("$batchfile" && set); print "Environment: $_" for `$cmd`;

    ... where test.cmd contains

    set TEST=C:\test.pl

    You should easily be able to combine this part with the parsing parts of Get default login environment into something that retrieves the environment under Windows.

Re: Best ways to run a windows batch with Perl
by Anonymous Monk on Nov 28, 2014 at 11:14 UTC
    Which are the plus and minuses of executing a Windows batch with system or with exec?

    Pluses and minuses as compared to what? Since you apparently want your Perl script to continue running, you want system, not exec. Even though it's been a while since I used it on Windows, system should return even if the batch file blows up, then you'll need to inspect the return codes as per its documentation. Or, to make your life easier, use a module like IPC::System::Simple, which has nicer error handling built in.

    When coded with portability in mind, such as using the right modules (like File::Spec or similar for filename handling), Perl is quite portable. For platform-specific notes see perlport (also perlwin32 might contain some useful hints).

      I meant system/exec compared to each other :)

      Unluckily I can't immediately include modules for the CPAN. I can only ask for them to be included in the "official next version of Perl", this ensures that all the servers and machines Perl versions are identical and contain the same packages, but it is bureaucratically slow-ish.

      I will though request the modules you suggest and insist that they are essential if they want Perl scripts that work both in Unix and Windows servers, and I will also read the notes you suggest about portability.

      Thank you very much for your approach :)