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