Hinweis des Verlages zum Urheberrecht und Digitalen Rechtemanagement
Der Verlag räumt Ihnen mit dem Kauf des ebooks das Recht ein, die Inhalte im Rahmen des geltenden Urheberrechts zu nutzen. Dieses Werk, einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und Einspeicherung und Verarbeitung in elektronischen Systemen.
Der Verlag schützt seine ebooks vor Missbrauch des urheberrechts durch ein digitales Rechtemanagement. Bei Kauf im Webshop des Verlages werden die ebooks mit einem nicht sichtbaren digitalen Wasserzeichen individuell pro Nutzer signiert.
Bei Kauf in anderen ebook-Webshops erfolgt die Signatur durch die Shopbetreiber. Angaben zu diesem DRM finden Sie auf den Seiten der jeweiligen Anbieter.
Bibliografische
Information
der
Deutschen
Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese
Publikation
in
der
Deutschen
Nationalbibliografie.
Detaillierte
bibliografische
Daten
sind
im
Internet
über
<http://dnb.d-nb.de>
abrufbar.
Bei
der
Herstellung
des
Werkes
haben
wir
uns
zukunftsbewusst
für
umweltverträgliche
und
wiederverwertbare
Materialien
entschieden.
Der
Inhalt
ist
auf
elementar
chlorfreiem
Papier
gedruckt.
ISBN 978-3-95845-555-9
www.mitp.de
E-Mail:
mitp-verlag@sigloch.de
Telefon:
+49
7953
7189
-
079
Telefax:
+49
7953
7189
-
082
© 2018 mitp Verlags GmbH & Co. KG, Frechen
Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.
Lektorat: Sabine Janatschek
Sprachkorrektorat: Renate Feichter, www.logos-wort.de
Covergestaltung: Christian Kalkert, www.kalkert.de
Bildnachweis Cover: www.fotolia.com/kalafoto
Satz: Dr. Joachim Schlosser, www.schlosser.info
Druck: Medienhaus Plump GmbH, Rheinbreitbach
Patrick Ditchen ist seit 1998 als freier Trainer tätig. Er gibt Schulungen auf den Gebieten der Unix-System-Administration, Unix-Shell-Skript-Programmierung und Perl. Für Sun Microsystems Deutschland erstellte er die Unterlagen des Perl-Kurses.
Vor seiner Tätigkeit als Kursleiter arbeitete er sechs Jahre lang am Max-Planck-Institut für Psychiatrie in München. Dort baute er als System- und Netzwerk-Administrator ein komplexes heterogenes Netzwerk mit über 300 Rechnern auf, das er in den folgenden Jahren gemeinsam mit seinen Kollegen betreute. Er implementierte Firewall-Funktionalitäten, half bei der Einführung von SAP und wirkte an vielen weiteren Vernetzungsprojekten mit.
Er besitzt ein Diplom als Physiker, wechselte jedoch gleich nach seinem Studium 1992 in die EDV. Bereits während der letzten Studienjahre hielt er an einer MTA-Schule einen selbst geschriebenen EDV-Kurs, eine Mathematik-Vorlesung, deren Unterlagen er sogleich neu gestaltete, und war Leiter eines Physik-Praktikums, das er ebenfalls an die Bedürfnisse der MTA-SchülerInnen anpasste.
In all seinen Lehrtätigkeiten, gleich ob auf Papier oder bei Schulungen, orientiert er sich in erster Linie an praktischen Fragen und der konkreten Anwendung des Lehrstoffes.
Aus seinem Buch Shell-Skript Programmierung, das der Vorgänger dieses Buches ist, wurde das Kapitel über den awk übernommen.
Martin Schulte arbeitet seit Mitte der 1980er Jahre mit Unix, seit frühen Versionen mit Linux. Seit einigen Jahren ist Debian seine bevorzugte Distribution.
Beruflich hat er für verschiedene Kunden Software entwickelt und für die German Unix User Group (https://guug.de) Veranstaltungen wie das Frühjahrsfachgespräch und den Linux-Kongress organisiert.
Daneben hat er immer wieder Kurse in den Bereichen Unix/Linux-Grundlagen, Shell- und Perl-Programmierung gehalten, in den letzten zwei Jahren für das Linuxhotel (http://linuxhotel.de).
Unter einer Shell versteht man – vor allem unter Unix – ein Programm, das eine Texteingabe des Benutzers entgegennimmt, um andere Programme zu starten.
Da diese Eingabe meist aus einer Zeile, die mit der Enter-Taste abgeschlossen wird, besteht und die Shell anschließend interpretiert, welches Programm mit welchen zusätzlichen Informationen gestartet werden soll, spricht man auch von einem Kommandozeileninterpreter (CLI für command line interpreter).
Zwei Beispiele:
Auf Unix-Systemen ohne grafische Benutzeroberfläche wird in aller Regel unmittelbar nach dem Anmelden eine Shell für den Benutzer gestartet. Das ist typischerweise immer noch der Fall, wenn man auf entfernten Systemen mit dem Kommando ssh arbeitet.
Auf Desktop-Systemen können viele Programme natürlich auch durch Anklicken eines Icons für das Programm selbst oder einer Datei, mit deren Dateinamen das Programm verbunden ist, gestartet werden.
Eine Shell, mit der ein Benutzer arbeiten kann, muss er in diesem Fall erst einmal starten – wie das funktioniert, ist von Desktop zu Desktop verschieden.
Wichtig ist es, im Hinterkopf zu behalten, dass Shells entwickelt worden sind, um das Starten von Kommandos einfach zu gestalten und nicht um Programme zu schreiben – das wird uns im Folgenden nicht selten beschäftigen, wenn wir für Programmiersprachen ungewöhnliche Konstrukte verwenden müssen.
Der Name Shell (englisch für Hülle oder (Muschel-)Schale) ist aus der Vorstellung entstanden, dass sich die Shell eben wie eine solche um den Betriebssystemkern legt und als Schnittstelle zwischen dem Betriebssystem und den anderen Programmen dient.
Shells sind unter Unix aber auch ganz normale Programme, das hat dazu geführt, dass die Entwicklung von Shells von der des Betriebssystem(kern)s losgelöst ist.
Zum Verständnis des Namens bash folgt hier ein kurzer Abriss über die Geschichte einiger Shells:
Die erste Shell unter Unix war die nach ihrem Entwickler benannte Thomson-Shell, sie enthielt einige Ideen, die bis heute in jeder Unix-Shell zu finden sind. Eine zur Thomson-Shell kompatible Shell wird bis heute im Etsh-Projekt (http://etsh.io) gepflegt.
Um 1979 wurde die Thomson-Shell (ab dann osh für old shell genannt) durch die ebenfalls nach ihrem Entwickler benannte Bourne-Shell abgelöst, sie wird üblicherweise mit sh abgekürzt.
Im gleichen Jahr entstand mit der C-Shell (csh) eine weitere Shell. In vielen Punkten sind die Konstrukte zumindest sehr ähnlich zur Bourne-Shell, lehnen sich aber mehr an die Programmiersprache C an, woraus der Name resultiert. Einige Sprachelemente aus der C-Shell und ihren Nachfolgern haben die Entwicklung der bash beeinflusst, ansonsten hat sie aber gerade als Programmiersprache nur noch eine untergeordnete Bedeutung.
1983 erschien die erste Version der nach ihrem Entwickler benannten Korn-Shell. Die Korn-Shell hat einen erheblichen Einfluss auf die Entwicklung der bash gehabt.
Die Entwicklung der bash begann 1987, der Name {Bourne,born}-again-Shell ist ein kleines Wortspiel, es ist also sowohl wieder eine Bourne-Shell als auch eine wiedergeborene Shell. Das Konstrukt mit den geschweiften Klammern wird übrigens in section 7.4 erklärt.
Das Portable Operating System Interface, kurz POSIX, ist ein Standard, der unter anderem die Funktionen einer Shell sowie etlicher Dienstprogramme, die mit einem standardkonformen System geliefert werden müssen, festlegt. Eine normal gestartete bash erfüllt im Wesentlichen diesen Standard – nach Ausführen des Kommandos set -o posix gibt es nur noch minimale Abweichungen. Andererseits spezifiziert POSIX das Verhalten einer Shell nicht so genau, dass sichergestellt ist, dass sich zwei POSIX-konforme Shells auch wirklich gleich verhalten.
Trotzdem gilt die POSIX-Kompatibilität als ein kleinster gemeinsamer Nenner zwischen verschiedenen Shells und es kann sinnvoll sein, im Sinne einer Portabilität zwischen verschiedenen Shells auf die Nutzung von Features, die eine bestimmte Shell mit sich bringt, die aber nicht im POSIX-Standard definiert sind, zu verzichten.
Als Beispiel ist die zur Drucklegung dieses Buches aktuelle Version 9 („Stretch“) der Debian-Linux-Distribution zu nennen, die ebenso wie die Vorgängerversion 8 („Jessie“) zur Abarbeitung der meisten im System mitgelieferten Shell-Programme die Debian Almquist Shell (dash) verwendet. Diese ist POSIX-kompatibel, bringt zusätzliche Features mit, die wohl von der bash unterstützt werden, ist aber insgesamt weniger mächtig als diese.
Daneben dürfte eine Unmenge von Programmen existieren, die für andere, ältere Shells (oder ältere Versionen der bash) geschrieben wurden, möglicherweise in Zeiten vor dem POSIX-Standard.
Ebenso kennen vermutlich nicht alle Personen, die Programme für die Shell entwickeln, den aktuellen POSIX-Standard und nutzen daher noch längst veraltete Konstrukte, die aber von praktisch jeder Shell unterstützt werden.
Beim Kompilieren der bash können einige Features ein- oder ausgebaut und die Voreinstellungen für Optionen angegeben werden.
Leider ist die Situation alles andere als übersichtlich ...
Wir werden uns daher in diesem Buch an der Version 4.4 der bash orientieren, aber auch vermeintlich veraltete Konstrukte darstellen und auf den POSIX-Standard hinweisen.
Das Buch erhebt auch nicht den Anspruch, wirklich alle Möglichkeiten der bash darzulegen – in der Menge vieler nebensächlicher Details drohen sonst wichtige Dinge unterzugehen.
In der alltäglichen Arbeit entsteht schnell der Wunsch, die Aufrufe mehrerer Programme zu kombinieren und zu automatisieren:
Die Entwicklerin aus unserem oben genannten Beispiel möchte ihr Programm nur starten, wenn der Übersetzungsvorgang erfolgreich war. Vor dem Start möchte sie vielleicht noch die alte Logdatei unter einem anderen Namen sichern.
Der Administrator möchte, dass regelmäßig automatisch überprüft wird, ob auf den Festplatten seines Servers noch ausreichend Platz vorhanden ist. Wenn bestimmte Grenzen überschritten sind, möchte er automatisch per E-Mail informiert werden.
Die mit jedem Unix-System ausgelieferten Programme (Unix-Toolbox) sind darauf ausgelegt, über einen sehr einfachen Mechanismus, sogenannte Pipes, kombiniert zu werden. Damit entstehen sehr schnell sehr mächtige neue Funktionen, das ist schon ein erster Schritt zur Programmierung. Nicht immer aber können alle Anforderungen über Pipes erfüllt werden, und dann entsteht der Bedarf nach einer richtigen Programmiersprache, die die bash inzwischen mitliefert.
Das Programmieren in der Shell ist anfangs sehr einfach, weil man mit den gerade erwähnten Pipes und Kenntnissen über einige wenige Programme aus der Unix-Toolbox sehr schnell sehr hilfreiche Ergebnisse erzielen kann.
Trotz vieler Verbesserungen und Erweiterungen ist den Unix-Shells aber immer noch anzumerken, dass sie nicht als Programmiersprache konzipiert worden sind.
Hinzu kommt, dass Shell-Skripte (so werden in der Shell Programme üblicherweise genannt) in der Ausführung langsam sind, da zum einen jede Zeile zur Laufzeit interpretiert wird (in Schleifen bei jedem Durchlauf) und zum anderen das übliche Starten von anderen Programmen (oft solchen aus der Unix-Toolbox) mit einem erheblichen Overhead verbunden ist.
Es gibt also gute Gründe, sich nach Alternativen umzusehen.
Der Vollständigkeit halber sei erwähnt, dass in älterer Literatur an dieser Stelle gerne die Programmiersprache C genannt wird. Sie erzeugt – zumindest in der Theorie – die schnellsten Programme, ist dafür aber wesentlich anfälliger für Programmierfehler und bietet für wiederkehrende Aufgaben vergleichsweise wenige vorgefertigte Bibliotheken. Dazu müssen C-Programme für das jeweilige Zielsystem kompiliert werden, was immer mit einem gewissen Aufwand und einer Misserfolgswahrscheinlichkeit verbunden ist.
Standardmäßig in der Unix-Toolbox enthalten ist die Programmiersprache awk. In Shell-Skripten werden häufig kleine awk-Skripte gestartet. Es ist aber genauso möglich, aus awk heraus Programme zu starten und so auf die Shell zu verzichten. Aus welchen Gründen auch immer wird dieser Weg aber in der Praxis selten gegangen.
Die erste populäre Programmiersprache, die sich zum Ziel gesetzt hatte, Shell-Skripte zu ersetzen, ist Perl. Vielen Elementen der Sprache Perl merkt man die enge Verbindung zu diesem Einsatzgebiet an. Wie bei Shell-Skripten werden auch Perl-Programme im Quellcode verteilt und auf dem Zielrechner interpretiert, allerdings weitaus effizienter als Shell-Skripte. Umfangreiche Bibliotheken bieten Lösungen für verschiedenste Aufgaben.
All das trifft auch auf später (zum Teil wenig später) entstandene Sprachen wie Python, Ruby und viele weitere zu. Ein Vergleich all dieser Sprachen ist ein umfangreiches Thema.
Auch soll nicht unerwähnt bleiben, dass es insbesondere mit der zsh eine weitere, zumindest auf modernen Linux-basierten Systemen auch problemlos installierbare Shell gibt, die der bash in vielen Bereichen als überlegen gilt.
Entscheidend ist es, sich den Gegebenheiten des Unternehmens oder der Organisation (oder des Open-Source-Projekts) anzupassen, für das eine Funktionalität entwickelt wird: Werden in einem Unternehmen hunderte von Shell-Skripten entwickelt und gepflegt, wird die Shell für neue Aufgaben eine gute Wahl sein.
Ist diese Voraussetzung aber nicht gegeben – oder ist gar eine andere Skript-Sprache gesetzt – sollte man spätestens nach 20 Zeilen Shell-Skript über eine der genannten Alternativen nachdenken.
Wir setzen voraus, dass Sie in Grundzügen mit einem Unix-System vertraut sind. Auf Konzepte wie die Grundzüge des Dateisystems, die Vergabe von Rechten oder Prozesse gehen wir deshalb in diesem Buch nicht ein. In den ersten Kapiteln erläutern wir vielleicht den Umgang mit der Shell etwas ausführlicher, als das für erfahrene Unix-Benutzer erforderlich ist: Das ermöglicht zum einen auch Lesern mit wenig bis keiner Erfahrung im Umgang mit der Shell einen Einstieg in das Thema und hilft zum anderen auch erfahrenen Shell-Nutzern, das eine oder andere Bekannte so zu vertiefen, wie es für die Programmierung erforderlich ist.
Wenn Sie die Beispiele im Buch nachvollziehen beziehungsweise die Aufgaben bearbeiten, brauchen Sie Zugang zu einem Rechner, auf dem die bash, am besten in einer Version ab 4.4, installiert ist.
Durch die Vielzahl der einfach zu installierenden Linux-Distributionen stellt das heute meist kein besonderes Problem mehr dar. Linux-Systeme können sowohl direkt gebootet als auch in einer virtuellen Maschine gestartet werden. Eine interessante Alternative ist auch die Nutzung eines virtuellen Servers im Internet.
Nutzen Sie ein direkt auf dem PC installiertes Unix-System, melden Sie sich meist über eine grafische Oberfläche an. In diesem Fall müssen Sie herausfinden, wie Sie in dieser Oberfläche ein sogenanntes Terminalfenster mit einer Shell starten können.
Seit Build 1607 läuft die bash zusammen mit der Unix-Toolbox von Microsoft unterstützt auch unter Windows 10, so dass man auch kein Unix-Betriebssystem mehr braucht.
Des Weiteren brauchen Sie einen Editor, um selbst Skripte erstellen zu können. Die Auswahl an Editoren ist ähnlich groß wie die an Shells.
Hilfreich ist es, wenn der Editor über ein auf die Shell-Programmierung zugeschnittenes Syntax-Highlighting verfügt, das Sprachelemente in unterschiedlichen Farben darstellen kann.
Im POSIX-Standard ist der – wegen seiner aus heutiger Sicht unintuitiven Bedienung oft verschriene – vi enthalten. Moderne Versionen sind in der Bedienung deutlich komfortabler und bieten das erwähnte Syntax-Highlighting.
Eine Sammlung von Links haben wir unter http://www.mitp.de/555 zusammengestellt.
Die Grundfunktion einer Shell wie der bash ist es, andere Programme zu starten.
Hinter der Eingabeaufforderung, dem sogenannten Prompt, gibt man den Namen des Kommandos ein und „schickt“ es dann mit der Enter-Taste „ab“. Um sparsam mit dem Platz umzugehen, verwenden wir in diesem Buch als Prompt immer die Zeichenfolge Dollar-Leerzeichen:
Es gibt kein Kommando abc, die Shell – in diesem Fall ist es eine bash – gibt eine entsprechende Fehlermeldung aus.
Hier startet die Shell das Kommando ls. Es zeigt in dieser einfachsten Form an, welche Dateien sich im aktuellen Arbeitsverzeichnis befinden. Zum Zeitpunkt der Programmausführung befanden sich im Arbeitsverzeichnis keine Dateien, daher erhalten wir keine Ausgabe.
Während das gestartete Kommando läuft, wartet die Shell, sobald es sich beendet, übernimmt sie wieder die Kontrolle, was durch das Anzeigen des Prompts erkennbar ist.
Das Verhalten von Kommandos lässt sich durch Mitgabe von sogenannten Argumenten beeinflussen. Die Shell teilt eine Eingabezeile an einer Folge von einem oder mehreren Leerzeichen in Worte auf. Das erste Wort ist das Kommando, alle weiteren Worte werden dem aufgerufenen Kommando als Argumente mitgegeben, hier ein Beispiel mit dem Kommando echo:
Das aufgerufene Kommando – wir werden später sehen, dass sein Name ihm zugleich als 0. Argument übergeben wird – ist echo. Es erhält die Zeichenkette Guten als 1. Argument, Tag, als 2. Argument sowie liebe und Leser. als 3. und 4.
Da echo nichts anderes tut, als seine Argumente – getrennt durch jeweils ein Leerzeichen und mit einem Zeilenumbruch abgeschlossen – auszugeben, erhalten wir das gezeigte Ergebnis.
Es ist jedem Programm überlassen, wie es die ihm vom Aufrufer (der in unseren Beispiel fast immer die Shell ist) übergebenen Argumente interpretiert. Sehr oft erwarten Programme als Argumente eine Liste von Dateinamen, die dann z.B. nacheinander kopiert, verschoben, gelöscht oder durchsucht werden.
Fast alle Programme bieten aber die Möglichkeit, das „normale“ Verhalten in einem gewissen Umfang über sogenannte Optionen zu modifizieren. Diese Optionen werden den Programmen über die Argumente in der Kommandozeile mitgeteilt. Es gibt dafür im POSIX-Standard ein paar Konventionen, die bekannt sein sollten: Zum einen, wenn man Programme selber aufruft, zum anderen sollte man in seinen eigenen Skripten auch diese Konventionen einhalten.
Die erste Konvention lautet, dass eine Option ein Argument bestehend aus einem Minuszeichen gefolgt von einem Buchstaben ist:
Überlegen Sie, mit wievielen Argumenten echo in diesem Beispiel aufgerufen wird!
Es sind zwei, nämlich -n und Hallo. Wenn man berücksichtigt, dass als 0. Argument der Kommandoname übergeben wird, ist die Antwort drei mindestens genauso richtig.
Da -n als Option erkannt wird, gibt echo nur Hallo aus. Die Option bewirkt, dass das sonst übliche Newline nach den Argumenten nicht ausgegeben wird, weshalb der folgende Prompt, den die Shell wieder ausgibt, wenn das von ihr aufgerufene Programm beendet ist, unmittelbar auf das Hallo folgt.
Hier noch ein ausführlicheres Beispiel für das Kommando ls:
Zunächst einmal sieht man die Wirkung der Option -a: Ohne Option zeigt das Kommando ls nur die Dateien an, deren Name nicht mit einem Punkt anfängt. Dieses Verhalten wird durch die genannte Option ausgeschaltet und man sieht die Verzeichnisse . für das eigene Verzeichnis und .. für das näher zur Wurzel liegende Verzeichnis, die sich in jedem auch vermeintlich leeren Unix-Verzeichnis befinden. Eine sehr sinnvolle Option ist -A, mit ihr zeigt ls alle Einträge in einen Verzeichnis bis auf . und .. an.
Die Option -l zeigt ausführlichere Informationen zu den gelisteten Dateien an, für Details sei auf grundlegendere Unix-Literatur verwiesen.
Einbuchstabige Optionen lassen sich auch kombinieren, wie -al zeigt.
Es gibt auch Optionen, die ihrerseits wieder einen Parameter haben, ein – wenn auch selten genutztes – Beispiel dafür ist -w, damit kann die Ausgabebreite festgelegt werden. Durch den auf das -w folgenden Parameter 3, der im Beispiel durch ein (optionales) Blank getrennt ist, wird diese auf 3 Zeichen beschränkt, damit werden die beiden Einträge . und .. untereinander und nicht nebeneinander angezeigt.
Viele Kommandos bieten inzwischen auch ausgeschriebene (oder lange) Optionen an – das erhöht zwar die Tipparbeit, erleichtert aber das Lesen und Verstehen. Bei 40 einbuchstabigen Optionen, die ls hat, ist das ein Argument.
Diese langen Optionen (in Abgrenzung zu denen, die im Folgenden erklärt werden, auch GNU-Style-Optionen genannten) werden mit einem doppelten Minus -- eingeleitet, dem ein beschreibender Text folgt. Hat die Option verpflichtend ein Argument, so kann dieses mit einem Gleichheitszeichen oder durch ein Blank getrennt angehängt werden. Hat die Option nur optional ein Argument, so muss dieses mit einem = angehängt werden. Beim Aufruf von Programmen können lange und kurze Optionen gemischt werden.
Es kann dabei durchaus Optionen geben, für die es nur eine kurze oder nur eine lange Schreibweise gibt.
Es gibt noch ein zweites System (X11-Style-Optionen genannt): Diese Optionen werden auch mit einem einfach Minus eingeleitet, dahinter folgt aber immer ein längerer Text. Welches Programm welches System verwendet, muss man der man-Page oder der Ausgabe des Programms, wenn man es mit der Option help aufruft, entnehmen – im einen System ist diese als --help, im anderen als -help zu schreiben.
Allein schon der Übersichtlichkeit halber sollte man Optionen zwischen den Kommandonamen und die „normalen“ Argumente schreiben. Es gibt allerdings auch Kommandos, die weiter hinten stehende Optionen nicht als solche erkennen. Ausnahme von dieser Regel sind test und find, die wir in chapter 7 beziehungsweise section 9.2.7 kennenlernen werden.
Eine wichtige „Pseudo“-Option, die von vielen (nicht allen) Programmen verstanden wird, ist -- – sie besagt, dass hinter ihr keine weiteren Optionen mehr kommen. Den Sinn werden wir in section 6.2.1 noch einmal beleuchten.
Klassischerweise werden Informationen über Kommandos (und mehr) unter Unix über das Kommando man cmd zur Verfügung gestellt.
Eine eher kürzere Übersicht stellen viele Kommandos inzwischen über die Option --help bereit, manche oder über -h oder -help.
Ebenso gibt es für etliche Kommandos Hilfe über info cmd .
Natürlich finden sich im Internet inzwischen Beschreibungen zu allen Kommandos. Die, die wie gerade beschrieben direkt auf dem System aufgerufen werden, haben den Vorteil, dass sie zur vorhandenen Version des Programms passen.
Mit dem #-Zeichen wird ein Kommentar bis zum Zeilenende eingeleitet. Das ist relativ unspektakulär, aber wir erläutern es hier, weil folgende Listings es verwenden:
Die bisher aufgeführten Kommandos haben ihre Ausgabe – sofern eine erfolgt ist – auf den Bildschirm ausgegeben.
Ein einfacher Mechanismus unter Unix erlaubt es nun, die Ausgaben sowohl in Dateien als auch zur Weiterverarbeitung in anderen Kommandos weiterzuleiten.
Ruft ein Programm ein anderes auf, so gibt der Aufrufer – so er sich an die Konventionen hält – nicht nur die bereits erläuterten Argumente mit, sondern auch drei vordefinierte Ein-/Ausgabekanäle, die Standard-Input, Standard-Output und Standard-Error heißen.
Im Fall einer interaktiven Shell, also einer, die vom Benutzer über ein Terminal(-fenster) bedient wird, sind diese mit diesem Terminal verbunden. Das bedeutet, dass Eingaben von der Tastatur gelesen werden und Ausgaben, sowohl Ergebnisse als auch Fehler, auf den Bildschirm geschrieben werden.
Die Shell stellt nun einen einfachen Mechanismus bereit, diese Voreinstellung zu ändern, sehen wir uns dies am Beispiel an, bei dem Sie auch noch den Befehl cat kennenlernen: