And*_*zco 33 python subprocess
我一直试图了解一段时间,现在subprocess.call和之间的区别是什么subprocess.run.我知道最后一个是Python 3.5上的新内容,两者都基于subprocess.Popen,但我还不能理解其中的差异.
Moi*_*dri 31
subprocess.call()明确提到的定义:
它相当于:(
run(...).returncode除了不支持输入和检查参数)
正如Python 3.5的子流程文档所说:
之前的Python 3.5,这三个功能(即
.call(),.check_call(),.check_output())包含高水平的API子进程.您现在可以run()在许多情况下使用,但许多现有代码会调用这些函数.
通常的做法是,当某些功能被替换时,它们不会立即被弃用,但对于某些版本,它们有一个支持窗口.这有助于防止升级语言版本时旧代码的破坏.我不知道.call()将来是否会被替换.但根据文件,我所知道的是它们几乎相同.
mau*_*era 11
为了让任何想知道使用哪个的人都清楚：
subprocess.run()是它可以处理的所有用例的推荐方法。该suprocess文档状态：
调用子进程的推荐方法是将 run() 函数用于它可以处理的所有用例。对于更高级的用例，可以直接使用底层的 Popen 接口。
subprocess.call()是Older 高级 API（Python 3.5 之前）的一部分。
我不确定我是否同意其他答案。
\n我刚刚使用启动守护进程（Elasticsearch）的 bash 脚本度过了一段非常令人沮丧的时光。该命令仅提供可执行 Bash 脚本的路径。
\n但subprocess.run(...)不会从此返回，而subprocess.call(...)会返回。
根据我的经验，如果您随后停止该进程（例如，如果从终端运行则为终端），则使用subprocess.run(...)此命令会终止其中启动的守护进程。但情况并非如此subprocess.call(...)：守护进程愉快地继续运行。
在这两种情况下我都设置了 kwarg shell=True。
我还尝试了subprocess.run\xe1\xba\x81ith shell=False（即如果省略则默认shell）：没有变化。
我看不到任何其他可能的选项subprocess.run可以克服这个问题，所以据我所知，无论subprocess.call文档似乎怎么说，这似乎都是根本不同的。在撰写本文时，文档说“您现在可以在许多情况下使用 run()，但许多现有代码都会调用这些函数。” （即旧函数，包括call）。
特别奇怪且令人沮丧的是，（显然）当您运行启动守护程序的脚本时，例如：
\n./bin/elasticsearch -d -p pid\n...它刚刚返回，您可以非常愉快地关闭终端。因此，似乎有一些非常奇怪的事情subprocess.run，一些超级专家可能会愿意解释一下。