我在一个项目中工作，该项目在由系统人员维护的机器上使用Perl脚本，并且安装诸如Perl模块之类的软件包并不是一件容易的事情 - 您通常需要调用具有权限的人来执行此操作，等待几天，了解该软件包的API，然后记住在每个新安装的计算机上安装它。
选择多次的替代方法是在Perl中调用system()（或反引号符号，``）并使用执行所需操作的shell命令的输出。当然，它并不总是可能的，当它使用时，通常会在命令调用周围进行包装，但通常更容易。
我的问题是，根据你的经验，在任何一方都需要权衡利弊？
编辑：添加示例：
我想以人类可读的格式打印目录的总大小，或列出大于特定大小的所有常规文件，du似乎比安装执行相同操作的模块更容易...
答案 0 :(得分：7)
哦，这很简单。人们总是喜欢模块，因为更紧密的集成可以传递不适合传统IPC的数据。
什么，你期望在糟糕的系统管理下帮助你理解你的痛苦吗？
答案 1 :(得分：2)
模块，总是模块。而且，当我总是说，我的意思是“几乎总是。”
模块更易于控制和调试。与某些不相关的实用程序相比，要求安装模块更容易。使用模块比依赖特定命令的chancy命令行语法更容易。
答案 2 :(得分：2)
你有核心发行版的bunch of modules。只需使用它们。
您可以直接在主目录中安装模块，并在时间到来时与系统管理员协商：http://perl.jonallen.info/writing/articles/install-perl-modules-without-root
答案 3 :(得分：2)
核心问题似乎是安装Perl模块的难度和时间长度。我会找出为什么他们在安装软件包时遇到问题并尝试帮助简化他们的流程。
常见的解决方案是修改您的流程。管理员通常不喜欢直接从CPAN安装，但作为开发人员，您可以使用本地CPAN仓库。您“冻结”您在那里使用的包，然后将它们推广用于生产。
那就是说使用模块之间的权衡还是如下所示：
数据
模块通常返回结构化数据，shelling out返回您必须解析的非结构化文本。
效果/资源使用
Shelling out创建了一个完整的其他过程，模块通常在当前操作过程中提供功能。
其他依赖性
脱离使你的程序依赖于你正在炮轰的任何东西。请记住，一些基本程序会在操作系统和操作系统之间改变输出和行为，因此您也可能将自己耦合到特定操作系统或操作系统集。
答案 4 :(得分：1)
如上所述，始终是模块，因为ls不是dir ...