Possible Duplicate:
Calling an external command in Python可能的重复:在Python中调用外部命令
I'm building a web application that will is going to manipulate (pad, mix, merge etc) sound files and I've found that sox does exactly what I want. Sox is a linux command line program and I'm feeling a little uncomfortable with having the python web app starting new sox processes on my server on a per request basis.
我正在构建一个web应用程序，它将操作(pad、mix、merge等)声音文件，我发现sox完全符合我的要求。Sox是一个linux命令行程序，我对让python web应用程序根据每个请求在我的服务器上启动新的Sox进程感到有点不舒服。
Example:
例子:
import os
os.system('sox input.wav -b 24 output.aiff rate -v -L -b 90 48k')
This whole setup seems a little unstable to me.
我觉得这整个计划有点不稳定。
So my question is, what's the best practice for running command line programs from within a python (or any scripting language) web app?
我的问题是，在python(或任何脚本语言)web应用程序中运行命令行程序的最佳实践是什么?
Message queues would be one thing to implement in order to get around the whole request response cycle. But is there other ways to make these things more elegant?
为了绕过整个请求响应周期，消息队列是需要实现的一件事。但是，还有其他方法可以让这些东西更优雅吗?
5 个解决方案
#1
163
The subprocess module is the preferred way of running other programs from Python -- much more flexible and nicer to use than os.system.
子进程模块是运行其他Python程序的首选方式——比os.system灵活得多，使用起来也更好。
import subprocess
#subprocess.check_output(['ls','-l']) #all that is technically needed...
print subprocess.check_output(['ls','-l'])
#2
19
"This whole setup seems a little unstable to me."
“整个计划在我看来有点不稳定。”
Talk to the ffmpegx folks about having a GUI front-end over a command-line backend. It doesn't seem to bother them.
请与ffmpegx人员讨论通过命令行后端拥有GUI前端。他们似乎并不介意。
Indeed, I submit that a GUI (or web) front-end over a command-line backend is actually more stable, since you have a very, very clean interface between GUI and command. The command can evolve at a different pace from the web, as long as the command-line options are compatible, you have no possibility of breakage.
实际上，我认为一个GUI(或web)前端的命令行后端实际上更稳定，因为您在GUI和命令之间有一个非常非常干净的接口。命令可以以不同的速度从web演进，只要命令行选项是兼容的，您就不可能有破损。
#3
3
I'm feeling a little uncomfortable with having the python web app starting new sox processes on my server on a per request basis.
让python web应用程序根据每个请求在我的服务器上启动新的sox进程，我感到有点不舒服。
To me this seems to mean that he fears that, if he opens up his webserver to the public, that there's not a lot he can do to prevent his server resources from being consumed if 15.000 people decide to click on that button that will launch sox in this way.
对我来说,这似乎意味着他担心,如果他打开了网络服务器,没有很多他可以做,以防止他的服务器资源消耗如果15.000人决定点击这个按钮,将启动袜。
#4
3
If you're concerned about server performance then look at capping the number of running sox processes. If the cap has been hit you can always cache the request and inform the user when it's finished in whichever way suits your application.
如果您关心服务器性能，那么请考虑限制运行sox进程的数量。如果上限已被命中，您可以始终缓存请求，并以适合您的应用程序的任何方式通知用户请求何时完成。
Alternatively, have the n worker scripts on other machines that pull requests from the db and call sox, and then push the resulting output file to where it needs to be.
或者，让其他机器上的n个worker脚本从db中提取请求并调用sox，然后将输出文件推到需要的位置。
#5
2
I am not familiar with sox, but instead of making repeated calls to the program as a command line, is it possible to set it up as a service and connect to it for requests? You can take a look at the connection interface such as sqlite for inspiration.
我不熟悉sox，但是不像命令行那样反复调用程序，是否可以将它设置为服务并连接到它以请求?您可以查看连接接口，如sqlite以获得灵感。
#1
163
The subprocess module is the preferred way of running other programs from Python -- much more flexible and nicer to use than os.system.
子进程模块是运行其他Python程序的首选方式——比os.system灵活得多，使用起来也更好。
import subprocess
#subprocess.check_output(['ls','-l']) #all that is technically needed...
print subprocess.check_output(['ls','-l'])
#2
19
"This whole setup seems a little unstable to me."
“整个计划在我看来有点不稳定。”
Talk to the ffmpegx folks about having a GUI front-end over a command-line backend. It doesn't seem to bother them.
请与ffmpegx人员讨论通过命令行后端拥有GUI前端。他们似乎并不介意。
Indeed, I submit that a GUI (or web) front-end over a command-line backend is actually more stable, since you have a very, very clean interface between GUI and command. The command can evolve at a different pace from the web, as long as the command-line options are compatible, you have no possibility of breakage.
实际上，我认为一个GUI(或web)前端的命令行后端实际上更稳定，因为您在GUI和命令之间有一个非常非常干净的接口。命令可以以不同的速度从web演进，只要命令行选项是兼容的，您就不可能有破损。
#3
3
I'm feeling a little uncomfortable with having the python web app starting new sox processes on my server on a per request basis.
让python web应用程序根据每个请求在我的服务器上启动新的sox进程，我感到有点不舒服。
To me this seems to mean that he fears that, if he opens up his webserver to the public, that there's not a lot he can do to prevent his server resources from being consumed if 15.000 people decide to click on that button that will launch sox in this way.
对我来说,这似乎意味着他担心,如果他打开了网络服务器,没有很多他可以做,以防止他的服务器资源消耗如果15.000人决定点击这个按钮,将启动袜。
#4
3
If you're concerned about server performance then look at capping the number of running sox processes. If the cap has been hit you can always cache the request and inform the user when it's finished in whichever way suits your application.
如果您关心服务器性能，那么请考虑限制运行sox进程的数量。如果上限已被命中，您可以始终缓存请求，并以适合您的应用程序的任何方式通知用户请求何时完成。
Alternatively, have the n worker scripts on other machines that pull requests from the db and call sox, and then push the resulting output file to where it needs to be.
或者，让其他机器上的n个worker脚本从db中提取请求并调用sox，然后将输出文件推到需要的位置。
#5
2
I am not familiar with sox, but instead of making repeated calls to the program as a command line, is it possible to set it up as a service and connect to it for requests? You can take a look at the connection interface such as sqlite for inspiration.
我不熟悉sox，但是不像命令行那样反复调用程序，是否可以将它设置为服务并连接到它以请求?您可以查看连接接口，如sqlite以获得灵感。