Vorwort

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

Jedes moderne Betriebssystem hat mindestens eine Shell, manche haben sogar mehrere. Einige Shells sind kommandozeilenorientiert, wie die in diesem Buch besprochene Shell. Andere sind grafisch, wie der Windows Explorer oder der Macintosh Finder. Manche Benutzer/innen interagieren nur so lange mit der Shell, bis sie ihre Lieblingsanwendung gestartet haben, und verlassen diese dann erst wieder, wenn sie sich abmelden. Die meisten Benutzer/innen verbringen jedoch eine beträchtliche Zeit mit der Shell. Je mehr du über deine Shell weißt, desto schneller und produktiver kannst du sein.

Egal, ob du ein Systemadministrator, ein Programmierer oder ein Endbenutzer bist, es gibt sicherlich Gelegenheiten, bei denen ein einfaches (oder vielleicht nicht so einfaches) Shell-Skript dir Zeit und Mühe ersparen oder die Konsistenz und Wiederholbarkeit einer wichtigen Aufgabe erleichtern kann. Selbst die Verwendung eines Alias, um den Namen eines häufig verwendeten Befehls zu ändern oder zu verkürzen, kann einen großen Effekt haben. Das und vieles mehr werden wir behandeln.

Wie bei jeder allgemeinen Programmiersprache gibt es auch in der Shell mehr als einen Weg, eine bestimmte Aufgabe zu erledigen. In manchen Fällen gibt es nur einen besten Weg, aber in den meisten Fällen gibt es mindestens zwei oder drei gleich effektive und effiziente Wege, eine Lösung zu schreiben. Welchen Weg du wählst, hängt von deinem persönlichen Stil, deiner Kreativität und deiner Vertrautheit mit den verschiedenen Befehlen und Techniken ab. Das gilt für uns als Autoren genauso wie für dich als Leser. In den meisten Fällen werden wir uns für eine einzige Methode entscheiden und diese umsetzen. In einigen wenigen Fällen wählen wir eine bestimmte Methode aus und erklären, warum wir sie für die beste halten. Gelegentlich zeigen wir auch mehr als eine gleichwertige Lösung, damit du diejenige auswählen kannst, die am besten zu deinen Bedürfnissen und deiner Umgebung passt.

Manchmal muss man sich auch zwischen einem cleveren Weg, einen Code zu schreiben, und einem lesbaren Weg entscheiden. Wir entscheiden uns immer für den lesbaren Weg, denn die Erfahrung hat uns gelehrt, dass du dich in 6 oder 18 Monaten und 10 Projekten fragen wirst, was du dir dabei gedacht hast, egal wie durchschaubar dein cleverer Code jetzt ist. Vertrau uns: Schreibe klaren Code und dokumentiere ihn - du wirst dir (und uns) später dankbar sein.

Wer sollte dieses Buch lesen?

Dieses Buch richtet sich an alle, die ein Unix- oder Linux-System benutzen, sowie an Systemadministratoren, die jeden Tag mit mehreren Systemen arbeiten. Mit diesem Buch wirst du in der Lage sein, Skripte zu erstellen, mit denen du mehr in kürzerer Zeit, einfacher, konsistenter und wiederholbarer als je zuvor erledigen kannst.

Irgendjemand? Ja. Neue Benutzer/innen werden die Abschnitte über die Automatisierung sich wiederholender Aufgaben, über einfache Ersetzungen und über die Anpassung ihrer Umgebung zu schätzen wissen, damit diese freundlicher ist und sich vielleicht auf vertrautere Weise verhält. Power-User und Administratoren werden neue und andere Lösungen für häufige Aufgaben und Herausforderungen finden. Fortgeschrittene Benutzer/innen werden eine Sammlung von Techniken haben, die sie im Handumdrehen anwenden können, um das letzte Feuer zu löschen, ohne sich an jedes kleine Detail der Syntax erinnern zu müssen.

