Python程序作为其他Unix程序的包装器和过滤器

有时我会遇到这样的情况，比如使用smartctl的JSON输出，我想用一个Python程序来处理和转换另一个Unix命令的输出。在这样的情况下，有两种方法来组织事情。我可以让Python程序作为一个子进程运行另一个命令，捕获它的输出并进行处理，或者我可以让一个周围的脚本运行另一个命令并把它的输出输送给Python程序，而Python程序则充当一个(Unix)过滤器。根据情况unix命令行，我已经用两种方法编写了程序。

这就引出了一个问题，即什么样的情况会让我选择一种方案或另一种方案？选择包装器方法的一个原因是容易复制结果的地方；Python包装器只是一个独立的东西，可以复制到我们的系统中，而运行Python过滤器的shell脚本至少是两个东西（然后shell脚本必须知道在哪里可以找到Python程序）。而且一般来说，Python包装程序使整个事情感觉有更少的活动部分（它运行另一个Unix命令作为程序的起点是一种实现细节，人们不必考虑）。

(包装器的自包含特性促使我对那些我希望在 "需要时 "才复制到系统中的东西使用包装器，而不是将它们作为系统设置的一部分来安装）。

我采用过滤器方法的一个原因是，如果我有一定量的逻辑，最容易用shell脚本来表达，例如选择哪些磁盘来报告SMART数据，然后在这些磁盘上进行迭代。Shell脚本使扩展文件名glob模式变得非常容易；Python则需要为此做更多的工作。我不得不承认，这个想法是如何演变的也起了作用；如果我一开始认为我有一个简单的重新格式化输出的工作可以完全在shell脚本中完成，那么我最有可能把Python写成一个落入其中的过滤器，而不是把shell脚本扔掉，写一个Python包装器。 从一开始就明显复杂的事情，更有可能是一个Python包装器，而不是一个由shell脚本使用的过滤器。

(这一点的推论是，如果我用或多或少不变的参数运行一次其他命令，我更有可能写一个包装程序而不是一个过滤器)。

我相信有一些（第三方）Python包，旨在使在Python中编写类似shell脚本的东西变得容易（我想我甚至曾经被指点过一次，尽管我现在找不到参考资料）。 理论上，我可以使用这些和本地的Python设施来编写更多的Python程序作为包装；实际上，我可能会采取阻力最小的方法，继续用Python程序作为过滤器来做各种事情的shell脚本。

我不知道写这篇文章是否会让我更系统、更自觉地在包装器和过滤器之间做出这种选择，但我可以希望如此。

PS: 这个选择的另一个方面是，通过改变脚本顶部的注释环境变量来调整shell脚本的设置，感觉比在Python程序中对全局变量做相应的改变更容易（也更出名）。我怀疑这主要是一个文化问题；如果我们更喜欢Python，对Python程序这样做可能会感觉完全自然（而且我们会有很多经验）。

（编辑：南京站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!