469,287 Members | 2,553 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,287 developers. It's quick & easy.

os.popen

When using os.popen, at what point is the process actually started? Take
the example below... would the first or second line actually execute the
command? If it's the first line, then why would I want to use the second
line at all unless I wanted to see on the console what happened?

ping = os.popen('sh ./ping.sh')
ping.read()
ping.close()

Jul 18 '05 #1
6 15732
P
Bart Nessux wrote:
When using os.popen, at what point is the process actually started? Take
the example below... would the first or second line actually execute the
command? If it's the first line, then why would I want to use the second
line at all unless I wanted to see on the console what happened?

ping = os.popen('sh ./ping.sh')
this will run until the buffer between the ping process and the python
app is full. This is 4k under linux. Then the ping process will block
until data is read as there is no where to put it's output.
ping.read()
This will read what's currently in the buffer between the processes.
You will need to do this in a loop.

alternatively if you don't care about the output then you
can throw it away, and hence remove the need for the ping.read() like:

ping = os.popen("sh ./ping.sh > /dev/null")
ping.close()


This will wait for the ping process to finish.

To tell it to finish you will need to do something like:
ping = popen2.Popen3("sh ./ping.sh > /dev/null")
os.kill(ping.pid, signal.SIGTERM)
ping.wait()

--
Pádraig Brady - http://www.pixelbeat.org

Jul 18 '05 #2
In article <40**************@draigBrady.com>, <P@draigBrady.com> wrote:
Bart Nessux wrote:
When using os.popen, at what point is the process actually started? Take
the example below... would the first or second line actually execute the
command? If it's the first line, then why would I want to use the second
line at all unless I wanted to see on the console what happened?

ping = os.popen('sh ./ping.sh')


this will run until the buffer between the ping process and the python
app is full. This is 4k under linux. Then the ping process will block
until data is read as there is no where to put it's output.
ping.read()


This will read what's currently in the buffer between the processes.
You will need to do this in a loop.

alternatively if you don't care about the output then you
can throw it away, and hence remove the need for the ping.read() like:

ping = os.popen("sh ./ping.sh > /dev/null")
ping.close()


This will wait for the ping process to finish.

To tell it to finish you will need to do something like:
ping = popen2.Popen3("sh ./ping.sh > /dev/null")
os.kill(ping.pid, signal.SIGTERM)
ping.wait()

Jul 18 '05 #3
P
Cameron Laird wrote:
1. Why
sh ./ping.sh ...
rather than
./ping.sh ...
?
Maybe he didn't make ping.sh executable for some reason.
Not relevant to this discussion.
2. For more typical processes that launch and run to
completion, yes, to the best of my knowledge, it
*is* feasible to simplify
op = os.popen(command)
op.read()
op.close()
to just
op = os.popen(command)
op.close()


iff the command doesn't fill the buffer.
If it does then it will not run to completion.

--
Pádraig Brady - http://www.pixelbeat.org

Jul 18 '05 #4
P@draigBrady.com wrote:
Bart Nessux wrote:
When using os.popen, at what point is the process actually started?
Take the example below... would the first or second line actually
execute the command? If it's the first line, then why would I want to
use the second line at all unless I wanted to see on the console what
happened?

ping = os.popen('sh ./ping.sh')

this will run until the buffer between the ping process and the python
app is full. This is 4k under linux. Then the ping process will block
until data is read as there is no where to put it's output.
ping.read()

This will read what's currently in the buffer between the processes.
You will need to do this in a loop.

alternatively if you don't care about the output then you
can throw it away, and hence remove the need for the ping.read() like:

ping = os.popen("sh ./ping.sh > /dev/null")
> ping.close()


This will wait for the ping process to finish.

To tell it to finish you will need to do something like:
ping = popen2.Popen3("sh ./ping.sh > /dev/null")
os.kill(ping.pid, signal.SIGTERM)
ping.wait()


Thank you for that explanation. It makes sense. When you say loop the
read do you mean something like this:

ping = os.popen('sh ./ping.sh')
while 1:
ping.read()
ping.close()

I liked the /dev/null examples too as I don't need output from some of
the functions. I didn't know I could throw output away like that.

Thanks,
Bart

Jul 18 '05 #5
Am Thu, 19 Feb 2004 10:18:56 -0500 schrieb Bart Nessux:
Thank you for that explanation. It makes sense. When you say loop the
read do you mean something like this:

ping = os.popen('sh ./ping.sh')
while 1:
ping.read()
ping.close()

I liked the /dev/null examples too as I don't need output from some of
the functions. I didn't know I could throw output away like that.


ping.read() will wait until EOF (End of File). You should
call it only once. This means ping.read() will return
as soon as the ping stopped pingging.

I think you can give the number of bytes to read
as an argument.

thomas
Jul 18 '05 #6
P@draigBrady.com wrote:
Maybe he didn't make ping.sh executable for some reason.
Not relevant to this discussion.


Or it has a broken/missing bangpath.

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ You and I / We've seen it all / Chasing our hearts' desire
-- The Russian and Florence, _Chess_
Jul 18 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Stuart McGraw | last post: by
17 posts views Thread by bastiaannaber | last post: by
2 posts views Thread by Maarten van Veen | last post: by
2 posts views Thread by Greg Ercolano | last post: by
3 posts views Thread by Jesse | last post: by
12 posts views Thread by Eric_Dexter | last post: by
15 posts views Thread by Daniel Klein | last post: by
25 posts views Thread by Jeremy Banks | last post: by
1 post views Thread by Mark Shewfelt | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.