Sanitising arguments to shell commands

Ben Finney ben+python at benfinney.id.au
Fri Aug 21 06:18:29 EDT 2009


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

-- 
 \     “Welchen Teil von ‘Gestalt’ verstehen Sie nicht?  [What part of |
  `\                ‘gestalt’ don't you understand?]” —Karsten M. Self |
_o__)                                                                  |
Ben Finney



More information about the Python-list mailing list