On Tuesday 08 February 2005 13:26, Simon Anders wrote:
> This is what I was about to reply as well. But I did a short test
> program and encountered a problem:
>
> import os
> fi, foe = os.popen4 ('ssh dopey')
> print >>fi, 'ls'
> fi.close () # <-- this is annoying
> for line in foe:
> print line,
> foe.close ()
>
> The above connects to a server, passes the command 'ls', which is
> executed there, and prints the returned result.
>
> However, reading from foe succeeds only if fin has been closed before.
> An fi.flush() seems to be not sufficient.
But this version below does work. Im not sure whats happening when using the
file as an iterator to make a difference.
import os, sys
fi, foe = os.popen4 ('ssh xxxxx')
print >>fi, 'ls'
fi.flush () # <-- this is annoying
while 1:
b = foe.readline()
sys.stdout.write(b)
> But if one wants Python to
> interactivly communicate with some shell on a remote machine, it is
> inconvenient to have to close and reopen the connection all the time.
But this route carries a big deadlock risk. the rsync program can tunnel over
ssh this way, but have first hand experience of
http://www.google.com/search?q=rsync+ssh+deadlock
In the script above, if 'ls' is replaced with a longer input then there is
every chance that the fi stream will block before all of it is written,
because this script hasnt started draining foe.
For a real python program using ssh (but not 'interactive'... data written to
fi does not depend on data read from foe) see
http://dirstorage.sourceforge.net/replica.html
--
Toby Dickenson
--
http://mail.python.org/mailman/listinfo/python-list
