Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #33975 > unrolled thread
| Started by | Andrew <drew00andy@yahoo.co.uk> |
|---|---|
| First post | 2012-11-27 20:00 +0200 |
| Last post | 2012-11-30 10:01 -0800 |
| Articles | 5 — 5 participants |
Back to article view | Back to comp.lang.python
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
| From | Andrew <drew00andy@yahoo.co.uk> |
|---|---|
| Date | 2012-11-27 20:00 +0200 |
| Subject | os.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]
| From | Tim Roberts <timr@probo.com> |
|---|---|
| Date | 2012-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]
| From | Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> |
|---|---|
| Date | 2012-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]
| From | Nobody <nobody@nowhere.com> |
|---|---|
| Date | 2012-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]
| From | emile <emile@fenx.com> |
|---|---|
| Date | 2012-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