stdout außerhalb des Skripts ohne Konsolenfenster umleiten

[cmax]

Hallo,

ich habe eine Tkinter-App geschrieben, die Infos an stdout und Fehler an stderr ausgibt. Mit python interpretiert, klappt das wunderbar.
Allerdings möchte ich beim Endanwender pythonw (Win7) verwenden und die Ausgaben in ein Logfile umleiten.

Bei einer Verknüfung mit Ziel

Code: Alles auswählen

pythonw skript.py >> logfile.txt 2>&1

werden die Umleitungsoperatoren dem Skript als Parameter übergeben.

Beim Start per Batch mit o.g. Umleitungen, lässt sich m.E. das Konsolenfenster nicht vermeiden.

Gibt es eine Möglichkeit Ausgaben an stdout/stderr in eine Datei umzuleiten, ohne dass das Skript geändert werden muss und ohne dass ein Konsolenfenster sichtbar wird?

Gruss

Max

[sparrow]

Ohne jetzt das Ganze in Python zu lösen:
stell dem Aufruf in der Batch-Datei mal ein start vorweg, das müsste das Konsolenfenster verhindern, wenn ich mich richtig erinnere.

[BlackJack]

@cmax: Warum darf die Anwendung denn nicht verändert werden? `sys.stdout` und `sys.stderr` durch ein Dateiobjekt zu ersetzen ist ja ziemlich einfach zu machen.

[lunar]

@cmax Ändere die Anwendung, und nutze "logging", statt direkt auf "sys.stdout" zu schreiben. Diese Lösung ist zwar aufwendiger als eine Batch-Datei, bietet Dir aber mehr Flexibilität und Kontrolle über die Ausgaben der Anwendung.

[cmax]

@sparrow,BlackJack,lunar: Vielen Dank für eure Tipps.

Ohne jetzt das Ganze in Python zu lösen:
stell dem Aufruf in der Batch-Datei mal ein start vorweg, das müsste das Konsolenfenster verhindern, wenn ich mich richtig erinnere.

M.E. ist es auch kein Python-Problem, sondern eher zwei Windows-Probleme.

1. Ein Prozess mit stdout Umleitung via > lässt sich nicht ohne Konsolenfenster erzeugen.
2. Wird stdout nicht ausgelesen, kommt es zum Bufferüberlauf.

Deine Idee reduziert zumindest das 1. Problem etwas: M.W. wird die Batch dann in einem neuen Prozess gestartet und der alte Prozess und somit das Konsolenfenster nach einem kurzen Augenblick beendet/geschlossen.

Es sollte doch aber eigentlich auch möglich sein, diesen Prozess ohne die 'Hilfskonsole' zu starten.

In Linux/Gnome2 zeigt ein Starter mit sh -c "echo hallo >> ~/hallo.txt" kein Terminal-Fenster. Unter Windows zeigt sich beim Anklicken einer Verknüpfung mit Ziel cmd /c "echo hallo >> c:\hallo.txt" immer kurz ein Fenster.

@cmax: Warum darf die Anwendung denn nicht verändert werden? `sys.stdout` und `sys.stderr` durch ein Dateiobjekt zu ersetzen ist ja ziemlich einfach zu machen.

Ich kann sie natürlich ändern. Nur sollte es nicht auf jedem Host notwendig sein. Ich schreibe die Skripte nur, sie werden dann vom Admin 'installiert' (Konfguration) und von anderen genutzt.
Mir gefällt die Funktionsweise der Linuxprogramme ganz gut, es dem Nutzer ohne Änderung des Programms/Skripts zu ermöglichen, Ausgaben umzuleiten oder weiter zu nutzen (bspw. sed, grep).

Das Ersetzen von sys.stdout & Co wird sich wahrscheinlich sowieso nicht vermeiden lassen, da ich unter Windows das o.g. 2. Problem verhindern muss. Also muss m.E. mindestens ein Wrapper mit try-Block her.

Im aktuellen Fall, lese ich ohnehin eine Konfig-Datei (SafeConfigParser) aus. Also läufts wohl auf Folgendes hinaus: Dateinamen für stdout/err aus Config. Bufferüberlauf in einem Try-Block abfangen.

Aber für kleinere Skripte würde ich es gern (ohne zusätzlichen Aufwand für Konfig und Skript-Optionen/-Parameter) dem Admin/Anwender ermöglichen, den Output entsprechend umzuleiten.

@cmax Ändere die Anwendung, und nutze "logging", statt direkt auf "sys.stdout" zu schreiben. Diese Lösung ist zwar aufwendiger als eine Batch-Datei, bietet Dir aber mehr Flexibilität und Kontrolle über die Ausgaben der Anwendung.

Ich hab mir das Modul mal angeschaut und bin von den Möglichkeiten recht angetan. Aber m.E. löst das Modul o.g. Probleme nicht, oder?

[lunar]

@cmax Diese Bemerkung verstehe ich nicht… beim Einsatz von logging benötigst Du keine Shellumleitungen mehr, weil Du im Programm selbst alle Logeinträge in eine Datei (oder in nahezu beliebige andere Ziele) leiten kannst. Alles eine Frage der richtigen Konfiguration des Moduls.

Wenn Du die Skripte auf jedem Host ändern musst, ist der Deployment-Prozess mehr als kaputt. Du solltest die Skripte einmal ändern, und standardmäßig eine sinnvolle Logging-Konfiguration implementieren. Unter Windows wäre das beispielsweise Logging in das Windows-Ereignislog, oder in eine Datei in den lokalen Anwendungsdaten. Dann kann der Administrator diese Einträge auswerten, wenn es zu Problemen kommt.

Falls doch mal eine Host-spezifische Logging-Konfiguration nötig sein sollte, dann muss der Administrator eigentlich nur die Konfigurationsdatei ändern.

[cmax]

... und standardmäßig eine sinnvolle Logging-Konfiguration implementieren...

Ich bin zwar immer noch der Meinung, dass ich stdout außerhalb von Skripten ohne Konsolenfenster umleiten können möchte, aber bzgl. der Fehlerprotokollierung stimme ich dir zu.