[Python-ideas] shutil.runret and shutil.runout
techtonik at gmail.com
Fri Feb 24 12:23:57 CET 2012
On Fri, Feb 24, 2012 at 2:10 PM, Tarek Ziadé <ziade.tarek at gmail.com> wrote:
> On Fri, Feb 24, 2012 at 11:52 AM, anatoly techtonik <techtonik at gmail.com>
>> subprocess is low level, cryptic, does too much, with poor usability,
>> i.e. "don't make me think" is not about it. I don't know about you,
>> but I can hardly write any subprocess call without spending at least
>> 5-10 meditating over the documentation. So, I propose two high level
>> KISS functions for shell utils (shutil) module:
>> runret(command) - run command through shell, return ret code
> mmm you are describing subprocess.call() here... I don't see how this new
> command makes thing better, besides shell=True.
shutil.runret() - by definition has shell=True
>> runout(command) - run command through shell, return output
> what is 'output' ? the stderr ? the stdout ? a merge of both ?
That's a high-level _user_ function. When user runs command in shell
he sees both. So, this 'shell util' is an analogue. If you have you
own user scripts that require stdout or stderr separately, I am free
to discuss the cases. The main purpose of this function is to be
useful from Python console, so the interface should be very simple to
remember from the first try. Like runout(command,
ret='stdout|stderr|both'). No universal PIPEs.
> what about subprocess.check_output() ?
See my reply above.
>> To avoid subprocess story (that makes Python too complicated)
> I seems to me that the only complication here is shell=True, which seems ok
> to me to have it at False for security reasons.
It won't be 'shell util' function anymore. If you're using shell
execution functions, you already realize that will happen if your
input parameters are not validated properly. Isolating calls that
require shell execution in shutil module will also simplify security
analysis for 3rd party libraries.
More information about the Python-ideas