Kapitel 1. Der Einstieg in die Bash

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Was ist eine Muschel und warum solltest du dich für sie interessieren?

Jedes neuere Computer-Betriebssystem (damit meinen wir seit etwa 1970) hat eine Art Benutzeroberfläche - eine Möglichkeit, dem Betriebssystem Befehle zu geben, die es ausführen soll. Aber bei vielen Betriebssystemen war diese Befehlsschnittstelle fest eingebaut und es gab nur eine Möglichkeit, mit dem Computer zu kommunizieren. Außerdem konnte man über die Befehlsschnittstelle eines Betriebssystems zwar Befehle ausführen, aber das war auch schon alles. Was gab es denn sonst noch zu tun?

Das Unix-Betriebssystem machte die Idee populär, die Shell (den Teil des Systems, in dem du Befehle eingeben kannst) von allem anderen zu trennen: dem Ein-/Ausgabesystem, dem Zeitplannungsprogramm, der Speicherverwaltung und all den anderen Dingen, die das Betriebssystem für dich erledigt (und um die sich die meisten Benutzer nicht kümmern wollen). Die Shell war nur ein weiteres Programm, ein Programm, dessen Aufgabe es war, andere Programme im Namen der Benutzer auszuführen.

Aber das war der Beginn einer Revolution. Die Shell war nur ein weiteres Programm, das unter Unix lief; wenn dir die Standard-Shell nicht gefiel, konntest du deine eigene erstellen. Am Ende des ersten Jahrzehnts von Unix gab es also mindestens zwei konkurrierende Shells: die Bourne-Shell, sh (die von der ursprünglichen Thompson-Shell abstammt), und die C-Shell, csh. Gegen Ende des zweiten Jahrzehnts von Unix gab es noch ein paar weitere Alternativen: die Korn-Shell ksh und die ersten Versionen der Bash-Shell. Am Ende des dritten Jahrzehnts von Unix gab es wahrscheinlich ein Dutzend verschiedene Shells.

Du sitzt wahrscheinlich nicht herum und fragst dich: "Soll ich heute csh oder bash oder ksh benutzen?" Wahrscheinlich bist du mit der Standard-Shell zufrieden, die mit deinem Linux- (oder BSD- oder macOS- oder Solaris- oder HP/UX-) System geliefert wurde. Durch die Entkopplung der Shell vom Betriebssystem selbst war es für Softwareentwickler (wie Brian Fox, dem Erfinder der bash, und Chet Ramey, dem aktuellen Entwickler und Betreuer) viel einfacher, bessere Shells zu schreiben - du konntest eine neue Shell erstellen, ohne das Betriebssystem selbst zu verändern. Es war viel einfacher, eine neue Shell durchzusetzen, da man keinen Betriebssystemhersteller überreden musste, die Shell in sein System einzubauen; man musste die Shell nur verpacken, damit sie wie jedes andere Programm installiert werden konnte.

Trotzdem denkst du vielleicht, dass das nach viel Aufwand für etwas klingt, das nur Befehle entgegennimmt und ausführt. Und du hättest Recht - eineShell, in der du nur Befehle eingeben kannst, wäre nicht sehr interessant. Aber zwei Faktoren haben die Entwicklung der Unix-Shell vorangetrieben: Benutzerfreundlichkeit und Programmierung. Das Ergebnis ist eine moderne Shell, die viel mehr kann, als nur Befehle entgegenzunehmen.

Moderne Shells sind sehr praktisch. Sie erinnern sich zum Beispiel an Befehle, die du schon einmal eingegeben hast, und lassen dich diese Befehle wiederverwenden. Mit modernen Shells kannst du diese Befehle auch bearbeiten, sodass sie nicht jedes Mal gleich sein müssen. Außerdem kannst du mit modernen Shells deine eigenen Befehlskürzel, Tastenkombinationen und andere Funktionen definieren. Für einen erfahrenen Benutzer ist das Eingeben von Befehlen (z. B. mit Abkürzungen, Tastenkombinationen und Befehlsvervollständigung) viel effizienter und effektiver als das Herumschieben von Dingen in einer schicken Benutzeroberfläche mit Fenstern.

Aber abgesehen von der einfachen Bequemlichkeit sind Shells auch programmierbar. Es gibt viele Befehlsfolgen, die du immer wieder eintippst. Jedes Mal, wenn du etwas ein zweites Mal machst, solltest du dich fragen: "Kann ich nicht ein Programm schreiben, das das für mich erledigt?" Das kannst du. Eine Shell ist auch eine Programmiersprache, die speziell dafür entwickelt wurde, mit den Befehlen deines Computersystems zu arbeiten. Wenn du also tausend MP3-Dateien aus WAV-Dateien erzeugen willst, kannst du ein Shell-Programm (oder Shell-Skript) schreiben. Wenn du alle Logdateien deines Systems komprimieren willst, kannst du dafür ein Shell-Skript schreiben. Wann immer du eine Aufgabe wiederholt ausführen musst, solltest du versuchen, sie zu automatisieren, indem du ein Shell-Skript schreibst. Es gibt mächtigere Skriptsprachen wie Perl, Python und Ruby, aber die Unix-Shell (egal, welche Variante du verwendest) ist ein guter Anfang. Schließlich weißt du bereits, wie man Befehle eintippt; warum also die Dinge noch komplizierter machen?

1.1 Warum Bash?

Warum geht es in diesem Buch um die Bash und nicht um eine andere Shell? Weil die Bash überall ist. Sie ist vielleicht nicht die neueste und wohl auch nicht die schickste oder leistungsstärkste (wenn auch nicht die einzige) und auch nicht die einzige Shell, die als Open-Source-Software vertrieben wird - aber sie ist allgegenwärtig.

Der Grund dafür hat mit der Geschichte zu tun. Die ersten Shells waren ziemlich gute Programmierwerkzeuge, aber nicht sehr bequem für die Benutzer. Die C-Shell fügte viele Annehmlichkeiten für die Benutzer hinzu (z. B. die Möglichkeit, einen gerade eingegebenen Befehl zu wiederholen), aber als Programmiersprache war sie sehr eigenwillig. Die Korn-Shell, die in den frühen 80er Jahren aufkam, fügte viele Annehmlichkeiten für die Benutzer hinzu, verbesserte die Programmiersprache und schien auf dem Weg zu einer breiten Akzeptanz zu sein. Aber ksh war zunächst keine Open-Source-Software, sondern ein proprietäres Softwareprodukt und konnte daher nur schwer mit einem freien Betriebssystem wie Linux ausgeliefert werden. (Die Lizenz der Korn-Shell wurde im Jahr 2000 und erneut 2005 geändert.)

In den späten 1980er Jahren beschloss die Unix-Gemeinschaft, dass eine Standardisierung eine gute Sache ist, und es wurden die POSIX-Arbeitsgruppen (organisiert von der IEEE) gegründet. POSIX standardisierte die Unix-Bibliotheken und -Dienstprogramme, darunter auch die Shell. Die Standard-Shell basierte in erster Linie auf der 1988er Version der Korn-Shell, mit einigen C-Shell-Funktionen und ein paar Erfindungen, um die Lücken zu füllen. bash entstand im Rahmen der Bemühungen des GNU-Projekts, ein komplettes POSIX-System zu entwickeln, das natürlich auch eine POSIX-Shell benötigte.

bash bot die Programmierfunktionen, die Shell-Programmierer brauchten, und die Annehmlichkeiten, die Kommandozeilenbenutzer mochten. Ursprünglich war sie als Alternative zur Korn-Shell gedacht, aber als die Freie-Software-Bewegung an Bedeutung gewann und Linux immer beliebter wurde, stellte die bash die ksh schnell in den Schatten.

Daher ist die Bash die Standard-Benutzershell auf jeder Linux-Distribution, die wir kennen (es gibt ein paar hundert Linux-Distributionen, also gibt es wahrscheinlich auch ein paar mit einer merkwürdigen Standard-Shell), sowie auf macOS (und den früheren OS X-Versionen). Es gibt sie auch für fast jedes andere Unix-Betriebssystem, einschließlich BSD Unix und Solaris. In den seltenen Fällen, in denen die Bash nicht mit dem Betriebssystem ausgeliefert wird, ist sie leicht zu installieren. Sie ist sogar für Windows verfügbar, und zwar über Cygwin und das neue Linux Subsystem (Ubuntu). bash ist sowohl eine mächtige Programmiersprache als auch eine gute Benutzeroberfläche, und du wirst nicht auf Tastenkombinationen verzichten müssen, um ausgefeilte Programmierfunktionen zu erhalten.

Wenn du die Bash lernst, kannst du nichts falsch machen. Die gängigsten Standard-Shells sind die alte Bourne-Shell und die Bash, die größtenteils mit der Bourne-Shell kompatibel ist. Eine dieser Shells ist sicherlich auf jedem modernen, größeren Unix- oder Unix-ähnlichen Betriebssystem vorhanden. Und wie gesagt, wenn die bash nicht vorhanden ist, kannst du sie jederzeit installieren. Aber es gibt auch andere Shells. Im Sinne der freien Software tauschen die Autoren und Betreuer all dieser Shells Ideen aus. Wenn du die Änderungsprotokolle der Bash liest, wirst du viele Stellen finden, an denen eine Funktion eingeführt oder angepasst wurde, um das Verhalten einer anderen Shell zu verbessern. Aber den meisten Leuten ist das egal. Sie nutzen das, was schon da ist und sind damit zufrieden. Wenn du also interessiert bist, solltest du unbedingt andere Shells untersuchen. Es gibt viele gute Alternativen und vielleicht findest du eine, die dir besser gefällt - auch wenn sie wahrscheinlich nicht so weit verbreitet sein wird wie die Bash.

1.2 Die bash-Shell

bash ist eine Shell: ein Befehlsinterpreter. Der Hauptzweck der Bash (oder jeder anderen Shell) besteht darin, dir die Interaktion mit dem Betriebssystem des Computers zu ermöglichen, damit du das tun kannst, was du tun musst. In der Regel geht es dabei um das Starten von Programmen. Die Shell nimmt die von dir eingegebenen Befehle entgegen, ermittelt anhand dieser Eingaben, welche Programme ausgeführt werden müssen, und startet sie für dich. Es gibt auch Aufgaben, bei denen du eine Reihe von Aktionen ausführen musst, die sich wiederholen oder sehr kompliziert sind, oder beides. Die Shell-Programmierung, auch Shell-Skripting genannt, ermöglicht es dir, diese Aufgaben zu automatisieren, um sie einfacher, zuverlässiger und reproduzierbarer zu machen.

Falls du neu in der Bash bist, fangen wir mit den Grundlagen an. Wenn du schon mal Unix oder Linux benutzt hast, ist dir die Bashwahrscheinlich nicht neu - aberdu hast vielleicht nicht gewusst, dass du sie benutzt. Die Bash ist eigentlich nur eine Sprache zum Ausführen von Befehlen - die Befehle, die du die ganze Zeit eintippst (z. B. ls, cd, grep, cat), sind also gewissermaßen Bash-Befehle. Einige dieser Befehle sind in der Bash selbst enthalten, andere sind separate Programme. Im Moment macht es keinen Unterschied, welche das sind.

Wir beenden dieses Kapitel mit ein paar Rezepten, um Bash zu installieren. Auf den meisten Systemen ist die Bash bereits vorinstalliert, auf einigen wenigen jedoch nicht. Auch wenn dein System bereits mit der Bash ausgestattet ist, solltest du wissen, wie du sie bekommst und installierst - von Zeit zu Zeit werden neue Versionen mit neuen Funktionen veröffentlicht.

Wenn du bereits mit der Bash arbeitest und dich ein wenig mit ihr auskennst, solltest du direkt zu Kapitel 2 gehen. Es ist unwahrscheinlich, dass du dieses Buch der Reihe nach liest. Wenn du in der Mitte eintauchst, solltest du einige Rezepte finden, die dir zeigen, was die Bash wirklich kann. Aber zunächst zu den Grundlagen.

1.3 Entschlüsselung der Eingabeaufforderung

Problem

Du würdest gerne wissen, was die ganzen Satzzeichen auf deinem Bildschirm bedeuten.

Lösung

Alle Kommandozeilen-Shells haben eine Art Eingabeaufforderung, die dir anzeigt, dass die Shell bereit ist, deine Eingaben entgegenzunehmen. Wie die Eingabeaufforderung aussieht, hängt von vielen Faktoren ab, z. B. vom Typ und der Version deines Betriebssystems, vom Typ und der Version der Shell, von der Distribution und davon, wie jemand anderes sie konfiguriert hat. In der Bourne-Shell-Familie bedeutet ein nachgestelltes $ in der Eingabeaufforderung in der Regel, dass du als normaler Benutzer eingeloggt bist, während ein nachgestelltes # bedeutet, dass du root bist. Das root-Konto ist der Administrator des Systems und entspricht dem System-Konto unter Windows (das sogar noch mächtiger ist als das Administrator-Konto ). root ist allmächtig und kann auf einem typischen Unix- oder Linux-System alles tun.

In den Standard-Eingabeaufforderungen wird oft auch der Pfad zu dem Verzeichnis angezeigt, in dem du dich gerade befindest. In der Regel wird er jedoch abgekürzt, sodass ~ bedeutet, dass du dich in deinem Heimatverzeichnis befindest. Einige Eingabeaufforderungen zeigen auch deinen Benutzernamen und den Namen des Rechners an, auf dem du angemeldet bist. Wenn dir das jetzt albern vorkommt, wird es das nicht, wenn du an fünf Rechnern gleichzeitig angemeldet bist, möglicherweise unter verschiedenen Benutzernamen.

Hier ist eine typische Linux-Eingabeaufforderung für einen Benutzer namens jp auf einem Rechner namens adams, der sich im Home-Verzeichnis befindet. Das nachgestellte $ zeigt an, dass es sich um einen normalen Benutzer handelt, nicht um root:

jp@adams:~$

Hier ist die Eingabeaufforderung nach dem Wechsel in das Verzeichnis /tmp. Beachte, dass ~, das eigentlich /home/jp bedeutete, zu /tmp gewechselt hat:

jp@adams:/tmp$

Diskussion

Die Eingabeaufforderung der Shell ist das, was du am häufigsten sehen wirst, wenn du an der Kommandozeile arbeitest, und es gibt viele Möglichkeiten, sie nach deinen Wünschen anzupassen. Aber fürs Erste reicht es, wenn du weißt, wie du sie interpretieren kannst. Natürlich kann deine Standard-Eingabeaufforderung anders aussehen, aber du solltest in der Lage sein, genug herauszufinden, um vorerst zurechtzukommen.

Es gibt einige Unix- oder Linux-Systeme, bei denen die Macht von root mit Befehlen wie su und sudo geteilt werden kann. Es kann aber auch sein, dass root gar nicht die ganze Macht hat, wenn auf dem System ein System zur obligatorischen Zugriffskontrolle (MAC) wie SELinux der NSA läuft.

1.4 Zeigen, wo du bist

Problem

Du bist dir nicht sicher, in welchem Verzeichnis du dich befindest, und die standardmäßige Eingabeaufforderung ist nicht hilfreich.

Lösung

Verwende den eingebauten Befehl pwd, oder setze eine nützlichere Eingabeaufforderung (wie in Rezept 16.2 beschrieben). Zum Beispiel:

bash-4.3$ pwd
/tmp

bash-4.3$ export PS1='[\u@\h \w]$ '
[jp@solaris8 /tmp]$

Diskussion

pwd steht für print working directory und hat zwei Optionen. -L zeigt den logischen Pfad an und ist die Standardeinstellung. -P zeigt den physischen Pfad an, der sich von deinem logischen Pfad unterscheiden kann, wenn du einem symbolischen Link gefolgt bist. In ähnlicher Weise bietet der cd-Befehl auch die Schalter -P und -L:

bash-4.3$ pwd
/tmp/dir2

