CLIs für Fox-Entwickler (1): Was eine CLI ist

Fast alles, was ein Fox-Entwickler je gebaut hat, hat Fenster: Formulare, Grids, Schaltflächen, Berichte. Die Konsole, dieses schwarze Fenster, in das man Befehle tippt, bleibt dem Systemadministrator überlassen oder dem, der von Linux kommt. Trotzdem gibt es immer mehr Dinge, die nur dort gehen: Git, Aufgabenplaner, Server ohne Desktop und seit Kurzem KI-Agenten, die arbeiten, indem sie Befehle starten und lesen, was zurückkommt.

Kommandozeilen-Tutorials gibt es tausende, aber sie stammen von Leuten, die nie eine .pjx geöffnet haben. Dieser Kurs geht andersherum vor: Er beginnt bei dem, was Sie über VFP schon wissen, und nutzt es als Brücke. Fünf kurze Teile:

1. Was eine CLI ist (dieser).
2. Anatomie eines Befehls: Befehle, Argumente, Optionen und Positionsargumente.
3. Eingabe, Ausgabe und Fehler, und der Exit-Code.
4. Hilfe lesen und schreiben.
5. CLIs aus VFP nutzen, und zwar richtig.

Alles hier habe ich auf einem Windows 11 in spanischer Sprache ausgeführt, deshalb sind die Meldungen in den Beispielen auf Spanisch. Bei Ihnen erscheinen sie in Ihrer Sprache, die Befehle sind dieselben.

Sie haben schon eine Kommandozeile benutzt

Öffnen Sie Visual FoxPro. Das Fenster mit dem Titel Command ist eine Kommandozeile: Sie tippen einen Befehl, drücken Enter, und das Ergebnis erscheint.

? DATE()
? VERSION()
DIR *.prg

Keine Schaltflächen, keine Menüs. Sie schreiben Text, VFP interpretiert ihn, tut etwas und antwortet mit mehr Text. Eine CLI (command-line interface, Kommandozeilen-Schnittstelle) ist dasselbe außerhalb von VFP: ein Programm, das man mit getippten Befehlen bedient statt mit Klicks auf Fenster.

Der erste Befehl in der Windows-Konsole

Drücken Sie Windows + R, tippen Sie cmd und drücken Sie Enter. Es öffnet sich ein Fenster mit etwas wie C:\Users\IhrName> und einem blinkenden Cursor. Dieser Text ist der Prompt: Er zeigt, in welchem Ordner Sie sind und dass ein Befehl erwartet wird, wie der Cursor im Befehlsfenster von VFP.

Tippen Sie das hier und drücken Sie Enter:

ping -n 2 127.0.0.1

Es sollte ungefähr so aussehen (bei mir auf Spanisch):

ping prüft, ob ein anderer Rechner im Netz antwortet. 127.0.0.1 ist Ihr eigener Rechner, also antwortet er immer, und -n 2 sagt ihm, es zweimal zu versuchen statt der üblichen vier Male. Was jedes Stück dieses Befehls ist, sehen wir in Teil 2.

Probieren Sie auch ver (die Windows-Version) und dir (die Dateien im Ordner). Das dir der Konsole und das DIR von VFP ähneln sich sehr: Beide listen Dateien auf, und beide verstehen Platzhalter wie *.prg.

Konsole, Terminal und Shell

Diese drei Wörter werden wie Synonyme benutzt, und es lohnt sich, sie von Anfang an auseinanderzuhalten, weil Sie ihnen überall begegnen.

Die Shell (auf Deutsch auch Kommandozeileninterpreter) ist das Programm, das liest, was Sie tippen, und es ausführt. Windows hat zwei:

• cmd.exe, die altbekannte, Erbin von COMMAND.COM aus MS-DOS. Das ist die, die Sie mit Windows + R geöffnet haben.
• PowerShell, moderner. Die mit Windows ausgelieferte ist 5.1; meine meldet 5.1.26100. Es gibt eine Version 7, die separat installiert wird und pwsh heißt.

Beide verstehen einfache Befehle wie ping oder dir, aber jede hat für alles andere ihre eigene Sprache: Variablen, Schleifen, Anführungszeichen. In diesem Kurs benutze ich beide und sage immer, welche.

Die Konsole oder das Terminal ist das Fenster, in dem Sie schreiben und lesen. In Windows 11 ist das standardmäßig die App Terminal (wt.exe), die Registerkarten hat und in jeder ein cmd, eine PowerShell oder eine andere Shell öffnen kann. Das Fenster zeichnet nur Text und nimmt Tasten entgegen; wer die Befehle versteht, ist die Shell, die darin läuft.

Das Programm, das Sie ausführen, ist noch etwas anderes. ping ist eine ganz normale Datei:

where ping

C:\Windows\System32\PING.EXE

Eine .exe wie die, die Sie beim Kompilieren eines VFP-Projekts erzeugen. In diesem Ordner meines Windows liegen 663 .exe-Dateien, und 270 davon sind Konsolenprogramme wie dieses.

