Sitzung: Jeden Freitag in der Vorlesungszeit ab 16 Uhr c. t. im MAR 0.005. In der vorlesungsfreien Zeit unregelmäßig (Jemensch da?). Macht mit!

Die wichtigsten Unix-Befehle: Unterschied zwischen den Versionen

(sortiert ...)
K (some gendering)
 
(21 dazwischenliegende Versionen von 12 Benutzern werden nicht angezeigt)
Zeile 2: Zeile 2:
  
 
=== Was ist das überhaupt ===
 
=== 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.
 
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.
 
* 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.
 
* 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:
 
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>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>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.
 
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 31: Zeile 31:
 
... und mit versteckten Dateien (das sind Dateien, deren Name mit einem Punkt beginnt):
 
... und mit versteckten Dateien (das sind Dateien, deren Name mit einem Punkt beginnt):
 
  ls -la
 
  ls -la
 +
Tipp: Kann man sich gut als "'''l'''i'''s'''t '''-l'''ong, '''a'''ll" merken.
  
 
Verzeichniswechsel:
 
Verzeichniswechsel:
  cd      # ins Homeverzeichnis gehen
+
  cd      # in das eigene Heimatverzeichnis gehen
 
  cd foo  # in das Verzeichnis foo gehen
 
  cd foo  # in das Verzeichnis foo gehen
 
  cd ..  # ein Verzeichnis aufwärts gehen
 
  cd ..  # ein Verzeichnis aufwärts gehen
 
  cd .    # in das aktuelle Verzeichnis gehen (sinnlos, aber möglich)
 
  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:
 
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
 
  for i in *.html
 
  do
 
  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
 
  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 \
 
  find . -name '*.html' -type f -exec \
 
         vi -c ':1,$s/alt@meinedomain.de/webmaster@meinedomain.de/g' -c ':wq' '{}' ';'
 
         vi -c ':1,$s/alt@meinedomain.de/webmaster@meinedomain.de/g' -c ':wq' '{}' ';'
Zeile 60: Zeile 61:
 
  #
 
  #
 
  # Der Rest der Datei besteht aus bash-Befehlen und ist in diesem
 
  # 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)
 
  FOO="foo    bar"        # eine Variable (Name links, Inhalt rechts)
 
                         # um das Gleichheitszeichen herum dürfen
 
                         # um das Gleichheitszeichen herum dürfen
Zeile 70: Zeile 71:
 
  echo -n "'$FOO' = "
 
  echo -n "'$FOO' = "
 
  echo '$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.
 
dann kann man sie wie ein normales Unix-Programm ausführen.
  
Zeile 87: Zeile 88:
 
* als durch geschweifte Klammern begrenzter Befehlsblock:
 
* als durch geschweifte Klammern begrenzter Befehlsblock:
 
  { echo foo ; echo bar ; echo qux }
 
  { 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 -
 
  echo 'Umweltverschmutzung' | tr mu nü | cat -
 
* als logischer Ausdruck:
 
* als logischer Ausdruck:
 
  test -e foo.bar && echo "Datei existiert." || echo "Datei existiert nicht."
 
  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.  
 +
 
 +
Zum Beispiel erzeugt:
 
  cat foo.txt | sort | uniq > bar.txt
 
  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
 
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 97: Zeile 100:
 
schreiben. (<code><</code> lenkt logischerweise die Eingabe so um, dass sie aus der Datei <code>foo.txt</code> kommt.)
 
schreiben. (<code><</code> lenkt logischerweise die Eingabe so um, dass sie aus der Datei <code>foo.txt</code> kommt.)
  
Wenn man einen Befehl mit einem <code>&</code> (kaufmännisches Und) abschließt (also <code>befehl &</code>, das Lehrzeichen 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.
+
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
 
* 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.
 
* 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.
 
* 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.
 
Zu all diesen Regelmäßigkeiten gibt es Ausnahmen. Es ist also immer ratsam, [[Manpage|Manpages]] zu konsultieren.
  
Zeile 112: Zeile 115:
 
  conde mhaecker 11 (~):
 
  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.)
 
# 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.)
 
# 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).
 
# Danach steht in Klammern das aktuelle Verzeichnis (<code>~</code> ist eine Abkürzung für das eigene Heimatverzeichnis).
Zeile 135: Zeile 138:
  
 
== Wichtige Befehle ==
 
== 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.)
 
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 234: Zeile 237:
 
