You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add subprocess.shell(cmd) function: similar to os.system(), but use subprocess #120952
I propose to add a subprocess.shell(cmd) function similar to os.system(), but use subprocess: close file descriptors, restore signal handlers, etc. The function runs a shell command and so is vulnerable by design to shell injection vulnerability if an attacker can modify the shell command.
The function accepts keyword arguments: subprocess.shell(cmd, env=env), subprocess.shell(cmd, stdout=subprocess.PIPE), etc.
This proposition is related to os.system() soft deprecation: #120744
I think that functools.partial definition is exactly all this should be (though lets make sure it does not allow shell=False to be passed - I don't recall off the top of my what functools.partial does in that situation).
Documentation wise it'd get listed in the subprocess docs aftersubprocess.run() with a one or two sentence description that it is just "run" with "shell=True" for convenience. With an example. And with the caveats of shell=True being re-stated.
Are we handing beginners a foot-shotgun by making shells (and all their quoting problems) easier to access? I like the explicit subprocess.run(..., shell=True) spelling, but maybe I've stockholm syndrome'd myself.
I think it has plenty of legitimate uses, which is why keeping os.system is important. But adding something new to support it is certainly endorsing its use. And it doesn't really have much of a place in production or library code, while it does have an important place in scripting.
It's being added here so we can soft deprecate it elsewhere. I'd rather just leave the original one in place without any kind of deprecation.
The benefit of this one is that it's subprocess backed with all that brings. I agree shell=True is not what I promote use of but if we recommend people skip over os.system in favor of something else, subprocess.shell might make a good gateway drug out of os land.
os.system is, as the os module is generally intended to be, a thin wrapper around the platform's libc or platform provided system() or _wsystem() C calls.
Reacted by Victor Stinner, Steve Dower and Barney Gale
Activity
zooba commentedon Jun 24, 2024
So essentially
shell = functools.partial(subprocess.run, shell=True)? That seems fine to me.gpshead commentedon Jun 24, 2024
I think that functools.partial definition is exactly all this should be (though lets make sure it does not allow
shell=Falseto be passed - I don't recall off the top of my what functools.partial does in that situation).Documentation wise it'd get listed in the subprocess docs after
subprocess.run()with a one or two sentence description that it is just "run" with "shell=True" for convenience. With an example. And with the caveats of shell=True being re-stated.barneygale commentedon Jun 24, 2024
Are we handing beginners a foot-shotgun by making shells (and all their quoting problems) easier to access? I like the explicit
subprocess.run(..., shell=True)spelling, but maybe I've stockholm syndrome'd myself.zooba commentedon Jun 24, 2024
Possibly.
I think it has plenty of legitimate uses, which is why keeping
os.systemis important. But adding something new to support it is certainly endorsing its use. And it doesn't really have much of a place in production or library code, while it does have an important place in scripting.It's being added here so we can soft deprecate it elsewhere. I'd rather just leave the original one in place without any kind of deprecation.
gpshead commentedon Jun 25, 2024
The benefit of this one is that it's
subprocessbacked with all that brings. I agree shell=True is not what I promote use of but if we recommend people skip overos.systemin favor of something else,subprocess.shellmight make a good gateway drug out ofosland.os.systemis, as theosmodule is generally intended to be, a thin wrapper around the platform's libc or platform providedsystem()or_wsystem()C calls.pythongh-120952: Add subprocess.shell() function
vstinner commentedon Aug 1, 2024
I failed to convince enough people, I prefer to abandon this function. Let's keep the status quo, os.system().