Warum verursacht das Zuführen von stdin zu subprocess.Popen, was in stdout geschrieben wird, um zu ändern?

Question

Ich benutze Pythons subprocess.Popen, um einige FTP mit dem binären Client des Host-Betriebssystems durchzuführen. Ich kann ftplib oder irgendeine andere Bibliothek aus verschiedenen Gründen nicht verwenden.

Das Verhalten der Binärdatei scheint sich zu ändern, wenn ich einen stdin-Handler an die Popen-Instanz anschließe. Zum Beispiel mit XP FTP-Client, der eine Textdatei von Befehlen ausgegeben werden akzeptiert:

>>>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 

Wenn auch stdin liefert alles, was Sie in stdout erhalten ist:

Ursprünglich dachte ich, das sei eine Eigenart des XP FTP Clients, vielleicht wissend, dass es nicht im interaktiven Modus war und daher die Ausgabe limitierte. Dasselbe Verhalten tritt jedoch bei OS Xs ftp auf - alle Server-Antworten fehlen in stdout, wenn stdin angegeben wird - was mich zu der Annahme verleitet, dass dies ein normales Verhalten ist.

In Windows kann ich verwenden Sie die Option -s, um effektiv zu schreiben FTP ohne stdin, aber auf anderen Plattformen stützt man sich auf die Shell für diese Art von Interaktion.

Python-Version ist 2.6.x auf beiden Plattformen. Warum sollte ein Handle für stdin die stdout ändern und wo sind die Antworten des Servers hin?

Answer 1

Ich glaube, ich habe irgendwo gelesen (kann mich aber nicht erinnern, wo), dass Windows-FTP-Client von einer der ursprünglichen BSD-Implementierungen kam. Darin würde sicherlich eine gewisse Verwandtschaft mit der FTP-Implementierung von Mac OS X bestehen.

Für mich hängt dies nicht mit Popen zusammen, sondern mit der Client-FTP-Programmimplementierung, die mit issatty einige Überprüfungen des Kontextes durchführt, in dem es gestartet wird (um zu sehen, ob es mit einem menschlichen oder einem Shell-Skript interagiert) (3) wie mit Ignacio in seiner Antwort erwähnt. Dies ist gängige Praxis für Programme, die in beiden Kontexten verwendet werden können. Ein bekanntes Beispiel ist die GNU-Implementierung von grep für die Option --color = auto: Die Ausgabe wird nur dann coloriert, wenn stdout ein tty ist, und nicht, wenn die Ausgabe von grep an einen anderen Befehl übergeben wird.

Answer 2

Das Programm verwendet möglicherweise isatty(3), um das Vorhandensein eines tty auf stdin zu erkennen.