* <code>t</code> zeigt die Dateien in einem Archiv an.
 
* <code>t</code> zeigt die Dateien in einem Archiv an.
 
* <code>x</code> steht für ''extract'' und tut genau das.
 
* <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 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.
 
Von den Optionen <code>c</code>, <code>t</code> und <code>x</code> sollte genau eine angegeben werden.
  
Zeile 249: Zeile 252:
 
* <code><Ctrl>-x</code> um den Editor zu beenden
 
* <code><Ctrl>-x</code> um den Editor zu beenden
  
=== <code>emacs</code> ===
+
=== <code>[x]emacs</code> ===
Ein eigenes Betriebsystem (in Lisp geschrieben und programmierbar). Nebenbei noch ein brauchbarer Text-Editor.
+
[X]Emacs ist ein Texteditor, der ursprünglich im Zusammenhang des [http://en.wikipedia.org/wiki/GNU GNU]-Projektes (der Ursprung der [http://en.wikipedia.org/wiki/GPL GPL]) von [http://en.wikipedia.org/wiki/Richard_Stallman Richard Stallman] (Gründer der [http://en.wikipedia.org/wiki/Free_Software_Foundation Free Software Foundation]) entwickelt wurde.
  
 
Tastenkombinationen:
 
Tastenkombinationen:
 
* <code><Ctrl>-x-c</code> (x und c nacheinander, Controltaste dabei gedrückt halten) um Emacs zu beenden.
 
* <code><Ctrl>-x-c</code> (x und c nacheinander, Controltaste dabei gedrückt halten) um Emacs zu beenden.
 +
 +
Weitere Informationen gibt es [http://en.wikipedia.org/wiki/Emacs hier].
  
 
=== <code>vi</code> oder <code>vim</code> ===
 
=== <code>vi</code> oder <code>vim</code> ===
<code>vi</code> (''visual'') ist der Unix-Standardtexteditor und bei fast jedem Unix vorhanden, daher sollte man zumindest die wichtigsten Befehle beherrschen. <code>vim</code> (''Vi IMproved'') ist der beliebteste und mächtigste Vi-Clone und der Editor der Wahl für Leute, die keinen Lisp-Editor brauchen um ASCII-Dateien zu editieren.
+
<code>vi</code> (''visual'') ist der Unix-Standardtexteditor und bei fast jedem Unix vorhanden, daher sollte man zumindest die wichtigsten Befehle beherrschen. <code>vim</code> (''Vi IMproved'') ist der beliebteste und mächtigste Vi-Clone.
  
 
Tastenkombinationen:
 
Tastenkombinationen:
Zeile 266: Zeile 271:
 
=== <code>grp</code> ===
 
=== <code>grp</code> ===
 
Mit <code>grp</code> (''group administrativia'') könnt ihr euch in Unix-Gruppen eintragen. Das ist wichtig, wenn ihr in Gruppen Hausaufgaben erledigen wollt. Siehe auch http://irb.cs.tu-berlin.de/leitfaden/arbeiten-in-gruppen.html
 
Mit <code>grp</code> (''group administrativia'') könnt ihr euch in Unix-Gruppen eintragen. Das ist wichtig, wenn ihr in Gruppen Hausaufgaben erledigen wollt. Siehe auch http://irb.cs.tu-berlin.de/leitfaden/arbeiten-in-gruppen.html
 +
 +
Anmerkung: Dieses Kommando ist eine Spezialität des IRB-Netzes! Das funktioniert außerdem häufig nur, wenn man sich auf pepita einloggt. Die Änderungen werden dann zur vollen Stunde übernommen.
  
 
=== <code>utsettings</code> ===
 
=== <code>utsettings</code> ===
Zeile 271: Zeile 278:
  
  
== Verschiedene Shells ==
 
Im Prinzip gibt es genau fünf 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.
 
* Shellscripte lassen sich schneller schreiben als (C-)Programme.
 
* Eine Shell ist in der Regel kleiner als eine GUI und beansprucht weniger Ressourcen.
 
* Wenn man sich über [[SSH]] auf einem anderen Rechner einloggt, bekommt man eine Shell. (Eine GUI zu bekommen ist nichttrivial.)
 
* 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.)
 
* Wenn man sich damit auskennt, kann man alle paar Wochen mal jemanden, der sich nicht damit auskennt, extrem verblüffen.
 
 
 
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>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>.
 
Im Rest dieses Artikels geht es um die <code>bash</code>; wer eine andere Shell benutzt, kann die Unterschiede anhand der [[Manpage|Manpages]] nachlesen.
 
 
=== Beispiele ===
 
So lässt man sich die Dateien im aktuellen Verzeichnis anzeigen:
 
ls
 
Und so wird die Anzeige ausführlicher:
 
ls -l
 
... und mit versteckten Dateien (das sind Dateien, deren Name mit einem Punkt beginnt):
 
ls -la
 
 
Verzeichniswechsel:
 
cd      # ins Homeverzeichnis 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.)
 
 
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 \
 
        vi -c ':1,$s/alt@meinedomain.de/webmaster@meinedomain.de/g' -c ':wq' "$i"; done
 
So sieht es aus, wenn man auf Lesbarkeit Wert legt:
 
for i in *.html
 
do
 
        vi -c ':1,$s/alt@meinedomain.de/webmaster@meinedomain.de/g' -c ':wq' "$i"
 
done
 
Alternativer Weg (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' '{}' ';'
 
 
=== Prinzipien ===
 
Die Idee der Shell ist, dass man eine relativ einfache (und aus vielen Abkürzungen bestehende) Programmiersprache hat, die man in einem Interpreter (der Shell) direkt eingeben kann - also genau das richtige Spielzeug für Informatiker.
 
 
Man kann Befehle auch in eine Datei schreiben und dann am Stück ausführen lassen. Diese Dateien heißen Shellskripte. Beispiel:
 
#!/bin/bash
 
# Das ist ein Shellskript. Die erste Zeile sagt dem Betriebssystem,
 
# dass es diese Datei mit Hilfe der bash interpretieren soll.
 
#
 
# Der Rest der Datei besteht aus bash-Befehlen und ist in diesem
 
# Fall sinnfrei (und harmlos).
 
FOO="foo    bar"        # eine Variable (Name links, Inhalt rechts)
 
                        # um das Gleichheitszeichen herum dürfen
 
                        # keine Leerzeichen stehen.
 
echo -n '$FOO = '
 
echo $FOO
 
echo -n '"$FOO" = '
 
echo "$FOO"
 
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
 
chmod 700 foo.sh
 
dann kann man sie wie ein normales Unix-Programm ausführen.
 
  
=== Befehle ===
 
Es gibt vier Arten von einfachen Befehlen:
 
* shellinterne Befehle (zum Beispiel <code>echo</code>),
 
* Kontrollstrukturen der Shell (zum Beispiel <code>while ''bedingung'' do ''code'' done</code>),
 
* Aliase (primitive Makros, die dann durch etwas anderes ersetzt werden) und
 
* Aufrufe externer Programme (zum Beispiel <code>vi</code> und <code>find</code>).
 
Dabei gibt man immer den Befehl selbst gefolgt von eventuellen Parametern an. Die Parameter sind vom Befehl und untereinander durch Leerräume (typischerweise Leerzeichen) getrennt.
 
 
Befehle lassen sich auf mehrere Arten zusammenfassen:
 
* als Verkettung mit einem Semikolon zwischen je zwei Befehlen:
 
echo foo ; echo bar
 
* als durch geschweifte Klammern begrenzter Befehlsblock:
 
{ echo foo ; echo bar ; echo qux }
 
* als Pipeline, wobei die Befehle durch einen senkrechten Strich getrennt werden:
 
echo 'Umweltverschmutzung' | tr mu nü | cat -
 
* 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
 
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
 
{ sort | uniq } < foo.txt > bar.txt
 
schreiben. (<code><</code> lenkt logischerweise die Eingabe so um, dass sie aus der Datei <code>foo.txt</code> kommt.)
 
 
Wenn man einen Befehl mit einem <code>&</code> (kaufmännisches Und) abschließt (also <code>befehl &</code>, das Lehrzeichen 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.
 
 
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:
 
* 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>.
 
Zu all diesen Regelmäßigkeiten gibt es Ausnahmen. Es ist also immer ratsam, [[Manpage|Manpages]] zu konsultieren.
 
 
=== Was sieht man ===
 
Man hat immer zuerst einen Prompt, der im Fakultätsnetz standardmäßig so aussieht:
 
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]]).
 