Ideale Leser sind:

  • Neue Unix- oder Linux-Benutzer, die nicht viel über die Shell wissen, aber mehr tun wollen, als nur zu zeigen und zu klicken

  • Erfahrene Unix- oder Linux-Benutzer und Systemadministratoren, die schnelle Antworten auf Fragen zum Shell-Scripting suchen

  • Programmierer, die in einer Unix- oder Linux- (oder sogar Windows-) Umgebung arbeiten und produktiver sein wollen

  • Neue Unix- oder Linux-Sysadmins oder solche, die aus einer Windows-Umgebung kommen und sich schnell zurechtfinden müssen

  • Erfahrene Windows-Benutzer und Sysadmins, die eine leistungsfähigere Skripting-Umgebung wünschen

In diesem Buch wird nur kurz auf grundlegende und fortgeschrittene Shell-Skripte eingegangen - siehe Learning the bash Shell, 3rd Edition, von Cameron Newham (O'Reilly) und Classic Shell Scripting von Nelson H. F. Beebe und Arnold Robbins (O'Reilly) für eine ausführlichere Behandlung. Unser Ziel ist es stattdessen, Lösungen für gängige Probleme zu liefern, wobei der Schwerpunkt eher auf dem "How to" als auf der Theorie liegt. Wir hoffen, dass du mit diesem Buch Zeit sparen kannst, wenn du nach Lösungen suchst oder dir die Syntax merken willst. Genau das ist der Grund, warum wir dieses Buch geschrieben haben: Wir wollten ein Buch, das wir durchlesen können, um Ideen zu bekommen, und in dem wir dann bei Bedarf praktische Beispiele nachschlagen können. Auf diese Weise müssen wir uns nicht an die feinen Unterschiede zwischen Shell, Perl, C usw. erinnern.

Dieses Buch setzt voraus, dass du Zugang zu einem Unix- oder Linux-System hast (siehe Rezepte 1.14 bis 1.18 oder Rezept 15.4) und damit vertraut bist, dich einzuloggen, grundlegende Befehle einzugeben und einen Texteditor zu benutzen. Für die meisten Rezepte brauchst du keinen Root-Zugang, aber für einige wenige, vor allem für die Installation der Bash, sind Root-Zugänge erforderlich.

Über dieses Buch

Dieses Buch behandelt die Bash, die GNU Bourne Again Shell, die zur Familie der Shells gehört, zu der auch die ursprüngliche Bourne Shell sh, die Korn Shell ksh und die Public Domain Korn Shell pdksh gehören. Diese und andere Shells wie z.B. dash und zsh werden zwar nicht speziell behandelt, aber die meisten Skripte werden mit ihnen gut funktionieren.

Du solltest in der Lage sein, dieses Buch von vorne bis hinten zu lesen und es auch einfach in die Hand zu nehmen und alles zu lesen, was dir ins Auge sticht. Vor allem aber hoffen wir, dass du, wenn du eine Frage hast oder einen Tipp brauchst, schnell die richtige Antwort findest - oder etwas, das der Antwort sehr nahe kommt - und so Zeit und Mühe sparst.

Ein großer Teil der Unix-Philosophie besteht darin, einfache Tools zu entwickeln, die eine Sache gut machen, und sie dann nach Bedarf zu kombinieren. Diese Kombination von Werkzeugen wird oft über ein Shell-Skript erreicht, weil diese Befehle, die so genannten Pipelines, lang oder schwer zu erinnern und einzugeben sein können. Wo es angebracht ist, werden wir die Verwendung vieler dieser Tools im Zusammenhang mit dem Shell-Skript als Klebstoff, der die Teile zusammenhält, um das Ziel zu erreichen, behandeln.

Die erste Ausgabe dieses Buches wurde mit OpenOffice.org Writer auf einem Linux- oder Windows-Rechner geschrieben, der gerade zur Hand war, und in Subversion gespeichert (siehe Anhang D). Das Open Document Format erleichterte viele wichtige Aspekte beim Schreiben dieses Buches, z. B. Querverweise und das Extrahieren von Code (siehe Rezept 13.18). Dieser Quelltext wurde später für die Produktion in DocBook konvertiert.

