I have a Perl script that is calling a program on Windows using backticks. It works fine when I run it in the command prompt. It stops working when I run it using Windows task scheduler. This is on Windows Server 2008 x64 with ActiveState Perl. It gives me an error is not recognized as an internal or external command, operable program or batch file. Once I change my call to the program to point to the full path of the program it works again.
So something about when its run in a task schedule with backticks prevents it from seeing the windows environmental variables, specifically the %PATH% variable when its run. Something is maybe missing from the shell that’s spawned by the backticks? Should I be using a different command to perform the system calls? Or is there a task scheduler setting that will solve this? If anyone can assist I would appreciate it.
To be honest my environment is more complicated than this, but this is what I’ve narrowed it down to. I actually have a task schedule with a batch file that runs a php script which itself runs the perl script which then runs the program. The rest of the stack that I didn’t mention before does seem to have access to %PATH%, so the batch file runs ‘php …’ and the php script runs ‘perl …’ and then the perl script fails when running ‘programname’ using backticks. I’ve stripped away the batch file and php script and the behavior still persists with just the task scheduler and perl.
Running path from in perl basically helped me solve the problem. The problem isn’t perl itself, but the fact that changes to the %PATH% variable don’t show up to the task scheduler until the task scheduler service is restarted. As far as I know there’s no way to restart task scheduler without rebooting the machine. So the program path was not showing up when run in the task schedule but was showing up in the command line.
I found two solutions to this.
One is to just reboot the machine.
The second is to make sure that your task schedule is set to ‘Run whether user is logged in or not’ (The closest command line parameter to that option is the /NP parameter for schtasks) For some reason running the schedule in that scenario gives it access to the current %PATH% variable. I’m not sure but I think this would break scripts that need to interact with the desktop though.