Python 的 subprocess.call 和 subprocess.run 之间的区别是什么

The definition of subprocess.call() clearly mentions:

It is equivalent to: run(...).returncode (except that the input and check parameters are not supported)

As the Python 3.5's subprocess document says:

Prior to Python 3.5, these three functions (i.e. .call(), .check_call(), .check_output()) comprised the high level API to subprocess. You can now use run() in many cases, but lots of existing code calls these functions.

It is a common practice that when some functions are replaced, they are not instantly deprecated but there is a support window for them for some versions. This helps in preventing the breakage of older code when the language version is upgraded. I do not know whether .call() is going to be replaced in the future or not. But based on the document, what I know is that they are pretty much same.

To make it clear for anyone wanting to know which to use:

subprocess.run() is the recommended approach for all use cases it can handle. The suprocess documentation states:

The recommended approach to invoking subprocesses is to use the run() function for all use cases it can handle. For more advanced use cases, the underlying Popen interface can be used directly.

subprocess.call() is part of the Older high-level API (Prior to Python 3.5).

I'm not sure I agree with the other answers.

I just had a very frustrating time with a bash script which starts a daemon process (Elasticsearch). The command merely supplies the path to the executable Bash script.

But subprocess.run(...) does not return from this, whereas subprocess.call(...) does.

From my experience, if you then stop the process (e.g. the Terminal if running from a Terminal) using subprocess.run(...) this kills off the daemon process started in it. But this is not the case with subprocess.call(...): the daemon carries on happily.

In both cases I set the kwarg shell=True.

I also tried subprocess.run ẁith shell=False (i.e. default if you omit shell): no change.

I can't see any other possible options in subprocess.run which might overcome this, so it appears, as far as I can tell that subprocess.call is fundamentally different, despite what the docs appear to say. At the time of writing the docs say "You can now use run() in many cases, but lots of existing code calls these functions." (i.e. the older functions, including call).

What is particularly strange, and frustrating, is that (obviously) when you run a script which starts a daemon, such as:

./bin/elasticsearch -d -p pid

... it just returns and you can close the Terminal quite happily. So there appears something quite odd about subprocess.run, which some super-expert might care to explain.

I am not fully clear on the differences either.

I can say that you use subprocess.call() when you want the program to wait for the process to complete before moving onto the next process. In the case of subprocess.run(), the program will attempt to run all the processes at once, inevitably causing the program to crash.