Für die zweite Ausgabe haben wir auf Asciidoc und Git auf dem Atlas-System von O'Reilly umgestellt, was sehr gut funktioniert hat. Wir sind den Abteilungen für Produktion und Tools von O'Reilly für ihre Hilfe dankbar.

GNU Software

Diebash und viele der anderen Tools, die wir in diesem Buch besprechen, sind Teil des GNU-Projekts. GNU (sprich: guh-noo, wie Kanu) ist ein rekursives Akronym für "GNU's Not Unix" und das Projekt geht auf das Jahr 1984 zurück. Sein Ziel ist es, ein freies (wie in Freiheit) Unix-ähnliches Betriebssystem zu entwickeln.

Ohne zu sehr ins Detail zu gehen, ist das, was gemeinhin als Linux bezeichnet wird, eigentlich ein Kernel mit verschiedener unterstützender Software als Kern. Die GNU-Tools sind um ihn herum angeordnet und je nach Distribution ist eine Vielzahl anderer Software enthalten. Der Linux-Kernel selbst ist jedoch keine GNU-Software.

Das GNU-Projekt argumentiert, dass Linux eigentlich "GNU/Linux" heißen sollte, und hat damit nicht ganz unrecht, weshalb einige Distributionen (vor allem Debian) dies tun. Damit ist das Ziel von GNU wohl erreicht, auch wenn das Ergebnis nicht ausschließlich GNU ist.

Das GNU-Projekt hat eine große Menge an hervorragender Software beigesteuert, darunter vor allem die Bash. Es gibt GNU-Versionen von praktisch jedem Tool, das wir in diesem Buch besprechen, und obwohl die GNU-Tools einen größeren Funktionsumfang und (in der Regel) eine höhere Benutzerfreundlichkeit aufweisen, sind sie manchmal auch etwas anders. Wir besprechen das in Rezept 15.3. Allerdings sind auch die kommerziellen Unix-Anbieter in den 1980er und 1990er Jahren zum großen Teil für diese Unterschiede verantwortlich.

Über all diese Aspekte von GNU, Unix und Linux wurde bereits genug gesagt (mehrere Bücher dieser Größe), aber wir hielten diese kurze Anmerkung für angemessen. Unter http://www.gnu.org findest du noch viel mehr zu diesem Thema.

Ein Hinweis zu Codebeispielen

Wenn wir in diesem Buch ein ausführbares Shell-Skript zeigen, zeigen wir es normalerweise in einem Offset-Bereich wie diesem:

$ ls
a.out  cong.txt  def.conf  file.txt  more.txt  zebra.list
$

Das erste Zeichen ist oft ein Dollarzeichen ($), um anzuzeigen, dass dieser Befehl an der Eingabeaufforderung der Bash-Shell eingegeben wurde. (Erinnere dich daran, dass du die Eingabeaufforderung, wie in Rezept 16.2 beschrieben, ändern kannst, so dass deine Eingabeaufforderung ganz anders aussehen kann.) Die Eingabeaufforderung wird von der Shell gedruckt; du gibst den Rest der Zeile ein. Auch die letzte Zeile in einem solchen Beispiel ist oft eine Eingabeaufforderung (wieder die $ ), um zu zeigen, dass die Ausführung des Befehls beendet ist und die Kontrolle an die Shell zurückgegeben wurde.

