OK, das ist tatsächlich bei
@fesc so beschrieben und - ohne den Hinweis auf das "Session-Problem" - schon ziemlich fehlerträchtig ... denn wie man an Deinem Versuch sieht, ist das eben ein reines Glücksspiel, wenn man nach einem
GETENV weitere Kommandos innerhalb derselben FTP-Session verwendet.
Das Problem ist durchaus bekannt ... und es hängt tatsächlich auch von der Implementierung des Clients ab, wie er mit dem, vom RFC-Inhalt abweichenden, Verhalten des FTP-Servers dann umgeht. Das kann sich aber mit der nächsten Version des FTP-Clients schon wieder ändern ... oder auch mit einem Update des verwendeten OS kann sich der genutzte FTP-Client ändern, etc.
Offenbar hat
@fesc selbst dieses Problem noch nicht gehabt ... oder er hat das nur noch nicht in dieser Abfolge innerhalb einer Session ausgeführt. Die "Ansage", daß das mit dem CLI-Client von Ubuntu/Debian funktionieren sollte, bezieht sich offenbar eher auf die Frage, ob der Client den benötigten "passive mode" bei Datenübertragungen beherrscht oder nicht.
Im RFC (
https://tools.ietf.org/html/rfc959) ist für FTP-Replies nun mal festgelegt:
A reply is defined to contain the 3-digit code, followed by Space <SP>, followed by one line of text (where some maximum line length has been specified), and terminated by the Telnet end-of-line code.
There will be cases however, where the text is longer than a single line. In these cases the complete text must be bracketed so the User-process knows when it may stop reading the reply (i.e. stop processing input on the control connection) and go do other things.
This requires a special format on the first line to indicate that more than one line is coming, and another on the last line to designate it as the last. At least one of these must contain the appropriate reply code to indicate the state of the transaction. To satisfy all factions, it was decided that both the first and last line codes should be the same.
Eine standardkonforme Antwort des Servers auf ein (erfolgreiches)
GETENV müßte also so aussehen:
Rich (BBCode):
ftp> quote GETENV linux_fs_start
200-GETENV response:
linux_fs_start 0
200 GETENV command successful
, wobei der Text in der ersten Zeile nach dem Bindestrich nicht relevant ist, weil erst die zweite Zeile, die mit
200 beginnt, die Antwort abschließt. Nur fehlt bei AVM eben genau diese erste Zeile und damit ist das
linux_fs_start 0 "außerhalb des Protokolls". Je nachdem, wie der FTP-Client damit umgeht/umgehen kann, kommt dann etwas wie oben bei Dir heraus. Eine neue Session hilft hier, weil damit auch die State-Machine für die Interpretation der Server-Responses im FTP-Client zurückgesetzt wird.
Und falls jetzt jemand denken sollte, das wäre auch irgendeine Spezialität der Puma7-Boxen ... weit gefehlt. Der FTP-Server in EVA verhält sich überall so (zumindest die, die ich bisher gesehen habe) und um genau dieses "Glücksspiel", welcher Client daraus nun was macht, nicht betreiben zu müssen, gibt es die Skript-Files in meinem YourFritz-Repo:
https://github.com/PeterPawn/YourFritz/tree/master/eva_tools - diese bedienen die FTP-Session "von Hand" und sind darauf vorbereitet, daß nach einem
GETENV-Kommando diese nicht-standardkonforme Antwort kommen kann.
