Perl：您何时使用 system() 以及何时安装软件包？答案

【问题标题】：Perl: when do you use system() and when do you install the package?Perl：您何时使用 system() 以及何时安装软件包？
【发布时间】：2010-12-28 09:40:49
【问题描述】：

我在一个项目中工作，该项目在由系统人员维护的机器上使用 Perl 脚本，安装 Perl 模块等软件包并非易事 - 您通常必须致电具有权限的人员，等待几天，了解包的 API，然后记得将它安装在每台新安装的机器上。

多次选择的替代方法是调用system()（或反引号，``，在 Perl 中）并使用 shell 命令的输出来执行您想要的操作。当然这并不总是可行的，而且在使用时，通常需要对命令调用进行包装，但通常更容易。

我的问题是，根据您的经验，权衡何时会偏向任何一方？

编辑：添加示例：我想以人类可读的格式打印目录的总大小，或者列出所有大于特定大小的常规文件，du 似乎比安装执行相同操作的模块更容易...

【问题讨论】：

标签： perl perl-module

【解决方案1】：

哦，这很简单。人们总是更喜欢模块，因为更紧密的集成使得传递不适合传统 IPC 的数据成为可能。

什么，你是否期望帮助你合理化你在糟糕的系统管理下的痛苦？

【讨论】：

另外，您可以将模块安装到非默认目录中，因此您不需要调用具有特殊权限的任何人。
虽然我总是更喜欢使用模块而不是“脱壳”，但我听说过一个类似这样的反论点：因为 Perl 不保证释放变量占用的内存，即使它消失了超出范围，有时最好（例如，在长期运行的持久性 Web 应用程序进程中）将任务分配给在单独进程中调用的外部命令，从而不会增加主进程的内存占用。由于分叉的开销，它的效率可能会稍低一些，但是一旦完成，操作系统就会回收子进程的内存。

【解决方案2】：

核心问题似乎是安装 Perl 模块的难度和时间长度。我会找出他们在安装软件包时遇到问题的原因，并尝试帮助简化他们的流程。

一个常见的解决方案是修改您的流程。管理员通常不喜欢直接从 CPAN 安装，但作为开发人员，您可以使用本地 CPAN 存储库。您“冻结”在那里使用的包，然后将它们推广到生产环境中使用。

这就是说使用模块或外壳之间的权衡如下：

数据

模块通常返回结构化数据，脱壳返回您必须解析的非结构化文本。

性能/资源使用情况

脱壳创建一个完整的其他流程，模块通常在当前操作流程中提供功能。

额外的依赖

脱壳使您的程序依赖于您要脱壳的任何东西。请记住，一些基本程序的输出和行为会因操作系统而异，因此您也可能将自己与特定操作系统或一组操作系统耦合。

【讨论】：

【解决方案3】：

模块，总是模块。而且，当我说总是时，我的意思是“几乎总是”。

模块更易于控制和调试。要求安装模块比一些不相关的实用程序更容易。使用模块比依赖特定命令的随机命令行语法更具可移植性。

【讨论】：

您认为隐藏在这个“几乎”中的异常是什么？这是我的问题。
例外情况是，当模块不如实用程序好或出于某些环境、程序或性能原因，命令行版本更好。这种情况很少见。

【解决方案4】：

您有一个 bunch of modules 与核心发行版一起使用。只需使用它们。

您可以直接在您的主目录中安装模块，到时候与系统管理员协商：http://perl.jonallen.info/writing/articles/install-perl-modules-without-root

【讨论】：

太好了，感谢您的链接！那么，这比我想象的要容易。
作为系统管理员，我绝不允许在生产环境中使用安装在主目录中的 perl 模块。这是糟糕的生产系统管理。
当然我不会在我的主目录中使用它进行生产 - 只是在系统管理员安装模块之前。

【解决方案5】：

如上所述，总是模块，因为ls 不是dir...

【讨论】：