Perl：什么时候使用 system() 以及什么时候安装软件包？
我工作的项目在由系统人员维护的机器上使用 Perl 脚本，安装 Perl 模块等软件包并不是一件容易的任务 - 您通常必须打电话给有权限的人来执行此操作，等待几天，了解包的 API，然后记住将其安装在每台新安装的配置机器上。
多次选择的替代方案是仅调用 system() （或 Perl 内部的反引号符号，``）并使用 shell 命令的输出来执行您想要的操作。想。当然，这并不总是可行，并且在使用时，通常需要对命令调用进行包装，但通常更容易。
我的问题是，根据您的经验，权衡何时会向任何一方倾斜？
编辑：添加示例： 我想以人类可读的格式打印目录的总大小，或者列出大于特定大小的所有常规文件，而 du 似乎比安装执行相同操作的模块更容易...
I work in a project that uses Perl scripts on machines that are maintained by system folks, and installing packages such as Perl modules is no easy task - you usually have to call the person with the permissions to do that, wait several days, learn the API of the package, and then remember to install it on every newly configured machine ever installed.
The alternative that is many times chosen is just calling system() (or backtick notation, ``, inside Perl) and using the output of the shell command that does what you want. Of course it's not always possible, and when it use, there is usually a wrapping to do around the command call, but it's generally easier.
My question is when is the trade-off pulling towards either side, in your experience?
Edit: adding an example:
I want to print the total size of a directory in a human-readable format, or list all regular files bigger than a certain size, and du seems to make this easier than installing modules that do the same thing...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
噢，这很简单。人们总是更喜欢模块，因为更紧密的集成使得可以传递不适合传统 IPC 的数据。
什么，您是否期望得到帮助来合理化您在蹩脚的系统管理下遭受的痛苦？
Oh, that's an easy one. One always prefers modules because the tighter integration makes it possible to pass around data that do not suit the traditional IPC.
What, did you expect help in rationalising your suffering under crappy sysadminship?
核心问题似乎是安装 Perl 模块的难度和时间长度。我会找出他们安装软件包时遇到问题的原因，并尝试帮助简化他们的流程。
常见的解决方案是修改您的流程。管理员通常不喜欢直接从 CPAN 安装，但作为开发人员，您可以使用本地 CPAN 存储库。您“冻结”在那里使用的包，然后将它们推广到生产中。
也就是说，使用模块或将其脱壳之间的权衡如下：
数据
模块通常返回结构化数据，脱壳返回必须解析的非结构化文本。
性能/资源使用
Shelling out会创建一个完整的其他进程，模块通常在当前操作进程中提供功能。
额外的依赖
Shelling out 会让你的程序依赖于你正在shelling 的任何东西。请记住，一些基本程序的输出和行为会随着操作系统的不同而发生变化，因此您也可能会将自己耦合到特定的操作系统或一组操作系统。
The core issue seems to be the perceived difficulty and length of time to install Perl modules. I would identify why they have problems installing the packages and try and help streamline their process.
A common solution is to modify your process. Admins don't typically like to install straight from CPAN, but as a developer you can use a local CPAN repo. You "freeze" the packages you use there, and then promote them for use in production.
That said the trade-off between using modules or shelling it out as follows:
Data
Modules typically return structured data, shelling out returns unstructured text that you have to parse.
Performance/Resource Usage
Shelling out creates a whole other process, modules usually provide functionality within the current operating process.
Additional Dependencies
Shelling out makes your program dependent on whatever you're shelling out to. Keep in mind that some basic programs change in output and behavior from OS to OS, so you may also be coupling yourself to a particular OS or set of OSes.
模块，永远是模块。而且，当我说总是时，我的意思是“几乎总是”。
模块更容易控制和调试。要求安装模块比安装一些不相关的实用程序更容易。使用模块比依赖特定命令的偶然命令行语法更便携。
Modules, always modules. And, when I say always, I mean "almost always."
Modules are easier to control and to debug. It's easier to require a module be installed than some unrelated utility. It's more portable to use a module than to rely on the chancy command line syntax of a particular command.
您有一个与核心发行版一起使用的一堆模块。只需使用它们即可。
您可以直接在主目录中安装模块，并在需要时与系统管理员协商： http://perl.jonallen.info/writing/articles/install-perl-modules-without-root
You have a bunch of modules that go with the core distro. Just use them.
You can install modules right in your home directory and when the time comes negotiate with the sysadmins: http://perl.jonallen.info/writing/articles/install-perl-modules-without-root
如上所述，始终是模块，因为
ls不是dir...As said above, always modules, because
lsain'tdir...