仅当外部应用程序存在时才运行它的最佳方式答案

【问题标题】：Best way to run external app only if it exists仅当外部应用程序存在时才运行它的最佳方式
【发布时间】：2009-08-17 15:32:28
【问题描述】：

我有一个 Perl 脚本，作为其最后步骤之一，它创建了它创建的文件的压缩版本。由于一些不幸的设置，我们不能保证给定的客户将具有特定的压缩功能。我想把这样的东西放在一起：

if ($has_jar) {
    system("jar -c $compressed_file $infile");
}
elsif ($has_zip) {
    system("zip -j $compressed_file $infile");
}
else {
    copy($infile, $compressed_file);
}

如果他们没有任何压缩应用程序，它只会将文件复制到压缩文件的位置而不压缩它。

我在这里的粘性检票口是我不太确定确定他们是否有罐子或拉链的最佳方法是什么。看起来我可以使用 exec() 而不是 system() 并利用它仅在失败时返回的事实，但脚本实际上确实做了一些之后的事情，这样就行不通了。

我还需要这是一个可移植的解决方案，因为该脚本可以在 Windows 和各种 Unix 发行版上运行。提前致谢。

【问题讨论】：

它会在 5.10.0 之前的 perls 上运行吗？
是的。尝试了两台不同的机器，得到了 5.8.4 和 5.8.0。

标签： perl system

【解决方案1】：

我认为你最好的选择是File::Which。

【讨论】：

这也是一个不错的主意，尽管我们的客户再次没有安装该软件包，并且将其提供给所有客户并非易事。
正确，在一个完美的世界里。我只知道这里的另一位开发人员推动我们的配置团队将 XML::Simple 捆绑为我们补丁的一部分，而我们的客户在将近一年后遇到了问题。

【解决方案2】：

见我的multi-which。

【讨论】：

哦，我喜欢这样。相对简单且易于集成到我现有的脚本中。除非发生一些疯狂的事情，否则我很可能会使用它。
刚刚实现了这个，一切都按照我的意愿工作......我知道这与 Paul Nathan 的答案相似，但 Sinan 提供了一段非常棒的代码。感谢大家提供的所有解决方案，远远超出我的预期。

【解决方案3】：

对于基于 *nix 的系统，这应该可以工作：

my $has_jar = `which jar` ne '';

如果您包含 which，这可能也适用于 Windows。

或者，您可以尝试this answer建议的命令，

my $has_jar = `for %i in (jar.exe) do @echo.   %~$PATH:i` ne '';

如果没有找到它，它很可能不会返回 ''，但是我没有在 Windows 机器上可用的 Perl 来测试它。

【讨论】：

这肯定会在 *nix 系统上工作，但我真的没有能力在 Windows 安装中包含哪个。如果就这么简单，我只会将 zip 与应用程序捆绑在一起，而不是首先提出这个问题。
在这种情况下，我添加了另一个潜在但未经测试的解决方案。

【解决方案4】：

查看 PATH 环境变量指定的目录。

【讨论】：

是的，这行得通，虽然我肯定希望有更“漂亮”的东西。
没有什么比这更流畅了。要么尝试运行可执行文件并报告失败，要么查看路径中是否有合适的可执行文件，尝试运行它并报告任何失败。

【解决方案5】：

通常，类似的东西不会突然从系统中消失，所以我建议在设置/安装期间检查工具的存在并将其保存在配置中使用。

【讨论】：

好主意，但由于我们修补客户的方式和设置方式，这并不是一个真正的选择。

【解决方案6】：

试着运行程序怎么样。如果它不能运行，那么你就知道有问题了。

【讨论】：

【解决方案7】：

为什么不使用Archive::Zip package 进行压缩，完全不需要外部程序？

【讨论】：

这不是我们要求客户拥有的软件包，试图在他们所有的机器上安装它是徒劳的。相信我，这几乎是我唯一的选择，我需要找到一种方法让它发挥作用。
如果您已经要求他们拥有非默认软件包，那么要求这个有什么问题？

【解决方案8】：

如果你要这样做，有几件事需要考虑：

在列表形式中使用 system 和 exec，这样 shell 就没有机会解释特殊字符。
您可以将其存储为配置而不是将其放入代码中吗？例如，看看 CPAN.pm 是如何做到的。
你怎么知道你正在运行你认为你正在运行的东西？如果有人制作了一个同名的木马，你的程序会愉快地执行它吗？请注意，使用 PATH，如思南的 multi-which 中所述，仍然存在此问题，因为它依赖于用户设置 PATH。

【讨论】：

这绝对是一个很好的建议。我改变了对系统的调用以使用列表形式，因为我独立发现了同样的事情。我真的无法将它存储在任何配置中，因为我们只是没有适当的机制，而且不，没有办法知道我在运行什么。虽然我同意这可能是一个问题，但我们的应用程序运行的环境通常是非常受控和卫生的，因此木马或类似的东西在这里并不是一个真正的问题。