# 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).
 
 
Das Aussehen und den Inhalt des Prompts kann man durch Setzen der Shellvariable <code>PS1</code> anpassen. Zum Beispiel kann man durch die Eingabe von
 
PS1='\[\033[01;32m\]\u@\h \[\033[01;34m\]\w \$ \[\033[00m\]'
 
den Gentoo-Standardprompt bekommen (die Syntax der Promptbeschreibung muss nicht unbedingt verstanden werden), der die Form
 
<span style="color: green">estar@fiesta </span><span style="color: blue">~ $ </span>
 
hat (Benutzername, <code>@</code>, Rechnername, <code>$</code>), oder mit
 
PS1='\$'
 
einen extrem einfachen Prompt.
 
 
Am Prompt kann man Befehle eingeben. Nachdem ein vollständiger Befehl eingegeben wurde, lässt man mit der Eingabetaste die Shell den Befehl ausführen. Wenn die Shell damit fertig ist, erscheint wieder der Prompt.
 
 
=== <code>.bashrc</code> ===
 
Viele Sachen, zum Beispiel das Setzen eines eigenen Prompts, möchte man bei jedem Start der Shell automatisch erledigen. Bei der <code>bash</code> geht das, indem man die entsprechenden Befehle zur Datei <code>.bashrc</code> im Homeverzeichnis hinzufügt.
 
 
==== Bevor man <code>.bashrc</code> bearbeitet ====
 
