dBASE war die erste weit verbreitete Datenbanksprache für den PC und prägte die gesamte xBase-Familie. Wayne Ratliff entwickelte den Vorläufer Vulcan 1978 in 8080-Assembly für CP/M; Ashton-Tate lizenzierte das Programm und verkaufte es ab 1981 als dBASE II. Es folgten dBASE III (1984), dBASE III PLUS (1986) und dBASE IV (1988). Borland übernahm Ashton-Tate 1991 und führte die Reihe bis Visual dBASE 7.0 (1997) fort.

Grundlagen

dBASE arbeitete als Interpreter: Am Punkt-Prompt gab man Befehle direkt ein, oder man speicherte sie in .PRG-Programmdateien. Die Daten lagen im .DBF-Format (dBase File), Memo-Felder in separaten .DBT-Dateien. Anders als SQL-Datenbanken war jede Tabelle eine eigene Datei ohne Serverprozess.

Kernbefehle

CREATE kunden          && neue Tabelle anlegen
USE kunden             && Tabelle öffnen
APPEND                 && Datensatz am Ende ergänzen
LIST / DISPLAY         && Datensätze anzeigen
BROWSE                 && tabellarische Bearbeitung
LOCATE FOR name = "M"  && sequenzielle Suche
CONTINUE               && nächsten Treffer suchen
GOTO 5 / SKIP 3        && Positionswechsel
REPLACE name WITH "X"  && Feldinhalt ändern
DELETE / PACK / ZAP    && markieren / kompaktieren / leeren
COUNT / SUM / AVERAGE  && Aggregationen
INDEX ON name TO ndx   && Indexdatei bauen
SEEK "M"               && indizierte Suche

Programmierung

Steuerstrukturen wie DO WHILE ... ENDDO, IF ... ELSE ... ENDIF und DO CASE ... ENDCASE erlaubten vollständige Geschäftsanwendungen. Mit SET RELATION TO ... INTO ... verknüpfte man Tabellen über Indexschlüssel — ein früher Vorläufer der JOINs aus SQL-Befehlen.

dBASE gilt als Blaupause für die gesamte PC-Datenbank-Ära. Ihre Syntax lebt in xBase-Befehlen und im Compiler-Nachfolger Clipper weiter.

Ninja ist ein Build-System, dessen oberstes Ziel Geschwindigkeit ist: Es baut nur das neu, was sich tatsächlich geändert hat — und das so schnell wie möglich. Entwickelt wurde Ninja von Evan Martin, die erste Veröffentlichung war 2012. Große Projekte wie Chromium, LLVM und viele CMake-basierte Projekte nutzen Ninja als Build-Backend.

Grundlagen

Ninja liest eine deklarative Beschreibung namens build.ninja: Regeln (rule) definieren, wie aus Eingaben Ausgaben entstehen; build-Anweisungen verdrahten konkrete Dateien mit einer Regel. Ninja verwaltet die Abhängigkeiten selbst und vergleicht Dateizeitstempel, um nur veraltete Ziele neu zu bauen.

rule cc
  command = gcc -c $in -o $out

build hello.o: cc hello.c

Wichtige Ninja-Befehle

• ninja — baut die Standardziele (bzw. ninja ziel ein bestimmtes Ziel)
• ninja -j 16 — parallele Jobs; -k n weiterbauen trotz Fehlern
• ninja -v — ausführliche Ausgabe der Kommandos
• ninja -d explain — zeigt, warum ein Ziel neu gebaut wird
• ninja -C verzeichnis — im angegebenen Verzeichnis bauen
• ninja -t clean — Ausgaben löschen; -t targets Ziele auflisten; -t commands Kommandos zeigen; -t query ziel Abhängigkeiten anzeigen; -t graph als DOT-Graph; -t compdb compile_commands.json erzeugen

Typische Elemente in build.ninja

• build ausgabe: regel eingabe1 eingabe2 — Grundform jeder Kante
• Implizite Abhängigkeiten per |, Nur-Reihenfolge-Abhängigkeiten per ||
• depfile in der Regel — nutzt Compiler-Header-Dependencies
• pool console — begrenzt Jobs und erlaubt direkte Terminalausgabe
• default ziel — Standardziele; build name: phony abhängigkeit — Aliase

Praxis: Generatoren

Ninja wird kaum von Hand geschrieben, sondern von Konfigurationswerkzeugen erzeugt: CMake mit cmake -G Ninja und Meson nutzen Ninja als Backend. Damit kombiniert man die bequeme Konfiguration von CMake mit der Geschwindigkeit von Ninja. Klassische Makefiles werden so zunehmend abgelöst — auch wenn das Make-Ökosystem mit Autotools (m4) historisch die Basis bildet.

Praxis-Tipps

• Kein eigenes Konfigurationssystem: Ninja ist bewusst minimal und verlässt sich auf Generatoren.
• Bei inkrementellen Problemen hilft ninja -d explain, die Neubau-Entscheidung nachzuvollziehen.
• Wie HCL für Terraform ist Ninja ein schlankes Zielformat, das von mächtigeren Werkzeugen erzeugt wird.

HCL (HashiCorp Configuration Language) ist die deklarative Konfigurationssprache von HashiCorp. Sie wurde 2014 zusammen mit Terraform 0.1 eingeführt und wird seither auch in Packer, Consul, Vault und Nomad verwendet. HCL beschreibt einen gewünschten Zustand, den ein Werkzeug anschließend plant und umsetzt.

Grundlagen

