Home Original page

os.popen

Cameron Laird claird at lairds.com
Thu Feb 19 09:40:27 EST 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)
      op.read()
      op.close()
    to just
      op = os.popen(command)
      op.close()
    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