tesh – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

tesh – Test-Shell

ZUSAMMENFASSUNG

tesh [zur Auswahl]... [FILE] ...

BESCHREIBUNG

Dies ist das TESH-Tool. Es stellt eine Test-Shell dar, also eine Art Shell, die darauf spezialisiert ist
Tests durchführen. Die Liste der auszuführenden Aktionen wird aus Dateien namens testsuite analysiert.

OPTIONAL

--cd some/directory: Tesh vorher bitten, das Arbeitsverzeichnis zu wechseln
die Tests starten
--setenv var=value: Legen Sie eine bestimmte Umgebungsvariable fest
--cfg arg: Parameter --cfg=arg zu jeder Befehlszeile hinzufügen
--enable-coverage: Ausgabezeilen ignorieren, die mit „profiling:“ beginnen

TESH FILE SYNTAX

Hier ist die Syntax dieser Dateien:

Der Typ jeder Zeile wird durch das erste Zeichen angegeben (das zweite Zeichen sollte leer sein und ist leer).
ignoriert):

„$“-Befehl zur Ausführung im Vordergrund
„&“-Befehl zur Ausführung im Hintergrund
„<“-Eingabe zur Übergabe an den Befehl
„>“-Ausgabe, die vom Befehl erwartet wird
„!“ Metabefehl, der einer der folgenden sein kann:
„Zeitüberschreitung“ |nr
„Signal erwarten“
„Rückkehr erwarten“
„Ausgabe“
`setenv = '
„p“ eine Zeichenfolge zum Drucken
„P“ eine Zeichenfolge, die auf der Ebene „KRITISCH“ gedruckt werden soll (erleichtert das Logging-Grepping)

Wenn die erwartete Ausgabe nicht mit der Ausgabe des Befehls übereinstimmt, erzeugt TESH einen Fehler
Zeigt den Unterschied an (siehe AUSGABE unten).

IO ORDERS

Die Zeilen < und > fügen E/A zu dem im aktuellen Block definierten Befehl hinzu (Blöcke werden getrennt).
durch Leerzeilen). Es ist möglich, diese Zeilen entweder nach dem Befehl oder davor zu platzieren.
Der Unterschied zwischen den beiden folgenden Abschnitten ist in Ihren Testsuiten hauptsächlich kosmetischer Natur.
TESH ist das egal. (vgl. IO-orders.tesh)

$ Katze
< TOTO
> TOTO

> TOTO
$ Katze
< TOTO

Dennoch ist es möglich, mehrere Befehle im selben Block zu haben, jedoch keinen davon
kann eine beliebige Ausgabe haben. Es mag etwas restriktiv erscheinen, da man sagen könnte, dass ein Befehl bekommt
alle E/A bis zum nächsten Befehl, aber ich habe Angst vor Fehlern wie den folgenden:

$ cd toto
> TOTO
$ mkfile-Datei

TOTO wird an den Befehl cd übergeben, wo der Benutzer es eindeutig an den übergeben möchte
Integrierter mkfile-Befehl (siehe unten).

STREAM UMLEITUNG

Stream-Umleitungen („>“, „<“ und „|“-Konstrukte in sh) sind in tesh noch nicht implementiert.
Das ist etwas restriktiv, aber nun ja, Patch willkommen ...

Die Situation, in der es hauptsächlich problematisch ist, besteht darin, eine temporäre Datei zu erstellen. Der
Die Lösung besteht darin, den integrierten Befehl „mkfile“ zu verwenden, wie im folgenden Beispiel: $ mkfile
myFile > einige Inhalte > zur Datei

Dadurch wird eine Datei namens myFile (erstes Argument des mkfile-Befehls) erstellt. Sein Inhalt
ist die gesamte Eingabe, die dem Befehl bereitgestellt wird.

RÜCKKEHR CODE

TESH gibt eine entsprechende Fehlermeldung aus, wenn das Kind nicht 0 als Rückkehrcode zurückgibt (vgl.
(catch-return.tesh) und gibt code+40 selbst zurück.

Es ist auch möglich, anzugeben, dass ein bestimmter Befehl einen anderen Wert zurückgeben muss. Dafür,
Verwenden Sie den Metabefehl „expect return“, der eine Ganzzahl als Argument akzeptiert. Nur die Veränderung
auf den nächsten Befehl anwenden (vgl. set-return.tesh).

SIGNALE

TESH erkennt, wenn das Kind durch ein Signal getötet wird (wie bei Segfaults) und spuckt ein Signal aus
entsprechende Fehlermeldung (vgl. Catch-Signal.tesh).

Es ist auch möglich, festzulegen, dass ein bestimmter Befehl ein bestimmtes Signal auslösen muss. Dafür,
Verwenden Sie den Metabefehl „Signal erwarten“. Als Argument wird der Signalname verwendet. Nur die Veränderung
auf den nächsten Befehl anwenden (vgl. set-signal.tesh).

AUSZEITEN

Standardmäßig erhalten alle Befehle 5 Sekunden Zeit zur Ausführung (vgl. Catch-Timeout.tesh). Du kannst
ändern Sie dies mit dem „timeout“, das eine Ganzzahl als Argument akzeptiert. Die Änderung gilt nur
zum nächsten Befehl (vgl. set-timeout.tesh). Wenn Sie „no“ als Argument übergeben, wird der Befehl
Zeitüberschreitung ist nicht möglich.

AUSGABE

Standardmäßig wird die Befehlsausgabe mit der erwarteten abgeglichen, und es wird ein Fehler angezeigt
auf Unstimmigkeiten angesprochen. Metabefehle, um dies zu ändern:
„Ausgabe ignorieren“ -> Ausgabe komplett verworfen
„Ausgabeanzeige“ -> Ausgabe angezeigt (aber nicht überprüft)
„Ausgabesortierung“ -> sortiert die Anzeige vor der Überprüfung (siehe unten)

SORTIERUNG AUSGABE

Das Sortieren der Ausgabe scheint eine seltsame Idee zu sein, ist aber in SimGrid seitdem obligatorisch
Prozesse laufen zu jedem Planungszeitpunkt außer Betrieb (d. h. alle Prozesse sind zur Ausführung bereit).
simulierte Zeit t parallel laufen). Um sicherzustellen, dass die Ausgänge des Simulators weiterhin übereinstimmen, haben wir
Sie müssen die Ausgabe vor dem Vergleich noch einmal sortieren.

Wir gehen davon aus, dass die Simulatoren mit diesem Protokollformatierungsargument ausgeführt werden:
--log=root.fmt:[%10.6r]%e(%i:%P@%h)%e%m%n Dann sortiert tesh die Zeichenfolge nach den 19 ersten Zeichen
nur und ist stabil, wenn die Zeilenanfänge gleich sind. Dadurch soll sichergestellt werden, dass:
(1) Tesh ist wirksam (kein falsch positives Ergebnis, kein falsch negatives Ergebnis)
(2) Planungspunkte sind voneinander getrennt
(3) An jedem Planungspunkt werden die Prozesse voneinander getrennt
(4) die Reihenfolge dessen, was ein bestimmter Prozess zu einem bestimmten Zeitpunkt sagt
Punkt bleibt erhalten.

Das ist natürlich sehr SimGrid-orientiert und sprengt die Allgemeingültigkeit von Tesh, aber wen interessiert das?
Genau genommen?

Wenn Sie die Länge des für die Sortierung verwendeten Präfixes ändern möchten, geben Sie es einfach danach an
die Ausgabesortieranweisung, etwa so:

! Ausgabesortierung 22

Mit dem Metabefehl setenv können Sie der getesteten Prozessumgebung einige Inhalte hinzufügen.
Es funktioniert wie erwartet. Zum Beispiel:
"setenv PATH=/Behälter"

Nutzen Sie Tesh online über die Dienste von onworks.net