Cameron Laird claird at lairds.com
Thu Feb 19 15:40:27 CET 2004

In article <4034C623.3030206 at draigBrady.com>,  <P at 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()
1.  Why 
      sh ./ping.sh ...
    rather than
      ./ping.sh ...
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)
    to just
      op = os.popen(command)
    I need to study the Windows-side implementation a bit
    more ...

Cameron Laird <claird at phaseit.net>
Business:  http://www.Phaseit.net

More information about the Python-list mailing list