4
STDOUT als virtuelle Datei (*nix-Like) ?
Hallo,
ich habe ein Programm (genauer gesagt dvipng), das die Ausgabe nur in eine Datei leiten kann. Unter Linux lässt sich nun als Ziel /dev/stdout angeben, womit die Ausgabe auf dem Standardt-Output umgeleitet wird, und somit mit anderen Programmen verkettet werden kann. Das hätte ich auch gerne unter WinXP.
Also: kann man den Standardtoutput auch mit einem Datei-Alias ansprechen?
Danke
Filipp
ich habe ein Programm (genauer gesagt dvipng), das die Ausgabe nur in eine Datei leiten kann. Unter Linux lässt sich nun als Ziel /dev/stdout angeben, womit die Ausgabe auf dem Standardt-Output umgeleitet wird, und somit mit anderen Programmen verkettet werden kann. Das hätte ich auch gerne unter WinXP.
Also: kann man den Standardtoutput auch mit einem Datei-Alias ansprechen?
Danke
Filipp
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 21584
Url: https://administrator.de/forum/stdout-als-virtuelle-datei-nix-like-21584.html
Ausgedruckt am: 05.02.2025 um 17:02 Uhr
4 Kommentare
Neuester Kommentar
Hmmmm, nur eine Teilantwort kann ich liefern, filippg,
Du kannst den STDOUT-Kanal auch als Device/als Datei ansprechen. Heißt dann "CON:"
Habe ich auch schon in irgendwelchen Bätchelchen hier im Forum gemacht, Beispiel..
(irgendein Batch)
IF (%1)== () (
Set "logdatei=c:\logs\logdatei"
) else (
Set "logdatei=Con:"
)
...
das heißt, normalerweise wird alles in eine Logdatei geschrieben, bei Bedarf zauber ich die Logdatei-Einträge aber auf den Bildschirm. zum Beispiel beim Testen.
Also - wenn dieses dvipng es zulässt, kannst Du dem als Datei "CON:" anbieten. Klein/Großschreibung egal, aber der Doppelpunkt ist zwingend.
Allerdings - Wermutstropfen: ich hatte auch schon Programme, die eine Umleitung auf "Con:" nicht akzeptierten.
Weiterer Workaround: Es gibt auch eine Menge "Tee"-Freeware-Utilitities für Windows - mit denen sollte es machbar sein, die Ausgabe zusätzlich auf Console umzuleiten, falls sich die Ausgabe in eine "echte" Datei nicht umbiegen lässt.
Im Zweifelsfall schick mir mal per pn eine Mail-Addy, dann graben wir mal zusammen.
Grüße Biber
Du kannst den STDOUT-Kanal auch als Device/als Datei ansprechen. Heißt dann "CON:"
Habe ich auch schon in irgendwelchen Bätchelchen hier im Forum gemacht, Beispiel..
(irgendein Batch)
IF (%1)== () (
Set "logdatei=c:\logs\logdatei"
) else (
Set "logdatei=Con:"
)
...
das heißt, normalerweise wird alles in eine Logdatei geschrieben, bei Bedarf zauber ich die Logdatei-Einträge aber auf den Bildschirm. zum Beispiel beim Testen.
Also - wenn dieses dvipng es zulässt, kannst Du dem als Datei "CON:" anbieten. Klein/Großschreibung egal, aber der Doppelpunkt ist zwingend.
Allerdings - Wermutstropfen: ich hatte auch schon Programme, die eine Umleitung auf "Con:" nicht akzeptierten.
Weiterer Workaround: Es gibt auch eine Menge "Tee"-Freeware-Utilitities für Windows - mit denen sollte es machbar sein, die Ausgabe zusätzlich auf Console umzuleiten, falls sich die Ausgabe in eine "echte" Datei nicht umbiegen lässt.
Im Zweifelsfall schick mir mal per pn eine Mail-Addy, dann graben wir mal zusammen.
Grüße Biber
Hallo,
nach einem ersten kurzen Test scheint es so, als würde das mit dem CON: funktionieren. Super, Danke.
Filipp
nach einem ersten kurzen Test scheint es so, als würde das mit dem CON: funktionieren. Super, Danke.
Filipp
Kein Problem, ich war eh noch wach 
Frank / der Biber aus Bremen
Frank / der Biber aus Bremen
Hallo,
das mit der Umleitung hat zwar grundsätzlich geklappt, nur hat C# (bzw. .Net) den Ausgabestrom so nicht akzeptiert. Ich vermute mal, es liegt daran, dass ja nicht nur der Datenstream, sondern eben auch befehle für Dateioperationen mit ausgegeben wurden. Aber ich lese halt jetzt einfach die Datei, hatte halt nur gehofft noch ein wenig Zeit zu sparen, wenn ich Streams statt Dateioperationen nehme.
Aber die nächsten Probleme sind auch schon wieder da: wenn jemand eine Idee hätte, wie man unter C# einen OLE-Server schreibt, der dann einen OLE-Container bereitstellen kann...
Filipp
das mit der Umleitung hat zwar grundsätzlich geklappt, nur hat C# (bzw. .Net) den Ausgabestrom so nicht akzeptiert. Ich vermute mal, es liegt daran, dass ja nicht nur der Datenstream, sondern eben auch befehle für Dateioperationen mit ausgegeben wurden. Aber ich lese halt jetzt einfach die Datei, hatte halt nur gehofft noch ein wenig Zeit zu sparen, wenn ich Streams statt Dateioperationen nehme.
Aber die nächsten Probleme sind auch schon wieder da: wenn jemand eine Idee hätte, wie man unter C# einen OLE-Server schreibt, der dann einen OLE-Container bereitstellen kann...
Filipp
