Bash (Shell)

Bash (auch BASH oder bash), die Bourne-again shell, ist eine freie Unix-Shell unter GPL.

Als Shell ist Bash eine Mensch-Maschine-Schnittstelle, die eine Umgebung (englisch environment) bereitstellt, in der zeilenweise Texteingaben und -ausgaben möglich sind. Letzteres erfolgt über die Befehlszeile, in die Befehle eingetippt und durch Betätigen der Eingabetaste eingegeben werden. Gleichzeitig ist Bash eine Skriptsprache, die schon beim Booten vieler Linux-Distributionen zum Einsatz kommt.

Bash ist elementarer Bestandteil des unixähnlichen Betriebssystems GNU und gehört zum GNU-Projekt. Auch bei den meisten auf GNU/Linux aufbauenden Betriebssystemen ist Bash die voreingestellte Shell. Darüber hinaus war Bash 3.x von 2003 bis 2019 die voreingestellte Shell in macOS von Apple (10.3–10.14) – wurde allerdings aus lizenzrechtlichen Gründen nie auf Version 4.0 oder höher aktualisiert.

Der Name Bash ist im Englischen mehrdeutig ([to] bash, [the] bash) und erfuhr im Laufe der Zeit weitere, meist humoristische Bedeutungen.

Brian Fox schrieb die Bash 1987 für das GNU-Projekt und wurde dabei von der FSF bezahlt.[4] 1990 wurde das Projekt von Chet Ramey übernommen. Version 3 erschien am 27. Juli 2004. Version 4 erschien am 20. Februar 2009 und brachte einige Neuerungen mit sich. Darunter sind eine neue Ausgabeumleitung, assoziative Arrays und eine neue Wildcard (**).[5][6] Am 7. Januar 2019 folgte Bash 5, zu den Neuerungen zählten diesmal etliche ergänzte Shellvariablen, eine flexiblere Handhabung der Historie und die Möglichkeit, die Werte lokaler Variablen aus einem übergeordneten Scope zu übernehmen.[7]

• Grundfunktionen
  • beliebige Kommandozeilen ausführen (beliebige Zeichen im Pfad des Kommandos und in den Argumenten; eindeutige Trennung der Argumente)
  • Handhabung der Ein- und Ausgaben von Kommandos (Umleitung, Pipelines)
  • Reaktion auf Erfolgs- und Fehler-Exit-Codes
• Ausführung von Scripten / Shellprogrammierung
  • Expansionen und Substitutionen
  • Kontrollstrukturen
  • Schleifen
  • Tests der Umgebung (Dateisystem, Eingabe- und Ausgabedeskriptoren, Umgebungsvariablen, UID)
  • Bereitstellung von Informationen über den Zustand der Shell
  • Erzeugung beliebiger Zeichen
  • Reaktion auf Signale
  • Debugging
• Arbeitserleichterungen v. a. in interaktiven Shells
  • der Prompt
  • Aliase, Shellfunktionen
  • Editieren der Kommandozeile (Readline)
  • Verwaltung von Vordergrund- und Hintergrundprozessen
  • Kommando-Historie
  • Vervollständigung von Kommandos und Argumenten (mit Standardmethoden und frei programmierbar)
  • Konfiguration des Verhaltens der Shell (v. a. (De-)Aktivierung von Funktionalitäten)
  • Schutzmechanismen (undefinierte/leere Variablen; nichtgehandhabte Fehler von Kommandos; Überschreiben von Dateien; Ressourcenlimits; riskante Funktionalitäten)
  • Reaktion auf nicht gefundene Kommandos

Die Shell ist weitgehend kompatibel zur Bourne-Shell (sh) und beherrscht zusätzlich sowohl die meisten Funktionen der Kornshell (ksh) als auch Teile der C-Shell-Syntax, wie zum Beispiel die Historie zuvor eingegebener Befehle, die $RANDOM-Variable und die POSIX-Form der Befehlssubstitution $(...) wurden übernommen. Einige Elemente wie etwa die **-Wildcard wurden von der Z shell (zsh) übernommen. Auch wurde sie um Funktionen wie z. B. die Ganzzahlarithmetik ohne die Ausführung externer Prozesse und Vereinfachung der I/O-Umleitungen erweitert. Bash bietet anhand ihrer benutzerspezifischen Konfigurationsdatei ~/.bashrc außerdem die Möglichkeit, jedem Benutzer eigene Einstellungen, wie eine individuelle Gestaltung der Eingabeaufforderung (englisch prompt), sitzungsübergreifend zu ermöglichen.

Die Kommandozeile (im weiteren Sinn) aus Sicht des aufgerufenen Programms besteht aus

• dem physischen Pfad der ausgeführten Datei
• dem vom aufrufenden Prozess vorgegebenen Namen des Prozesses
• den Argumenten
• der Standardeingabe (stdin), Standardausgabe (stdout) und Standardfehlerausgabe (stderr)
• den Umgebungsvariablen

Aus Sicht der Shell ist eine Kommandozeile die Eingabe des Benutzers, die dramatisch komplizierter sein kann als das Ergebnis für das aufgerufene Programm. Die Bash erzeugt aus der Eingabe und weiteren Informationen die Daten, aus denen am Ende der Kernel das Programm startet.

Die folgende Tabelle illustriert die Schritte, mit denen die Bash die Eingabezeile bearbeitet. Die betroffenen Mechanismen werden in den folgenden Abschnitten erläutert. Die Reihenfolge orientiert sich am qualitativen Ergebnis aus Benutzersicht, nicht an den Details des Bash-Parsers. Spalten:

• S: Szenarien
• B: ggf. mehrere Beispiele pro Szenario

Formatierungen:

• Der Pfad des Programms, der dem Kernel übergeben wird.
• Argumente, die dem Kernel übergeben werden
• Teil der Eingabe, der im nächsten Schritt bearbeitet wird

Zusatzinformationen: Änderungen an der Vorbereitung des neuen Prozesses (Programms), die weder Programmpfad noch Argument sind. Annahmen:

• alias ls='ls --color=auto'

Für das Verständnis der Kommandozeile ist es wichtig zu wissen, wie die Bash die Zeichen bewertet. Dabei wird unterschieden zwischen Zeichen(kombinationen) mit spezieller Bedeutung und normalen Zeichen (in der folgenden Auflistung passen manche Zeichen in mehrere Kategorien, werden aber nur in der obersten aufgeführt):

