Sanitising arguments to shell commands

[Jean-Michel Pichavant]

Ben Finney wrote:
> Jean-Michel Pichavant <jeanmichel at sequans.com> writes:
>
>   
>> Can someone explain the difference with the shell argument ? giving
>> for instance an example of what True will do that False won't.
>>     
>
> The ‘shell’ argument to the ‘subprocess.Popen’ constructor specifies
> whether the command-line should be invoked directly (‘shell=False’) or
> indirectly through invoking a shell (‘shell=True’).
>
> If ‘shell=False’, the command-line arguments are used as direct
> arguments to the kernel's “run this program for me”.
>
> If ‘shell=True’ the command-line arguments are themselves passed to a
> new instance of the user's current shell, as a command line that *it*
> should invoke on the program's behalf. This allows the command line to
> be manipulated and interpolated etc., the way it would be if typed at a
> new shell prompt. Then, that shell will in turn ask the kernel “run this
> program for me” as it normally does after processing the arguments.
>
>   
>> I mean, I've read the doc, and to be honest, I didn't get it. I'm
>> concerned because I'm using subprocess, but I guess my shell arg has
>> been filled a little bit random..
>>     
>
> Use ‘shell=False’ by default (which, since that's the default for
> ‘subprocess.Popen’, means you can omit it entirely), and specify exactly
> the command line arguments you want the kernel to execute. Only if you
> know you want a shell process to be involved should you use
> ‘shell=True’.
>
>   
Thank you Ben for the update. It's clear for me now, I've checked and I 
use it with no shell arg, except at one place, but I don't think it's 
intended and it happens to work anyway. I've added a small comment just 
in case it fails in the future.

JM