Auf VFP übertragen: Das Fenster Command ist das Terminal, die VFP-Engine, die ? DATE() interpretiert, ist die Shell, und DATE() ist das, was ausgeführt wird. Der Unterschied: In der Windows-Konsole ist fast alles, was Sie ausführen, eine eigene .exe, und jede macht genau eine Sache.

Aus VFP starten Sie schon Konsolenprogramme

RUN (und seine Kurzform !) gibt es in FoxPro seit DOS-Zeiten. Es startet einen Befehl, als hätten Sie ihn in cmd getippt:

RUN ver > version.txt
? FILETOSTR("version.txt")

Das funktioniert, und darin stecken schon zwei Ideen des Kurses: RUN startet ein Konsolenprogramm, und > schickt, was das Programm schreibt, in eine Datei statt auf den Bildschirm. Drei Dinge über RUN sollten Sie wissen:

1. RUN wartet, bis das Programm fertig ist. Ein ping -n 4 brauchte 4,03 Sekunden, und VFP stand die ganze Zeit still.
2. RUN /N wartet nicht. Derselbe Befehl kam nach 0,04 Sekunden zurück, und ping lief allein weiter.
3. Mit /N bewirkt > nichts. RUN /N ping -n 1 127.0.0.1 > ausgabe.txt legt die Datei nicht an. Ohne /N läuft der Befehl über cmd.exe (die Shell aus der Variable COMSPEC), und die versteht >. Mit /N findet diese Umleitung nicht statt.

Und ein Detail, das Sie sehen, sobald Sie diese version.txt aus VFP lesen: Bei mir steht dort Versi¢n statt Versión. Die Windows-Konsole schreibt mit einer anderen Codepage als VFP (bei mir 850 gegenüber 1252), und Buchstaben mit Akzent kommen verändert an. Auf einem deutschen Windows passiert dasselbe mit Umlauten: ein ü in einem Dateinamen oder einer Meldung kommt nicht als ü an. Das lässt sich beheben, wie, sehen wir in Teil 3.

Teil 5 handelt ganz davon: Konsolenprogramme aus VFP starten, warten oder nicht, einsammeln, was sie schreiben, und wissen, ob sie gut gelaufen sind.

Warum sie immer noch leben

CLIs stammen aus den Siebzigern und sind immer noch überall, weil sie Dinge können, die ein Fenster nicht kann:

• Sie lassen sich automatisieren. Ein Befehl ist Text, und Text lässt sich in einer .bat speichern, in der Windows-Aufgabenplanung um drei Uhr morgens einplanen oder aus einem anderen Programm starten. Ein Formular braucht jemanden davor, der die Schaltfläche drückt.
• Sie lassen sich verketten. Die Ausgabe eines Programms kann die Eingabe des nächsten sein, und so baut man große Aufgaben aus kleinen Teilen. Das macht das > von oben, und es gibt mehr (Teil 3).
• Sie funktionieren ohne Desktop. Ein Server, mit dem Sie sich aus der Ferne verbinden, ein Prozess, der als Dienst läuft, eine virtuelle Maschine in der Cloud: Dort schaut nicht immer jemand auf einen Bildschirm, und die Konsole ist das, was man hat.

Wer sie heute benutzt

Sie selbst, auch ohne es zu wissen, jedes Mal, wenn Ihre Anwendung ein RUN ausführt. Außerdem:

• Skripte: die .bat- und .ps1-Dateien, die jemand geschrieben hat, um Sicherungen zu kopieren, eine Version auszurollen oder temporäre Dateien zu löschen.
• Die Aufgabenplanung: Jede geplante Aufgabe ist ein Programm plus seine Argumente, also eine Kommandozeile.
• Entwicklerwerkzeuge: Git, Compiler, stille Installer. Fast alle haben eine CLI, und viele haben nichts anderes.
• KI-Agenten, das Neueste. Ein Agent, der mit Ihnen programmiert, arbeitet, indem er Befehle in einer Konsole startet und liest, was sie zurückgeben. Wenn Ihr Werkzeug eine CLI hat, die ihr Ergebnis in einem lesbaren Format schreibt (JSON zum Beispiel), kann ein Agent es benutzen, ohne dass jemand etwas dafür programmiert.

Zum Üben

Öffnen Sie ein cmd mit Windows + R und probieren Sie diese Befehle. Keiner verändert etwas auf Ihrem Rechner:

ver
dir C:\Windows\System32\*.exe
where notepad
ping -n 2 127.0.0.1
hostname

Dann im Befehlsfenster von VFP:

RUN hostname > rechner.txt
? FILETOSTR("rechner.txt")

Und achten Sie für den nächsten Teil auf eines: Welcher Teil von dir C:\Windows\System32\*.exe ist das Programm, und welcher ist das, was Sie ihm sagen? Darum geht es in Teil 2, der Anatomie eines Befehls.