Problem mit popen

[M.Dietz]

Hi,

um zu überprüfen, ob auf einem Remote-Rechner eine Datei existiert, gebe ich per popen einen ls-Befehl:

void GetCommandOutput(std::string filename, std::string remote, std::string &result)
{
    char buffer[1024]; //überdimensioniert, aber das sollte egal sein
... std::string cmdBuffer;
    //Setze den Kommandstring zusammen als z.B. "export DROPBEAR_PASSWORD=nurEinBeispiel; ssh [email protected] \"ls /tmp/install/project_install.sh 2>/dev/null\""
    FILE *read_from=popen(cmdBuffer.c_str(), "r"); 
    if (read_from EQ NULL) 
        throw(ERR_FILE_READ);
    else
    {
        while (fgets(buffer, sizeof buffer, read_from))
            result.append(buffer);
        fclose(read_from);
    }
}

und teste dann in der eigentlichen Funktion ob der Rückgabewert meinen Dateinamen enthält. Diese Strategie funktioniert aber anscheinend nicht immer, also selbst wenn die Konsolenausgabe mir etwas zurückgeben würde, wenn ich diesen Befehl eintippe, das Programm erhält in den Buffer nach wie vor nichts. Lasse ich die Sache im Debugger laufen, funktioniert es immer (deshalb ist es mir auch noch nie aufgefallen), läuft es als release-Version auf dem Gerät aber anscheinend nicht (habe ich jetzt mehr durch Zufall herausgefunden, dass der empfangende Buffer leer ist, obwohl die Datei vorhanden ist).

Gibt es da irgendwelche bekannten Probleme mit popen, dass der sich unter debug Kompilierungen anders verhält? Ich möchte vermeiden eine Datei auf das lokale Gerät kopieren zu müssen, nur um mit fopen(..) zu überprüfen, ob die Datei danach vorhanden ist, deshalb nutze ich ja den Befehl wie oben.

[M.Dietz]

Zur Vervollständigung Ich habe herausgefunden, was los war:

Der mit popen geöffnete filestream wurde mit fclose geschlossen statt mit pclose. Dem Debugger war anscheinend egal dass dadurch der Stream nicht korrekt geschlossen wurde, und er hat beim nächsten popen einen neuen Stream geöffnet, der release-Version war es aber anscheinend nicht egal, und die hat den stream nicht öffnen können und dementsprechend auch nichts auslesen.

Was mich jetzt nur noch wundert ist, warum er dann keinen Fehler geworfen hat...

Edit (21.8.12): Und noch etwas haben wir gerade festgestellt (weil es nach dem Wechsel von fclose nach pclose auch im eigentlichen System nicht klappte, sondern nur im Testprogramm): Da der Prozess im System, in der die Release-Version getestet wird, im Hintergrund lief, hat popen die Ausgabe verweigert. Gut, konnte aus der Frage niemand wissen, ich konnte aber auch nicht erahnen, dass das relevant ist. Für dieses Problem mit popen in Hintergrundprozessen gibt es anscheinend auch kein Workaround, d.h. im obigen Beispiel musste ich es so umstellen, dass jegliches Kommando auf dem Remote-Rechner, dessen Ausgabe ich brauche, seine Ausgabe dort in eine Datei umleitet, die ich nach dem Kommando herunterladen und einlesen muss.