bash-4.3$ pwd -L
/tmp/dir2

bash-4.3$ pwd -P
/tmp/dir1

1.5 Finden und Ausführen von Befehlen

Problem

Du musst einen bestimmten Befehl unter der Bash finden und ausführen.

Lösung

Probiere die Befehle type, which, apropos, locate, slocate, find und ls aus.

Diskussion

Diebash speichert eine Liste der Verzeichnisse, in denen sie nach Befehlen suchen soll, in einer Umgebungsvariablen namens PATH. Der Befehl bash builtin type durchsucht deine Umgebung (einschließlich Aliase, Schlüsselwörter, Funktionen, builtins, Verzeichnisse in $PATH und die Befehls-Hashtabelle) nach ausführbaren Befehlen, die den Argumenten entsprechen, und zeigt den Typ und den Ort aller Übereinstimmungen an. Er hat mehrere Optionen, insbesondere das -a Flag, das bewirkt, dass er alle Treffer ausgibt, anstatt beim ersten Treffer stehen zu bleiben. Der Befehl which ist ähnlich, durchsucht aber nur deine $PATH (und csh-Aliasnamen ). Er kann sich von System zu System unterscheiden (unter BSD ist er normalerweise ein csh-Shellskript, unter Linux eine Binärdatei) und hat normalerweise ein -a Flag wie type. Verwende diese Befehle, wenn du den Namen eines Befehls kennst und genau wissen musst, wo er sich befindet, oder um zu sehen, ob er auf diesem Computer vorhanden ist. Zum Beispiel:

$ type which
which is hashed (/usr/bin/which)

$ type ls
ls is aliased to `ls -F -h'

$ type -a ls
ls is aliased to `ls -F -h'
ls is /bin/ls

$ which which
/usr/bin/which

Zu fast allen Befehlen gibt es irgendeine Form von Hilfe, wie man sie benutzt. Normalerweise gibt es eine Online-Dokumentation, die manpages, wobei "man" die Abkürzung für Handbuch ist. Diese werden mit dem man-Befehl aufgerufen, so dass du unter eine Dokumentation über den Befehl man ls ls findest. Viele Programme haben auch eine eingebaute Hilfefunktion, die du mit dem Argument "help me" aufrufen kannst, z. B. oder . Einige Programme, vor allem auf anderen Betriebssystemen, geben dir Hilfe, wenn du ihnen keine Argumente gibst. Einige Unix-Befehle tun das auch, aber viele von ihnen tun es nicht. Das liegt an der Art und Weise, wie Unix-Befehle in so genannten -h --help Pipelines zusammengefügt werden, auf die wir später eingehen. Aber was ist, wenn du den Namen des benötigten Befehls nicht kennst oder dich nicht mehr daran erinnern kannst? apropos durchsucht die Namen und Beschreibungen der Manpages nach regulären Ausdrücken, die als Argumente angegeben werden. Das ist unglaublich nützlich, wenn du dich nicht mehr an den Namen des benötigten Befehls erinnern kannst. Dies ist dasselbe wie : man -k

$ apropos music
cms (4) - Creative Music System device driver

$ man -k music
cms (4) - Creative Music System device driver

locate und slocate konsultieren Datenbankdateien über das System (die normalerweise von einem Job des Zeitplannungsprogramms cron zusammengestellt und aktualisiert werden), um Dateien oder Befehle fast sofort zu finden. Wo sich die Datenbankdateien befinden, was darin indiziert wird und wie oft sie überprüft werden, kann von System zu System unterschiedlich sein. Einzelheiten findest du in den Manpages deines Systems. slocate (secure locate) speichert zusätzlich zu den Dateinamen und Pfaden auch Informationen über die Zugriffsrechte, damit es keine Programme auflistet, auf die der Benutzer keinen Zugriff hat. Auf den meisten Linux-Systemen ist locate ein symbolischer Link zu slocate; andere Systeme haben möglicherweise separate Programme oder gar kein slocate. Hier ist ein Beispiel:

$ locate apropos
/usr/bin/apropos
/usr/share/man/de/man1/apropos.1.gz
/usr/share/man/es/man1/apropos.1.gz
/usr/share/man/it/man1/apropos.1.gz
/usr/share/man/ja/man1/apropos.1.gz
/usr/share/man/man1/apropos.1.gz

Weitere Informationen über den Befehl find findest du in Kapitel 9.

Zu guter Letzt solltest du ls verwenden. Erinnere dich daran, dass du dem Befehl, den du ausführen möchtest, ein ./ voranstellen musst, da das aktuelle Arbeitsverzeichnis aus Sicherheitsgründen normalerweise nicht in deinem $PATH steht (siehe Rezepte 14.3 und 14.10).

1.6 Informationen über Dateien erhalten

Problem

Du brauchst mehr Informationen über eine Datei, wie z.B. was sie ist, wem sie gehört, ob sie ausführbar ist, wie viele Hardlinks sie hat oder wann sie zuletzt aufgerufen oder geändert wurde.

Lösung

Verwende die Befehle ls, stat, file oder find:

$ touch /tmp/sample_file

$ ls /tmp/sample_file
/tmp/sample_file

$ ls -l /tmp/sample_file
-rw-r--r-- 1 jp         jp            0 Dec 18 15:03 /tmp/sample_file

$ stat /tmp/sample_file
File: "/tmp/sample_file"
Size: 0           Blocks: 0        IO Block: 4096   Regular File
Device: 303h/771d Inode:  2310201    Links: 1
Access: (0644/-rw-r--r--) Uid: (  501/      jp)   Gid: ( 501/        jp)
Access: Sun Dec 18 15:03:35 2005
Modify: Sun Dec 18 15:03:35 2005
Change: Sun Dec 18 15:03:42 2005

$ file /tmp/sample_file
/tmp/sample_file: empty

$ file -b /tmp/sample_file
empty

$ echo '#!/bin/bash -' > /tmp/sample_file

$ file /tmp/sample_file
/tmp/sample_file: Bourne-Again shell script text executable

$ file -b /tmp/sample_file
Bourne-Again shell script text executable

Mehr über den Befehl find erfährst du in Kapitel 9.

Diskussion

Der Befehl ls zeigt nur Dateinamen an, während -l mehr Details über jede Datei liefert. ls hat viele Optionen; sieh in der Manpage deines Systems nach, welche es unterstützt. Nützliche Optionen sind unter anderem:

-a

Verstecke keine Dateien, die mit . (Punkt) beginnen.

-A

Wie -a, überspringt aber die beiden gängigen Verzeichnisse . (Punkt) und .. (Punkt Punkt), da sie in praktisch jedem Verzeichnis vorhanden sind.

-F

Zeigt den Dateityp mit einem von mehreren nachgestellten Typkennzeichen an.

Ein Schrägstrich (/) zeigt an, dass die Datei ein Verzeichnis ist, ein Sternchen (*) bedeutet, dass die Datei ausführbar ist, ein at-Zeichen (@) weist auf einen symbolischen Link hin, ein Gleichheitszeichen (=) ist ein Socket und eine Pipe oder ein vertikaler Balken (|) ist ein FIFO-Puffer (first in, first out).

-l

Verwende das lange Listenformat.

-L

Zeigt Informationen über die verlinkte Datei und nicht den symbolischen Link selbst an.

-Q

Zitatnamen (GNU-Erweiterung, nicht auf allen Systemen unterstützt).

-r

Kehr die Sortierreihenfolge um.

-R

Rekurs durch Unterverzeichnisse.

-S

Nach Dateigröße sortieren.

-1

Verwende das Kurzformat, aber mit nur einer Datei pro Zeile.

stat, file und find haben alle viele Optionen, die das Ausgabeformat steuern; siehe die Manpages auf deinem System für unterstützte Optionen. Diese Optionen erzeugen zum Beispiel eine Ausgabe, die der von ls -l ähnelt:

$ ls -l /tmp/sample_file
-rw-r--r--  1 jp         jp                14 Dec 18 15:04 /tmp/sample_file

$ stat -c'%A %h %U %G %s %y %n' /tmp/sample_file
-rw-r--r-- 1 jp jp 14 Sun Dec 18 15:04:12 2005 /tmp/sample_file

$ find /tmp/ -name sample_file -printf '%m %n %u %g %t %p'
644 1 jp jp Sun Dec 18 15:04:12 2005 /tmp/sample_file

Nicht alle Betriebssysteme und Versionen verfügen über alle diese Tools. Solaris enthält zum Beispiel standardmäßig kein stat.

Es sei auch darauf hingewiesen, dass Verzeichnisse nichts anderes sind als Dateien, die das Betriebssystem besonders behandelt. Die hier gezeigten Befehle funktionieren also auch bei Verzeichnissen, obwohl du manchmal einen Befehl ändern musst, um das gewünschte Verhalten zu erreichen. Verwende zum Beispiel ls -d, um Informationen über das Verzeichnis selbst aufzulisten, anstatt nur ls (das den Inhalt des Verzeichnisses auflistet).

Siehe auch

  • man ls

  • man stat

  • man file

  • man find

  • Kapitel 9

1.7 Alle versteckten (Punkt-)Dateien im aktuellen Verzeichnis anzeigen

Problem

Du möchtest nur versteckte (Punkt-)Dateien in einem Verzeichnis sehen, um eine Datei zu bearbeiten, deren Namen du vergessen hast, oder veraltete Dateien zu entfernen. ls -a zeigt alle Dateien an, auch die normalerweise versteckten, aber das ist oft zu laut, und ls -a .* macht mehr, als du denkst, oder mehr, als du willst.

Lösung

Verwende ls -d zusammen mit allen anderen Kriterien, die du hast. Zum Beispiel:

ls -d .*
ls -d .b*
ls -d .[!.]*
ls -d .*/

Da jedes normale Verzeichnis ein . und .. enthält, brauchst du diese nicht zu sehen. Du kannst ls -A verwenden, um alle Dateien in einem Verzeichnis außer diesen beiden aufzulisten. Bei anderen Befehlen, bei denen du Dateien mit einem Platzhalter (d.h. einem Muster) auflistest, kannst du deinen Platzhalter so konstruieren, dass . und .. nicht übereinstimmen:

$ grep -l 'PATH' ~/.[!.]*
/home/jp/.bash_history
/home/jp/.bash_profile
$

Diskussion

