Die wichtigsten Unix-Befehle - Versionsgeschichte

Bmay: some gendering

2013-05-25T17:29:08Z

some gendering

Xamiax: Änderung 15367 von 91.201.66.204 (Diskussion) wurde rückgängig gemacht.

2010-11-13T14:33:28Z

Änderung 15367 von 91.201.66.204 (Diskussion) wurde rückgängig gemacht.

Änderungen zeigen

91.201.66.204: Health

2010-11-13T13:57:32Z

Health

Änderungen zeigen

217.10.60.85: /* `tar` */

2008-03-13T09:38:01Z

‎<code>tar</code>

87.164.250.168: /* Befehle */

2007-10-17T17:31:10Z

‎Befehle

87.164.250.168: /* Befehle */

2007-10-17T17:22:11Z

‎Befehle

87.164.250.168: /* Prinzipien */

2007-10-17T16:52:58Z

‎Prinzipien

Dirk: /* Ausblick, links */ Rechtschreibung

2007-02-28T15:43:18Z

‎Ausblick, links: Rechtschreibung

Dirk: /* Weblinks */ "Beginning Perl" hinzugefügt

2007-02-28T14:21:15Z

‎Weblinks: "Beginning Perl" hinzugefügt

Felix: Auch wenn Perl schauderhaft ist, sollte es als klassiche Sysadmin-Sprache nicht fehlen.

2007-02-25T13:02:49Z

Auch wenn Perl schauderhaft ist, sollte es als klassiche Sysadmin-Sprache nicht fehlen.

@@ Zeile 2: / Zeile 2: @@
 === Was ist das überhaupt ===
-Prinzipiell kann man mit einem Betriebsystem auf verschiedenen Ebenen arbeiten (um z. B. Dateien zu erzeugen, zu bearbeiten, zu verschieben oder zu löschen):
+Prinzipiell kann man mit einem Betriebsystem auf verschiedenen Ebenen arbeiten, um z. B. Dateien zu erzeugen, zu bearbeiten, zu verschieben oder zu löschen:
-* als Benutzer einer graphischen Oberfläche (GUI) indem man Programme wie den OS X Finder, Windows Explorer oder Gnome Nautilus verwendet,
+* als Benutzer/in einer graphischen Oberfläche (GUI) indem man Programme wie den OS X Finder, Windows Explorer oder Gnome Nautilus verwendet,
-* als Programmierer, indem man Funktionen des Betriebsystems aufruft,
+* als Programmierer/in, indem man Funktionen des Betriebsystems aufruft,
-* als Shell-Benutzer, der (scheinbar) kryptische Befehle in eine Text-Eingabe schreibt.
+* als Shell-Benutzer/in, der (scheinbar) kryptische Befehle in eine Text-Eingabe schreibt.
 Und genau um diesen letzten Weg soll es hier gehen.
-Im Prinzip gibt es genau fünf Gründe, wieso man eine Shell verwenden möchte:
+Im Prinzip gibt es mindestens fünf gute Gründe, wieso man eine Shell verwenden möchte:
-* Es ist in der Regel schneller, etwas in einer Shell zu machen, als das äquivalente Ergebnis mit einer GUI zu erzielen.
+* Es ist in der Regel schneller, etwas in einer Shell zu machen, als das äquivalente Ergebnis mit einem GUI zu erzielen.
 * Shellscripte lassen sich schneller schreiben als (C-)Programme.
-* Eine Shell ist in der Regel kleiner als eine GUI und beansprucht weniger Ressourcen.
+* Eine Shell ist in der Regel kleiner (was den Verbrauch an Rechenressourcen angeht), als ein GUI.
-* Wenn man sich über [[SSH]] auf einem anderen Rechner einloggt, bekommt man eine Shell. (Eine GUI zu bekommen ist nichttrivial.)
+* Wenn man sich über [[SSH]] auf einem anderen Rechner einloggt, bekommt man eine Shell (Ein GUI zu bekommen ist nicht trivial).
-* In einer Shell werden Befehle für extrem einfache und extrem komplexe Vorgänge nach dem gleichen Prinzip aufgebaut. (Bei einer GUI muss man dazu oft jeweils verschiedene Werkzeuge benutzen, oder sogar Zusatzsoftware installieren.)
+* In einer Shell werden Befehle für extrem einfache und extrem komplexe Vorgänge nach dem gleichen Prinzip aufgebaut (Bei einem GUI muss man dazu oft jeweils verschiedene Werkzeuge benutzen, oder sogar Zusatzsoftware installieren).
 * Wenn man sich damit auskennt, kann man alle paar Wochen mal jemanden, der sich nicht damit auskennt, extrem verblüffen.
