突然之间,除非我给它们加上前缀“ perl”并给出该脚本的完整路径,否则perl脚本将无法工作

我一直在使用自己的个人环境,该环境已经持续工作了20多年。大约14年前,我开始合并许多perl脚本。 我使用相同的命令行解释器树已有22年了(NDOS-> 4DOS-> 4NT-> TCMD,实际上都是同一程序)。 我只是从ActiveState Windows Perl切换到Strawberry Perl。 多年来,这是我运行perl脚本所需要的:
SET .pl=perl
这是您指定用于打开内容的程序的方式。 我可以简单地做到这一点:
c:\\>test.pl
Hello, world!
事情才奏效。永远。 今天,在使用了一周的OS上,一切都停止了工作。 Perl脚本将运行,但不会执行任何操作。没错无输出。没有。 唯一可行的方法是在脚本前加上\“ perl \”(在这种情况下,不会搜索我的路径,因为脚本名称现在是一个参数,因此我不得不填写完整路径对于脚本) 这就是成为我的感觉:
C:\\>test.pl

C:\\>perl test.pl 
Can\'t open perl script \"test.pl\": No such file or directory

C:\\>perl c:\\bat\\test.pl 
Hello, world!
请注意,昨天(甚至今天今天早些时候)这种方法运行良好。我不知道是什么改变了它,什么打破了它,而且我已经看了很长时间了,发现了类似但不完全相同的问题-修复没有帮助。 我花了一大堆脚本。我真的很讨厌不得不在每个人之前插入“ perl”这个世界,然后限定整个路径! 实际上,我可能必须编写一个perl.bat包装器,将参数文件名转换为完全限定的路径,并显式调用perl。 我真的不想这么做。那是一个禁令解决方案。我想了解问题所在,解决并解决该问题。 我开始讨厌Windows 7 ...     
已邀请:
        我认为您的问题很可能是与.pl到perl.exe的关联断开了。 在注册表中查看HKEY_CLASSES_ROOT \\。pl,它下面可能有Perl(或说FOO)子节点 现在,如果是这种情况,请查看HKEY_CLASSES_ROOT \\ Perl或FOO。 它应该有一个shell \\ Open \\ command键 应该看起来像这样
  \"C:\\Perl\\bin\\perl.exe\" \"%1\" %*
当然,您系统上的perl.exe路径可能不同。 %*是重要的位,它将传递给脚本的参数传递给perl.exe 因此,当您在命令窗口中执行“ test.pl foo bar”时,幕后的外壳实际上是在调用
C:\\perlpath\\perl.exe C:\\scriptpath\\test.pl foo bar.
当您仅在Windows资源管理器中选择一个* .pl文件并尝试将其与perl.exe关联时,就会发生此类问题。 另外,如果将.PL添加到PATHEXT环境变量中,甚至不必指定test.pl,只要它在路径中位于第一个位置,test就会调用test.pl :)     
        Windows Powershell 在Windows Powershell中,将.PL添加到PATHEXT环境变量中(否则脚本将在单独的CMD窗口中运行)。 但是,除非它们在PATH中,否则Powershell不会运行命令(即\“。\”默认不在$ env:PATH中,这有点像Unix上的root) 因此,要运行脚本
./script 
./script.pl
最简单的方法是使用Powershell配置文件。 例如在C:\\ Users \\ username \\ Documents \\ WindowsPowerShell \\ Microsoft.PowerShell_profile.ps1中
$env:PATH   = \"C:\\strawberry\\perl\\bin;$env:PATH\"
$env:PATHEXT    = \"$env:PATHEXT;.PL\"
如果您不需要这样做。/(请注意,这是安全隐患),请在路径中添加\。(不带引号)。
$env:PATH   = \"C:\\strawberry\\perl\\bin;$env:PATH;.\"
那你就可以做
script
    
        您可以通过右键单击
.pl
文件,选择
properties
,然后单击“打开方式”按钮(这是XP,我不知道它在Windows 7中的外观)来检查文件扩展名关联。可能是您的扩展名指向错误的位置。     

要回复问题请先登录注册