Each Answer to this Q is separated by one/two green lines.
I’ve been trying to understand for a while now what’s the difference between
subprocess.run. I know the last one is new on Python 3.5 and both are based on
subprocess.Popen, but I’m not able to understand the difference yet.
The definition of
subprocess.call() clearly mentions:
It is equivalent to:
(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.
.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:
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.
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.
subprocess.run(...) does not return from this, whereas
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
I also tried
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
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.