@@ Zeile 19: / Zeile 19: @@
 Es gibt viele Shells. Alle haben kryptische Namen und die meisten enden auf -sh. Bekannte Beispiele sind:
 * <code>sh</code> ist die erste moderne Shell, genannt Bourne-Shell. Eine <code>sh</code>-kompatible Shell ist auf fast jedem Unix-System vorhanden.
-* <code>bash</code> ist die Bourne Again SHell, ein Nachfolger von <code>sh</code>, und die Standardshell in den meisten [[Linux]]-Distributionen und auch im Fakultätsnetz.
+* <code>bash</code> ist die Bourne Again Shell, ein Nachfolger von <code>sh</code> und die Standardshell in den meisten [[Linux]]-Distributionen, auch im Fakultätsnetz.
 * <code>csh</code> ist die C Shell.
-* <code>tcsh</code> ist eine Weiterentwicklung von <code>csh</code>, die manche Leute mehr mögen als <code>bash</code>.
+* <code>tcsh</code> ist eine Weiterentwicklung der <code>csh</code>, die manche Leute mehr mögen als <code>bash</code>.
 Im Rest dieses Artikels geht es um die <code>bash</code>; wer eine andere Shell benutzt, kann die Unterschiede anhand der [[Manpage|Manpages]] nachlesen.
@@ Zeile 34: / Zeile 34: @@
 Verzeichniswechsel:
-  cd      # ins Homeverzeichnis gehen
+  cd      # in das eigene Heimatverzeichnis gehen
   cd foo  # in das Verzeichnis foo gehen
   cd ..   # ein Verzeichnis aufwärts gehen
   cd .    # in das aktuelle Verzeichnis gehen (sinnlos, aber möglich)