• Zeichen, die immer einzeln wirken
  • Quoting-Zeichen: \, ", '
  • Metacharacter (reine Worttrenner): space, tab, newline
  • Metacharacter (Worttrenner mit weiterer Bedeutung): |, &, ;, (, ), <, >
  • veraltete Form der Kommando-Substitution (jetzt: $( )): `
  • Pattern-Matching: *, ?
• Zeichen, die nur als komplettes Wort eine Sonderbedeutung haben
  • Reservierte Wörter (einzelne Zeichen): !, {, }
• Zeichen, die nur am Wortanfang eine Sonderbedeutung haben
  • Tilde-Expansion (Homeverzeichnis): ~
  • Kommentarzeichen: #
• Zeichen, die später in einem Wort eine Sonderbedeutung haben
  • Variablenzuweisung: =
• Zeichen, die am Anfang bestimmter Zeichenfolgen eine Sonderbedeutung haben
  • Variablen, Kommandosubstitution, Arithmetik-Expansion, ANSI-C-Quoting: $
  • einfaches Pattern-Matching: [
  • Pattern-Matching (extglob): @, +
• Zeichen, die später in einer bestimmten Zeichenfolge eine Sonderbedeutung haben
  • Zeichen, die ein Shellkonstrukt beenden: ]
• Reservierte Wörter (Zeichenfolgen): case coproc do done elif else esac fi for function if in select then until while time [[ ]]
• vorbelegte Wörter (abschaltbar)
  • eingebaute Befehle (builtins)
  • Aliase

Die einfachste Kommandozeile besteht aus nur einem Wort und endet mit newline, ;, & oder dem Ende der Eingabe (Script oder bash -c / bash -s). Eine Bash-Eingabezeile kann mehrere Kommandos / Kommandozeilen enthalten.

Ein Zeichen, reserviertes Wort oder ein Alias, der seine Sonderbedeutung verlieren soll, muss mit Quoting geschützt werden. Die Quoting-Zeichen werden dabei (fast immer) entfernt. Quoting schützt auch Quoting-Zeichen:

printf '%s ' \\ \' \" '"' "'" '\' "\\" $'\"\'\\'
\ ' " " ' \ \ "'\

Bei einem reservierten Wort oder einem Alias reicht es aus, dass ein einzelnes Zeichen geschützt wird. Bash kennt vier Quoting-Varianten:

• Der Backslash (\) schützt das folgende Zeichen.
• Einfache ASCII-Anführungszeichen (') schützen ausnahmslos alle folgenden Zeichen bis zum nächsten einfachen ASCII-Anführungszeichen. Wenn man innerhalb einer derart geschützten Zeichenkette ein einfaches ASCII-Anführungszeichen benötigt, dann muss man das Quoting beenden, ein geschütztes einfaches ASCII-Anführungszeichen unmittelbar danach eingeben und dann die Zeichenkette mit erzeugtem Quoting fortsetzen:

  $ printf '%s\n' 'foo ${HOME} ; &   '\''   bar bat < >'
  foo ${HOME}; &   '   bar bat < >
  

• Doppelte ASCII-Anführungszeichen (") schützen alle Zeichen außer `, $ und ggf. \ sowie !. Der Backslash schützt `, $, ", newline und – wenn History-Expansion (die ! nutzt) aktiv ist – auch ! (dies ist der Ausnahmefall, in dem das Quotezeichen nicht entfernt wird, man würde also eher das Quoting unterbrechen: echo "$( date +%F ) "'foo!!bar').
• ANSI-C-Quoting erfüllt eine Doppelfunktion: Es schützt nicht nur Zeichen, sondern ermöglicht die Verwendung spezieller Zeichen über die Escape-Sequenz dieses Zeichens oder die Verwendung des Byte- oder Unicode-Werts.

  $ printf '%s\n' $'foo.\nbar\tbat\x2e 1\u20105'
  foo.
  bar     bat. 1‐5
  

Der Prompt ist eine typischerweise dynamische Zeichenkette, die die Bash ausgibt, wenn sie auf eine Benutzereingabe wartet. Typischerweise wird sie allein von der Bash generiert, aber man kann darüber beliebige Programme aufrufen, was etwa dafür genutzt wird, darin Git-Informationen anzuzeigen, wenn das aktuelle Verzeichnis von Git verwaltet wird.

Aliase sind eine Textersetzung sehr früh im Auswertungsprozess, wodurch sie andere Möglichkeiten haben als beispielsweise Shellfunktionen und Variablen. Sie werden zumeist genutzt, um häufig genutzte Kommandos abzukürzen oder mit Optionen zu ergänzen, etwa l statt ls -lh und ls statt ls --color=auto: alias l='ls -lh' ; alias ls='ls --color=auto'

Shellfunktionen sind im Grunde Shellscripte, die im aktuellen Kontext definiert und ausgeführt werden. Man kann sie, wie in Programmiersprachen üblich, dafür nutzen, die Wiederholung identischen oder sehr ähnlichen Codes zu vermeiden. Wie Aliase können Shellfunktionen den Namen eines externen Kommandos überschreiben, aber im Gegensatz zu Aliasen können sie mit Argumenten arbeiten: function mkcd() { test $# -eq 1 || return 1; mkdir -p "$1" && cd "$1"; }

Die Bash nutzt GNU Readline, um dem Benutzer komplexe Möglichkeiten der Bearbeitung (v. a.) der Kommandozeile vor dem Abschicken (mit Enter) zu bieten:

• Positionierung des Cursors
• Löschen von Teilen der Kommandozeile
• Einfügen gelöschter Teile der Kommandozeile
• letzte Änderungen rückgängig machen
• Vervollständigung von Wörtern
• Einfügen vordefinierter Texte

Ein im Vordergrund laufendes einzelnes Programm oder eine solche Pipeline (zusammenfassend als Job bezeichnet), kann vom Terminal angehalten werden (typischerweise ausgelöst durch Strg-Z), was die Shell (einen neuen Prompt) in den Vordergrund bringt. Man kann dann mit den eingebauten Befehlen (builtins) jobs, fg, bg und kill

• die vorhandenen Jobs anzeigen lassen
• den angehaltenen Job
  • fortsetzen (und im Vordergrund oder Hintergrund laufen lassen)
  • beenden
• einen schon im Hintergrund laufenden Prozess
  • im Vordergrund fortsetzen
  • beenden

Normalerweise schreibt Bash die abgeschickte Kommandozeile in die Kommando-Historie (und diese beim sauberen Beenden in eine Datei). Man kann diese Historie auf mehrere Arten nutzen:

• mit den Pfeiltasten ↑ und ↓ durchblättern
• den Inhalt durchsuchen (typischerweise mit Strg-R)
• den Inhalt anzeigen lassen (mit history oder fc -l)
• den Inhalt bearbeiten und ggf. ausführen (fc)
• mit History-Expansion (!) eine komplette frühere Kommandozeile oder Teile davon (verändern und) einfügen

Mit Tab kann man Kommandonamen, Kommandopfade, Argumente (v. a. Pfade im Dateisystem) und Bash-Elemente (etwa Variablennamen) vervollständigen. Die Grundfunktionen dafür sind in Bash eingebaut, man kann aber Vervollständigungs-Shellfunktionen speziell für ein Programm schreiben, die die Kommandozeilen-Optionen dieses Programms kennen und deshalb gezielt deren Einfügen ermöglichen.

Wenn die Bash ein eingegebenes Kommando nicht findet, kann sie eine Shellfunktion aufrufen, die die Distribution nutzen kann, um darauf zu reagieren. Viele große Distributionen durchsuchen dann die Paketliste und zeigen ggf. dem Benutzer an, welches Paket installiert werden kann, um dieses Kommando verfügbar zu machen.

Die Bash kann in unterschiedlichen Varianten genutzt werden, die sich dadurch unterscheiden,

• ob die Shell interaktiv ist oder als Script läuft
• ob die Shell als externes Kommando mit den Befehlen auf der Kommandozeile (-c) oder Standardeingabe (-s) aufgerufen wird
• ob die Standardeingabe der Shell ein Terminal ist (oder nicht: cat | bash -s, echo echo foo | ssh targethost bash -s)
• ob die Shell als Login-Shell aufgerufen wird (--login oder mit -bash als $0)
• ob die Shell als restricted shell aufgerufen wird (--restricted oder Aufrufname rbash)
• ob die Shell im privileged mode aufgerufen wird (für SUID/SGID, -p)
• mit welchem Namen die Shell aufgerufen wird (bash, sh, rbash)
• mit welchen Argumentoptionen sie aufgerufen wird
• welche set-Optionen gesetzt werden
• welche shopt-Optionen gesetzt werden
• ob POSIX-Konformität erzwungen wird (--posix)

Eine interaktive Shell erwartet Benutzereingaben auf der Standardeingabe (abgesehen von exotischen Spezialfällen mit -i). Das ist normalerweise ein Terminal. Wenn die Bash erkennt, dass die Standardeingabe und die Standardfehlerausgabe ein Terminal sind und dass sie weder ein Dateiargument noch die -c-Argumentoption hat, betrachtet sie sich als interaktiv und produziert einen Prompt. Normalerweise weiß man, ob man sich in einer interaktiven Shell befindet, aber wenn man eine Shellfunktion ausführt, die in beiden Varianten verwendet werden kann, kann man dies mit [[ $- == *i* ]] testen.

Man kann Shellcode in eine Datei – das Script – schreiben und dann entweder die Bash mit dieser Datei als Argument aufrufen oder diese Datei direkt als Kommando, wenn sie ausführbar ist und mit einer Shebang-Zeile (üblicherweise #! /bin/bash oder #! /usr/bin/bash) beginnt. Eine überschaubare Menge an Shellcode, der in einer unabhängigen, frisch initialisierten Shell laufen soll, kann man mit bash -c 'echo foo; echo bar' ausführen. Anstatt ein Script erst auf ein anderes System zu kopieren und dort über Umgebungsvariablen (ssh targethost env var=foo /path/to/script.sh) oder Argumente zu konfigurieren, kann man auch eine Shell starten, die ihre Eingaben via SSH aus einem Script (v. a. mit einem Here-Document, in dem man die Variablen bequem setzen kann) bekommt:

{
    cat <<-EOT # weil EOT nicht gequotet ist, wird ${var} ersetzt
    var='${var}'
    EOT
    cat <<-'EOT'
    # hier kann ein langes Script stehen
    # der Code wird wegen des 'EOT'-Quotings literal übermittelt...
    EOT
} | ssh host bash -s

In einer nichtinteraktiven Shell gibt es keinen Prompt und wird Readline nicht verwendet. Außerdem sind einige Funktionen deaktiviert (aber aktivierbar): Aliase, history expansion und job control. Es werden keine Startdateien abgearbeitet, es sei denn in der Umgebungsvariable BASH_ENV ist ein solcher Pfad definiert oder die Bash erkennt, dass ihre Standardeingabe an einer SSH-Verbindung hängt.

Die Bash verhält sich anders, wenn sie als Login-Shell gestartet wird. Der Name bezieht sich darauf, dass Login-Shells zumeist von Daemonen (SSH) und ähnlichen Programmen (login auf den virtuellen Konsolen, su und sudo in einer Shell) erzeugt werden. Dies sind Programme, die mit root-Rechten laufen und deshalb die Möglichkeit haben

• eine Authentifizierung durchzuführen
  • über eigene Methoden (SSH mit Schlüsseln)
  • oder über die Methoden des Systems (v. a. Passwortprüfung, unter Linux via PAM)
• eine Shell als ein beliebiger Benutzer zu starten (eine root-Shell ist nicht automatisch eine Login-Shell)

Eine Login-Shell ist dafür gedacht, der erste vom Benutzer konfigurierbare Prozess in einer Prozesshierarchie zu sein. Nur der erste Prozess muss bestimmte Einstellungen vornehmen, da diese an seine Kindprozesse vererbt werden. Deshalb ist die Initialisierung einer Login-Shell umfangreicher als die einer normalen Shell. Die bash-spezifische Initialisierung ist normalerweise für beide Arten identisch. Die Bash erkennt auf zwei Arten, dass sie als Login-Shell laufen soll:

• Der Kommandoname in $0, der von dem aufrufenden Programm gesetzt wird, beginnt mit - (-bash, -sh, -rbash).
• Sie wird mit der Argumentoption -l / --login aufgerufen.

Man kann mit shopt login_shell herausfinden, ob eine Shell eine Login-Shell ist.

Die Bash wird durch eine Reihe von Konfigurationsdateien konfiguriert. Hierbei ist zu unterscheiden zwischen systemweiter und benutzerspezifischer Konfiguration.

Eine Login-Shell liest zuerst die systemweite Konfigurationsdatei /etc/profile ein und führt die darin enthaltenen Anweisungen aus; dies kann (auch für die folgenden, benutzerspezifischen Dateien) mit der Argumentoption --noprofile unterbunden werden. Manche Distributionen inkludieren von dieser Datei aus die /etc/bash.bashrc und die ~/.bashrc. Danach prüft Bash im Benutzerverzeichnis der Reihe nach, ob ~/.bash_profile, ~/.bash_login und ~/.profile existieren, wobei nur die erste gefundene Datei abgearbeitet wird. Wenn sich eine interaktive Login-Shell beendet oder eine nicht-interaktive Login-Shell den eingebauten Befehl (builtin) exit ausführt, wird die Datei ~/.bash_logout abgearbeitet, sofern vorhanden.

Eine interaktive Nicht-Login-Shell arbeitet die Dateien /etc/bash.bashrc und ~/.bashrc ab. Mit --norc kann dies unterbunden werden. Mit --rcfile kann man eine andere benutzerspezifische Konfigurationsdatei festlegen.

In einer nichtinteraktiven Shell werden keine Startdateien abgearbeitet, es sei denn in der Umgebungsvariable BASH_ENV ist ein solcher Pfad definiert oder die Bash erkennt, dass ihre Standardeingabe an einer SSH-Verbindung hängt (oder an einer anderen Netzwerkverbindung wie rsh, was aber heute nicht mehr relevant ist). Im SSH-Fall werden die Dateien /etc/bash.bashrc (die üblicherweise prüft, ob /etc/profile inkludiert wurde und dies ggf. nachholt) und ~/.bashrc abgearbeitet, allerdings wird BASH_ENV dort nicht beachtet.

Bash hat zwei Kategorien von Konfigurationsmöglichkeiten, die von unterschiedlichen eingebauten Befehlen (builtins) verwaltet werden: set und shopt. Beide können auch beim Aufruf der Shell über Argumentoptionen konfiguriert werden.

Die set-Konfigurationen kann man auf drei Arten ändern: Jede Option hat einen Namen (etwa noglob), fast jede auch einen einzelnen Buchstaben für eine Kommandozeilenoption, sowohl für set als auch für den Aufruf der Bash selber (in diesem Fall -f).

set -f / set -o noglob setzt die Option, set +f / set +o noglob löscht sie. Gesetzte Optionen (denen ein Buchstabe zugeordnet ist) werden der Variable $- hinzugefügt (und ggf. dort herausgelöscht). Alternativ kann man diese Optionen über die Umgebungsvariable SHELLOPTS (vor dem Start der Bash) setzen.

$ bash -c 'echo -n /e?c; echo "   $-"'
/etc   hBc
$ bash -c 'set -f ; echo -n /e?c; echo "   $-"'
/e?c   fhBc
$ bash -f -c 'echo -n /e?c; echo "   $-"'
/e?c   fhBc

Die aktuelle Konfiguration kann mit set -o angezeigt werden. Mit set +o bekommt man eine Ausgabe, die als Kommandoliste verwendet werden kann, um den aktuellen Zustand wiederherzustellen (errexit muss allerdings gesondert behandelt werden, weil es nicht verlässlich in eine Subshell vererbt wird):

# aktuellen Stand sichern
$ set_restore="$( set +o )"
set +o | grep -q 'set -o errexit' && set_restore+=$'\nset -o errexit\n'
# Konfiguration ändern
$ set -o allexport
# gesicherten Stand wiederherstellen
$ eval "$set_restore" 2>/dev/null # ggf. irrelevante Fehlermeldungen ignorieren

In einer Shellfunktion kann man mit local - die Änderung von set-Optionen auf den Bereich der Funktion begrenzen.

Die shopt-Konfigurationen kann man auf drei Arten ändern: Jede Option hat einen Namen (etwa extglob), anders als bei set aber keine Buchstaben-Abkürzung. In der laufenden Shell kann man eine Option mit shopt -s extglob setzen und mit shopt -u extglob löschen. Die Bash-Argumentoption ist -O extglob für das Setzen und +O extglob für das Löschen einer Option. Alternativ kann man diese Optionen über die Umgebungsvariable BASHOPTS (vor dem Start der Bash) setzen.

Mit shopt / shopt extglob nullglob kann man sich den Status für alle oder einzelne Konfigurationen ansehen; mit shopt -s nur den der aktiven, mit shopt -u nur die inaktiven. Anders als bei set kann man für shopt-Optionen direkt abfragen, ob sie (einzeln oder als Gruppe) aktiv sind: shopt -q extglob, shopt -q extglob nullglob. Sichern und wiederherstellen kann man den aktuellen Stand mit:

# aktuellen Stand sichern
$ shopt_restore="$( shopt -p )"
# Konfiguration ändern
$ shopt -s nullglob
# gesicherten Stand wiederherstellen
$ eval "$shopt_restore"

Eine Subshell ist ein Kindprozess von bash, der als diese Shell weiterläuft, also sich nicht mittels execve() neu initialisiert (typischerweise als ein anderes externes Kommando). Wenn bash ausdrücklich einen neuen bash-Prozess startet,

$ bash -c 'echo foo'

dann ist dies keine Subshell, sondern nur „zufällig“ ein bash-Prozess, der aber genauso erzeugt wurde und genauso unabhängig von seiner Elternshell ist, wie jedes andere externe Kommando.

Da die Subshell eine (fast) exakte Kopie ist, die den normalen Shell-Initialisierungsprozess nicht durchläuft, hat man Zugriff auf dieselben Variablenwerte wie in der Hauptshell. Man kann eine Subshell auf folgenden Wegen erkennen:

• Die Variable $BASH_SUBSHELL wird inkrementiert.
• In einer normalen Shell sind $$ und $BASHPID identisch. In einer Subshell enthält $$ die Prozess-ID der aufrufenden Shell; dies ist zumeist die Elternshell, kann aber auch eine frühere Elterngeneration sein: echo $BASHPID $$ ; ( echo $BASHPID $$ ; ( echo $BASHPID $$ ) )

Eine Subshell kann die Elternshell nicht beeinflussen, deshalb kann man sie explizit nutzen, um keine Rücksicht darauf nehmen zu müssen, dass man die Shellkonfiguration ändert:

$ if ( shopt -s nullglob extglob ; set -- foo_@(xy|yz)_bar.txt ; test $# -eq 0) ; then
echo 'ERROR: Datei nicht vorhanden'
fi

Man kann Subshells auch nutzen, um Kommandos zusammenzufassen, etwa für die Ein- oder Ausgabeumleitung, aber dafür benötigt man keine Subshell, das kann man genauso mit einem group command erreichen:

$ ( echo foo ; echo bar ; echo bat ) | grep a
$ { echo foo ; echo bar ; echo bat;} | grep a

In manchen Situationen erzeugt bash automatisch Subshells:

• Pipelines
  • grep -v '^\s*#' *.conf | grep user
  • Die Elemente einer Pipeline laufen gleichzeitig, es müssen also zwangsläufig Kindprozesse erzeugt werden. Bevor die eigentlichen Prozesse der Pipeline-Elemente gestartet werden, werden die Dateideskriptoren 0 (stdin) und 1 (stdout) der Kindprozesse so miteinander verbunden, wie die Pipelinestruktur dies vorsieht.
  • Mit shopt -s lastpipe (wenn job control deaktiviert ist, also vor allem in Shellscripten) kann man das letzte Element einer Pipeline in der Hauptshell laufen lassen (was nur bei internen Shellkommandos (eingebauten Befehlen (builtins); Funktionen; compound commands) ein Unterschied ist).
• command substituion
  • $ echo "Das heutige Datum ist: $( date )"
• process substitution
  • diff <( grep -v '^\s*#' file-1 ) <( grep -v '^\s*#' file-2 )
• Hintergrundprozesse
  • long_running_command &
• Koprozess-Hintergrundprozesse
  • coproc grep foo

Subshells können durchaus hinderlich sein:

# in einer Shell ohne lastpipe
$ echo foo | read line
$ echo "$line"

# keine Ausgabe

Das read line wird in einer Subshell ausgeführt. Dort wird die Variable $line erstellt, aber dies erzeugt keine Variable in der Hauptshell.

Die Bash enthält zahlreiche eingebaute Befehle und reservierte Wörter. Zu den eingebauten Befehlen zählen beispielsweise alias, cd, echo, exit, help, kill, logout oder pwd und zu den reservierten Wörtern zählen die für die Bash-Programmierung nötigen Schlüsselwörter wie case, for, function oder while.

Bash bietet drei Varianten von Pattern Matching:

• Wildcards (Platzhalter)
• extglob (extended globbing)
• erweiterte reguläre Ausdrücke

Als Wildcards verwendet die Bash

• * für beliebig viele Zeichen (also auch keines)
• ** nur pathname expansion: alle Dateien, Verzeichnisse und deren Unterverzeichnisse
• **/ nur pathname expansion: alle Verzeichnisse und deren Unterverzeichnisse
• ? für genau ein beliebiges Zeichen
• [...] für genau eins der zwischen den eckigen Klammern aufgelisteten Zeichen
• [^...] / [!...] für genau ein Zeichen, das nicht zwischen den eckigen Klammern aufgelistet ist
• [a-eF-J0-4] für genau eins der Zeichen aus einem Zeichenbereich, der durch das Locale (Sortierreihenfolge) oder die Shelloption globasciiranges (auf C) festgelegt wird
• [[:class:]] für genau eins der Zeichen aus einer Zeichenklasse
• [[=,=]] für genau eins der Zeichen aus der Äquivalenzklasse (z. B. ,, ;, .) des angegebenen Zeichens

Die verfügbaren Zeichenklassen sind dieselben wie bei regulären Ausdrücken: [:alnum:], [:alpha:], [:ascii:], [:blank:], [:cntrl:], [:digit:], [:graph:], [:lower:], [:print:], [:punct:], [:space:], [:upper:], [:word:], [:xdigit:]

Mit shopt -s extglob kann man extended globbing aktivieren. Diese Funktion stellt fünf Klammerausdrücke zur Verfügung, die einen oder mehrere alternative Muster enthalten, die wiederum Wildcards und Klammerausdrücke enthalten können: @(foo|bar) passt auf entweder foo oder bar.

Wenn sich ein Klammermuster wiederholen darf (*(foo), +(foo)), dann bezieht sich die Wiederholung auf das Muster, nicht auf das Zeichen, das beim ersten Mal getroffen wurde! Der Klammerausdruck kann also eine Zeichenkette aus unterschiedlichen Zeichen treffen.

Die Bash unterstützt erweiterte reguläre Ausdrücke. Diese stehen nur in dieser Form zur Verfügung:

[[ $zeichenkette =~ $pattern ]], z. B. [[ $zeichenkette =~ ^.*\.txt~?$ ]]

Beide Varianten können sowohl in abstraktem pattern matching mit beliebigen Zeichenketten als auch mit pathname expansion verwendet werden.

Beliebige Zeichenketten können mit dem [[ ]]-Kommando getestet werden:

• [[ foo == f[o]? ]] / [[ foo != f[o]? ]]
• [[ $dateiname == *.conf ]] / [[ $dateiname != *.conf ]]
• [[ $systemd unit name == *.@(service|target|mount|timer) ]]

Pathname expansion ist die allgemein bekannte Verwendung von Wildcards zum Erfassen aller oder nur bestimmter real existierender Dateinamen / Dateipfade. Vor Bash 4.0 war pathname expansion nur in einer bestimmten Verzeichnisebene möglich (keine Rekursion). Inzwischen kann man mit shopt -s globstar das rekursive Erfassen aller Unterverzeichnisse mittels ** aktivieren.

Für die folgenden Beispiele werden mit den Kommandos

mkdir -p subdir/subsubdir ; touch datei datei{1..3} datei{,1,2}.{txt,conf} archiv.tar subdir/{,subsubdir/}archiv.tar

diese Dateien und Unterverzeichnisse angelegt:

datei datei1 datei2 datei3 datei.txt datei.conf datei1.txt datei1.conf datei2.txt datei2.conf archiv.tar subdir/archiv.tar subdir/subsubdir/archiv.tar

Die Shelloption nullglob (shopt -s nullglob) steuert die Reaktion der Bash, wenn ein Muster bei pathname expansion keine Treffer generiert. Standardmäßig ist diese Option abgeschaltet, dann bleibt das Muster unverändert stehen, was selten sinnvoll ist, wenn pathname expansion beabsichtigt war. Es funktioniert, wenn eine Zeichenkette mit Wildcards als Argument übergeben werden soll, etwa in

find. -type f -name *.conf

Aber solche Aufrufe sollte man grundsätzlich vermeiden und immer mit Quoting arbeiten (-name '*.conf'). Wenn die Shelloption nullglob angeschaltet ist, wird das Muster komplett aus der Kommandozeile entfernt. Auch das kann unerwünscht sein. Es gibt zwei Möglichkeiten, den Fall fehlender Treffer zu handhaben:

• explizit: if ( shopt -s nullglob ; set -- *pattern* ; (( $# )) ) ; then...
• Man setzt die Shelloption failglob (shopt -s failglob), dann führt die Shell die Kommandozeile gar nicht erst aus, wenn eins der Muster in der Kommandozeile keine Treffer generiert:

  $ echo *nomatch*
  bash: Keine Entsprechung: *nomatch*
  
  # oder
  if ( shopt -s failglob;: *nomatch* ) 2>/dev/null; then...
  

Man kann nullglob auch ohne „echtes“ pattern matching nutzen, um Einträge aus einer Argumentliste zu entfernen, wenn die entsprechende Datei nicht existiert:

$ touch datei_existiert
$ echo datei_existier[t] datei_existiert_nich[t]
datei_existiert
$ touch datei_existiert_nicht
$ echo datei_existier[t] datei_existiert_nich[t]
datei_existiert datei_existiert_nicht

Mit der Shelloption nocaseglob (shopt -s nocaseglob) kann man dafür sorgen, dass die Groß-Klein-Schreibung bei der Trefferprüfung ignoriert wird.

Mit der Shell-Variable GLOBIGNORE kann man Treffer herausfiltern. Ist diese Variable nicht leer, wird die Shelloption dotglob automatisch gesetzt und werden die Treffer . und .. immer ignoriert.

Pathname expansion erfasst standardmäßig keine versteckten Dateinamen; das sind diejenigen, die mit einem Punkt . beginnen. Es gibt zwei Möglichkeiten, diese Dateien zu erreichen:

• Man adressiert sie direkt, indem man das Suchmuster (innerhalb des Verzeichnisses) mit einem Punkt beginnen lässt. Das hat den Nachteil, dass man nur diejenigen Einträge erfasst, die mit einem Punkt beginnen.
• Mit der Shelloption dotglob (shopt -s dotglob) erfasst * auch versteckte Dateien – mit Ausnahme von . und .., die man also ggf. hinzufügen muss (typischerweise will man die gar nicht in den Ergebnissen haben): ls -ld... *

Die Shelloption globskipdots (shopt -s globskipdots) sorgt dafür, dass bei Verwendung des Musters .* die Verzeichnisse . und .. nicht getroffen werden.

Konsolenprogramme – auch die Bash – kommunizieren nicht nur beim expliziten Arbeiten mit Dateien mit Hilfe sogenannter Dateideskriptoren. Das sind ganze Zahlen, beginnend bei Null. Die Zahlen 0, 1 und 2 sind dabei vorbelegt:

• 0: stdin, die Standardeingabe; normalerweise die Tastatur bzw. das (Pseudo-)Terminal (das seine Eingaben auch auf anderem Weg erhalten kann, etwa per SSH).
• 1: stdout, die Standardausgabe, normalerweise das Terminal oder eine Pipeline (verbunden mit der Standardeingabe eines anderen Programms)
• 2: stderr, die Standardfehlerausgabe, normalerweise ebenfalls das Terminal

Ein Programm kann zwar prüfen, ob ein I/O-Deskriptor mit einem Terminal verbunden ist (bash: if [ -t 1 ]; then), aber normalerweise muss ein Programm das nicht wissen und macht in allen Fällen dasselbe. Häufigste Ausnahme ist die Formatierung: Auf dem Terminal wird in Farbe ausgegeben, aber in einer Pipeline oder Datei würden die ANSI-Escape-Sequenzen zumeist nur stören, deshalb wird dorthin unformatiert geschrieben. Wenn man wissen will, welches das aktuelle Terminal ist, kann man den (nicht bash-spezifischen) Befehl tty verwenden:

$ tty
/dev/pts/92

Falls ein Programm von der Standardeingabe lesen soll, aber zwingend eine Qualldatei erwartet, kann man sich mit cat datei | programm oder (unter Linux) mit programm /dev/stdin behelfen.

Die häufigste Form der expliziten I/O-Konfiguration ist die Umleitung der Standard-Deskriptoren (innerhalb einer Pipeline kümmert sich die Bash automatisch um die nötigen Anpassungen). Die Umleitungsanweisungen können an beliebiger Stelle in der Kommandozeile stehen. Die Bash wertet sie aus und „entfernt“ sie, bevor das Kommando gestartet wird. Das Kommando sieht die Umleitungen nicht als eigenes Argument. Zwischen dem Umleitungszeichen und einem folgenden Dateinamen kann ein Leerzeichen stehen, muss aber nicht. Bei der Umleitung auf einen bestehenden Deskriptor (>&2) darf kein Leerzeichen folgen.

• Wegwerfen der Standardfehlerausgabe. Oftmals will man die Fehlermeldungen nicht sehen:

  $ find /etc/selinux -name '*.LOCK'
  /etc/selinux/targeted/semanage.read.LOCK
  /etc/selinux/targeted/semanage.trans.LOCK
  find: ‘/etc/selinux/targeted/active’: Keine Berechtigung
  find: ‘/etc/selinux/final’: Keine Berechtigung
  
  $ find /etc/selinux -name '*.LOCK' 2>/dev/null
  /etc/selinux/targeted/semanage.read.LOCK
  /etc/selinux/targeted/semanage.trans.LOCK
  

• Umleiten der Standardausgabe in eine Datei

  $ find /etc -type f 2>/dev/null >~/find-etc.txt
  

• Umleiten der Standardeingabe auf eine Datei (d. h. Lesen aus der Datei statt vom Terminal)

  $ while IFS= read -r line; do printf '%s: %s\n' "$inputfile" "$line"; done < "$inputfile"
  

• Umleiten eines Deskriptors auf den anderen, z. B. die stdout-Ausgabe eines Kommandos auf stderr lenken:

  $ echo foo 1>&2 # oder: echo foo >&2
  

Bei der Eingabeumleitung ist der Standard-Deskriptor 0, bei der Ausgabeumleitung 1. Deshalb kann man statt 0< einfach < verwenden und statt 1> einfach >.

Man kann beide Ausgaben gleichzeitig umleiten:

• beide wegwerfen:
  • beide explizit (Reihenfolge ist egal):
    • $ bash -c 'echo foo >&1 ; echo bar >&2' >/dev/null 2>/dev/null
  • beide Deskriptoren gleichzeitig umleiten:
    • $ bash -c 'echo foo >&1 ; echo bar >&2' &>/dev/null
  • einen Deskriptor explizit umleiten, den anderen auf den ersten kopieren; hier ist die Reihenfolge entscheidend!
    • funktioniert: $ bash -c 'echo foo >&1 ; echo bar >&2' >/dev/null 2>&1
    • funktioniert nicht: $ bash -c 'echo foo >&1 ; echo bar >&2' 2>&1 >/dev/null
• getrennt umleiten (Reihenfolge ist egal):
  • $ find /etc -type f 2>/dev/null >~/find-etc.txt

Die meisten Programme, die eine Eingabe bearbeiten können (grep, awk, sed, cut, cat, nl, fold, …) können direkt mit einer Datei aufgerufen werden, es gibt also selten Grund für grep < file statt grep file. Allerdings schafft die Umleitung ein hohes Maß an Gewissheit, dass das Programm die Datei nicht verändert.

Mit >> statt > kann die Ausgabe an eine bestehende Datei angehängt werden, anstatt die Datei zu überschreiben.

Bei einer Ausgabeumleitung wird die Datei angelegt, wenn sie noch nicht existiert. Eine bestehende Datei wird (ohne Warnung) überschrieben. Wenn man eine Datei nicht löschen, sondern nur ihre Größe auf Null setzen möchte, kann man das also hiermit tun:

$ echo foo >datei
$ ls -l datei
-rw-r----- 1 hl hl 4 19. Aug 02:07 datei # Größe 4 Byte für foo und den Zeilenumbruch am Ende
$ >datei
$ ls -l datei
-rw-r----- 1 hl hl 0 19. Aug 02:09 datei

Wenn man nicht riskieren möchte, dass man eine bestehende Datei versehentlich überschreibt, kann man dies mit der Shelloption noclobber (set -o noclobber) unterbinden.

$ >datei
bash: datei: Kann existierende Datei nicht überschreiben

Man kann dann entweder vor der Umleitung die Datei löschen oder statt > den Umleitungsoperator >| verwenden.

Anstatt pro Kommando einen der Standard-Deskriptoren umzuleiten, kann man dauerhaft weitere anlegen (bis 9 problemlos, bei größeren Werten sollte man prüfen (unter Linux mit test -e /proc/self/fd/42), ob der Deskriptor frei ist, oder die bash mit {varname}>datei einen freien (oberhalb von 9) auswählen lassen). Neue Deskriptoren legt man mit dem eingebauten Shellkommando (builtin) exec an.

• 4 zum Lesen öffnen
  • exec 4<datei_read
  • read line <&4
• 5 zum Schreiben öffnen
  • exec 5>datei_write
  • echo foo >&5
  • echo bar >&5 # überschreibt die Datei trotz > nicht, weil der Deskriptor nicht neu geöffnet wird
• 6 zum Anhängen öffnen
  • exec 6>>datei_append
  • echo foo >&6 # kein >> erforderlich, weil der Deskriptor schon für Anhängen geöffnet ist
  • echo bar >&6
• 7 zum Lesen und Schreiben öffnen
  • exec 7<>datei_read_write
  • read line <&7
  • echo bar >&7
• beliebigen freien Deskriptor (größer 9) zum Lesen öffnen
  • exec {fdname}<datei_read
  • read line <&${fdname}

Einen Deskriptor gleichzeitig zum Lesen und Schreiben zu öffnen ist nicht immer sinnvoll, weil jeder Deskriptor nur eine gemeinsame Position für Lesen und Schreiben hat und deshalb beide Zugriffsarten einander in die Quere kommen können. In diesen Fällen öffnet man unterschiedliche Deskriptoren explizit (keine 5>&4-Deskriptor-Duplikation) auf dieselbe Datei, einen zum Lesen, den anderen zum Schreiben. Schließen kann man einen Deskriptor mit exec 10>&-. Die Variante echo foo {fdname}>datei_write erzeugt auch ohne exec einen dauerhaften Deskriptor (sofern die Shelloption varredir_close nicht gesetzt ist: shopt -s varredir_close).

Unter Linux kann man sich das Ergebnis der unterschiedlichen Varianten so ansehen:

$ ls -l /proc/self/fd
insgesamt 0
lrwx------ 1 hl hl 64 19. Aug 03:04 0 -> /dev/pts/92
lrwx------ 1 hl hl 64 19. Aug 03:04 1 -> /dev/pts/92
lrwx------ 1 hl hl 64 19. Aug 03:04 2 -> /dev/pts/92
lr-x------ 1 hl hl 64 19. Aug 03:04 3 -> /proc/1375879/fd
lr-x------ 1 hl hl 64 19. Aug 03:04 4 -> /.../datei_read
l-wx------ 1 hl hl 64 19. Aug 03:04 5 -> /.../datei_write
l-wx------ 1 hl hl 64 19. Aug 03:04 6 -> /.../datei_append
lrwx------ 1 hl hl 64 19. Aug 03:04 7 -> /.../datei_read_write

$ head /proc/self/fdinfo/5 /proc/self/fdinfo/6
== > /proc/self/fdinfo/5 < ==
pos:    0
flags:  0100001
mnt_id: 114
ino:    19764409

== > /proc/self/fdinfo/6 < ==
pos:    0
flags:  0102001
mnt_id: 114
ino:    19764578

Der Unterschied zwischen > und >> zeigt sich nicht in den /proc-Zugriffsrechten, sondern erst in den unterschiedlichen (oktalen, nicht zwingend auf allen Linux-Systemen identischen) Flags in /proc/self/fdinfo:

Ein Here-Document ist eine Komfort-Funktion zur besseren Handhabung längerer, insbesondere mehrzeiliger Texte. Die Bash behandelt alle Zeilen zwischen der Zeile mit dem Startoperator und der Start-Zeichenkette und der Zeile mit der Ende-Zeichenkette als Inhalt, der auf die Standardeingabe des jeweiligen Kommandos geschrieben wird, so wie cat datei | cmd dies täte, wenn der Text in einer gesonderten Datei stünde. Allerdings gibt es zwei Kategorien für unterschiedliche Betriebsarten:

• Quoting:
  • Wenn das nach dem Startoperator << festgelegte Wort gequotet ist, dann ist die Ende-Zeichenkette (häufig EOT für end of text) das Wort ohne die Quotezeichen und wird der Inhalt literal ausgegeben.
  • Bei einer nicht gequoteten Start-Zeichenkette Werden Parameter-Expansion (${HOME}), Command-Substitution ($( date )) und Arithmetic-Expansion ($((2+3))) auf den Inhalt angewendet, und ein Backslash am Zeilenende und der folgende Zeilenumbruch werden entfernt, was die Ende-Zeichenkette in der nächsten Zeile aufhebt. \, $ und ` können mit \ gequotet werden, um sicherzugehen, dass sie literal verwendet werden:

    $ cat <<EOT
    foo ${HOME} bar $( date +%F ) bat $(( 2+5 )) \$ \` \\ _\
    bar
    bat\
    EOT
    EOT
    
    # Ausgabe ist:
    foo /home/hl bar 2026-08-20 bat 7 $ ` \ _bar
    batEOT
    
    $ cat <<'E O T'
    foo ${HOME} bar $( date +%F ) bat $(( 2+5 )) \$ \` \\ _\
    bar
    bat\
    E O T
    E O T
    
    # Ausgabe ist:
    foo ${HOME} bar $( date +%F ) bat $(( 2+5 )) \$ \` \\ _\
    bar
    bat\
    test.sh: Zeile 16: E: Kommando nicht gefunden
    

• Tabulator-Einrückung: Damit die Inhaltszeilen und die Ende-Zeichenkette die Einrückungsformatierung des Scripts nicht stören, hat man die Möglichkeit, statt << den Operator <<- zu verwenden, wodurch dann Tabulatoren am Zeilenanfang ignoriert werden; sowohl bei den Inhaltszeilen als auch bei der Ende-Zeichenkette:

  function testf {
          if [ "${condition1}" = '1' ]; then
                  if [ "${condition2}" = '1' ]; then
                          cat <<EOT
  foo ${HOME} bar $( date +%F ) bat $(( 2+5 ))
  EOT
                  fi
          fi
  }
  
  
  function testf {
          if [ "${condition1}" = '1' ]; then
                  if [ "${condition2}" = '1' ]; then
                          cat <<-EOT
                          foo ${HOME} bar $( date +%F ) bat $(( 2+5 ))
                          EOT
                  fi
          fi
  }
  

Here-Strings sind eine kleinere Variante eines Here-Documents. Man kann ein Kommandozeilen-Wort zur Standardeingabe eines Kommandos machen. Zusätzlich zu den Expansions bei Here-Documents steht hier zusätzlich Tilde-Expansion zur Verfügung:

# cat ist unkritisch, zeigt hier nur die Expansionen
$ cat <<<~hl/"   foo ${HOME} bar $( date +%F ) bat $(( 2+5 ))"
/home/hl/   foo /home/hl bar 2026-08-20 bat 7

$ read hash rest <<<"$( echo foo | sha1sum )"
declare -p hash
declare -- hash="f1d2d2f924e986ac86fdf7b36c94bcdf32beec15"

Dies ist eine überlegene Alternative zu

$ printf '%s\n' ~hl/"   foo ${HOME} bar $( date +%F ) bat $(( 2+5 ))" | cat

# read in einer Pipeline ist kritisch; funktioniert nur mit lastpipe und inaktiver Job-Steuerung
$ echo foo | sha1sum | read hash rest
declare -p hash
bash: declare: hash: Nicht gefunden.

wenn man das Kommando in der normalen Shellumgebung (statt in einer Subshell) ausführen muss, etwa weil man Variablen setzt. Der Vorteil des Here-Strings ist, dass er unabhängig von der Shelloption lastpipe funktioniert.

Man kann auch auf /dev/tcp/host/port und /dev/udp/host/port umleiten (dies sind keine real existierenden Pfade, sondern spezielle Konstrukte, die Bash erkennt):

exec 4<>/dev/tcp/localhost/80
printf 'GET / HTTP/1.0\r\n\r\n' >&4; cat <&4

Mit der Pipe (|) lassen sich Kommandos verketten, indem die Ausgabe des ersten mit der Eingabe des zweiten Kommandos verbunden wird, was sich (fast) beliebig verlängern lässt:

user@blablubb:~/test$ ls -l /etc | grep '^d' | wc -l

Der Mechanismus der Umlenkung der Standardkanäle und die Pipe sind keine Besonderheit der Bash.

In der Bash gibt es unterschiedliche Arten von Variablen, die sich in ihrem Namensraum, ihren Attributen und dem Typ ihres Inhalts unterscheiden:

• Namensräume
  • innerhalb von Bash
    • globale Variablen
      • Wenn eine Variable im Hauptprogramm oder ohne local in einer Funktion definiert wird, steht sie überall im Programm zur Verfügung: var='value'
    • lokale Variablen
      • In einer Funktion kann eine Variable mit dem eingebauten Befehl (builtin) local / declare / typeset deklariert werden, was sie zu einer Variable macht, die nur in dieser Funktion (und von ihr aufgerufenen Funktionen) sichtbar ist.
  • außerhalb von Bash
    • Umgebungsvariablen für Bash
      • Umgebungsvariablen werden vom Elternprozess festgelegt (zumeist schlicht vererbt). Umgebungsvariablen stehen in der Bash unmittelbar zur Verfügung: echo "\$HOME: ${HOME}"
    • exportierte Variablen für Kindprozesse
      • Wenn die Bash ein externes Kommando ausführt, werden nur die Variablen mit dem Attribut export zu Umgebungsvariablen für das externe Kommando. Die Umgebungsvariablen der Bash haben dieses Attribut automatisch gesetzt. Standardmäßig haben Kindprozesse der Bash also dieselben Umgebungsvariablen wie die Bash.
      • Das Attribut export kann bei der Erzeugung einer Variable oder auch später gesetzt (und sogar gelöscht) werden: export var='value' / declare -x var='value' / typeset -x var='value'

      • $ var='value'
        $ declare -p var
        declare -- var="value"
        $ export var
        $ declare -p var
        declare -x var="value"
        $ declare +x var
        $ declare -p var
        declare -- var="value"
        

• Attribute (Auswahl)
  • nur-lesen (-r)
  • integer (-i)
    • Eine Zeichenkette wird bei Zuweisungen als arithmetischer Ausdruck betrachtet und entsprechend ausgewertet.

    • $ var=5
      $ var+=1
      $ declare -p var
      declare -- var="51"
      $ var=5
      $ declare -i var
      $ var+=1
      $ declare -p var
      declare -i var="6"
      

  • nameref (-n)
    • Das Attribut nameref führt eine weitere Möglichkeit der Indirektion ein. Anstatt auf die Variable NAME zuzugreifen, wird auf die Variable zugegriffen, deren Name der Wert von NAME ist. Während echo "${!varname}" nur lesend funktioniert, kann man mit varname='foo' die referenzierte Variable überschreiben.

    • $ var='value'
      $ varname='var'
      $ echo "${!varname}"
      value
      $ varname='newvar'
      $ echo "${!varname}"
      
      $ declare -n varname='var'
      $ echo "${!varname}"
      var
      $ echo "${varname}"
      value
      $ varname='foo'
      $ echo "${varname}"
      foo
      $ echo "${var}"
      foo
      $ declare -p varname
      declare -n varname="var"
      

• Typen
  • Zeichenketten
    • Standardmäßig sind Bash-Variablen Zeichenketten (die im Bedarfsfall automatisch als ganze Zahlen interpretiert werden).
  • indizierte Arrays
    • declare -a iarray=( 'foo' 'bar' 'bat' ) erzeugt ein Array, auf dessen Elemente mit numerischen Indizes (natürliche Zahlen inklusive Null) zugegriffen werden kann

    • $ echo "${iarray[1]}"
      bar
      $ iarray[5]='baz'
      $ declare -p iarray
      declare -a iarray=([0]="foo" [1]="bar" [2]="bat" [5]="baz")
      

  • assoziative Arrays
    • declare -A aarray=( [foo]='bar' [bat]='baz' ) erzeugt ein Array, auf dessen Elemente mit Zeichenketten-Indizes zugegriffen werden kann

    • $ echo "${aarray[foo]}"
      bar
      $ aarray[index]='foo bar'
      $ declare -p aarray
      declare -A aarray=([index]="foo bar" [foo]="bar" [bat]="baz" )
      

Bash-Programmierung unterscheidet sich in vielen Punkten von anderen Programmiersprachen. So wird beispielsweise bei der Verzweigung traditionell die Bedingung nicht von der Shell selbst ausgewertet, sondern an ein weiteres Programm übergeben:

if [ Bedingung ]; then
  # Falls Bedingung wahr ist, wird dies ausgeführt
else
  # Falls Bedingung falsch ist, wird dies ausgeführt
fi

Die beiden eckigen Klammern sind keine Begrenzer, sondern ein Synonym für den integrierten (builtin) Shell-Befehl test. Der Befehl test prüft die Bedingung und liefert einen Rückgabewert 0 (wahr) oder 1 (falsch), der von der if-Anweisung verarbeitet wird. Der oben angeführte Code ist also identisch mit der folgenden Schreibweise:

if test Bedingung; then
  # Falls Bedingung wahr ist, wird dies ausgeführt
else
  # Falls Bedingung falsch ist, wird dies ausgeführt
fi

Heutzutage existiert jedoch auch ein eingebauter Ausdruck, der ohne externen Befehl auskommt, daher nicht mehr den Beschränkungen unterliegt, denen die Befehlsform unterlag, und so unter anderem auch keine Anführungszeichen um Variablen mehr benötigt:

if [[ Bedingung ]]; then
  # Falls Bedingung wahr ist, wird dies ausgeführt
else
  # Falls Bedingung falsch ist, wird dies ausgeführt
fi

Hier kann die Bedingung nun z. B. auch Operatoren wie <, > (kleiner als und größer als), und =~ (Vergleich mit Regulärem Ausdruck) enthalten.

Diese Variante wird daher, wenn keine Kompatibilität zu älteren Versionen benötigt wird, generell empfohlen.

Jedoch kann auch weiterhin der Rückgabewert (0–127, wobei >0 = falsch) eines beliebigen Programmes verarbeitet werden. Nicht nur der des test-Befehls. Als Beispiel wird hier der kill-Befehl verwendet, um zu testen, ob ein Prozess mit einer bestimmten Nummer noch läuft bzw. in der Lage ist, Signale entgegenzunehmen:

if kill -0 1234; then
  # Prozess 1234 läuft
else
  # Prozess 1234 läuft nicht
fi

Im September 2014 wurde eine gravierende Sicherheitslücke unter dem Namen Shellshock bekannt. Die seit langem bestehende Lücke ermöglicht, dass beim Start einer neuen Shell Schadcode, der per Umgebungsvariable eingefügt wurde, ungeprüft ausgeführt wird.[8] Die Lücke gilt seit Oktober 2014 als geschlossen.[9][10]

• Christian Meißner: Bash – Arbeiten und programmieren mit der Shell. Open Source Press, 2011, ISBN 978-3-941841-44-4.
• Karsten Günther: Bash - kurz & gut. 2008, ISBN 978-3-89721-533-7. 
• Cameron Newham, Bill Rosenblatt: Learning the Bash Shell. 3. Aufl., O’Reilly & Associates, 2009, ISBN 0-596-00965-8.
• Jürgen Wolf, Stefan Kania, Frank Sommer: Shell-Programmierung. Das umfassende Handbuch. Rheinwerk Computing, 7. Aufl. 2022, ISBN 978-3-8362-8923-8.

Commons: Bash – Sammlung von Bildern, Videos und Audiodateien

Wikibooks: Linux-Praxisbuch/ Shellprogrammierung – Lern- und Lehrmaterialien

• Homepage
• Bash auf der GNU-Seite
• Advanced Bash-Scripting Guide (englisch)
• Oh My Bash (Konfigurations-Framework)
• Lerne Bash in Y Minuten Übersicht der wichtigsten Elemente und Strukturen
• Bash-Skripting-Guide für Anfänger Einführung bei ubuntuusers.de
• Shell-Programmierung - Einführung, Praxis, Referenz Ausführliches Lern- und Nachschlagwerk, Rheinwerk openbook 2005

1. ↑ Chet Ramey: Bash-5.3-release available. 5. Juli 2025 (englisch, abgerufen am 5. Juli 2025).
2. ↑ The bash Open Source Project on Open Hub: Languages Page. In: Open Hub. (abgerufen am 3. September 2018).
3. ↑ Licensing of Bash. (abgerufen am 3. Oktober 2016).
4. ↑ Richard Stallman: The GNU Project. Abgerufen am 23. August 2026. 
5. ↑ heise.de
6. ↑ NEWS
7. ↑ Bash-5.0 release available Chet Ramey, 7. Januar 2019, abgerufen am 12. Oktober 2020.
8. ↑ ShellShock: Standard-Unix-Shell Bash erlaubt das Ausführen von Schadcode, heise online
9. ↑ Michał Zalewski: Bash bug: the other two RCEs, or how we chipped away at the original fix (CVE-2014-6277 and '78). In: lcamtuf blog. 1. Oktober 2014, abgerufen am 31. Oktober 2014 (englisch). 
10. ↑ Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169). Red Hat, 2. Oktober 2014, abgerufen am 1. November 2014 (englisch).