Das Pfund- oder Rautenzeichen (#) ist ein wenig komplizierter. In vielen Unix- oder Linux-Dateien, einschließlich Bash-Shell-Skripten, bedeutet ein führendes # einen Kommentar, und wir haben es in einigen unserer Code-Beispiele auch so verwendet. Als nachgestelltes Symbol in einer Bash-Eingabeaufforderung (anstelle von $) bedeutet # jedoch, dass du als Root eingeloggt bist. Wir haben nur ein Beispiel, in dem etwas als root ausgeführt wird, also sollte das nicht verwirrend sein, aber es ist wichtig zu verstehen.

Wenn du ein Beispiel ohne die Eingabeaufforderung siehst, zeigen wir den Inhalt eines Shell-Skripts. Bei einigen großen Beispielen werden wir die Zeilen des Skripts nummerieren, obwohl die Nummern nicht Teil des Skripts sind.

Gelegentlich zeigen wir auch ein Beispiel in Form eines Sitzungsprotokolls oder einer Reihe von Befehlen. In manchen Fällen zeigen wir eine oder mehrere Dateien auf cat, damit du das Skript und/oder die Datendateien sehen kannst, die wir im Beispiel oder in den Ergebnissen unserer Operation verwenden, wie hier:

$ cat data_file
static header line1
static header line2
1 foo
2 bar
3 baz

Viele der längeren Skripte und Funktionen stehen auch zum Download bereit. Weitere Informationen findest du unter "Codebeispiele verwenden". Wir haben uns entschieden, !/usr/bin/env bash für diese Beispiele zu verwenden, da es portabler ist als das !/bin/bash, das du unter Linux oder auf einem Mac findest. Siehe Rezept 15.1 für weitere Details.

Außerdem wirst du in vielen Codebeispielen etwas wie das Folgende finden:

# cookbook filename: snippet_name

Das bedeutet, dass der Code, den du gerade liest, in unserem GitHub-Repository zum Download bereitsteht. Du findest den Code in einem Verzeichnis wie ./chXX/snippet_name, wobei chXX für das Kapitel und snippet_name für den Namen der Datei steht.

Unnötige Verwendung der Katze

Manche Unix-Benutzer haben ein geradezu schwindelerregendes Vergnügen daran, auf Unzulänglichkeiten im Code anderer Leute hinzuweisen. Meistens handelt es sich dabei um konstruktive Kritik, die freundlich geäußert und dankbar angenommen wird.

Der wahrscheinlich häufigste Fall ist der so genannte "useless use of cat award", der vergeben wird, wenn jemand etwas wie cat file | grep foo statt einfach grep foo file macht. In diesem Fall ist cat unnötig und verursacht einen gewissen System-Overhead, da es in einem Unterprozess läuft. Ein anderer häufiger Fall wäre cat file | tr '[A-Z]' '[a-z]' statt tr '[A-Z]' '[a-z]' < file. Manchmal kann die Verwendung von cat sogar dazu führen, dass dein Skript fehlschlägt (siehe Rezept 19.8).

Aber... (du wusstest, dass das kommt, nicht wahr?) manchmal hat die unnötige Verwendung von cat tatsächlich einen Zweck. Es könnte ein Platzhalter sein, um ein Fragment einer Pipeline zu demonstrieren, das später durch andere Befehle ersetzt wird (vielleicht sogar durch cat -n). Oder es könnte sein, dass die Datei in der Nähe der linken Seite des Codes platziert wird, um die Aufmerksamkeit auf sie zu lenken, als wenn sie hinter einem < ganz rechts auf der Seite versteckt wäre.

Auch wenn wir Effizienz begrüßen und zustimmen, dass sie ein erstrebenswertes Ziel ist, ist sie nicht mehr so wichtig wie früher. Wir plädieren nicht für Nachlässigkeit und aufgeblähten Code, wir sagen nur, dass die Prozessoren in nächster Zeit nicht langsamer werden. Wenn du also Cat magst, benutze sie.

Ein Hinweis zu Perl

Wir haben uns bewusst dafür entschieden, Perl in unseren Lösungen so weit wie möglich zu vermeiden, obwohl es immer noch ein paar Fälle gibt, in denen es Sinn macht. Perl wird bereits an anderer Stelle in viel größerer Tiefe und Breite behandelt, als wir es hier je könnten. Außerdem sind Perl-Lösungen in der Regel viel größer und haben einen deutlich höheren Overhead als unsere. Außerdem gibt es einen feinen Unterschied zwischen Shell-Skripten und Perl-Skripten, und dies ist ein Buch über Shell-Skripte.

Shell-Skripte sind im Grunde nur ein Klebstoff, mit dem Unix-Programme zusammengeklebt werden, während Perl einen Großteil der Funktionalität der externen Unix-Programme in die Sprache selbst integriert. Das macht die Sprache effizienter und in gewisser Weise auch portabler, allerdings auf Kosten der Andersartigkeit und der Schwierigkeit, externe Programme, die du noch brauchst, effizient auszuführen.

Die Wahl des richtigen Werkzeugs hat oft mehr mit Vertrautheit zu tun als mit anderen Gründen. Im Endeffekt geht es immer darum, die Arbeit zu erledigen; die Wahl der Werkzeuge ist zweitrangig. Wir zeigen dir viele Möglichkeiten, Dinge mit der Bash und verwandten Tools zu erledigen. Wenn du deine Arbeit erledigen musst, kannst du selbst entscheiden, welche Werkzeuge du benutzt.

Mehr Ressourcen

In diesem Buch verwendete Konventionen

In diesem Buch werden die folgenden typografischen Konventionen verwendet:

Klartext

Zeigt Menütitel, Menüoptionen, Menütasten und Tastaturkürzel (wie Alt und Strg) an.

Kursiv

Zeigt neue Begriffe, URLs, E-Mail-Adressen, Dateinamen, Dateierweiterungen, Pfadnamen, Verzeichnisse und Unix-Dienstprogramme an.

Constant width

Bezeichnet Befehle, Optionen, Schalter, Variablen, Attribute, Schlüssel, Funktionen, Typen, Klassen, Namensräume, Methoden, Module, Eigenschaften, Parameter, Werte, Objekte, Ereignisse, Ereignishandler, XML-Tags, HTML-Tags, Makros, den Inhalt von Dateien und die Ausgabe von Befehlen.

Constant width bold

Zeigt Befehle oder anderen Text an, der vom Benutzer wortwörtlich eingetippt werden sollte.

Constant width italic

Zeigt Text an, der durch vom Benutzer eingegebene Werte ersetzt werden soll.

Hinweis

Dieses Symbol steht für einen allgemeinen Hinweis.

Tipp

Dieses Symbol steht für einen Tipp oder eine Anregung.

Warnung

Dieses Symbol weist auf eine Warnung oder Vorsicht hin.

Code-Beispiele verwenden

Zusätzliches Material (Code-Beispiele, Übungen usw.) steht unter https://github.com/vossenjp/bashcookbook-examples zum Download bereit .

Dieses Buch soll dir helfen, deine Arbeit zu erledigen. Wenn in diesem Buch Beispielcode angeboten wird, darfst du ihn in deinen Programmen und deiner Dokumentation verwenden. Du musst uns nicht um Erlaubnis fragen, es sei denn, du reproduzierst einen großen Teil des Codes. Wenn du zum Beispiel ein Programm schreibst, das mehrere Teile des Codes aus diesem Buch verwendet, brauchst du keine Erlaubnis. Wenn du eine CD-ROM mit Beispielen aus den O'Reilly-Büchern verkaufst oder verteilst, ist eine Genehmigung erforderlich. Die Beantwortung einer Frage mit einem Zitat aus diesem Buch und einem Beispielcode erfordert keine Genehmigung. Wenn du einen großen Teil des Beispielcodes aus diesem Buch in die Dokumentation deines Produkts aufnimmst, ist eine Erlaubnis erforderlich.

Wir freuen uns über eine Namensnennung, verlangen sie aber nicht. Eine Quellenangabe umfasst normalerweise den Titel, den Autor, den Verlag und die ISBN. Zum Beispiel: "bash Cookbook, 2nd Edition, von Carl Albing und JP Vossen. Copyright 2018 Carl Albing und JP Vossen, 978-1-491-97533-6."

Wenn du der Meinung bist, dass die Verwendung von Code-Beispielen nicht unter die Fair-Use-Regelung oder die oben genannte Erlaubnis fällt, kannst du uns gerne unter kontaktieren

O'Reilly Safari

Hinweis

Safari (ehemals Safari Books Online) ist eine mitgliedschaftsbasierte Schulungs- und Nachschlageplattform für Unternehmen, Behörden, Lehrkräfte und Einzelpersonen.

Mitglieder haben Zugang zu Tausenden von Büchern, Schulungsvideos, Lernpfaden, interaktiven Tutorials und kuratierten Playlists von über 250 Verlagen, darunter O'Reilly Media, Harvard Business Review, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Adobe, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett und Course Technology, um nur einige zu nennen.

Weitere Informationen erhältst du unter http://oreilly.com/safari.

Wir würden gerne von dir hören

Bitte richte Kommentare und Fragen zu diesem Buch an den Verlag:

  • O'Reilly Media, Inc.
  • 1005 Gravenstein Highway Nord
  • Sebastopol, CA 95472
  • 800-998-9938 (in den Vereinigten Staaten oder Kanada)
  • 707-829-0515 (international oder lokal)
  • 707-829-0104 (Fax)

Wir haben eine Webseite für dieses Buch, auf der wir Errata, Beispiele und zusätzliche Informationen auflisten. Du kannst diese Seite unter http://bit.ly/bash_cookbook_2E aufrufen .

Informationen zu diesem Buch, Codebeispiele, Errata, Links, Bash-Dokumentation und mehr findest du auf der Website der Autoren, http://www.bashcookbook.com.

Schau doch mal vorbei, um zu lernen, etwas beizutragen oder zu plaudern. Die Autoren würden sich freuen, von dir zu hören, was dir an dem Buch gefällt und was nicht, welche Bash-Wunder du gefunden hast oder was du gelernt hast. Wenn du Kommentare oder technische Fragen zu diesem Buch stellen möchtest, sende eine E-Mail an bookquestions@oreilly.com.

Weitere Informationen zu unseren Büchern, Kursen, Konferenzen und Neuigkeiten findest du auf unserer Website unter http://www.oreilly.com.

Finde uns auf Facebook: http://facebook.com/oreilly

Folge uns auf Twitter: http://twitter.com/oreillymedia

Schau uns auf YouTube: http://www.youtube.com/oreillymedia

Danksagungen

Vielen Dank an die GNU Software Foundation und Brian Fox für die Entwicklung der Bash. Und vielen Dank an Chet Ramey, der die Bash seit etwa Version 1.14 Anfang bis Mitte der 1990er Jahre pflegt und verbessert hat. Noch mehr Dank an Chet für die Beantwortung unserer Fragen und für die Durchsicht eines Entwurfs dieses Buches.

Ein besonderer Dank geht auch an Cameron Newham, der einige Materialien für die erste Ausgabe zur Verfügung gestellt hat, von denen einige auch in dieser Ausgabe enthalten sind. Wir empfehlen sein O'Reilly-Buch Learning the bash Shell, geschrieben von Cameron Newham und Bill Rosenblatt, sehr.

Rezensenten

Vielen Dank an unsere Rezensenten! Sie alle haben uns wertvolles Feedback, Vorschläge und in einigen Fällen auch alternative Lösungen geliefert, uns auf Probleme hingewiesen, die wir übersehen hatten, und das Buch im Allgemeinen stark verbessert. Alle Fehler oder Auslassungen in diesem Text stammen von uns und nicht von ihnen. Ein hervorragendes Beispiel für ihre Weisheit ist die richtige Feststellung: "Dieser Satz weiß nicht, ob er kommt oder geht!"

Erste Ausgabe: Yves Eynard, Chet Ramey, William Shotts, Ryan Waldron und Michael Wang.

Zweite Auflage: Chet Ramey, Robert Day und Arnold Robbins.

O'Reilly

Vielen Dank an das gesamte Team von O'Reilly, ohne das es dieses Buch aus vielen Gründen nicht gäbe, und wenn doch, wäre der Inhalt nicht annähernd so gut oder würde nicht so gut aussehen!

Erste Ausgabe: unser Redakteur Mike Loukides, Derek Di Matteo und Laurel Ruma.

Zweite Ausgabe: unser Redakteur Jeff Bleiel, Rachel Head, Kristen Brown, James Fraleigh, Ellen Troutman-Zaig und Rebecca Demarest in der Produktion sowie Matthew Hacker und andere Tools-Mitarbeiter. Aus verschiedenen Gründen war für die zweite Ausgabe eine Menge akribischer Arbeit nötig: Vielen Dank dafür. Wir sind sehr beeindruckt von eurem Engagement für dieses Projekt und eurer Liebe zum Detail.

Von den Autoren

Carl

Das Schreiben eines Buches ist nie eine einsame Leistung, auch wenn es seine Momente hat. Ich danke JP dafür, dass er über viele Jahre hinweg mit mir an diesem Projekt gearbeitet hat, und zwar in beiden Ausgaben. Unsere sich ergänzenden Talente und Zeitplannungsprogramme haben dieses Buch zu einem besseren Werk gemacht, als ich es allein hätte schaffen können. Danke auch an JP für seine großartigen Bemühungen als Systemadministrator, uns die Infrastruktur zur Verfügung zu stellen. Danke an Mike, dass er sich unsere Vorschläge für ein Bash-Kochbuch angehört hat, dass er uns angetrieben hat, wenn wir nicht weiter wussten, und dass er uns gebremst hat, wenn wir durchgedreht sind. Wir wissen seine ständige Anleitung und seinen technischen Input sehr zu schätzen. Meine Frau Cynthia und meine (inzwischen erwachsenen!) Kinder haben mich während dieses Prozesses geduldig unterstützt, mich ermutigt und motiviert und mir Zeit und Raum zum Arbeiten gegeben. Ich danke ihnen von ganzem Herzen.

Aber noch wichtiger als die unmittelbare Aufgabe dieses Buches waren der Hintergrund und die Vorbereitung. Ich stehe tief in der Schuld von Dr. Ralph Bjork, der es mir ermöglicht hat, mit Unix zu arbeiten, als noch kaum jemand davon gehört hatte. Seine Vision, sein Weitblick und seine Anleitung haben sich für mich länger ausgezahlt, als ich je erwartet hätte.

Die Arbeit an diesem Buch ist meinen Eltern, Hank und Betty, gewidmet, die mir alles Gute gegeben haben, was sie zu bieten hatten - das Leben selbst, den christlichen Glauben, die Liebe, eine hervorragende Ausbildung, ein Gefühl der Zugehörigkeit und all die guten und gesunden Dinge, die man hoffentlich an seine eigenen Kinder weitergeben kann. Ich kann ihnen nie genug danken.

JP

Danke an Cameron für das Buch Learning the bash Shell, aus dem ich viel gelernt habe und das meine wichtigste Referenz war, bis ich dieses Projekt begonnen habe, und dafür, dass er so viel nützliches Material beigesteuert hat. Danke an Carl für all seine Arbeit: Ohne ihn hätte dieses Projekt viermal so lange gedauert und wäre nur halb so gut geworden. Danke an Mike dafür, dass er den Ball ins Rollen gebracht und am Laufen gehalten hat, und dafür, dass er Carl mit ins Boot geholt hat. Und danke an Carl und Mike für ihre Geduld mit meinem Leben und meinem Zeitmanagement.

Dieses Buch ist meinem Vater gewidmet, der sich darüber freuen würde. Er hat mir immer gesagt, dass nur zwei Entscheidungen wichtig sind: was du machst und wen du heiratest. Ich habe es geschafft, zwei von zwei Entscheidungen zu treffen, also schätze ich, dass ich ziemlich gut abschneide. Dieser Artikel ist auch Karen gewidmet, die mich während dieses langen Prozesses unglaublich unterstützt hat und ohne die selbst Computer nicht so viel Spaß machen würden. Und schließlich möchte ich mich bei Kate und Sam bedanken, die einen großen Beitrag zu meinen oben erwähnten Lebensmanagementproblemen geleistet haben.

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