-(<code>#</code> ist das Kommentarzeichen der <code>bash</code>. <code>#</code> und alles, was rechts davon steht, wird ignoriert.)
+(<code>#</code> ist das Kommentarzeichen der <code>bash</code>. <code>#</code> und alles, was rechts davon steht, wird bei der Interpretation ignoriert.)
 Dieser Schnipsel ersetzt mit Hilfe des Texteditors [http://de.wikipedia.org/wiki/Vi vi] in allen html-Dateien im aktuellen Verzeichnis eine veraltete Emailadresse:
-  for i in *.html; do \
+  for htmlfile in *.html; do \
-          vi -c ':1,$s/alt@meinedomain.de/webmaster@meinedomain.de/g' -c ':wq' "$i"; done
+          vi -c ':1,$s/alt@meinedomain.de/webmaster@meinedomain.de/g' -c ':wq' "$htmlfile"; done
-So sieht es aus, wenn man auf Lesbarkeit Wert legt:
+Alternativ kann man schreiben:
   for i in *.html
   do
-          vi -c ':1,$s/alt@meinedomain.de/webmaster@meinedomain.de/g' -c ':wq' "$i"
+          vi -c ':1,$s/alt@meinedomain.de/webmaster@meinedomain.de/g' -c ':wq' "$htmlfile"
   done
-Alternativer Weg (wobei auch die Unterverzeichnisse rekursiv bearbeitet werden):
+Noch eine Alternative (wobei auch die Unterverzeichnisse rekursiv bearbeitet werden):
   find . -name '*.html' -type f -exec \
           vi -c ':1,$s/alt@meinedomain.de/webmaster@meinedomain.de/g' -c ':wq' '{}' ';'
@@ Zeile 61: / Zeile 61: @@
+  #
   # Der Rest der Datei besteht aus bash-Befehlen und ist in diesem
-  # Fall sinnfrei (und harmlos).
+  # Fall sinnfrei (und i.d.R. harmlos).
   FOO="foo    bar"        # eine Variable (Name links, Inhalt rechts)
                           # um das Gleichheitszeichen herum dürfen
@@ Zeile 102: / Zeile 102: @@
 Wenn man einen Befehl mit einem <code>&</code> (kaufmännisches Und) abschließt (also <code>befehl &</code>, das Leerzeichen ist wichtig), so wird er im Hintergrund ausgeführt und man kann in der Shell solange etwas anderes tun. Hat man das <code>&</code> vergessen, kann man einen laufenden Befehl durch den Tastenkürzel <Ctrl>-Z anhalten und mit dem Kommando <code>bg</code> im Hintergrund fortsetzen.
-Führt man ein Kommando im Vordergrund in der Shell aus und schließt sie, wird das laufende Programm in der Regel (aber nicht unbedingt) mit der Shell beendet. Besser ist es, erst das Programm und dann die Shell zu beenden.
+Führt man ein Kommando im Vordergrund in der Shell aus und schließt sie, wird das laufende Programm in der Regel (aber nicht unbedingt) mit der Shell beendet. Besser ist es, erst das Programm und dann die Shell zu beenden. Alternativ benutzt man den befehl <code>nohup</code> um das Programm gänzlich von der Shell abzukoppeln.
-Jeder Befehl hat seine eigene Menge von möglichen und/oder erforderlichen Argumenten, die bei jedem Befehl anders sind. Allerdings ist die Schreibweise der Argumente bei vielen Befehlen (es gibt Ausnahmen) ähnlich:
+Jeder Befehl hat seine eigene Menge von möglichen und/oder erforderlichen Optionen, die bei jedem Befehl anders sind. Allerdings ist die Schreibweise der Argumente bei vielen Befehlen (es gibt Ausnahmen) ähnlich:
 * Kurzform: <code>-a -d -f -r</code>, aus jeweils einem Buchstaben bestehende Argumente mit einem Bindestrich vor jedem Argument
 * abgekürzte Kurzform: <code>-adfr</code>. Diese Form wird nicht von allen Befehlen unterstützt und kann manchmal eine sehr unerwartete Wirkung haben.
 * Langform: <code>--all --directory --force --recursive</code> etc. Hier werden aus Worten (oder zumindest längeren Zeichenketten) geschriebe Worte von zwei Bindestrichen (manchmal aber nur einem) angeführt. Zusammenfassen kann man diese Argumente nicht. Diese Form ist bei vielen GNU-Programmen möglich.
-* Parametrisierte Argumente: Manchmal gibt es Argumente, die aus einem Schalter und einem Wert bestehen, z. B. <code>--directory /home/pub/lib</code>, <code>-d /home/pub/lib</code>, <code>--force YES</code>, <code>-f YES</code>, <code>--number 23</code>.
+* Parametrisierte Optionen (im englischen 'flags'): Manchmal gibt es Argumente, die aus einem Schalter und einem Wert bestehen, z. B. <code>--directory /home/pub/lib</code>, <code>-d /home/pub/lib</code>, <code>--force YES</code>, <code>-f YES</code>, <code>--number=23</code>.
 Zu all diesen Regelmäßigkeiten gibt es Ausnahmen. Es ist also immer ratsam, [[Manpage|Manpages]] zu konsultieren.
@@ Zeile 115: / Zeile 115: @@
   conde mhaecker 11 (~):
 # Vorne steht immer der Name des Rechners, auf dem man gerade eingelogt ist. In der Uni kann das zum Beispiel <code>conde</code> (schnell), <code>fiesta</code> (lahm) oder einer von vielen anderen sein. (Welcher Rechner schnell ist, hängt natürlich davon ab, wie viele hundert Studierende dort gerade versuchen, die ziemlich ressourcenlastige grafische Benutzeroberfläche KDE zu benutzen.)
-# Danach kommt der Benutzername desjenigen, dem die Shell gehört, das heißt, in wessen Namen die eingegebenen Kommandos ausgeführt werden (<code>mhaecker</code> ist der Benutzername von [[Benutzer:Martin Häcker|Martin Häcker]]).
+# Danach kommt der Benutzername derjenigen, der die Shell gehört, das heißt, in wessen Namen die eingegebenen Kommandos ausgeführt werden (<code>mhaecker</code> ist der Benutzername von [[Benutzer:Martin Häcker|Martin Häcker]]).
 # Die Zahl danach gibt an, wie viele Kommandos schon in dieser Shell eingegeben wurden. (Das ist meistens nicht nützlich.)
 # Danach steht in Klammern das aktuelle Verzeichnis (<code>~</code> ist eine Abkürzung für das eigene Heimatverzeichnis).
@@ Zeile 138: / Zeile 138: @@
 == Wichtige Befehle ==
-Der Leser wird dazu aufgerufen, interessante Befehle gleich auszuprobieren. Das macht es einfacher, sich später daran zu erinnern. Außerdem sollte man die [[Manpage|Manpages]] zu den einzelnen Befehlen lesen, bevor man sie ernsthaft einsetzt.
+Die Lesenden werden dazu aufgerufen, interessante Befehle gleich auszuprobieren. Das macht es einfacher, sich später daran zu erinnern. Außerdem sollte man die [[Manpage|Manpages]] zu den einzelnen Befehlen lesen, bevor man sie ernsthaft einsetzt.
 Da laut Unix-Philosophie der Benutzer immer am besten weiß, was zu tun ist, fragen die hier vorgestellten Programme im Allgemeinen nicht nach, ob zum Beispiel Dateien "wirklich" gelöscht werden sollen, sondern tun es einfach. (Allerdings ist das im Fakultätsnetz teilweise anders konfiguriert.)

@@ Zeile 237: / Zeile 237: @@
 * <code>t</code> zeigt die Dateien in einem Archiv an.
 * <code>x</code> steht für ''extract'' und tut genau das.
-* <code>z</code> steht für ''zip''. Fügt man diesen Parameter hinzu, dann arbeitet <code>tar</code> mit gzip-komprimierten Archiven. Amsonsten bleibt die Benutzung gleich; statt <code>datei.tar</code> schreibt man dann sinnvollerweise immer <code>datei.tar.gz</code>.
+* <code>z</code> steht für ''zip''. Fügt man diesen Parameter hinzu, dann arbeitet <code>tar</code> mit gzip-komprimierten Archiven. Ansonsten bleibt die Benutzung gleich; statt <code>datei.tar</code> schreibt man dann sinnvollerweise immer <code>datei.tar.gz</code>.
 Von den Optionen <code>c</code>, <code>t</code> und <code>x</code> sollte genau eine angegeben werden.

@@ Zeile 92: / Zeile 92: @@
 * als logischer Ausdruck:
   test -e foo.bar && echo "Datei existiert." || echo "Datei existiert nicht."
-Pipe(line)s bewirken, dass die Ausgabe des ersten Befehls die Eingabe des zweiten Befehls wird; dessen Ausgabe geht zum dritten Befehl und so weiter. Da viele Unix-Programme Text produzieren, umwandeln oder lesen, ist das ein mächtiges Werkzeug, um mit einfachen Mitteln komplizierte Dinge zu machen, die in einer GUI bestenfalls dann möglich sind, wenn die Entwickler sie genau in der Form eingeplant haben. Zum Beispiel erzeugt
+'''Pipe'''(line)'''s'''  |  bewirken, dass die Ausgabe des ersten Befehls die Eingabe des zweiten Befehls wird; dessen Ausgabe geht zum dritten Befehl und so weiter. Da viele Unix-Programme Text produzieren, umwandeln oder lesen, ist das ein mächtiges Werkzeug, um mit einfachen Mitteln komplizierte Dinge zu machen, die in einer GUI bestenfalls dann möglich sind, wenn die Entwickler sie genau in der Form eingeplant haben.
   cat foo.txt | sort | uniq > bar.txt
 die Datei <code>bar.txt</code>, die die sortierten Zeilen aus <code>foo.txt</code> ohne doppelte Zeilen enthält. Das Zeichen <code>></code> lenkt dabei die Ausgabe in die Datei <code>bar.txt</code> um. Eleganter lässt sich das ganze als

@@ Zeile 88: / Zeile 88: @@
 * als durch geschweifte Klammern begrenzter Befehlsblock:
   { echo foo ; echo bar ; echo qux }
-* als Pipeline, wobei die Befehle durch einen senkrechten Strich getrennt werden:
+* als Pipeline, wobei die Befehle durch einen senkrechten Strich '''|''' getrennt werden:
   echo 'Umweltverschmutzung' | tr mu nü | cat -
 * als logischer Ausdruck:

@@ Zeile 71: / Zeile 71: @@
   echo -n "'$FOO' = "
   echo '$FOO'
-Wenn man diesen Text in einer Textdatei, z. B. <code>foo.sh</code>, speichert und diese ausführbar macht, z. B. mit
+Wenn man diesen Text in einer Textdatei, z. B. <code>'''foo.sh'''</code>, speichert und diese ausführbar macht, z. B. mit
-  chmod 700 foo.sh
+  chmod 700 '''foo.sh'''
 dann kann man sie wie ein normales Unix-Programm ausführen.

@@ Zeile 289: / Zeile 289: @@
 Bevor man die Programme aus <code>/home/pub</code> benutzt oder dort etwas installiert, sollte man [http://irb.cs.tu-berlin.de/usr/INFO/InstallierenFuerAlle die Hinweise des IRB] lesen (die allerdings nicht mehr 100%-ig zutreffen).
-== Ausblick, links ==
+== Ausblick, Links ==
-Es lohnt sich, zumindest rudimentär über die Shell Bescheid zu wissen, gerade weil man an der Uni nicht daran vorbeikommt.
+Es lohnt sich, zumindest rudimentär über die Shell Bescheid zu wissen, gerade weil man an der Uni nicht daran vorbei kommt.
 Weiter Informationen findet Ihr in der [http://irb.cs.tu-berlin.de/leitfaden/manuale/escript/escript.html Anleitung des Fachbereichs] und überall sonst im Internet.

@@ Zeile 299: / Zeile 299: @@
 * [ftp://ftp.cwru.edu/pub/bash/FAQ Bash FAQ]
 * [http://www.tldp.org/LDP/abs/html/ Advanced Bash Scripting Guide] und dessen [http://www.tldp.org/LDP/abs/html/ Bibliografie]
 [[Kategorie: Überleben im Fakultätsnetz]]

@@ Zeile 293: / Zeile 293: @@
 Weiter Informationen findet Ihr in der [http://irb.cs.tu-berlin.de/leitfaden/manuale/escript/escript.html Anleitung des Fachbereichs] und überall sonst im Internet.
-Es lohnt sich auch zumindest eine Shell-Script-Sprache zu beherschen. Ich bin allerdings der Meinung das man sich für diesen Zweck ruhig eine richtige Programmiersprache so wie [http://www.python.org/ Python] oder [http://www.ruby.org/ Ruby] ins mentale Boot holen sollte.
+Es lohnt sich auch zumindest eine Shell-Script-Sprache zu beherschen. Ich bin allerdings der Meinung das man sich für diesen Zweck ruhig eine richtige Programmiersprache so wie [http://www.python.org/ Python], [http://www.perl.org/ Perl] oder [http://www.ruby.org/ Ruby] ins mentale Boot holen sollte.
 == Weblinks ==

Die wichtigsten Unix-Befehle - Versionsgeschichte

Bmay: some gendering

Xamiax: Änderung 15367 von 91.201.66.204 (Diskussion) wurde rückgängig gemacht.

91.201.66.204: Health

217.10.60.85: /* tar */

87.164.250.168: /* Befehle */

87.164.250.168: /* Befehle */

87.164.250.168: /* Prinzipien */

Dirk: /* Ausblick, links */ Rechtschreibung

Dirk: /* Weblinks */ "Beginning Perl" hinzugefügt

Felix: Auch wenn Perl schauderhaft ist, sollte es als klassiche Sysadmin-Sprache nicht fehlen.

217.10.60.85: /* `tar` */