Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #33975 > unrolled thread

os.popen and the subprocess module

Started byAndrew <drew00andy@yahoo.co.uk>
First post2012-11-27 20:00 +0200
Last post2012-11-30 10:01 -0800
Articles 5 — 5 participants

Back to article view | Back to comp.lang.python


Contents

  os.popen and the subprocess module Andrew <drew00andy@yahoo.co.uk> - 2012-11-27 20:00 +0200
    Re: os.popen and the subprocess module Tim Roberts <timr@probo.com> - 2012-11-28 20:14 -0800
    Re: os.popen and the subprocess module Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2012-11-29 10:09 +0100
      Re: os.popen and the subprocess module Nobody <nobody@nowhere.com> - 2012-11-29 18:39 +0000
        Re: os.popen and the subprocess module emile <emile@fenx.com> - 2012-11-30 10:01 -0800

#33975 — os.popen and the subprocess module

FromAndrew <drew00andy@yahoo.co.uk>
Date2012-11-27 20:00 +0200
Subjectos.popen and the subprocess module
Message-ID<mailman.316.1354039468.29569.python-list@python.org>
Hello world,

I'm working on a script that will run an executable obtaine the output  
 from the executable
and do some analysis on the output. Essentially the script runs the  
executable analyses
the data.
I'm looking into os.popen and the subprocess module, implementing os.popen  
is easy but i hear
it is depreciating  however I'm finding the implemantation of subprocess  
daunting can anyone help

Dx
-- 
守破離(shuhari)first learn, then detach, and finally transcend

[toc] | [next] | [standalone]


#34048

FromTim Roberts <timr@probo.com>
Date2012-11-28 20:14 -0800
Message-ID<n5odb8h1ku0h56tun39uiqa8lm43rv3gqp@4ax.com>
In reply to#33975
Andrew <drew00andy@yahoo.co.uk> wrote:
>
>I'm working on a script that will run an executable obtaine the output  
> from the executable
>and do some analysis on the output. Essentially the script runs the  
>executable analyses
>the data.
>I'm looking into os.popen and the subprocess module, implementing os.popen  
>is easy but i hear
>it is depreciating  however I'm finding the implemantation of subprocess  
>daunting can anyone help

One of my favorite things about the subprocess module is that the
introductory comments have examples of how to use subprocess to replace
almost every use case for os.system and os.popen.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

[toc] | [prev] | [next] | [standalone]


#34055

FromThomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de>
Date2012-11-29 10:09 +0100
Message-ID<k978ot$b04$1@r03.glglgl.gl>
In reply to#33975
Am 27.11.2012 19:00 schrieb Andrew:

> I'm looking into os.popen and the subprocess module, implementing
> os.popen is easy but i hear it is depreciating however I'm finding the
> implemantation of subprocess daunting can anyone help

This is only the first impression.

subprocess is much more powerful, but you don't need to use the full power.

For just executing and reading the data, you do not need much.

First step: create your object and performing the call:

sp = subprocess.Popen(['program', 'arg1', 'arg2'], stdout=subprocess.PIPE)

or

sp = subprocess.Popen('program arg1 arg2', shell=True, 
stdout=subprocess.PIPE)


The variant with shell=True is more os.popen()-like, but has security 
flaws (e.g., what happens if there are spaces or, even worse, ";"s in 
the command string?


Second step: Obtain output.

Here you either can do

     stdout, stderr = sp.communicate()

can be used if the whole output fits into memory at once or you really 
have to deal with stderr or stdin additionally.

In other, simpler cases, it is possible to read from sp.stdout like from 
a file (with a for loop, with .read() or whatever you like).


Third step: Getting the status, terminating the process.

And if you have read the whole output, you do status = sp.wait() in 
order not to have a zombie process in your process table and to obtain 
the process status.


Thomas

[toc] | [prev] | [next] | [standalone]


#34075

FromNobody <nobody@nowhere.com>
Date2012-11-29 18:39 +0000
Message-ID<pan.2012.11.29.18.39.14.718000@nowhere.com>
In reply to#34055
On Thu, 29 Nov 2012 10:09:44 +0100, Thomas Rachel wrote:

> The variant with shell=True is more os.popen()-like, but has security
> flaws (e.g., what happens if there are spaces or, even worse, ";"s in the
> command string?

I think that you're conflating the shell= option with whether the command
is a given as a list or a string.

Attempting to construct a command string risks introducing security flaws
(or other bugs). Wherever possible, the first argument should be a list. A
string should only be used if that's what you're given (e.g. via a
configuration file), in which case it should be used literally, without
any attempt to substitute filenames or other parameters.

On Windows, list-versus-string and shell= are orthogonal. A list will
always be converted to a string, as that's what the underlying
CreateProcess() function requires. shell=True prepends "cmd /c " ("cmd" is
replaced by the value of %comspec% if that is defined); this allows
execution of batch files, scripts, etc based upon their associations.

On Unix, passing a list with shell=True is rarely useful. It just prepends
['/bin/sh', '-c'] to the list, so the first item is the shell command
while subsequent items provide the values for the shell variables $1, $2,
etc.

[toc] | [prev] | [next] | [standalone]


#34102

Fromemile <emile@fenx.com>
Date2012-11-30 10:01 -0800
Message-ID<mailman.387.1354298509.29569.python-list@python.org>
In reply to#34075
On 11/29/2012 10:39 AM, Nobody wrote:

<aside>

Every time I see your posts "Shanghai Noodle Factory" sticks in my head 
as my daily hummer.  :)

</aside>


[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web