Aufgrund der Art und Weise, wie die Shell mit Platzhaltern für Dateien umgeht, verhält sich die Sequenz .* nicht so, wie du es vielleicht erwartest oder wünschst. Die Dateierweiterung bzw. das Globbing funktioniert so, dass jede Zeichenkette, die die Zeichen *, ? oder [ enthält, als Muster behandelt und durch eine alphabetisch sortierte Liste von Dateinamen ersetzt wird, die dem Muster entsprechen. * passt auf jede Zeichenkette, auch auf die Null-Zeichenkette, während ? auf jedes einzelne Zeichen passt. Zeichen, die in [] eingeschlossen sind, geben eine Liste oder einen Bereich von Zeichen an, von denen jedes übereinstimmt. Außerdem gibt es verschiedene erweiterte Operatoren für die Mustererkennung, die wir hier nicht behandeln werden (siehe "Zeichen für die Mustererkennung" und "extglob Erweiterte Operatoren für die Mustererkennung" in Anhang A). So bedeutet *.txt jede Datei, die auf .txt endet, während *txt jede Datei bedeutet, die auf txt (ohne Punkt) endet. f?o würde auf foo oder fao passen, aber nicht auf fooo. Du könntest also denken, dass .* auf jede Datei passt, die mit einem Punkt beginnt.

Das Problem ist, dass .* sowohl die Verzeichnisse . und .. findet (die in jedem Verzeichnis vorhanden sind), die dann beide zusammen mit allen anderen Dateinamen, die mit einem Punkt beginnen, angezeigt werden. Wenn ls einen Verzeichnisnamen erhält, listet es nicht nur den Verzeichnisnamen, sondern auch den Inhalt des Verzeichnisses auf. Anstatt nur die Dateien mit Punkt im aktuellen Verzeichnis zu erhalten, bekommst du also diese Dateien plus alle Dateien und Verzeichnisse im aktuellen Verzeichnis (.), alle Dateien und Verzeichnisse im übergeordneten Verzeichnis (..) und die Namen und Inhalte aller Unterverzeichnisse im aktuellen Verzeichnis, die mit einem Punkt beginnen. Das kann, gelinde gesagt, sehr verwirrend sein und ist meist mehr, als du willst.

Du kannst mit dem gleichen ls-Befehl mit -d und ohne experimentieren und dann echo . * ausprobieren. Der echo-Befehl zeigt dir einfach an, was die Shell aus deinem .* macht, was dann die Argumente für den ls-Befehl wären.

Probiere auch echo .[!.]* aus. .[!.]* ist ein Muster zur Erweiterung des Dateinamens, bei dem [] eine Liste von Zeichen angibt, die übereinstimmen sollen, aber das führende ! negiert die Liste. Hier suchen wir also nach einem Punkt, gefolgt von einem beliebigen Zeichen, das kein Punkt ist, gefolgt von einer beliebigen Anzahl von beliebigen Zeichen. Du kannst auch ^ verwenden, um eine Zeichenklasse zu negieren, aber ! ist im POSIX-Standard spezifiziert und daher besser übertragbar.

Es gibt noch einen weiteren Sonderfall im ls-Befehl, der hier weiterhilft. Wenn die Option -d angegeben ist und das Dateinamensmuster mit einem Schrägstrich endet, zeigt der Befehl ls nur Verzeichnisse an, die mit diesem Muster übereinstimmen, und nicht alle Dateinamen, die übereinstimmen. Zum Beispiel:

$ ls -d .v*
.vim  .viminfo  .vimrc
$ ls -d .v*/
.vim
$

Der erste Befehl zeigt die drei Dateinamen an, die mit .v beginnen, ohne (wegen der Option -d ) den Inhalt der Verzeichnisse aufzulisten. Der zweite Befehl in diesem Beispiel verwendet einen Schrägstrich am Ende des Musters (.v*/), so dass der Befehl ls nur Verzeichnisse anzeigt, die mit dem Muster übereinstimmen; in diesem Fall ist das nur das Verzeichnis namens .vim und kein anderes.

Warnung

Wenn du doppelte Schrägstriche in der Ausgabe des ls -d .v*/ Befehls siehst, wie hier:

$ ls -d .v*/
.vim//
$

dann liegt das wahrscheinlich daran, dass du einen Alias für ls ausführst, der das -F Flag enthält. Verwende einen Backslash vor dem Befehlsnamen, um einen Alias zu vermeiden:

$ \ls -d .v*/
.vim/
$

Manche Kombinationen sind einfach schwer zu finden. .[!.]* wird eine Datei namens ..foo übersehen. Du könntest etwas wie .??* hinzufügen, um alles zu finden, was mit einem Punkt beginnt und mindestens drei Zeichen lang ist, aber ls -d .[!.]* .??* zeigt dann alles an, was zweimal auf beide Muster passt. Oder du kannst .??* allein verwenden, aber dann werden Dateien wie .a übersehen:

$ touch ..foo .a .normal_dot_file normal_file

$ ls -a
. .. ..foo .a .normal_dot_file normal_file

$ ls -d .??*
..foo .normal_dot_file

$ ls -d .[!.]*
.a .normal_dot_file

$ ls -d .[!.]* .??* | sort -u
..foo
.a
.normal_dot_file

Welche du verwendest, hängt von deinen Bedürfnissen und deiner Umgebung ab; es gibt keine allgemeingültige Lösung.

Hinweis

Du kannst echo * als Notfallersatz für ls verwenden, wenn der Befehl ls beschädigt oder aus irgendeinem Grund nicht verfügbar ist. Das funktioniert, weil * von der Shell auf alles im aktuellen Verzeichnis erweitert wird, was zu einer Liste führt, die der von ls ähnelt.

1.8 Shell-Quoting verwenden

Problem

Du brauchst eine Faustregel für die Verwendung von Kommandozeilenquoting.

Lösung

Schließe eine Zeichenkette in einfache Anführungszeichen ein, es sei denn, sie enthält Elemente, die die Shell interpolieren soll.

Diskussion

Nicht in Anführungszeichen gesetzter Text und sogar in Anführungszeichen eingeschlossener Text unterliegt der Shell-Expansion und Substitution. Bedenke:

$ echo A coffee is $5?!
A coffee is ?!

$ echo "A coffee is $5?!"
-bash: !": event not found

$ echo 'A coffee is $5?!'
A coffee is $5?!

Im ersten Beispiel wird $5 als zu erweiternde Variable behandelt, aber da sie nicht existiert, wird sie auf null gesetzt. Im zweiten Beispiel ist das Gleiche der Fall, aber wir kommen gar nicht erst dazu, weil ! als Substitution in der Geschichte behandelt wird, was in diesem Fall fehlschlägt, weil es mit nichts in der Geschichte übereinstimmt. Das dritte Beispiel funktioniert wie erwartet.

Um einige Shell-Erweiterungen mit literalen Zeichenfolgen zu mischen, kannst du das Shell-Escape-Zeichen \ verwenden oder die Quotierung ändern. Das Ausrufezeichen ist ein Sonderfall, weil das vorangehende Backslash-Escape-Zeichen nicht entfernt wird. Du kannst dies umgehen, indem du einfache Anführungszeichen oder ein Leerzeichen am Ende verwendest, wie hier gezeigt:

$ echo 'A coffee is $5 for' "$USER" '?!'
A coffee is $5 for jp ?!

$ echo "A coffee is \$5 for $USER?\!"
A coffee is $5 for jp?\!

$ echo "A coffee is \$5 for $USER?! "
A coffee is $5 for jp?!

Außerdem kannst du kein einfaches Anführungszeichen in einfache Anführungszeichen einbetten, selbst wenn du einen umgekehrten Schrägstrich verwendest, da nichts (nicht einmal der umgekehrte Schrägstrich) innerhalb von einfachen Anführungszeichen interpoliert wird. Du kannst das aber umgehen, indem du doppelte Anführungszeichen mit Escape-Elementen verwendest oder indem du ein einfaches Anführungszeichen außerhalb von einfachen Anführungszeichen einbettest.

# We'll get a continuation prompt since we now have unbalanced quotes
$ echo '$USER won't pay $5 for coffee.'
> ^C

# WRONG
$ echo "$USER won't pay $5 for coffee."
jp won't pay for coffee.

# Works
$ echo "$USER won't pay \$5 for coffee."
jp won't pay $5 for coffee.

# Also works
$ echo 'I won'\''t pay $5 for coffee.'
I won't pay $5 for coffee.

Siehe auch

  • Kapitel 5 für mehr über Shell-Variablen und die $VAR Syntax

  • Kapitel 18 für mehr über ! und die History-Befehle

1.9 Verwenden oder Ersetzen von eingebauten und externen Befehlen

Problem

Du willst einen eingebauten Befehl durch eine eigene Funktion oder einen externen Befehl ersetzen und musst genau wissen, was dein Skript ausführt (z. B. /bin/echo oder das eingebaute echo). Oder du hast einen neuen Befehl erstellt, der mit einem bestehenden externen oder eingebauten Befehl kollidiert.

Lösung

Verwende den Typ und die Befehle um zu sehen, ob ein bestimmter Befehl existiert und ob er eingebaut oder extern ist:

$ type cd
cd is a shell builtin

$ type awk
awk is /usr/bin/awk

$ which cd
/usr/bin/which: no cd in (/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/ \
local/sbin:/usr/bin/X11:/usr/X11R6/bin:/root/bin)

$ which awk
/usr/bin/awk

Diskussion

Ein integrierter Befehl ist genau das: Er ist in die Shell selbst eingebaut, während ein externer Befehl eine externe Datei ist, die von der Shell gestartet wird. Bei der externen Datei kann es sich um eine Binärdatei oder um ein Shell-Skript handeln, und es ist aus mehreren Gründen wichtig, den Unterschied zu verstehen. Erstens: Wenn du eine bestimmte Version einer bestimmten Shell verwendest, sind Builtins immer verfügbar, aber externe Programme können auf einem bestimmten System installiert sein oder auch nicht. Zweitens: Wenn du einem deiner eigenen Programme denselben Namen wie einem Builtin gibst, wird das Ergebnis sehr verwirrend sein, da das Builtin immer Vorrang hat (siehe Rezept 19.4). Mit dem Befehl enable kannst du Buildin-Befehle ein- und ausschalten. Wir raten dir jedoch dringend davon ab, wenn du dir nicht absolut sicher bist, was du tust. enable -a listet alle Buildins und ihren Aktivierungs- oder Deaktivierungsstatus auf.

Ein Problem mit den Builtin-Befehlen ist, dass du in der Regel keine -h oder --help Option verwenden kannst, um Hinweise zur Verwendung zu erhalten, und wenn es eine Manpage gibt, ist sie oft nur ein Verweis auf die große Bash-Manpage. Hier kommt der help-Befehl ins Spiel, der selbst ein Builtin ist. help zeigt Hilfe zu Shell-Builtins an:

help: help [-dms] [pattern ...]
    Display information about builtin commands.

    Displays brief summaries of builtin commands.  If PATTERN is
    specified, gives detailed help on all commands matching PATTERN,
    otherwise the list of help topics is printed.

    Options:
      -d	output short description for each topic
      -m	display usage in pseudo-manpage format
      -s	output only a short usage synopsis for each topic matching
    	PATTERN

    Arguments:
      PATTERN	Pattern specifying a help topic

    Exit Status:
    Returns success unless PATTERN is not found or an invalid option is given.

Wenn du ein Builtin umdefinieren musst, benutzt du den Builtin-Befehl, um Schleifen zu vermeiden. Wir können zum Beispiel eine Shell-Funktion definieren (siehe Rezept 10.4), um zu ändern, wie der Befehl cd funktioniert:

cd () {
    builtin cd "$@"
    echo "$OLDPWD --> $PWD"
}

Um die Verwendung eines externen Befehls anstelle einer Funktion oder eines Builtins zu erzwingen, die sonst Vorrang hätten, verwende enable -n, das die Shell-Buildins ausschaltet, oder command, das die Shell-Funktionen ignoriert. Um zum Beispiel den Test aus $PATH anstelle der Shell-Builtin-Version zu verwenden, gibst du enable -n test ein und führst dann test aus. Oder verwende command ls, um den nativen ls-Befehl zu verwenden und nicht irgendeine ls-Funktion, die du vielleicht erstellt hast.

Siehe auch

1.10 Feststellen, ob du interaktiv arbeitest

Problem

Du hast einen Code, den du nur ausführen möchtest, wenn du interaktiv bist (oder nicht).

Lösung

Verwende die Anweisung case in Beispiel 1-1.

Beispiel 1-1. ch01/interactive
#!/usr/bin/env bash
# cookbook filename: interactive

case "$-" in
    *i*) # Code for interactive shell here
     ;;
    *)   # Code for noninteractive shell here
     ;;
esac

Diskussion

$- ist eine Zeichenkette, die alle aktuellen Shell-Optionsflags auflistet. Sie enthält i, wenn die Shell interaktiv ist.

Du kannst auch Code wie den folgenden sehen (das funktioniert zwar auch, aber die Lösung in Beispiel 1-1 ist die bevorzugte Methode):

if [ -n "$PS1" ]; then
    echo This shell is interactive
else
    echo This shell is not interactive
fi

Siehe auch

1.11 Bash als Standardshell einstellen

Problem

Du verwendest ein BSD-System, Solaris oder eine andere Unix-Variante, für die die Bash nicht die Standardshell ist. Du hast es satt, die Bash immer explizit zu starten, und willst die Bash zu deiner Standardshell machen.

Lösung

Stelle zunächst sicher, dass die Bash installiert ist. Gib dazu bash --version in die Befehlszeile ein. Wenn du eine Version erhältst, ist sie installiert:

