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

[Masklinn]

On 2012-02-24, at 12:12 , anatoly techtonik wrote:
> 
> 1. they require try/catch

No.

> 2. docs still refer Popen, which IS complicated

True.

> 3. contain shell FUD

No, they contain warnings, against shell injection security
risks. Warnings are not FUD, it's not trying to sell some sort
of alternative it's just warning that `shell=True` is dangerous
on untrusted input.

> 4. completely confuse users with stdout=PIPE or stderr=PIPE stuff
> 
> http://docs.python.org/library/subprocess.html#subprocess.check_call

On the one hand, these notes are a bit clumsy. On the other hand,
piping is a pretty fundamental concept of shell execution, I see
nothing wrong about saying that these functions *can't* be involved
in pipes. In fact stating it upfront looks sensible.

>> If you do "pip install shell-command" you can also access the
>> shell_call(), shell_check_call() and shell_output() functions I
>> currently plan to include in subprocess for 3.3. (I'm not sure which
>> versions of Python that module currently supports though - 2.7 and
>> 3.2, IIRC).
> 
> Don't you find strange that shell utils module don't have any
> functions for the main shell function - command execution?

What "shell utils" module? Subprocess has exactly that in `call`
and its variants. And "shutil" does not bill itself as a 
"shell utils" module right now, its description is
"High-level file operations".

> shutil.runret()  - by definition has shell=True

Great, so your recommendation is to be completely insecure by default?

> That's a high-level _user_ function. When user runs command in shell
> he sees both. So, this 'shell util' is an analogue.

That makes no sense, when users invoke shell commands programmatically
(which is what these APIs are about), they expect two semantically
different reporting streams to be split, not to be merged,
indistinguishable and unusable as a default. Dropping stderr on the
ground may be an acceptable default but munging stdout and stderr is not.

> The main purpose of this function is to be useful from Python console

Then I'm not sure it belongs in subprocess or shutil, and users with that
need should probably be driven towards iPython which provides extensive
means of calling into the system shell in interactive sessions[0].
bpython may also provide such facilities.

It *may* belong in the interactive interpreter's own namespace.

> 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').

As opposed to `check_output(command)`?

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

This assertion demonstrably does not match reality, shell injections
(the very reason for this warning) would not exist if this were the
case.

[0] http://ipython.org/ipython-doc/rel-0.12/interactive/reference.html#system-shell-access