I've written a python wrapper around the smbclient program, so that I
can list/upload/download from Windows shares.
Using smbclient 2.0.9 or Version 2.2.5-2 for Debian, my wrapper works
well and is able to control the smbclient process via pipes well. With
both smbclient 2.999+3.0cvs20020723-1 and 2.999+3.0.alpha20-3 (on a
Debian box) the smbclient responses appear to be not always BEFORE the
new smbclient command prompt. I expect this kind of behaviour:
smb: \> ls
Ranger D 0 Tue Nov 20 12:45:40 2001
telix D 0 Tue Nov 20 14:56:28 2001
DOS D 0 Tue Nov 20 14:57:32 2001
65526 blocks of size 32768. 65526 blocks available
smb: \>
But with the more recent smbclient versions I get this:
smb: \> ls
smb: \>
Ranger D 0 Tue Nov 20 12:45:40 2001
telix D 0 Tue Nov 20 14:56:28 2001
DOS D 0 Tue Nov 20 14:57:32 2001
65526 blocks of size 32768. 65526 blocks available
And once I saw this:
smb: \> ls
Ranger D 0 Tue Nov 20 12:45:40 2001
telix D 0 Tue Nov 20 14:56:28 2001 smb:
\>
DOS D 0 Tue Nov 20 14:57:32 2001
65526 blocks of size 32768. 65526 blocks available
As I look for the command prompt to know smbclient has finished giving
me the reply, this messes things up.
I control smbclient via popen4() in python2.1. I've found this strange
placement in the prompt to be the reason my code isn't working, via
running smbclient like this:
c = popen2.Popen4("smbclient //machine/c -N | tee /tmp/smb_out.txt)
And watching smb_out.txt (Popen3() acts the same way).
Is this likely to be an issue with how python talks to the process ? I
have not included a test case in this mail because it would make it
longer than it already is, but can provide one.
Note that when I talk to the smbclient myself (via starting one from a
shell) it appears to act normally.
Is there anymore information I could provide to help find out why this
occurs ?
Thanks,
Nick
--
Part 3 MEng Cybernetics; Reading, UK http://www.nickpiper.co.uk/
GPG Encrypted mail welcome! 1024D/3ED8B27F
Choose life. Be Vegan :-) Please reduce needless cruelty + suffering !
daniel.jarboe@custserv.com
2002-Nov-22 19:44 UTC
[Samba] Controlling smbclient from python weirdness
May be completely unrelated, but does anyone know if the latest
smbclient forks a child which returns the file list to stdout, and then
the parent writes the prompt to stdout? I was once in a situation where
multiple children took turns writing to stdout. The output was correct
if I ran the file by itself, or if I captured the output using 'script',
but piping stdout to a file caused the output to be all out of order.
It may be completely unrelated because this was in minix, but it may be
a place to start looking. CVS access is firewalled off here :(, so I
can't check the src myself.
~ Daniel
-----Original Message-----
From: Nicholas Piper [mailto:nick-samba@nickpiper.co.uk]
Sent: Wednesday, November 20, 2002 12:35 PM
To: samba@lists.samba.org
Subject: [Samba] Controlling smbclient from python weirdness
I've written a python wrapper around the smbclient program, so that I
can list/upload/download from Windows shares.
Using smbclient 2.0.9 or Version 2.2.5-2 for Debian, my wrapper works
well and is able to control the smbclient process via pipes well. With
both smbclient 2.999+3.0cvs20020723-1 and 2.999+3.0.alpha20-3 (on a
Debian box) the smbclient responses appear to be not always BEFORE the
new smbclient command prompt. I expect this kind of behaviour:
smb: \> ls
Ranger D 0 Tue Nov 20 12:45:40
2001
telix D 0 Tue Nov 20 14:56:28
2001
DOS D 0 Tue Nov 20 14:57:32
2001
65526 blocks of size 32768. 65526 blocks available
smb: \>
But with the more recent smbclient versions I get this:
smb: \> ls
smb: \>
Ranger D 0 Tue Nov 20 12:45:40
2001
telix D 0 Tue Nov 20 14:56:28
2001
DOS D 0 Tue Nov 20 14:57:32
2001
65526 blocks of size 32768. 65526 blocks available
And once I saw this:
smb: \> ls
Ranger D 0 Tue Nov 20 12:45:40
2001
telix D 0 Tue Nov 20 14:56:28
2001 smb: \>
DOS D 0 Tue Nov 20 14:57:32
2001
65526 blocks of size 32768. 65526 blocks available
As I look for the command prompt to know smbclient has finished giving
me the reply, this messes things up.
I control smbclient via popen4() in python2.1. I've found this strange
placement in the prompt to be the reason my code isn't working, via
running smbclient like this:
c = popen2.Popen4("smbclient //machine/c -N | tee /tmp/smb_out.txt)
And watching smb_out.txt (Popen3() acts the same way).
Is this likely to be an issue with how python talks to the process ? I
have not included a test case in this mail because it would make it
longer than it already is, but can provide one.
Note that when I talk to the smbclient myself (via starting one from a
shell) it appears to act normally.
Is there anymore information I could provide to help find out why this
occurs ?
Thanks,
Nick
--
Part 3 MEng Cybernetics; Reading, UK http://www.nickpiper.co.uk/
GPG Encrypted mail welcome! 1024D/3ED8B27F
Choose life. Be Vegan :-) Please reduce needless cruelty + suffering !
--
To unsubscribe from this list go to the following URL and read the
instructions: http://lists.samba.org/mailman/listinfo/samba
-----------------------------------------------------------------------
This message is the property of Time Inc. or its affiliates. It may be
legally privileged and/or confidential and is intended only for the use
of the addressee(s). No addressee should forward, print, copy, or
otherwise reproduce this message in any manner that would allow it to be
viewed by any individual not originally listed as a recipient. If the
reader of this message is not the intended recipient, you are hereby
notified that any unauthorized disclosure, dissemination, distribution,
copying or the taking of any action in reliance on the information
herein is strictly prohibited. If you have received this communication
in error, please immediately notify the sender and delete this message.
Thank you.