$ bash --version
GNU bash, version 3.00.16(1)-release (i386-pc-solaris2.10)
Copyright (C) 2004 Free Software Foundation, Inc.
$

Wenn du keine Versionsnummer siehst, fehlt dir vielleicht ein Verzeichnis in deinem Pfad. chsh -l oder cat /etc/shells können dir auf manchen Systemen eine Liste der gültigen Shells geben. Andernfalls frag deinen Systemadministrator, wo sich die Bash befindet oder ob sie installiert werden kann.

chsh -l bietet unter Linux eine Liste gültiger Shells, öffnet aber unter BSD einen Editor und ermöglicht es dir, die Einstellungen zu ändern. -l ist unter macOS keine gültige Option für chsh, aber wenn du chsh ausführst, wird ein Editor geöffnet, in dem du die Einstellungen ändern kannst, und chpass -s shell wird deine Shell ändern.

Wenn die Bash installiert ist, kannst du mit dem Befehl chsh -s deine Standard-Shell ändern: zum Beispiel chsh -s /bin/bash. Wenn das aus irgendeinem Grund fehlschlägt, versuche es mit chsh, passwd -e, passwd -l, chpass oder usermod -s /usr/bin/bash. Wenn du deine Shell immer noch nicht ändern kannst, frage deinen Systemadministrator, der eventuell die Datei /etc/passwd bearbeiten muss. Auf den meisten Systemen enthält /etc/passwd Zeilen in der Form:

cam:pK1Z9BCJbzCrBNrkjRUdUiTtFOh/:501:100:Cameron Newham:/home/cam:/bin/bash
cc:kfDKDjfkeDJKJySFgJFWErrElpe/:502:100:Cheshire Cat:/home/cc:/bin/bash

Als root kannst du einfach das letzte Feld der Zeilen in der Passwortdatei mit dem vollständigen Pfadnamen der Shell deiner Wahl ändern. Wenn dein System über einen vipw-Befehl verfügt, solltest du ihn verwenden, um die Konsistenz der Passwortdatei sicherzustellen.

Warnung

Manche Systeme lehnen es ab, eine Anmeldeshell zuzulassen, die nicht in /etc/shells aufgeführt ist. Wenn die Bash in dieser Datei nicht aufgeführt ist, musst du sie von deinem Systemadministrator hinzufügen lassen.

Diskussion

Einige Betriebssysteme, vor allem die BSD-Unixe, legen die Bash normalerweise in der Partition /usr ab. Auf solchen Systemen solltest du dir zweimal überlegen, ob du die Shell von rootändern willst. Wenn das System beim Booten Probleme macht und du daran arbeiten musst, bevor /usr gemountet ist, hast du ein echtes Problem: Es gibt keine Shell, die root benutzen kann. Deshalb ist es am besten, die Standard-Shell für root unverändert zu lassen. Es gibt jedoch keinen Grund, die bash nicht zur Standardshell für normale Benutzerkonten zu machen. Und es versteht sich von selbst, dass es keine gute Praxis ist, den Root-Account zu benutzen, wenn es nicht unbedingt notwendig ist. Verwende wann immer möglich dein normales (Benutzer-)Konto. Mit Befehlen wie sudo solltest du nur sehr selten eine Root-Shell brauchen.

Wenn alles andere fehlschlägt, kannst du deine bestehende Login-Shell wahrscheinlich mit exec durch die Bash ersetzen, aber das ist nichts für schwache Nerven. Siehe "A7) Wie kann ich die bash zu meiner Login-Shell machen?" in der bash-FAQ.

Siehe auch

1.12 Bash auf dem neuesten Stand halten

Problem

Das ist eigentlich kein normales Rezept, , und es versteht sich wahrscheinlich von selbst, aber es ist ein Thema, das niemand ignorieren kann, und wir wollten es trotzdem sagen. Du musst sowohl die Bash als auch dein gesamtes System mit Sicherheitspatches auf dem neuesten Stand halten.

Lösung

Dein gesamtes System auf dem neuesten Stand zu halten, liegt außerhalb des Rahmens dieses Buches; frage deinen Systemadministrator und die Dokumentation.

Wie du die Bash aktuell hältst, hängt davon ab, wie du sie überhaupt bekommen hast. Im Idealfall ist sie ein Teil des Systems und wird aktualisiert, wenn das System aktualisiert wird. Das ist vielleicht nicht der Fall, wenn du ein sehr altes System verwendest, das nicht mehr unterstützt wird; in diesem Fall musst du das gesamte System aktualisieren. In diesem Fall musst du das gesamte System aktualisieren. Wenn du dein Paketsystem verwendest und das ursprüngliche Repository noch aktiv gewartet wird, solltest du die Updates von dort beziehen - zum Beispiel von Extra Packages for Enterprise Linux (EPEL) oder einem Ubuntu Personal Package Archive (PPA).

Wenn du aus dem Quellcode installiert hast, musst du deinen Quellcode aktualisieren und gegebenenfalls neu erstellen.

Diskussion

Wir alle wissen, warum wir auf dem Laufenden bleiben müssen, aber wir werden trotzdem einen bekannten Grund anführen: CVE-2014-6271, besser bekannt als die Shellshock-Schwachstelle.

1.13 Bash für Linux bekommen

Problem

Du willst dir die Bash für dein Linux-System besorgen oder du willst sicherstellen, dass du die neueste Version hast.

Lösung

Diebash ist in praktisch allen modernen Linux-Distributionen enthalten. Um sicherzustellen, dass du die neueste Version für deine Distribution hast, verwende die in der Distribution integrierten Paketierungs-Tools. Du musst root sein oder über sudo oder das root-Passwort verfügen, um Anwendungen zu aktualisieren oder zu installieren.

Einige Linux-Distributionen (vor allem die Debian-Familie) verwenden die Debian Almquist Shell, oder Dash,als /bin/sh, weil sie kleiner ist und daher etwas schneller läuft als Bash. Diese Umstellung sorgte für viel Verwirrung, wenn Skripte davon ausgingen, dass /bin/sh in Wirklichkeit Bash ist, da Skripte, die Bash-Funktionen mit #!/bin/sh verwenden, fehlschlugen. Siehe Rezept 15.3 für weitere Details.

Für Debian und von Debian abgeleitete Systeme wie Ubuntu und Linux Mint verwendest du eines der verschiedenen GUI-Tools oder ein Kommandozeilen-Tool wie apt-get, aptitude oder apt, um sicherzustellen, dass es installiert und aktuell ist:

apt-get update && apt-get install bash bash-completion bash-doc

Für Red Hat-Distributionen, einschließlich Fedora, Community OS (CentOS) und Red Hat Enterprise Linux (RHEL), verwendest du das GUI-Tool Add/Remove Applications. Wenn du nur die Kommandozeile verwendest, benutze:

yum update bash

Für SUSE verwendest du entweder die GUI- oder die Terminal-Version von YaST. Du kannst auch das Kommandozeilenwerkzeug rpm verwenden.

Diskussion

Es ist unmöglich, alle Linux-Distributionen zu behandeln, und selbst bei den wichtigsten ist es schwierig, da sie sich alle schnell weiterentwickeln. Glücklicherweise findet ein Großteil dieser Entwicklung im Bereich der Benutzerfreundlichkeit statt, so dass es nicht sehr schwierig sein sollte, herauszufinden, wie man Software unter der Distribution deiner Wahl installiert.

Bei der Verwendung von LiveCDs werden Softwareaktualisierungen und -installationen höchstwahrscheinlich aufgrund des schreibgeschützten Mediums fehlschlagen. Versionen solcher Distributionen, die auf einer Festplatte installiert wurden, sollten aktualisierbar sein.

Wenn du dich unter fragst, welche Version der Bash in einer bestimmten Linux-Distribution verfügbar ist, suche nach der Distribution auf DistroWatch.com und sieh in der Pakettabelle nach. https://distrowatch.com/table.php?distribution=mint zeigt zum Beispiel, was du in Tabelle 1-1 siehst.

