通过Windows Task Scheduler运行的Perl脚本产生的进程无权访问%PATH% [英] Processes spawned from a Perl script run via Windows Task Scheduler don't have access to %PATH%

查看:108
本文介绍了通过Windows Task Scheduler运行的Perl脚本产生的进程无权访问%PATH%的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个Perl脚本,该脚本使用反引号在Windows上调用程序.当我在命令提示符下运行它时,它工作正常.当我使用Windows任务计划程序运行它时,它将停止工作.这是在带有ActiveState Perl的Windows Server 2008 x64上.它给我一个错误,无法识别为内部或外部命令,可操作程序或批处理文件.一旦我将对程序的调用更改为指向程序的完整路径,它就会再次起作用.

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.

因此,当它在带有反引号的任务计划中运行时,会阻止它查看Windows环境变量,特别是运行时看到的%PATH%变量.反引号产生的外壳中可能缺少某些东西吗?我应该使用其他命令来执行系统调用吗?还是有一个任务计划程序设置可以解决这个问题?如果有人可以提供帮助,我将不胜感激.

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.

说实话,我的环境比这还复杂,但这就是我所要缩小的范围.我实际上有一个带有批处理文件的任务计划,该批处理文件运行一个php脚本,该脚本本身运行perl脚本,然后运行该程序.我之前未提到的其余堆栈似乎都可以访问%PATH%,因此批处理文件运行"php ...",而php脚本运行"perl ...",然后perl脚本失败使用反引号运行程序名"时.我已经删除了批处理文件和php脚本,并且仅使用任务计划程序和perl仍然可以继续执行该行为.

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.

推荐答案

perl中的运行路径基本上可以帮助我解决问题.问题不在于perl本身,而是对%PATH%变量所做的更改在任务计划程序服务重新启动之前不会显示在任务计划程序中.据我所知,不重新启动计算机就无法重新启动任务计划程序.因此,在任务计划中运行时,程序路径没有显示,而在命令行中显示.

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.

第二个是确保将任务计划设置为无论用户是否登录都运行"(该选项最接近的命令行参数是schtasks的/NP参数).出于某种原因,在该方案使它可以访问当前的%PATH%变量.我不确定,但是我认为这会破坏需要与桌面交互的脚本.

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.

这篇关于通过Windows Task Scheduler运行的Perl脚本产生的进程无权访问%PATH%的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