Stringübergabe an aufrufendes Batchprogramm
-
Simon2 schrieb:
aber das Programm darf natürlich NICHTS Anderes ausgeben (oder eben nur nach cerr/clog) ... und das schaffe ich nicht
...Hm, gibts in DOS-shells kein grep und/oder awk, womit man sich den Output auf das nötige zurechtschnipseln kann?
-
Umgebungsvariablen duerften eigentlich ned funktionnieren ...
die batch ruft das program auf, fuer das programm wird eine kopie der umgebung von der umgebung der batch gezogen. da sind auch die umgebungsvariablen bei ... und nachm aufruf des programms wird die umgebung das programms verworfen ...
Also "normal" gehts nur in einer richtung, der parent prozess kann uber die variablen Daten an seinen child "vererben" .
und ich glaub ned, das es sowas wie ein "export" fuer umgebungsvariablen im C++ standard gibt.Ciao ...
-
Das schreit doch gerade nach der Registry.
SCNR
-
und ich glaub ned, das es sowas wie ein "export" fuer umgebungsvariablen im C++ standard gibt.
Richtig: gibt's nicht. Dafür aber im POSIX.
-
pumuckl schrieb:
Simon2 schrieb:
aber das Programm darf natürlich NICHTS Anderes ausgeben (oder eben nur nach cerr/clog) ... und das schaffe ich nicht
...Hm, gibts in DOS-shells kein grep und/oder awk, womit man sich den Output auf das nötige zurechtschnipseln kann?
Mag sein (weiß ich nicht), aber cout/cerr/clog sind nunmal globale (und damit in jeder Funktion/LIB/DLL nutzbare) Variablen und werden derart "wild" genutzt, dass ich nicht für die Daten dieser Schnittstelle garantieren wollen würde.
Wie schon gesagt: Bei "Miniprogrammen" mit im Wesentlichen einer Funktion, kann man das Risiko eingehen.
... aber bei größeren Sachen, wird das schnell sehr unübersichtlich - spätestens, wenn man Usereingaben zur Laufzeit braucht.Gruß,
Simon2.
-
Simon2 schrieb:
Mag sein (weiß ich nicht), aber cout/cerr/clog sind nunmal globale (und damit in jeder Funktion/LIB/DLL nutzbare) Variablen und werden derart "wild" genutzt, dass ich nicht für die Daten dieser Schnittstelle garantieren wollen würde.
Wie schon gesagt: Bei "Miniprogrammen" mit im Wesentlichen einer Funktion, kann man das Risiko eingehen.
... aber bei größeren Sachen, wird das schnell sehr unübersichtlich - spätestens, wenn man Usereingaben zur Laufzeit braucht.Du bist größtenteils im Windows-Umfeld unterwegs, oder?
Unter UNIX ist es gang und gäbe, dass Konsolenprogramme Ihre "Programmausgabe" auf stdout machen, während alles für den User auf stderr landet. Es ist ebenfalls völlig normal, dass viele kleine Programme über Pipes zusammengesteckt werden, also sich über stdin und stdout unterhalten. Und da darf auch keine Meldung zwischen den (potentiellen) MPEG-Daten auftauchen.
-
LordJaxom schrieb:
...
Du bist größtenteils im Windows-Umfeld unterwegs, oder? :D...Im Gegenteil !
Ich schreibe im Wesentlichen für AIX und zOS und fast gar nichts für Windows (ich weiß auch gar nicht, wie Windows-GUI-PGs auf KonsolenIO verkraften ).
Aber bei unseren Server-PGs wird eifrigst über cout/cerr/clog geloggt, während IO im Wesentlichen über File,DB und verschiedene Netzwerkprotokolle stattfindet.Die Beispiele, die Du da angibst, sind aber eben die klassischen "FilterPGs" ("one-pass"), die ich als "Miniprogramm mit einer Funktion" bezeichnet habe.
Gruß,
Simon2.
-
Simon2 schrieb:
Die Beispiele, die Du da angibst, sind aber eben die klassischen "FilterPGs" ("one-pass"), die ich als "Miniprogramm mit einer Funktion" bezeichnet habe.
Ok, damit kann ich leben, wenn Du das "Mini" streichst.
Ich kenne da durchaus komplexe Programmsuiten, die Videos recodieren, DVD-Files erstellen, Steuern berechnen etc und alle Piping-fähig sind.PS: Und entschuldige die Fehleinschätzung, jetzt wo Du's sagst erinnere ich mich von Dir schon öfters was von AIX und zOS gelesen zu haben.
-
LordJaxom schrieb:
...wenn Du das "Mini" streichst...
Kein Problem !
Mir ging es auch nicht um geringe Komplexität der einzelnen Aufgabe, sondern um die Beschränkung auf eine Funktionalität zur Laufzeit.
War wohl nicht so deutlich, wie gewünscht.LordJaxom schrieb:
...
PS: Und entschuldige die Fehleinschätzung, ....Da gibt's nichts zu entschuldigen, denn nach meiner Auffassung ist es keine Schande, für Windows zu programmieren ....
Gruß,
Simon2.
-
pumuckl schrieb:
Hm, gibts in DOS-shells kein grep und/oder awk, womit man sich den Output auf das nötige zurechtschnipseln kann?
In der PowerShell gibt es Möglichkeiten sowas zu machen. Ein grep-ähnliches Kommando wäre dort select-string. Bei der einfachen "Eingabeaufforderung" (cmd) gibt es afaik kein entsprechendes Kommando.
Greetz
-
KEINE Umgebungsvariable.
Abgesehen davon: Gab es da nicht mal das Problem, dass das Environment beim Aufruf eines Programmes als Kopie angelegt wird?