+if hassubprocess == 1:
+assert 0 == subprocess.call([wget, -N, -c, -O, fname, loc])
+else:
+assert 0 == os.spawnvp(os.P_WAIT, wget, [-N, -c, -O,
fname, loc])
Why not use os.spawnvp even with newer versions? Less complex.
Best regards,
---
Peter
On Sat, 11 Apr 2009, DRC wrote:
However, I ran into a problem with dbus. RHEL 4 ships a pre-release
version (0.22) which isn't compatible with the X server 1.5 source. For
comparison, RHEL 5 uses a significantly newer version (1.12.)
Unfortunately, however, other system applications are tied
I agree. Also, it wasn't just the implementation that was broken - the
special protocol had many problems as well. I would say that the design
was flawed from the start: If a file transfer feature should at all be
included in a VNC implementation, it should at least be based on some
existing
Hello Peter:
Thank you for your comments. The file transfer feature in the VNC4
branch of TightVNC always felt flimsy to me. The UI was especially
inadequate for keyboard-only users. I made several modifications to the
UI, which I would contribute back to that branch of TightVNC if it were
Well, except for that fact that it would require building TigerVNC
against OpenSSL, which has its own set of issues. Why not just set up a
separate SFTP or SSh server on the Windows server? I use the Cygwin SSh
daemon to accomplish this, but there are others that are easier to set
up. There are