Tabelle 1-1. Bash-Versionen in Linux Mint
Paket 18 sarah 17.3 rosa 16 petra 15 olivia 14 nadia 13 maya 12 lisa 11 katya 10 julia ...

bash (4.4)

4.3

4.3

4.2

4.2

4.2

4.2

4.2

4.2

4.1

...

1.14 Bash für xBSD installieren

Problem

Du möchtest die bash für dein FreeBSD-, NetBSD- oder OpenBSD-System bekommen oder sicherstellen, dass du die neueste Version hast.

Lösung

Laut der Bash-Seite von Chet Ramey

Bash-4.3 ist Teil der FreeBSD Ports Collection, der OpenBSD Packages Collection und der NetBSD Packages Collection.

Um zu sehen, ob die Bash installiert ist, überprüfe die Datei /etc/shells. Um bash zu installieren oder zu aktualisieren, verwende den Befehl pkg_add. Wenn du ein erfahrener BSD-Benutzer bist, verwendest du vielleicht lieber die Ports-Sammlung, aber das werden wir hier nicht behandeln.

Wenn du dich fragst, welche Version der Bash in einer bestimmten BSD-Distribution verfügbar ist, suche nach der Distro auf DistroWatch.com und sieh in der Pakettabelle nach. Zum Beispiel:

Für FreeBSD verwendet den Befehl:

pkg_add -vr bash

Für NetBSD suchst du unter Anwendungssoftware für NetBSD nach dem neuesten Bash-Paket für deine Version und Architektur und verwendest dann einen Befehl wie

pkg_add -vu ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc-2005Q3/NetBSD-2.0/ \
i386/All/bash-3.0pl16nb3.tgz

Unter OpenBSD verwendest du den Befehl pkg_add -vr. Möglicherweise musst du den FTP-Pfad für deine Version und Architektur anpassen. Außerdem kann es eine statisch kompilierte Version geben. Zum Beispiel:

pkg_add -vr ftp://ftp.openbsd.org/pub/OpenBSD/3.8/packages/i386/bash-3.0.16p1.tgz

Diskussion

FreeBSD und OpenBSD platzieren die bash in /usr/local/bin/bash, während NetBSD /usr/pkg/ bin/bash verwendet.

1.15 Bash für macOS bekommen

Problem

Du willst dir die Bash für deinen Mac besorgen oder sicherstellen, dass du die neueste Version hast.

Lösung

Laut der Bash-Seite von Chet Ramey

Aktuelle Versionen von Mac OS X [jetzt macOS genannt] (ab Jaguar/Mac OS X 10.2) werden mit bash-3.2 als /bin/sh ausgeliefert. Es gibt auch vorkompilierte OS X-Pakete von bash-4.3, die auf vielen Websites erhältlich sind, obwohl die Quellpakete normalerweise aktueller sind. Bash für Darwin (die Basis für MacOS X) ist bei MacPorts, Homebrew oder Fink erhältlich.

Diskussion

Es ist auch möglich, eine neuere Version der Bash aus dem Quellcode zu erstellen, aber das ist nur für erfahrene Benutzer zu empfehlen (siehe Anhang E).

1.16 Bash für Unix bekommen

Problem

Du willst dir die Bash für dein Unix-System besorgen oder du willst sicherstellen, dass du die neueste Version hast.

Lösung

Wenn es noch nicht installiert ist oder sich nicht im Programm-Repository deines Betriebssystems befindet, kannst du es auf der Bash-Seite von Chet Ramey als Binärdatei herunterladen oder aus dem Quellcode erstellen (siehe Anhang E).

Diskussion

Laut der Bash-Seite von Chet Ramey

Das OpenPKG-Projekt stellt Quell-RPMs von bash-4.3 für eine Vielzahl von Unix- und Linux-Systemen als Kernbestandteil der aktuellen Version zur Verfügung.

Benutzer von Solaris 2.x, Solaris 7/8/9/10/11 können eine vorkompilierte Version von bash-4.3 von der Unixpackages-Website (Abonnement) oder von OpenCSW erhalten. Oracle liefert bash-3.2 als unterstützten Teil von Solaris 10 und bash-4.1 als Teil von Solaris 11 aus. Die Version von Solaris/Illumos, die als OpenIndiana vertrieben wird, enthält bash-4.3 (Stand: September 2016).

AIX-Benutzer können vorkompilierte Versionen von bash-4.3 und älteren Versionen für verschiedene AIX-Versionen von Groupe Bull und Quellen und Binärdateien von bash-4.3 für verschiedene AIX-Versionen von perzl.org erhalten. IBM stellt bash-4.2 und bash-4.3 für AIX 5L, AIX 6.1 und AIX 7.1 als Teil der AIX Toolbox für GNU/Linux-Anwendungen zur Verfügung. Sie verwenden das RPM-Format; du kannst RPM für AIX auch von dort beziehen.

HP-UX-Benutzer können bash-4.3-Binärdateien und Quellcode vom Software Porting and Archive Center for HP-UX erhalten.

1.17 Bash für Windows installieren

Problem

Du möchtest die Bash für dein Windows-System bekommen oder sicherstellen, dass du die neueste Version hast.

Lösung

Verwende Cygwin oder Ubuntu unter Windows oder eine virtuelle Maschine. Oder verwende keine Bash.

Lade Cygwin herunter und starte es. Folge den Eingabeaufforderungen und wähle die zu installierenden Pakete aus, einschließlich der bash, die sich in der Kategorie Shells befindet und standardmäßig ausgewählt ist. Sobald Cygwin installiert ist, musst du es konfigurieren. Einzelheiten dazu findest du im Benutzerhandbuch.

Für Ubuntu unter Windows brauchst du eine Version von Windows 10 vom Sommer 2016 oder neuer; dann folge den Installationsanweisungen, die in der Diskussion beschrieben werden.

Um eine virtuelle Maschine zu verwenden, siehe Rezept 15.4.

Auch wenn wir es nur ungern sagen, vielleicht ist die richtige Lösung, native Tools wie die PowerShell zu verwenden.

Diskussion

Cygwin

Cygwin ist eine Linux-ähnliche Umgebung für Windows, die ein Linux-Look-and-Feel bietet.

Von der Cygwin-Website:

Cygwin ist:

  • eine große Sammlung von GNU- und Open-Source-Tools, die ähnliche Funktionen wie eine Linux-Distribution unter Windows bieten.

  • eine DLL (cygwin1.dll), die umfangreiche POSIX-API-Funktionen bietet.

Cygwin ist es nicht:

  • eine Möglichkeit, native Linux-Anwendungen unter Windows auszuführen. Du musst deine Anwendung vom Quellcode aus neu erstellen, wenn du sie unter Windows ausführen willst.

  • eine Möglichkeit, native Windows-Anwendungen auf magische Weise mit UNIX® -Funktionen wie Signalen, ptys usw. vertraut zu machen. Auch hier musst du deine Anwendungen aus dem Quellcode erstellen, wenn du die Vorteile der Cygwin-Funktionen nutzen willst.

Die Cygwin DLL funktioniert derzeit mit allen aktuellen, im Handel erhältlichen x86 32-Bit- und 64-Bit-Versionen von Windows, beginnend mit Windows Vista.

Hinweis

Die vorherige Cygwin-Version 2.5.2 war die letzte Version, die Windows XP und Server 2003 unterstützte.

Cygwin ist eine echte Unix-ähnliche Umgebung, die auf Windows läuft. Es ist ein hervorragendes Werkzeug, aber manchmal kann es zu viel sein. Windows-eigene Binärdateien der GNU Text-Utilities (mit Ausnahme der Bash) findest du unter http://unxutils.sourceforge.net/.

Ubuntu unter Windows

Ubuntu unter Windows laufen zu lassen, ist sehr interessant, aber abgesehen davon, dass es die Bash beinhaltet, ist es nicht Gegenstand dieses Buches, daher werden wir es nicht im Detail behandeln. In den Referenzen im Abschnitt "Siehe auch" findest du weitere Informationen.

