在Perl中使用系统命令而不是内置库/函数

Question

有时我看到人们从Perl（以及其他脚本语言）调用系统grep，而不是使用内置的语言工具/库来解析文件。我想鼓励人们使用内置设施，我想征求一些原因，说明为什么使用内置工具是一种好习惯。我可以想到一些如

• 使用库/语言设施更快。由于执行外部命令的开销，性能会受到影响。
• 坚持语言设施更便携。

任何其他原因？

另一方面，有没有理由支持使用系统命令而不是内置语言设施？在这方面，如果Perl脚本基本上只调用外部命令（例如没有库的自定义实用程序），那么创建它的shell脚本可能更好吗？

Answer 1

实际上，重要的是，专业工具可以更快。

保持Perl工作的真正好处是：

• 可移植性（即使在具有相同操作系统的计算机之间）。
• 易于检测错误。
• 处理错误的灵活性。
• 更高的可定制性/灵活性。
• 更少“活动部件”。 （你确定你正确地逃脱了所有事情并正确设置了环境吗？）
• 需要的专业知识减少。 （您不需要知道Perl和外部工具（及其端口）来编写和维护程序。）

---

  

就此而言，如果Perl脚本基本上只调用外部命令（例如没有库的自定义实用程序），那么创建它的shell脚本可能更好吗？

可能。如果任何程序返回不成功的错误代码，您可以配置一些shell退出。这可以使一些脚本非常健壮。例如，我有一些bash脚本，其中包含

行

trap 'e=$? ; echo "Error." ; exit $e' ERR

Answer 2

“硬币的另一面，是否有理由支持使用系统命令而不是内置语言工具？请注意，如果Perl脚本基本上只调用外部命令（例如，没有库的自定义实用程序） ），制作一个shell脚本可能会更好吗？“

在这里冒着Perl强硬派的愤怒。但对我来说，有一个简单的理由使用系统grep而不是perl grep：我知道它的语法。

使用Perl脚本而不是bash脚本的原因相同：我知道如何在Perl中执行操作并且从不打扰bash脚本语法。

正如我们在这里讨论脚本一样，我主要担心的是快速可靠（可读）。在工作中，我不必担心可移植性，因为所有生产都在同一个系统上完成，直到整个产品生命周期的所有产品的相同软件版本。

在家里，我不必关心一生或其他什么，因为剧本最有可能是单一目的。

在这两种情况下，我都不关心性能或软件安全性，因为我会使用C ++或其他东西来处理商业软件或时间或内存有限的情况。

编辑：不说这些理由适用于任何人，甚至任何其他人。但实际上我知道如何使用Perls grep，我真的不知道如何编写bash脚本，而且很可能永远不会。在Perl中添加几行对我来说总是更快。

Answer 3

使用外部工具会导致更多错误。 此外，您需要解析外部命令的结果（如果有的话），这是另一个错误来源。 没必要说它在安全性方面是不好的。