* Diese Datei lässt sich so kaputtmachen, dass man keine Shell mehr öffnen kann. Also sollten alle Befehle zuerst in der Shell getestet werden.
 
* Damit [[SSH]] und insbesondere <code>scp</code> richtig funktionieren, dürfen die Befehle in <code>.bashrc</code> '''keine''' Ausgabe produzieren.
 
* Es ist sinnvoll, zuerst die Dokumentation der <code>bash</code> zu lesen.
 
  
 
== Weitere Programme ==
 
== Weitere Programme ==
Zeile 409: Zeile 291:
 
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).
 
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.
 
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 ==
 
== Weblinks ==
Zeile 419: Zeile 301:
 
* [ftp://ftp.cwru.edu/pub/bash/FAQ Bash FAQ]
 
* [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]
 
* [http://www.tldp.org/LDP/abs/html/ Advanced Bash Scripting Guide] und dessen [http://www.tldp.org/LDP/abs/html/ Bibliografie]
 +
* [http://www.perl.org/books/beginning-perl/ Beginning Perl] als PDF oder "ISBN-10: 1861003145". <br /> Beispiele nach dem Perl-Konzept: '',,There’s more than one way to do it.´´'' ([http://en.wikipedia.org/wiki/Larry_Wall Larry Wall]). Anhänge auch zum "on the fly"-Nachschlagen geeignet.
  
 
[[Kategorie: Überleben im Fakultätsnetz]]
 
[[Kategorie: Überleben im Fakultätsnetz]]

Aktuelle Version vom 25. Mai 2013, 17:29 Uhr

Die Unix-Shell

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:

  • als Benutzer/in einer graphischen Oberfläche (GUI) indem man Programme wie den OS X Finder, Windows Explorer oder Gnome Nautilus verwendet,
  • als Programmierer/in, indem man Funktionen des Betriebsystems aufruft,
  • 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 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 einem GUI zu erzielen.
  • Shellscripte lassen sich schneller schreiben als (C-)Programme.
  • 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 (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 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.

Verschiedene Shells

Es gibt viele Shells. Alle haben kryptische Namen und die meisten enden auf -sh. Bekannte Beispiele sind:

  • sh ist die erste moderne Shell, genannt Bourne-Shell. Eine sh-kompatible Shell ist auf fast jedem Unix-System vorhanden.
  • bash ist die Bourne Again Shell, ein Nachfolger von sh und die Standardshell in den meisten Linux-Distributionen, auch im Fakultätsnetz.
  • csh ist die C Shell.
  • tcsh ist eine Weiterentwicklung der csh, die manche Leute mehr mögen als bash.

Im Rest dieses Artikels geht es um die bash; wer eine andere Shell benutzt, kann die Unterschiede anhand der Manpages nachlesen.

Beispiele

So lässt man sich die Dateien im aktuellen Verzeichnis anzeigen:

ls

Und so wird die Anzeige ausführlicher:

ls -l

... und mit versteckten Dateien (das sind Dateien, deren Name mit einem Punkt beginnt):

ls -la

Tipp: Kann man sich gut als "list -long, all" merken.

Verzeichniswechsel:

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)

(# ist das Kommentarzeichen der bash. # und alles, was rechts davon steht, wird bei der Interpretation ignoriert.)

Dieser Schnipsel ersetzt mit Hilfe des Texteditors vi in allen html-Dateien im aktuellen Verzeichnis eine veraltete Emailadresse:

for htmlfile in *.html; do \
        vi -c ':1,$s/alt@meinedomain.de/webmaster@meinedomain.de/g' -c ':wq' "$htmlfile"; done

Alternativ kann man schreiben:

for i in *.html
do
        vi -c ':1,$s/alt@meinedomain.de/webmaster@meinedomain.de/g' -c ':wq' "$htmlfile"
done

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' '{}' ';'

Prinzipien

Die Idee der Shell ist, dass man eine relativ einfache (und aus vielen Abkürzungen bestehende) Programmiersprache hat, die man in einem Interpreter (der Shell) direkt eingeben kann - also genau das richtige Spielzeug für Informatiker.

Man kann Befehle auch in eine Datei schreiben und dann am Stück ausführen lassen. Diese Dateien heißen Shellskripte. Beispiel:

#!/bin/bash
# Das ist ein Shellskript. Die erste Zeile sagt dem Betriebssystem,
# dass es diese Datei mit Hilfe der bash interpretieren soll.
#
# Der Rest der Datei besteht aus bash-Befehlen und ist in diesem
# Fall sinnfrei (und i.d.R. harmlos).
FOO="foo    bar"        # eine Variable (Name links, Inhalt rechts)
                        # um das Gleichheitszeichen herum dürfen
                        # keine Leerzeichen stehen.
echo -n '$FOO = '
echo $FOO
echo -n '"$FOO" = '
echo "$FOO"
echo -n "'$FOO' = "
echo '$FOO'

Wenn man diesen Text in einer Textdatei, z. B. foo.sh, speichert und diese ausführbar macht, z. B. mit

chmod 700 foo.sh

dann kann man sie wie ein normales Unix-Programm ausführen.

Befehle

Es gibt vier Arten von einfachen Befehlen:

  • shellinterne Befehle (zum Beispiel echo),
  • Kontrollstrukturen der Shell (zum Beispiel while bedingung do code done),
  • Aliase (primitive Makros, die dann durch etwas anderes ersetzt werden) und
  • Aufrufe externer Programme (zum Beispiel vi und find).

Dabei gibt man immer den Befehl selbst gefolgt von eventuellen Parametern an. Die Parameter sind vom Befehl und untereinander durch Leerräume (typischerweise Leerzeichen) getrennt.

Befehle lassen sich auf mehrere Arten zusammenfassen:

  • als Verkettung mit einem Semikolon zwischen je zwei Befehlen:
echo foo ; echo bar
  • als durch geschweifte Klammern begrenzter Befehlsblock:
{ echo foo ; echo bar ; echo qux }
  • als Pipeline, wobei die Befehle durch einen senkrechten Strich | getrennt werden:
echo 'Umweltverschmutzung' | tr mu nü | cat -
  • 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:

cat foo.txt | sort | uniq > bar.txt

die Datei bar.txt, die die sortierten Zeilen aus foo.txt ohne doppelte Zeilen enthält. Das Zeichen > lenkt dabei die Ausgabe in die Datei bar.txt um. Eleganter lässt sich das ganze als

{ sort | uniq } < foo.txt > bar.txt

schreiben. (< lenkt logischerweise die Eingabe so um, dass sie aus der Datei foo.txt kommt.)

Wenn man einen Befehl mit einem & (kaufmännisches Und) abschließt (also befehl &, das Leerzeichen ist wichtig), so wird er im Hintergrund ausgeführt und man kann in der Shell solange etwas anderes tun. Hat man das & vergessen, kann man einen laufenden Befehl durch den Tastenkürzel <Ctrl>-Z anhalten und mit dem Kommando bg 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. Alternativ benutzt man den befehl nohup um das Programm gänzlich von der Shell abzukoppeln.

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: -a -d -f -r, aus jeweils einem Buchstaben bestehende Argumente mit einem Bindestrich vor jedem Argument
  • abgekürzte Kurzform: -adfr. Diese Form wird nicht von allen Befehlen unterstützt und kann manchmal eine sehr unerwartete Wirkung haben.
  • Langform: --all --directory --force --recursive 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 Optionen (im englischen 'flags'): Manchmal gibt es Argumente, die aus einem Schalter und einem Wert bestehen, z. B. --directory /home/pub/lib, -d /home/pub/lib, --force YES, -f YES, --number=23.

Zu all diesen Regelmäßigkeiten gibt es Ausnahmen. Es ist also immer ratsam, Manpages zu konsultieren.

Was sieht man

Man hat immer zuerst einen Prompt, der im Fakultätsnetz standardmäßig so aussieht:

conde mhaecker 11 (~):
  1. Vorne steht immer der Name des Rechners, auf dem man gerade eingelogt ist. In der Uni kann das zum Beispiel conde (schnell), fiesta (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.)
  2. Danach kommt der Benutzername derjenigen, der die Shell gehört, das heißt, in wessen Namen die eingegebenen Kommandos ausgeführt werden (mhaecker ist der Benutzername von Martin Häcker).
  3. Die Zahl danach gibt an, wie viele Kommandos schon in dieser Shell eingegeben wurden. (Das ist meistens nicht nützlich.)
  4. Danach steht in Klammern das aktuelle Verzeichnis (~ ist eine Abkürzung für das eigene Heimatverzeichnis).

Das Aussehen und den Inhalt des Prompts kann man durch Setzen der Shellvariable PS1 anpassen. Zum Beispiel kann man durch die Eingabe von

PS1='\[\033[01;32m\]\u@\h \[\033[01;34m\]\w \$ \[\033[00m\]'

den Gentoo-Standardprompt bekommen (die Syntax der Promptbeschreibung muss nicht unbedingt verstanden werden), der die Form

estar@fiesta ~ $ 

hat (Benutzername, @, Rechnername, $), oder mit

PS1='\$'

einen extrem einfachen Prompt.

Am Prompt kann man Befehle eingeben. Nachdem ein vollständiger Befehl eingegeben wurde, lässt man mit der Eingabetaste die Shell den Befehl ausführen. Wenn die Shell damit fertig ist, erscheint wieder der Prompt.

.bashrc

Viele Sachen, zum Beispiel das Setzen eines eigenen Prompts, möchte man bei jedem Start der Shell automatisch erledigen. Bei der bash geht das, indem man die entsprechenden Befehle zur Datei .bashrc im Homeverzeichnis hinzufügt.

Bevor man .bashrc bearbeitet

  • Diese Datei lässt sich so kaputtmachen, dass man keine Shell mehr öffnen kann. Also sollten alle Befehle zuerst in der Shell getestet werden.
  • Damit SSH und insbesondere scp richtig funktionieren, dürfen die Befehle in .bashrc keine Ausgabe produzieren.
  • Es ist sinnvoll, zuerst die Dokumentation der bash zu lesen.

Wichtige Befehle

Die Lesenden werden dazu aufgerufen, interessante Befehle gleich auszuprobieren. Das macht es einfacher, sich später daran zu erinnern. Außerdem sollte man die 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.)

ls

ls steht für list und zeigt den inhalt des derzeitigen Verzeichnisses an.

Nützliche Optionen sind:

  • -a alle Dateien anzeigen (auch "versteckte", die mit "." anfangen)
  • -l langes Format mit Anzeige vieler nützlicher Informationen zu den Dateien

cd

cd steht für change directory und macht genau das.

cd

bringt einen immer ins Homeverzeichnis zurück,

cd ..

in das Verzeichnis, das das aktuelle Verzeichnis enthält und

cd einVerzeichnisName

in genau das angegebene Verzeichnis.

mv

mv steht für move und verschiebt Dateien (auch Verzeichnisse). Da Umbenennung ein Spezialfall des Verschiebens ist, kann mv auch Dateien umbenennen.

Aufruf:

mv alter_name neuer_name

cp

cp steht für copy und kopiert Dateien (mit dem Parameter -R auch Verzeichnisse).

Aufruf:

cp name1 name2

kopiert die Datei name1 nach name2,

cp name verzeichnis/

kopiert die Datei name in das Verzeichnis verzeichnis/ und

cp -R verzeichnis1 verzeichnis2

kopiert das Verzeichnis verzeichnis1 rekursiv nach verzeichnis2, falls verzeichnis2 noch nicht existiert, oder in das Verzeichnis verzeichnis2, falls es existiert.

ssh

Siehe SSH.

scp

Siehe SSH.

less

less zeigt komfortabel und einfach Dateien an. In less kann man sich mit "h" eine ausführliche Hilfe anzeigen lassen. Wichtigste Kommandos: (Leerzeichen) für nächste Seite, b (backwards) für vorherige Seite, ansonsten Pfeiltasten. /muster sucht nach muster und man kann mit n zum nächsten Fundort springen. f geht ganz ans Ende und F geht ganz ans Ende und zeigt neue Zeilen falls diese dazukommen.

Aufruf:

less dateiname

grep

grep sucht nach Text in Dateien, oder, falls keine Dateien angegeben werden, in der Eingabe. Es kann auch nach regulären Ausdrücken gesucht werden.

Aufruf:

grep 'zu suchender Text' dateinamen...
egrep '[rR]egulärer *Ausdruck' dateinamen...

man

Siehe Manpage.

gzip

Packt und entpackt Dateien. Im Unterschied z. B. zu WinZip arbeitet gzip mit genau einer Datei. Das Packen mehrerer Dateien wird weiter unten erläutert.

Packen:

gzip datei

erzeugt eine komprimierte Datei mit dem Namen datei.gz und löscht die Datei datei.

Packen ohne Löschen:

cp datei datei.bck
gzip datei
mv datei.bck datei

(siehe auch die Beschreibungen von cp und mv).

Entpacken:

gunzip datei.gz

entpackt die Daten aus datei.gz nach datei und löscht datei.gz.

Entpacken ohne Löschen:
geht analog zum Packen ohne Löschen.

tar

tar ist der tape archiver und wurde ursprünglich für Backups auf Bandlaufwerken verwendet. Es ist inzwischen das Unix-Standardwerkzeug, um viele Dateien in eine Datei zu packen.

Aufruf:

tar fvc datei.tar dateinamen...

erzeugt das Archiv datei.tar aus den weiter angegebenen Dateien (und Verzeichnissen!).

tar fvt datei.tar

zeigt den Inhalt des Archivs datei.tar an.

tar fvx datei.tar

entpackt alle Dateien aus datei.tar und

tar fvx datei.tar dateinamen...

nur die angegebenen.

Erklärung der Optionen:

  • f steht für file, d. h., tar soll eine Archivdatei bearbeiten. (Sonst ist das Verhalten je nach tar-Implementierung unterschiedlich.)
  • v steht für verbose. In diesem Modus zeigt tar mehr Information als sonst an.
  • c steht für create und sagt tar, dass es ein neues Archiv erzeugen soll.
  • t zeigt die Dateien in einem Archiv an.
  • x steht für extract und tut genau das.
  • z steht für zip. Fügt man diesen Parameter hinzu, dann arbeitet tar mit gzip-komprimierten Archiven. Ansonsten bleibt die Benutzung gleich; statt datei.tar schreibt man dann sinnvollerweise immer datei.tar.gz.

Von den Optionen c, t und x sollte genau eine angegeben werden.

Wenn man ein tar-Archiv erstellt, das für andere Leute gedacht ist, sollte man im Allgemeinen darin genau ein Verzeichnis packen, dessen Name etwas mit dem Inhalt zu tun hat. Das macht es einfacher, nach dem Entpacken den Überblick über die entpackten Dateien zu behalten.

Verschickt man viele Dateien in einer Email, dann sollte man sie zuerst in ein komprimiertes tar-Archiv packen. Das erspart dem Empfänger Arbeit (Wer speichert schon gern ein dutzend Anhänge einzeln ab?) und ist deshalb höflich. WinZip würde zwar prinzipiell das Gleiche tun, aber nicht alle Unix-Benutzer können WinZip-Dateien lesen.

Quellcode wird häufig in komprimierten tar-Archiven (tarballs) angeboten.

pico und nano

pico ein minimaler Texteditor aus dem Mailprogramm pine. Sein großer Vorteil ist, das er unten am Bildschirmrand immer ein Menü anzeigt. "^" steht dabei immer für <Ctrl>. nano ist eine Standalone-Version des Editors.

Tastenkombinationen:

  • <Ctrl>-x um den Editor zu beenden

[x]emacs

[X]Emacs ist ein Texteditor, der ursprünglich im Zusammenhang des GNU-Projektes (der Ursprung der GPL) von Richard Stallman (Gründer der Free Software Foundation) entwickelt wurde.

Tastenkombinationen:

  • <Ctrl>-x-c (x und c nacheinander, Controltaste dabei gedrückt halten) um Emacs zu beenden.

Weitere Informationen gibt es hier.

vi oder vim

vi (visual) ist der Unix-Standardtexteditor und bei fast jedem Unix vorhanden, daher sollte man zumindest die wichtigsten Befehle beherrschen. vim (Vi IMproved) ist der beliebteste und mächtigste Vi-Clone.

Tastenkombinationen:

  • <Esc>:q<Enter> zum Beenden. Alles Weitere liest man woanders nach.

chmod

chmod steht für change mode und ändert die Zugriffsrechte von Dateien, also wer sie lesen und schreiben darf und wer nicht. Das ist wichtig, wenn man mit anderen Leuten zusammenarbeiten will/muss. Dass man es braucht, merkt man, wenn man Fehlermeldungen wie "Permission Denied" bekommt. Eine Erläuterung der Unix-Dateirechte und somit auch der chmod-Optionen lässt sich anderswo nachlesen.

grp

Mit grp (group administrativia) könnt ihr euch in Unix-Gruppen eintragen. Das ist wichtig, wenn ihr in Gruppen Hausaufgaben erledigen wollt. Siehe auch http://irb.cs.tu-berlin.de/leitfaden/arbeiten-in-gruppen.html

Anmerkung: Dieses Kommando ist eine Spezialität des IRB-Netzes! Das funktioniert außerdem häufig nur, wenn man sich auf pepita einloggt. Die Änderungen werden dann zur vollen Stunde übernommen.

utsettings

Mit utsettings kann man u.a. die Auflösung eines, an eine SunRay angeschlossenen, Monitors ändern. Dies ist insbesondere dann sinnvoll, wenn zum Beispiel nach einem Stromausfall die Standardauflösung nicht wieder hergestellt wurde. Bei Eingabe des Befehls in ein Terminal ('/usr/local/bin/utsettings') öffnet sich ein kleines Programm in einem Fenster, dessen Bedienung selbsterklärend sein sollte.



Weitere Programme

Viele interessante Programme, z. B. Firefox und Eclipse, aber auch relative aktuelle GNU-Implementierungen der Standardwerkzeuge von Unix, werden von Studenten installiert und gewartet.

Alle diese Programme findet Ihr im Verzeichnis /home/pub. Es lohnt sich also, ab und an einen Blick dorthin zu werfen. Wer diese Programme öfter verwendet, sollte in .applrc den Eintrag

pub

hinzufügen. Fügt man ihn oberhalb von

standard

hinzu, so hat das die Wirkung, dass die Shell zuerst in /home/pub nach Programmen sucht, also z. B. zuerst die GNU-Werkzeuge findet (die Solaris-Gegenstücke sind teilweise deutlich anders), was vor allem Linux-Anwender freuen sollte.

Bevor man die Programme aus /home/pub benutzt oder dort etwas installiert, sollte man die Hinweise des IRB lesen (die allerdings nicht mehr 100%-ig zutreffen).

Ausblick, Links

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 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 Python, Perl oder Ruby ins mentale Boot holen sollte.

Weblinks