(Bitte darauf achten, dass du "Antwort an alle" oder so benutzt, damit deine Antwort an die Liste geht.)

Jan Strauch schrieb:

Frank Heckenbach frank@g-n-u.de schrieb am 24.07.03 04:42:49:

...

Jan Strauch schrieb:

...

ich bin der neue und hab' da auch gleich 'ne frage:

ich soll unter linux ein programm schreiben, das mit eine bunten java-oberfläche kommunizieren kann. mein problem ist jetzt, daß das programm mit einem textfile als "parameter" aufgereufen wrid, im stil von progxyz.pas < textfile.txt

solange alle readln's noch was aus dem text ziehen können klappt alles prima, aber danach soll die normale tastatureingabe wieder laufen, un das klappt nicht. ich muß das ding immer gewaltsam killen, um wieder was machen zu können. hab schon alle (glaub ich) kombinationen von input/output/assign/reset/rewrite/close (open?) probiert, und das ganze in gpc , fpc und kylix nix läuft muß ich das inputfile erst schließen, wenn ja , wie close(input) klappt teilweise, aber readln will trotzdem nicht

Also, etwas seltsam ist das schon, normalerweise dient `<' ja dazu, die Standardeingabe (normalerweise Tastatur) zu ersetzen. Evtl. wäre es daher sinnvoller, die beiden Dinge über getrennte Dateien zu lesen, also z.B. die Standardeingabe über `Input' und den Dateinamen als Kommandozeilen-Paramaeter zu übergeben und mit einer Dateivariable zu öffnen.

Wenn das aus irgendeinem Grund nicht geht und der Aufruf mit Umleitung sein "muss", kann man noch auf das Terminal zugreifen. Dieses kann man als normale Datei öffnen. Der Dateiname wird durch `TtyDeviceName' in der Unit `GPC' gegeben.

Wenn gewünscht, kann man auch `Input' neu öffnen, also:

uses GPC;

[...]

Close (Input); Reset (Input, TtyDeviceName);

Das Problem könnte sein, wann man das machen muss. Wenn es viele `ReadLn's im Programm gibt, und prinzipiell bei jedem der Wechsel von Standardeingabe zu Terminal stattfinden kann, müsste man praktisch vor jedem auf `EOF' testen und dann ggf. wechseln. Das kann aufwendig werden ...

Eine "billige" Lösung wäre evtl. auf der Shell-Ebene möglich, wenn das in der Umgebung geht, im Stil von:

cat textfile.txt - | progxyz.pas

(sodass `cat' die Datei und Standardeingabe zusammenfügt und dem Programm als dessen Standardeingabe weiterreicht).

...

(auch readkey und keypressed wollen nicht)

Wenn du die Unit CRT benutzt, wird es evtl. noch aufwendiger (weil die nicht über `Input' liest). Wenn das nötig ist (und nicht nur ein Versuch war, weil es mit `ReadLn' nicht ging), müsste man nochmal drüber nachdenken.

Danke erstmal, bin schon etwas weiter, aber CRT muss sein. ich muss die eingabe abhoeren, ohne sie zu blockieren.

das programm soll folgendes leisten: -es soll gegen ein anderes programm kaempfen, und die spielzuege ueber die standardein/ausgabe ueber den spielleiter (JAVA programm) an den gegner geben, bzw erhalten. wenn ich writeln benutze kommt was beim spielleiter an, aber readln erhaelt nichts(ich lasse zwei instanzen meines programms gegeneinander spielen). muss ich bei readln sonst flush anwenden?

Verstehe ich ehrlich gesagt nicht ganz. Wenn mehrere Programme die selben Daten lesen sollen, müssen sie an irgendeiner Stelle kopiert werden. Also entweder, der, der die Daten erzeugt, schreibt sie mehrmals (dann am besten gleich in mehrere Pipes zu den verschiedenen Programmen), oder notfalls muss ein Programm sie lesen und dann wieder an die anderen weiterleiten. `Flush' hilft vermutlich nicht, da es die Ausgabe betrifft.

Aber ich schätze, du musst mal *ganz genau* beschreiben, was du eigentlich vorhast, welche Programme beteiligt sind, wer was in welcher Reihenfolge(!) schreibt und liest usw. Ich blicke nämlich nicht wirklich durch.

Frank