在python中使用子进程或rpc/rest与另一个程序通信？
我有一个情况，有一个用 C++ 编写的程序。它是一种您需要首先启动的服务器。然后，您可以从另一个控制台调用传递命令行参数的程序，它会执行一些操作。它还提供基于 rpc 和 Rest 的访问。因此，您可以编写一个基于 rpc 或 Rest 的库来与服务器交互。
所以我的问题是，既然可以仅使用命令行参数来管理程序，那么使用 python 的子进程模块并围绕它构建一个库（包装器）不是更好吗？或者这个方法有什么问题吗？
考虑另一个例子。假设我想围绕 grep 等任何 Linux 实用程序构建一个 GUI，它允许用户测试正则表达式（就像我们在网站上那样）。那么使用 subprocess 与 grep 通信不是更容易吗？
谢谢。
I have a situation where there is a program which is written in c++. It is a kind of a server which you need to start first. Then from another konsole you can call the program passing commandline arguments and it does stuff. Also it provides rpc and rest based access. So you can write a rpc or rest based library to interface with the server.
So my question is, since the program can be managed using mere commandline arguments, isn't it better to use python's subprocess module and build a library (wrapper) around it? Or is there any problem with this method?
Consider another case. Say I wanted to build a GUI around any linux utility like grep which allows user to test regular expressions (like we have on websites). So isn't it easier to communicate to grep using subprocess?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想我更喜欢使用任何 rpc 或 Rest 接口，因为您可以从它们获得的结果通常采用易于解析的格式，因为这些接口是为机器交互而设计的。然而，命令行界面是为人机交互而设计的，这意味着输出很容易被人眼解析，但不一定由接收输出的另一个程序解析。
I think I'd prefer to use any of the rpc or rest interfaces, because the results you can obtain from them are usually in a format that is easy to parse since those interfaces have been designed for machine interaction. However, a command line interface is designed for human interaction and this means that the output is easy to parse for the human eye, but not necessarily by another program that receives the output.