Wie kann ich eine interaktive Unix-Anwendung programmatisch über Perl steuern?

7

Ich habe eine 20 Jahre alte interaktive Befehlszeilen-Unix-Anwendung geerbt, die von ihrem Anbieter nicht mehr unterstützt wird. Wir müssen einige Aufgaben in dieser Anwendung automatisieren.

Am schwierigsten ist es, Tausende neuer Datensätze mit leicht unterschiedlichen Parametern (z. B. unterschiedliche Bezeichner, unterschiedliche Namen) zu erstellen. Die Datensätze müssen nacheinander nacheinander erstellt werden, was viele Monate (und damit auch Dollars) von Hand erfordern würde. In den meisten Fällen hat das Erstellen eines Datensatzes ein sehr vorhersehbares Muster für das Eingeben von Befehlen, das Lesen von Antworten, das Eingeben weiterer Befehle usw. Einige Aufzeichnungs-Erstellungsvorgänge führen jedoch zu Fehlerbedingungen ("Datensatz mit diesem Bezeichner ist bereits vorhanden") eine andere Reihe von Befehlen, die elegant beendet werden sollen.

Ich kann ein paar verschiedene Möglichkeiten sehen, dies zu tun:

  • Benannte Pipes. Schreiben Sie ein Perl-Skript, das die Zielanwendung ausführt, wobei STDIN und STDOUT auf Named Pipes festgelegt sind, und sendet dann der Zielanwendung die Befehlsfolge, um einen Datensatz mit den erforderlichen Parametern zu erstellen, und weist dann die Zielanwendung zum Beenden und Herunterfahren an. Wir führen das Skript dann so oft wie nötig mit verschiedenen Parametern aus.

  • Anwendung. Suchen Sie ein anderes Unix-Tool, mit dem interaktive Programme geschrieben werden können. Die einzigen, die ich gefunden habe, sind expect , aber dies scheint nicht oben zu sein. und Chats, an die ich mich seit Ewigkeiten erinnere, und die mehr oder weniger das zu tun scheinen, was ich will, aber anscheinend nur für die Kontrolle von Modems.

Noch eine mögliche Komplikation: Ich denke, die Zielanwendung wurde für ein VT100-Terminal geschrieben und verwendet eine Art von Escape-Sequenzen, um beispielsweise Hervorhebungen vorzunehmen.

Meine Frage ist, welchen Ansatz sollte ich nehmen? Einer von ihnen oder etwas ganz anderes? Ich mag die Idee, Named Pipes zu verwenden und dann ein Perl-Skript zu haben, das die FIFOs öffnet und liest und schreibt, wie es erforderlich ist, da es eine Menge Flexibilität bietet, aber von dem, was ich gelesen habe, scheint es eine Menge potentieller Probleme zu geben Ich gehe diesen Pfad hinunter.

Vielen Dank im Voraus.

    
Anon Gordon 24.09.2009, 11:12
quelle

3 Antworten

12

Ich würde auf jeden Fall für die zusätzliche Flexibilität bei Perl bleiben, wie das Chaos nahelegte. Ist Ihnen das Modul Expect perl bekannt? Es ist viel schöner als der Named-Pipe-Ansatz.

Beachten Sie auch, dass Sie bei Named Pipes nicht dazu gezwungen werden können, dass die Ausgabe, die von Ihrer Legacy-Anwendung zurückkommt, ungepuffert ist, was ärgerlich sein könnte. Ich denke, Expect.pm verwendet Pseudo-Ttys, um dieses Problem zu umgehen, aber ich bin mir nicht sicher. Siehe die Diskussion in perlipc im Abschnitt "Bidirektionale Kommunikation mit einem anderen Prozess" für weitere Details.

    
ire_and_curses 24.09.2009, 12:15
quelle
4

expect ist viel solider, als Sie es wahrscheinlich verdienen, aber wenn ich Sie wäre, würde ich immer noch mit der Perl-Option gehen, die eine vollständige und vertraute Programmiersprache für die Verwaltung des Prozesses haben möchte in der Überzeugung, dass, was auch immer komische Probleme entstehen, es Wege geben wird, sie anzugehen.

    
chaos 24.09.2009 11:19
quelle
4

Erwarten Sie, entweder mit der Tcl oder Perl-Implementierung , wäre mein erster Versuch. Wenn Sie in der Ausgabe ungerade Sequenzen sehen, weil es seltsame terminale Dinge macht, filtern Sie diese einfach aus der Ausgabe, bevor Sie das Matching durchführen.

Mit Named Pipes werden Sie Expect auf jeden Fall neu erfinden.

    
brian d foy 24.09.2009 16:38
quelle

Tags und Links