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

Hello revered monks,

I have a bit of an issue here w/ a set of Perl modules I compiled into an .exe for Windows using Perl PAR module (http://search.cpan.org/dist/PAR/lib/PAR/Tutorial.pod) and Strawberry Perl.

The compiled .exe file uses a config file (through Config::IniFiles module) and works as expected when launched from a Windows Explorer window and a MS-DOS CLI shell.

But when the very same executable is called directly in a scheduled task (set up to run when my current user account is logged only), I can see no activity and the logging done by my program does not log anything.

To make matters worse, the same Perl script and its modules work fine in the same scheduled task when called "raw" (i.e. w/o PAR packaging) using :
wperl -IC:\my_app\libs\ C:\my_app\my_app.pl

It looks like a PATH issue but I can't determine where it could be triggered in a PAR-generated executable.

Any help would be appreciated.

Thanks in advance.

Replies are listed 'Best First'.
Re: PAR packaging and Windows scheduled tasks
by Corion (Patriarch) on Jan 06, 2016 at 13:28 UTC

    The PAR executable unpacks the Perl files into a directory below $ENV{TEMP} - is this variable set when your scheduled task runs and does the user the task runs as have the appropriate permissions to create the directory and files there?

    I think there is a swithc or an environment variable that makes PAR retain the unpacked files in the temp directory. Maybe if you enable that, you find remnants of the attempted run.

      Thanks for your answer, I'll look into it.

      However, let me add a few things to my original diagnosis:
      - the executable is not started when defined in a scheduled task, even if I add the .exe location dir to the option "Start in"
      - if I create a .bat file w/ the code below and call it directly in a scheduled task, it works as intended:
      set "WDIR=c:\my_app\" c: cd %WDIR% my_app.exe exit
      I am puzzled...

        Maybe the real path you use contains whitespace and the link in the Task Scheduler does not contain the appropriate double quotes? But the same should apply to the .bat file, so I'm not really sure where/why the problem is there as well.

        Does your PAR program expect to be able to write to STDOUT? It might be that Windows does not allocate a console for the program, but allocates one for cmd.exe, which your PAR program then inherits.