Windows 上的 Perl、文件关联和 I/O 重定向
有人可以解释通过文件关联调用 perl 脚本与通过 perl.exe 显式调用同一脚本之间的区别吗？
显然，当通过文件关联调用脚本时，I/O 重定向效果不太好，我真的很想知道为什么。
例如，查看Windows 上 Perl 的 Activestate 常见问题解答。只要脚本不通过重定向接收输入，cat file 示例就可以完美运行。所以
cat file.txt
按预期工作，但
whoami | cat.pl
没有。不仅需要 .pl 扩展名，而且 whoami 的输出显然没有通过管道传输到脚本中。该脚本已运行（可以通过修改示例 cat.pl 脚本进行验证），但由于某种原因，它没有收到 whoami 的输出作为输入。
但是，如果我这样调用脚本：
whoami | perl cat.pl
一切都会按预期进行。
显然，通过文件关联运行脚本和使用脚本显式调用 perl.exe 之间存在重要区别。
FAQ提到了这个问题，并指出使用pl2bat为脚本生成bat文件覆盖可以解决问题，但我不明白为什么这是必要的。
请赐教。
Can someone explain the difference between calling a perl script via file association versus calling the same script explicitly via perl.exe?
Apparently I/O redirection doesn't work very well when the script is called via file association, and I would really like to know why.
E.g. take a look at the Activestate FAQ for Perl on Windows. The cat file example works perfectly as long as the script doesn't receive its input via redirection. So
cat file.txt
works as expected, but
whoami | cat.pl
does not. Not only is the .pl extension needed, but apparently the output of whoami isn't piped into the script. The script is run (which can be verified by modifying the example cat.pl script), but for some reason it doesn't receive the output of whoami as input.
However, if I call the script like this:
whoami | perl cat.pl
everything works as expected.
So apparently there is an important difference between running the script via file association and explicitly calling perl.exe with the script.
The FAQ mentions the problem and points out that using pl2bat to generate a bat file cover for the script fixes the problem, but I don't understand why this is necessary.
Please enlighten me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
看起来这是 Windows 2000 中的一个已知错误：如果从文件启动，STDIN/STDOUT 重定向可能无法工作协会。
我在 WinXP 上使用 Strawberry Perl 得到了与您描述的相同的行为，但是一旦我创建了上面文章中描述的注册表项（即使该注册表项针对 Win2K），
stdin就会按预期工作。为了完整起见，如果上面的链接消失，它建议创建的注册表项是：
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\ExplorerInheritConsoleHandlesREG_DWORD十进制1编辑：我应该补充一点，即使知识库文章声称它已在 XP SP1 中修复，但我已经安装了 XP SP3。所以我不能说微软是否已经破坏了这个问题，或者从未完全修复它！
It looks like it was a known bug in Windows 2000: STDIN/STDOUT Redirection May Not Work If Started from a File Association.
I get the same behaviour you describe with Strawberry Perl on WinXP, however once I created the registry entry described in the above article (even though the reg entry is targetted at Win2K),
stdinworks as expected.For completeness, in case the link above goes away, the reg entry it suggests creating is:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\ExplorerInheritConsoleHandlesREG_DWORDDecimal1Edit: I ought to add that even though the KB article claims it was fixed in XP SP1, I've got XP SP3 installed. So whether MS have broken this, or never fixed it completely, I can't say!
我知道这是一个老话题，但值得注意的是，微软似乎已经颠倒了 Windows 10 中此设置的极性。不知道他们为什么要这样做，但这让我抓狂了一天。请参阅我的其他发布的问题（Perl 脚本在 Windows 10 上从资源管理器运行，但不是命令提示符），尤其是链接的 MSDN 帖子。
I know this is an old thread, but it's important to note that Microsoft appears to have reversed the polarity of this setting in Windows 10. No idea why they would do that, but this had me pulling my hair out for a day. See my other posted question (Perl Scripts on Windows 10 run from Explorer but not Command Prompt), and especially the linked MSDN post there.