HCL2 (seit Terraform 0.12, 2019) besteht aus drei integrierten Teilsprachen: einer Struktursprache für Blöcke und Attribute, einer Ausdruckssprache für Werte und einer Template-Sprache für interpolierte Zeichenketten.

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
  tags = {
    Name = "Webserver"
  }
}

Wichtige HCL-Konstrukte

• resource "typ" "name" { ... } — verwaltete Ressource; data für lesende Datenquellen
• terraform { ... } — Provider- und Backend-Konfiguration; provider "aws" { ... } — Provider-Einstellungen
• variable "name" { ... } / output "name" { ... } — Eingabe- und Ausgabevariablen
• module "name" { source = ... } — wiederverwendbare Module; locals { ... } — lokale Werte
• Attribute: name = wert, z. B. region = "eu-central-1"
• Ausdrücke: Referenzen wie var.name oder aws_instance.web.id, Operatoren, Funktionen wie length(), join(), file(), lookup(), for-Ausdrücke und Splat-Syntax [*]
• count / for_each — Ressourcen mehrfach erzeugen; dynamic-Blöcke — Blöcke aus Daten generieren
• Kommentare: # und // für Zeilen, /* ... */ für Blöcke

Praxis: Terraform

Der typische Ablauf mit Terraform-Befehlen: terraform init lädt Provider und Module, terraform plan zeigt die geplanten Änderungen, terraform apply setzt sie um. Der aktuelle Zustand wird in der State-Datei gespeichert. Terraform ist damit das bekannteste Beispiel für Infrastructure as Code; der quelloffene Fork OpenTofu setzt die gleiche Sprache fort.

terraform fmt        # HCL formatieren
terraform validate   # Syntax und Referenzen prüfen
terraform plan       # Änderungen anzeigen
terraform apply      # Änderungen umsetzen

Praxis-Tipps

• HCL ist deklarativ: Die Reihenfolge der Blöcke spielt keine Rolle, Terraform berechnet die Abhängigkeiten selbst.
• Im Gegensatz zu YAML/TOML/JSON kann HCL Ausdrücke und Interpolation auswerten.
• Wo Makroprozessoren wie m4 früher Konfigurationstexte erzeugten, liefert HCL typisierte, überprüfbare Strukturen.
• Wie Ninja für Builds ist HCL ein Zielformat, das von einem Planungs- und Ausführungswerkzeug interpretiert wird.

m4 ist ein universeller Makroprozessor für Unix: Er liest Text mit eingebetteten Makro-Aufrufen, expandiert die Makros und gibt den erweiterten Text aus. Entwickelt wurde m4 1977 in den Bell Labs von Dennis Ritchie und Brian Kernighan als Frontend für die Programmiersprache Ratfor. GNU m4 ist die heute verbreitete Implementierung und zugleich Kernkomponente des GNU-Autotools-Bausystems.

Grundlagen

m4 verarbeitet einen Eingabetext von links nach rechts. Alles, was kein Makroaufruf ist, wird unverändert ausgegeben; Makros werden durch ihre Definition ersetzt. Makronamen bestehen aus Buchstaben, Ziffern und Unterstrich; Aufrufe folgen dem Muster name(arg1, arg2, ...).

define(PROGRAMM, Hallo Welt)
PROGRAMM
dnl Kommentar bis Zeilenende
ifdef(PROGRAMM, Programm ist definiert, fehlt)

Wichtige m4-Befehle und Makros

• define(name, wert) / undefine(name) — Makro definieren bzw. entfernen; pushdef/popdef legen Definitionen auf einen Stapel
• ifdef(name, dann, sonst) / ifelse(a, b, dann, sonst) — bedingte Expansion
• dnl — verwirft alles bis zum Zeilenende (Kommentar)
• include(datei) / sinclude(datei) — Dateien einbinden
• divert(n) / undivert — Ausgabe in Puffer umleiten
• translit(zeichenkette, von, nach) — Zeichen ersetzen
• regexp(text, regex, ersatz) / patsubst(text, regex, ersatz) — reguläre Ausdrücke
• incr(n), decr(n), eval(ausdruck) — Arithmetik
• len(s), substr(s, anfang, länge), index(s, teil), format(fmt, ...) — Zeichenketten
• esyscmd(befehl) / syscmd(befehl) — Shell-Kommando ausführen und Ergebnis einlesen

Praxis: GNU Autotools

Die wichtigste Anwendung von m4 ist Autoconf: Die Datei configure.ac besteht fast vollständig aus m4-Makros. Autoconf expandiert sie und erzeugt daraus das portierbare configure-Shell-Skript, das anschließend das Make-Build konfiguriert.

AC_INIT([mein-programm], [1.0])
AC_PROG_CC
AC_OUTPUT

Aufruf: m4 datei.m4, Definitionen von außen per m4 -DPROGRAMM=Wert, Include-Pfade per m4 -Iverzeichnis, GNU-Erweiterungen per m4 -P. Das erzeugte configure-Skript ist reine Shell, m4 selbst wird danach nicht mehr benötigt.

Praxis-Tipps

• Makros mit m4_-Präfix (GNU-Modus) vermeiden Kollisionen mit Autoconf-Makros.
• define erlaubt auch mehrzeilige Werte — praktisch für ganze Textbausteine.
• m4 ist bewusst minimal: Für moderne Konfigurationen setzen Projekte zunehmend auf deklarative Sprachen wie HCL oder direkt auf Generatoren wie CMake.

Verwandt: Ninja als moderner Build-Ausführer.