views:

296

answers:

2

I'm using Python's subprocess.Popen to perform some FTP using the binary client of the host operating system. I can't use ftplib or any other library for various reasons.

The behavior of the binary seems to change if I attach a stdin handler to the Popen instance. For example, using XP's ftp client, which accepts a text file of commands to issue:

>>> from subprocess import Popen, PIPE
>>> p = Popen(['ftp','-A','-s:commands.txt','example.com'], stdout=PIPE)
>>> p.communicate()[0]
'Connected to example.com.
220 ProFTPD 1.3.1 Server (Debian) ...
331 Anonymous login ok, send your complete email address as your password
<snip>
ftp> binary
200 Type set to I
ftp> get /testfiles/100.KiB
200 PORT command successful
150 Opening BINARY mode data connection for /testfiles/100.KiB (102400 bytes)
226 Transfer complete
ftp: 102400 bytes received in 0.28Seconds 365.71Kbytes/sec.
ftp> quit
>>>

commands.txt:

binary
get /testfiles/100.KiB
quit

When also supplying stdin, all you get in stdout is:

>>> from subprocess import Popen, PIPE
>>> p = Popen(['ftp','-A','-s:commands.txt','example.com'], stdin=PIPE, stdout=PIPE)
>>> p.communicate()[0]
'binary
get /testfiles/100.KiB
quit'
>>>

Initially I thought this was a quirk of the XP ftp client, perhaps knowing it wasn't in interactive mode and therefore limiting its output. However, the same behaviour happens with OS X's ftp - all the server responses are missing from stdout if stdin is supplied - which leads me to think that this is normal behaviour.

In Windows I can use the -s switch to effectively script ftp without using stdin, but on other platforms one relies on the shell for that kind of interaction.

Python version is 2.6.x on both platforms. Why would supplying a handle for stdin change stdout, and where have the server responses gone to?

Thanks,
Matt.

+3  A: 

The program may be using isatty(3) to detect presence of a tty on stdin.

Ignacio Vazquez-Abrams
+2  A: 

I think I read somewhere (but can't remember where) that Windows ftp client came from one of the original BSD implementations. In that it would certainly shares some relationship with Mac OS X's ftp implementation.

For me, this is not related to Popen but to the client ftp program implementation, which makes some checks about the context in which it is launched (to see if it's interacting with a human or a shell script), using isatty(3) as mentionned with Ignacio in his answer. This is common practise for programs which can be used in both context. A well known example is GNU grep implementation for the --color=auto option : it will colorize output only if stdout is a tty, and not if the output of grep is piped into another command.

gurney alex
Yes I think you're right about this. When I run the working code as a Windows service (which also has a non-interactive stdin) I get the same behaviour. So the follow-up question is - is there a cross-platform way of 'tricking' the executable that it's talking to a tty? I'm assuming it doesn't actually need any features of a tty to produce the full output.
Matt
Not that I know of. However, note that there is no standard cross platform ftp command with a unified interface (i.e. command line arguments), so you will have a hard time writing portable code with this approach. If your script only needs to download a couple of files using ftp, I recommend using urllib or urllib2:import urllibf = urllib.urlopen('ftp://example.com/testfiles/100.KiB')data = f.read()
gurney alex
I spent some time experimenting with pexpect/wexpect, which promised to be a reasonably platform independent solution. Regrettably wexpect needs a console and dies horribly when run as a Windows Service.
Matt