问题
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.
回答1:
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.
回答2:
If you have administrative access, you can define a system wide %PATH%. The user's %PATH% augments it. Regular programs running on the system under user accounts should be able to see the system wide %PATH%.
I do not know whether you scheduled the task from the GUI or using AT, but Scheduled Jobs Cannot Access User Environment Variables might be helpful.
回答3:
I just ran into this same, or at least similar issue. I'll spare you the gory details of my investigation. The solution was that UAT was getting in the way.
I have local admin privs on my Windows 7 machine. I had to go into Adminstration Tools > Local Security Policy > Security Options and ENABLE User Account Control: Run all administrators in Admin Approval Mode. Reboot - and voila. My scripts now run in Task Scheduler.
Hope this helps
来源：https://stackoverflow.com/questions/10559050/processes-spawned-from-a-perl-script-run-via-windows-task-scheduler-dont-have-a