[Python-ideas] shutil.runret and shutil.runout

[anatoly techtonik]

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>
> wrote:
>>
>> 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.

-- 
anatoly t.