Kurz gesagt:

  • Schalte den Entwicklermodus ein (siehe http://bit.ly/2h21MSZ).

    • Suche nach "Windows Features".

    • Wähle "Windows-Funktionen ein- oder ausschalten" und aktiviere "Windows Subsystem für Linux".

      • Das erfordert wahrscheinlich einen Neustart!!! Ernsthaft!?!

  • Öffnen Sie die Eingabeaufforderung und geben Sie ein bash.

    • Lade das Windows Subsystem für Linux aus dem Windows Store herunter.

PowerShell oder andere native Tools verwenden

PowerShell ist Microsofts Antwort auf die Leistungsfähigkeit und Flexibilität skriptfähiger Befehlszeilentools und der Ersatz für die Batch-Dateien command.com und cmd.exe. Abgesehen von der Tatsache, dass sie die Windows-eigene Antwort auf Shell-Skripte ist, fällt sie aus dem Rahmen dieses Buches und wird daher nicht behandelt.

Auch wenn sie im Vergleich zu den Unix/Linux-Tools verblasst sind, waren die alten Shell-Skriptsprachen mächtiger, als viele Leute wussten. Sie können für sehr einfache Aufgaben geeignet sein, bei denen die anderen hier vorgestellten Lösungen zu viel Aufwand bedeuten. Siehe http://www.jpsdomain.org/windows/winshell.html für weitere Informationen.

Mächtige zeichenbasierte und GUI-Befehlszeilen-Shells mit einer einheitlicheren Oberfläche, aber mit DOS/Windows-Ambiente findest du unter http://jpsoft.com. Keiner der Autoren ist mit diesem Unternehmen verbunden, aber einer der Autoren ist ein langjähriger zufriedener Nutzer.

1.18 Bash holen ohne Bash zu holen

Problem

Du willst eine Shell oder ein Shell-Skript auf einem System ausprobieren, für das du weder die Zeit noch die Ressourcen hast, es zu bauen oder zu kaufen.

Oder du hast gerade Lust, ein Zen-artiges Rezept zu lesen.

Lösung

Hol dir ein fast kostenloses Shell-Konto von http://polarhome.com, das eine winzige, symbolische Einmalgebühr verlangt, oder von einem anderen Anbieter.

Da fast jede Linux- und BSD-Distribution ein LiveCD- oder LiveDVD-Image hat, das mit ziemlicher Sicherheit auch als LiveUSB verwendet werden kann, kannst du diese zum Experimentieren herunterladen und booten. Das ist auch eine gute Idee, wenn du über einen Wechsel nachdenkst, damit du überprüfen kannst, ob deine Hardware unterstützt wird und funktioniert. Der knifflige Teil könnte sein, das BIOS oder UEFI deines Systems dazu zu bringen, von der CD/DVD oder USB zu booten. Früher war es schwierig, eine ISO-Datei auf einen USB-Stick zu "brennen", aber heute gibt es im Internet viele Tools und detaillierte Anleitungen für die Distribution deiner Wahl.

Alternativ kannst du auch eine Virtualisierungslösung verwenden; siehe Rezept 15.4.

Diskussion

Polarhome bietet viele kostenlose Dienste und fast kostenlose Shell-Konten. Laut der Website:

polarhome.com ist ein nicht-kommerzielles, pädagogisches Projekt zur Verbreitung von Shell-Betriebssystemen und Internetdiensten. Es bietet Shell-Accounts, die Entwicklungsumgebung, Mail und andere Online-Dienste auf allen verfügbaren Systemen (derzeit auf verschiedenen Linux-Varianten, MacOS X, OpenVMS, Solaris, OpenIndiana, AIX, QNX, IRIX, HP-UX, Tru64, SCO OpenServer, UnixWare, FreeBSD, OpenBSD, NetBSD, DragonFly/BSD, MirBSD, Ultrix, Minix, GNU Hurd, Syllable und OPENSTEP).

1.19 Mehr über die bash-Dokumentation erfahren

Problem

Du würdest gerne mehr über die Bash lesen, weißt aber nicht, wo du anfangen sollst.

Lösung

Nun, du liest dieses Buch und das ist ein guter Anfang! Die anderen O'Reilly-Bücher über Bash und Shell-Scripting sind Learning the Bash Shell, 3rd Edition, von Cameron Newham und Classic Shell Scripting von Nelson H. F. Beebe und Arnold Robbins.

Leider sind nicht alle offiziellen Bash-Dokumente und Support-Dateien online leicht zugänglich. Das Bash-Referenzhandbuch ist auf der Website des GNU-Projekts verfügbar, aber viele andere Materialien sind schwieriger zu finden oder zugänglich. Unsere begleitende Website hat die ganze Arbeit für dich erledigt und stellt die offizielle Bash-Referenzdokumentation und andere nützliche Materialien online zur Verfügung, damit du sie leicht nachschlagen kannst. Schau sie dir an und verweise bei Bedarf auch andere darauf.

Offizielle Dokumentation

Die offizielle Bash-FAQ findest du unter ftp://ftp.cwru.edu/pub/bash/FAQ. Siehe insbesondere "H2) Welche Art von Bash-Dokumentation gibt es?" Auch das offizielle Referenzhandbuch ist sehr empfehlenswert; siehe unten für Details.

Die Bash-Seite von Chet Ramey enthält eine Menge nützlicher Informationen. Chet (der derzeitige Bash-Maintainer ) pflegt auch die folgenden Seiten:

README

Eine Datei, die die Bash beschreibt

NEWS

Eine Datei mit einer kurzen Auflistung der wichtigsten Änderungen zwischen der aktuellen und der vorherigen Version

ÄNDERUNGEN

Eine vollständige Bash-Änderungshistorie

INSTALLIEREN

Einbauanleitung

ANMERKUNGEN

Plattformspezifische Hinweise zur Konfiguration und zum Betrieb

COMPAT

Eine Liste der Kompatibilitätsprobleme zwischen bash3 und bash1

Der neueste Bash-Quellcode und die Dokumentation sind immer unter http://ftp.gnu.org/gnu/bash/ verfügbar .

Wir empfehlen dringend, sowohl den Quellcode als auch die Dokumentation herunterzuladen, auch wenn du bereits fertige Binärdateien verwendest (siehe Anhang B für einen Index der enthaltenen Beispiele und des Quellcodes). Hier ist eine kurze Liste der Dokumentation, die im Verzeichnis ./doc des Quell-Tarballs enthalten ist (z. B. für http://ftp.gnu.org/gnu/bash/bash-4.4.tar.gz/, bash-4.4/doc):

FAQ

Eine Reihe von häufig gestellten Fragen zur Bash mit Antworten

INTRO

Eine kurze Einführung in die Bash

artikel.ms

Ein Artikel, den Chet über Bash für das Linux Journal geschrieben hat

bash.1

Die bash manpage

bashbug.1

Die Bashbug Manpage

einbauten.1

Eine Manpage, die die aus der bash extrahierten Buildins dokumentiert .1

bashref.texi

Das Bash-Referenzhandbuch

bashref.info

Das Bash-Referenzhandbuch, verarbeitet von makeinfo

rbash.1

Die eingeschränkte Manpage der Bash-Shell

readline.3

Die readline Manpage

Die .ps-Dateien sind PostScript-Versionen der hier aufgeführten Dateien. Die .html-Dateien sind HTML-Versionen der Manpage und des Referenzhandbuchs. Die .0-Dateien sind formatierte Handbuchseiten. Die .txt-Versionen sind ASCII - die Ausgabe von groff -Tascii.

Im Dokument-Tarball (z.B. http://ftp. gnu.org/gnu/bash/bash-doc-4.4.tar.gz) findest du formatierte Versionen von:

bash-doc-4.4:

bash.0

Die bash manpage (auch .pdf, .ps, .html)

bashbug.0

Die Bashbug Manpage

bashref

Das GNU Bash Referenzhandbuch (auch .pdf, .ps, .html, .dvi)

buildins.0

Die builtins manpage

rbash.0

Die eingeschränkte Manpage der Bash-Shell

Siehe auch

Get bash Kochbuch, 2. Auflage now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial