Dies ist Teil 3 eines Tutorials zu Terminal
Inhalt
Teil 1
(0) Einleitung
(1) Das Programm
(2) Unix als System
(3) man
(4) Einige Befehle
Teil 2
(5) I/O-Redirection / Pipes und Wildcards / Regular Expressions
(6) Editoren vi/vim, Emacs und nano
(7) "Pimp my Terminal"
Teil 3
(7) "Pimp my Terminal" (Fortsetzung)
(8) User / Admin / Superuser
Teil 4
(8) User / Admin / Superuser (Fortsetzung)
(9) Wie komme ich zu UNIX-Programmen?
Teil 5
(9) Wie komme ich zu UNIX-Programmen? (Fortsetzung)
Teil 6
(10) Einige Unterschiede zwischen Darwin und anderen UNICES
(11) Weitere Informationen / Referenzen / Links
Dank
------
(7) "Pimp my Terminal" (Fortsetzung)
(7.3) bash
Auf die Standardshell des aktuellen Mac OS gehen wir etwas ausführlicher ein. UNIX hat ja nicht gerade das Problem, dass man es zuwenig konfigurieren könnte.
So sehen wir uns hier nur auf ein paar Dinge an, welche auch schon zu Beginn hilfreich sein könnten. Gerade zu bash finden sich im Internet ausführliche Informationen (zB. hier).
Lernen wir ein paar seiner Shortcuts im interaktiven Modus kennen:
(7.3.1) bash Prompt
Zahlreiche Informationen zur Konfiguration der Shell sind in Umgebungsvariablen festgehalten.
Das Aussehen des Prompts ist in der Umgebungsvariable PS1 der Shell gespeichert. Wir können uns diese Umgebungsvariablen ansehen mittels des Befehls
$ set
und finden dabei auch die Definition der Variable PS1. Diese kann beispielsweise so aussehen
Diese Formatierung bewirkt den folgenden Prompt:
Der Prompt kann sehr frei definiert werden. Als nun routinierte Shell-Benutzer fällt es uns ja nicht mehr schwer, uns die Informationen mittels man selbst zu beschaffen.
$ man bash
So sehen wir nun alle Informationen zur Konfiguration des Prompts. Einige wichtige habe ich ausgewählt. Schauen wir uns die Definition unseres Beispiels nochmals an. Unten stehen die Erklärungen:
PS1='\h:\w \u\$ '
\h Hostname bis zum ersten .
\w aktuelles Arbeitsverzeichnis
\u Benutzername des aktuellen Benutzers
\$ #bei UID 0 (Superuser), sonst $
Einzelne weitere interessante Parameter
\! History-Nummer
\# Befehlsnummer
Der neue Prompt wird mittels des Befehls export gesetzt und bekanntgemacht. Beispiel:
$ export PS1='[\!] \h:\w \u\$ '
Zahlreiche Beispiele finden sich hier: Beispiele, Beispiele, Beispiele, Beispiele
Information: Der standardmässig eingestellte Prompt beinhaltet bereits die wichtigsten Informationen in guter Darstellung. So gibt es eigentlich keinen zwingenden Grund, diesen anpassen zu müssen. Für fortgeschrittene Benutzer kann es sich jedoch beispielsweise lohnen, für Admin-Accounts andere Farben zu definieren, so dass immer klar ist, ob man in einem User- oder Admin-Account arbeitet...
Dieser innerhalb der Shell definierte Prompt verschwindet nach Ende der Shell wieder. Dies hat auch den Vorteil, dass wir einen Fehler rasch rückgängig machen können.
Deshalb funktioniert auch folgende Notfall-Info: Wir geben einfach exit auf einer neuen Zeile ein und schliessen das Terminal-Fenster. Beim Neustart der Shell kommt wieder der Standard-Prompt.
Später sehen wir, wie wir die Shell bleibend konfigurieren. Da sieht es dann schon anders aus.
(7.3.2) alias
Dieser Befehl ist ausserordentlich nützlich. Er erlaubt es uns neue Befehle zu definieren. Weiter oben erklärten wir, dass eine gewisse Sicherheitsfunktion uns vor versehentlichem Überschreiben schützen kann bei Befehl cp (kopieren). Wir können den Befehl cp nun auch so definieren, dass er automatisch immer diesen Parameter dazufügt.
$ alias cp=’cp -i’
Probiere mit dieser Funktion mal eine Datei zweimal an denselben Ort zu kopieren...
Mit folgendem Befehl können wir uns alle Definitionen ansehen:
$ alias
Auch diese Definitionen verfliegen wieder, sobald wir uns aus der Shell ausloggen. So wollen wir uns doch mal ansehen, dass wir ein paar Dinge definitiv konfigurieren können...
(7.3.3) bash - Konfiguration
bash sucht sich seine Informationen an verschiedenen Stellen zusammen. Es gibt
1) Systemweit geltende Informationen (vordefiniert oder allenfalls modifiziert durch den Admin)
2) Benutzerspezifische Dateien
Konzept: Dabei unterscheidet bash, wie gestartet wurde. Kurz und vereinfacht:
Ganz einfach
Wir werden es mit folgenden Beispielen leichter verstehen. Auch fortgeschrittene User sollten nur die Dateien im persönlichen Verzeichnis zu ändern. Diese können im schlimmsten Fall ohne Probleme einfach wieder gelöscht werden. Bei Fehlern in den Systemdateien in /etc kann das System unter umständen in einen nicht mehr boot-fähigen Zustand geschossen werden...
Auch müssen wir uns so nicht als Admin anmelden (was wir ja gar noch nicht gelernt haben
). Aber wir können uns die systemweiten Konfigurationsdateien ja trotzdem mal ansehen:
$ less /etc/profile
$ less /etc/bashrc
Wir sehen echte Shell-Scripts. Scripts sind kurz gesagt eine Abfolge von Befehlen. Auf die Syntax gehen wir im Moment nicht ein. Wir erkennen jedoch in /etc/profile, dass irgendwo /etc/bashrc aufgerufen wird. In /etc/bashrc erkennen wir, wie der Prompt definiert wird.
Bevor wir unsere eigenen Konfigurationsdateien definieren und so die ersten Shell-Scripts schreiben werden, muss ich noch etwas beichten
:
Bisher haben wir einen wichtigen Punkt unterschlagen. Unsere Shell kann noch nicht korrekt mit Umlauten umgehen. Sie wird nicht automatisch mit der Installation des Mac OS internationalisiert. Aus didaktischen Gründen haben wir dies bisher weggelassen. Jetzt werden wir das korrigieren...
Beispiele:
So findet sich auf der Harddisk, sozusagen im Basisverzeichnis / ein Link mit dem Namen 'Benutzerhandbücher und Informationen'. Schauen wir doch nochmals
$ ls –la /
Anstelle des Umlauts stehen nur zwei Fragezeichen. Dies können wir zwar mit der Option –w bei ls korrigieren:
$ ls –law /
Jedoch besteht das Problem auch, wenn wir eine Datei mit Umlauten schreiben wollen:
$ touch ~/jöö.txt
$ touch ~/ähm.txt
$ ls –law ~
Die Umlaute werden nicht korrekt generiert. Wir können das auch im Finder in unserem Benutzerverzeichnis kontrollieren...
Dies werden wir nun unter anderem korrigieren. Die Beispiele sind dabei an Scripts angelehnt isnbesondere zur Internationalisierung, wie sie bereits früher in Apfeltalk beschrieben wurden (man muss ja nicht immer alles neu erfinden, Link (MacMark)).
Generieren wir mal unsere eigenen einfachen Scripts. Wir benutzen dazu simpel nano (oder Könner bereits vim, der sich ja sowieso zu lernen lohnt) und speichern das Ganze. Selbstverständlich können wir dazu auch copy & paste benutzen
$ nano ~/.bash_profile
Zeilenweise Erklärung:
1) Das zusätzliche Shell-Script .bashrc wird gestartet. Dies erfolgt mit dem Punkt am Zeilenanfang (ein kurzer aber mächtiger Befehl ).
2) Wir definieren unseren Prompt nach Wunsch.
3) Alias definieren unsere Zusatzfunktionen. Dabei benutzen wir auch schon die Option –w für ls. Weitere können nach belieben definiert werden.
4) Definition einer Shell-Function: pman kann aufgerufen werden wie man. Der neue Befehl generiert dann jedoch direkt ein PDF (man für Ästheten); von pepi
Wenn wir diese Datei gespeichert haben, editieren wir die nächste:
$ nano ~/.bashrc
Wir erinnern uns, dass wir das Terminalprogramm ebenso auf UTF-8 eingestellte haben.
Als nächstes benutzen wir noch eine weitere Definitionsdatei von bash, um auch noch die letzten Konfigurationen vorzunehmen:
$ nano ~/.inputrc
Die Erklärungen zu diesen Schaltern finden sich hier. Dies zeigt auch, dass man noch viel konfigurieren könnte...
So, jetzt haben wir viel eingestellt. Insbesondere haben wir unser System auf deutsch internationalisiert. Eigentlich haben wir uns eine Pause verdient – und so auch der Computer. Schliessen wir die Shell
$ exit
und schliessen wir das Terminal-Fenster.
Schon zurück?
Nach der Pause können wir nun eine neue Shell öffnen. Dies müssen wir übrigens auch tun, wenn wir direkt ohne Pause durchgearbeitet haben.
Die oben gemachten Änderungen funktionieren erst ab dem neuen Start der Shell. Wir erinnern uns: Es sind Scripts, die zu bestimmten Zeitpunkten ausgeführt werden.
So könnte man übrigens auch ein Script definieren, das beim Verlassen der Shell ausgeführt wird. Wir müssen es in ~/.bash_logout speichern. Doch das lassen wir für den Moment.
(7.3.4) bash - Scripts
Bereits im Rahmen der Konfiguration erwähnten wir oftmals Scripts. Scripts sind eine Abfolge von Befehlen, die zur einfacheren wiederkehrenden Anwendung derselben in einer Textdatei zusammengefasst werden. Dazu können mittels spezifischer Konstrukte bedingte Ausführung (if...fi), repetitive Anwendungen (Schleifen) und auch weitere Sprachelemente zur Ablaufsteuerung verwendet werden. Diese Befehlsabfolge kann dann wie ein einzelnes Programm aufgerufen werden.
Shell-Scripts sind wirklich das Salz in der UNIX-Suppe. Ohne sie läuft schlichtweg nichts. Mit etwas Erfahrung anderer Programmiersprachen lassen sich die verschiedenen Scriptsprachen zwar leicht aneignen. Dennoch sei zur Vorsicht gemahnt, da die Syntax oft in kleinen jedoch entscheidenden Details unterschiedlich ist.
Das Internet ist voll mit Beispielen zu Scripts (Suchfunktion). Auch gibt es einige sehr gute Informationen (hier und hier), welche den Umfang dieses Tutorials bei weitem sprengen würden. Ebenso empfehlen sich einige Bücher.
(7.4) tcsh
Bis Mac OS 10.2 war die tcsh (klassische BSD-Unix-Shell) die Standard-Shell. Der grösste Hauptunterschied zu einer sh-kompatiblen Shell wie bash ist die Script-Sprache. Diese ist sehr nahe an C angelehnt - und damit nicht mehr kompatibel zu beiden. Dies bringt jedoch Vorteile, wenn sich jemand sowieso gewohnt ist, C-Programme zu schreiben.
Daneben bietet die Shell einigen Benutzerkomfort. Sie hat einen command line editor, der mit dem gleichen Befehlssatz wie vi bedient werden kann. Auto-Vervollständigung von Programmen und Dateinamen (Tabulator) können Geschwindigkeitsvorteile bringen. Eine Rechtschreibprüfung (Korrektur zb. des Befehls lz nach ls) kann ebenso Vorteile bringen. Andererseits können solche Eingabehilfen auch rasch Probleme mit sich bringen, wenn (trotz Sicherheitsnachfrage nach automatischer Korrektur) ein Befehl oder eine Datei halt doch falsch durch das System substituiert wurde. Diese sehr mächtigen Zusatzfunktionen sind also eher etwas für fortgeschrittene Benutzer.
Ansonsten kann die Shell recht ähnlich wie bash in eigenen Konfigurationsskripten (andere Namen) konfiguriert werden. Ich verweise aufgrund des Umfangs in diesem Kontext auf das ausführliche Manual (man tcsh / oder wer oben für bash in .bash_profile bereits pman definiert hat (Danke pepi), kann in bash das ganze noch ästhetischer ansehen mittels pman tcsh).
Der Wechsel von tcsh auf bash erfolgte wahrscheinlich hauptsächlich wegen der ausserodentlich weiten Verbreitung von bash im Bereich der Linux-Welt.
(Anmerkung: Da Scripts in der ersten Zeile optimal direkt angeben, mit welcher Shell sie ausgeführt werden [she-bang], können ohne Probleme sh- bzw. csh-kompatible Scripts ausgeführt werden. Andererseits gibt es eher Probleme, wenn Scripts versionen-spezifische Features einer Shell verwenden. Diese werden nicht direkt durch die Shell abgefangen, sondern müssen durch den Programmierer abgefangen werden.)
(7.5) Perl / Python / andere Programmiersprachen
Scripts / Programme müssen nicht nicht unbedingt in einer Shell-spezifische Sprache geschrieben werden. Es können auch echte Programmiersprachen wie Perl und Python (benannt nach Monty Python) verwendet werden. Diese sind viel mächtiger an Funktionalität und bieten so mehr Möglichkeiten.
Systemprogramme werden dann jeweils an passender Stelle aus dem Programm heraus aufgerufen, so dass sich auch mit ihnen die gleiche Funktionalität wie in Shell-Sprachen erzielen lässt. Letztlich kommt es auf die Komplexität des Problems und die Kenntnisse des Entwicklers an, welche Sprache in welchem Ausmass verwendet wird.
Zu Perl habe ich von etinzi und Skeeve einen Link auf ein ausführliches Tutorial erhalten: Link. Auch hat sich Skeeve bereit erklärt, dass man sich bei Perl-spezifischen Fragen gern an ihn wenden kann. Vielen Dank!
(8) User / Admin / Superuser (meist = root)
Wie im ersten Teil dieses Tutorials gesehen (Kapitel 2.2), wird klar zwischen diesen Benutzerkategorien unterschieden. Die für normale User vergebenen Rechte genügen für das alltägliche Arbeiten, schützen jedoch andere Benutzer und insbesondere das System vor schädlichen Einflüssen. Einige Konfigurationen (Programme für alle Benutzer freigeben) müssen jedoch als Superuser ausgeführt werden. Der Superuser wird auf Macs immer root genannt. In anderen Systemen heisst er meist auch so (muss jedoch nicht).
Wir sind ja mittlerweile schon etwas geübt im Umgang mit unserer Shell. Nichtsdestoweniger muss nochmals ein Warnschild hier hin:
Kommentar: Mac OS ist so konfiguriert, dass man das Passwort für root selbst gar nicht benötigt. Standardmässig ist root auch deaktiviert (unmöglicher Passwort-Hash). Das Ganze funktioniert - wie wir sehen werden - wesentlich eleganter und besser geschützt. Dieses Vorenthalten des root Passworts ist eine hervorragende Idee für einen Computer, der doch hauptsächlich von Personen benutzt wird, welche v.a. die grafische Benutzeroberfläche benutzen und mit UNIX sonst nicht zwingend Kontakt hatten.
Die Sicherheit des Systems hängt stark von der Sicherheit dieses Passwortes ab. Wieso soll man vom Benutzer, welcher den Computer erst gerade auspackte, bereits so eine schwierige und - wie wir sehen werden - unnötige Frage stellen?
Mit zunehmender Kenntnis im Umgang mit UNIX wirst Du sehen, dass es für viele Fragen zahlreiche Lösungswege gibt. So gibt es gerade im Umgang mit den im folgenden beschriebenen Bereichen verschiedene Lösungsmöglichkeiten. Ich habe eine Form gewählt, die so sicher funktioniert und es mir gleichzeitig erlaubt, einige weitere Punkte zu beleuchten.
(8.1) sudo – Ein Entfesslungskünstler, von Houdinis Klasse
Dieses Programm ist die Antwort auf die Frage: Wie kann ich Programme mit den Rechten eines anderen Benutzers (v.a. Superusers) starten, wenn ich nicht mal deren Passwort kenne. Damit kann die Zeitdauer, während der effektiv der Superuser aktiv ist, auf ein Minimum reduziert werden. Ausserdem kann man so Personen das Rechte geben, gewisse administrative Aufgaben auszuführen ("rollenbasierte Administration"), ohne dass man ihnen gleich ein geheimes Passwort geben muss (das man bei Vertrauensbruch wieder bei allen anderen Administratoren ersetzen muss). Die Authentifikation erfolgt nämlich nicht über ein zentrales root Passwort, sondern über das benutzereigene Passwort (das selbstverständlich wie jedes Passwort auch sicher gewählt werden muss).
sudo ist ein Akronym für 'substitute user do' (führe einen Befehl als anderen Benutzer aus)
Probieren wir es mal aus mit einem gefahrlosen Befehl.
$ sudo ls
sudo fragt nach einem Passwort. Dies ist Dein persönliches Passwort und hat nichts mit dem Passwort von root zu tun. Dieses Passwort werden wir nie brauchen.
Es gibt nun zwei Möglichkeiten
sudo verfügt über einen ausgeklügelten Schutzmechanismus, mit dem präzise definiert werden kann, wer was mittels sudo machen kann. Es wäre ja noch zu schön, wenn jeder Benutzer (zB. gar ein Gast) mittels sudo Programme mit root Rechten ausführen könnte...
Standardmässig haben normale Benutzer also nicht das Recht, sudo zu benutzen. Andererseits haben alle mit Administrationsrechten ausgestatten Mac User das Recht, sudo ohne Einschränkung zu benutzen.
Wir werden diesen Schutzmechanismus im Verlauf genauer ansehen. Auch dieser Mechanismus kann präzise eingestellt werden. Jedoch benötigt man dazu root Rechte, die es erstmal zu erlangen gilt
Anmerkung: sudo kann nicht nur ein Programm als root ausführen. Man kann mittels der Option -u (siehe einmal mehr man sudo ) auch einen beliebigen anderen Benutzer wählen. Das einzugebende Passwort bleibt jedoch das eigene.
Link: Fortsetzung Teil 4
Inhalt
Teil 1
(0) Einleitung
(1) Das Programm
(2) Unix als System
(3) man
(4) Einige Befehle
Teil 2
(5) I/O-Redirection / Pipes und Wildcards / Regular Expressions
(6) Editoren vi/vim, Emacs und nano
(7) "Pimp my Terminal"
Teil 3
(7) "Pimp my Terminal" (Fortsetzung)
(8) User / Admin / Superuser
Teil 4
(8) User / Admin / Superuser (Fortsetzung)
(9) Wie komme ich zu UNIX-Programmen?
Teil 5
(9) Wie komme ich zu UNIX-Programmen? (Fortsetzung)
Teil 6
(10) Einige Unterschiede zwischen Darwin und anderen UNICES
(11) Weitere Informationen / Referenzen / Links
Dank
------
(7) "Pimp my Terminal" (Fortsetzung)
(7.3) bash
Auf die Standardshell des aktuellen Mac OS gehen wir etwas ausführlicher ein. UNIX hat ja nicht gerade das Problem, dass man es zuwenig konfigurieren könnte.
So sehen wir uns hier nur auf ein paar Dinge an, welche auch schon zu Beginn hilfreich sein könnten. Gerade zu bash finden sich im Internet ausführliche Informationen (zB. hier).Lernen wir ein paar seiner Shortcuts im interaktiven Modus kennen:
- Pfeil links = ctrl-b : Cursor ein Zeichen nach links
- Pfeil rechts = ctrl-f : Cursor ein Zeichen nach rechts
- esc-b : Cursor ein Wort nach links
- esc-f : Cursor ein Wort nach rechts
- ctrl-a : Zeilenanfang
- ctrl-e : Zeilenende
- ctrl-k : löschen bis ans Zeilenende
- ctrl-u : ganze Zeile löschen
- ctrl-t : twiddle - tauscht das Zeichen links des Cursors und unter dem Cursor
- ctrl-c : laufendes Programm stoppen
- ctrl-d : aktuelle Shell beenden (enspricht logout bzw. exit)
- Pfeil oben = ctrl-p : vorheriges Kommando (Befehls-History)
- Pfeil unten = ctrl-n : nächstes Kommando (Befehls-History)
- ctrl-r : Befehl suchen rückwärts
- ctrl-R : Befehl in History rückwärts (mehrere Befehle)
- ctrl-z : aktuelles Programm in den Hintergrund schicken (suspend); man kann es von der Shell später wieder mittels fg bzwl fg <Nummer> in den Vordergrund holen; Der Befehl jobs zeigt uns die Nummer).
(7.3.1) bash Prompt
Zahlreiche Informationen zur Konfiguration der Shell sind in Umgebungsvariablen festgehalten.
Das Aussehen des Prompts ist in der Umgebungsvariable PS1 der Shell gespeichert. Wir können uns diese Umgebungsvariablen ansehen mittels des Befehls
$ set
und finden dabei auch die Definition der Variable PS1. Diese kann beispielsweise so aussehen
PS1='\h:\w \u\$ '
Diese Formatierung bewirkt den folgenden Prompt:
Computername:Verzeichnis Benutzer$
Der Prompt kann sehr frei definiert werden. Als nun routinierte Shell-Benutzer fällt es uns ja nicht mehr schwer, uns die Informationen mittels man selbst zu beschaffen.
$ man bash
dann eingeben:
/prompting (für Suche 'prompting')
n (nächste Fundstelle; dann sind wir dort, wo wir hin wollten)
/prompting (für Suche 'prompting')
n (nächste Fundstelle; dann sind wir dort, wo wir hin wollten)
So sehen wir nun alle Informationen zur Konfiguration des Prompts. Einige wichtige habe ich ausgewählt. Schauen wir uns die Definition unseres Beispiels nochmals an. Unten stehen die Erklärungen:
PS1='\h:\w \u\$ '
\h Hostname bis zum ersten .
\w aktuelles Arbeitsverzeichnis
\u Benutzername des aktuellen Benutzers
\$ #bei UID 0 (Superuser), sonst $
Einzelne weitere interessante Parameter
\! History-Nummer
\# Befehlsnummer
Der neue Prompt wird mittels des Befehls export gesetzt und bekanntgemacht. Beispiel:
$ export PS1='[\!] \h:\w \u\$ '
Zahlreiche Beispiele finden sich hier: Beispiele, Beispiele, Beispiele, Beispiele
Information: Der standardmässig eingestellte Prompt beinhaltet bereits die wichtigsten Informationen in guter Darstellung. So gibt es eigentlich keinen zwingenden Grund, diesen anpassen zu müssen. Für fortgeschrittene Benutzer kann es sich jedoch beispielsweise lohnen, für Admin-Accounts andere Farben zu definieren, so dass immer klar ist, ob man in einem User- oder Admin-Account arbeitet...
Dieser innerhalb der Shell definierte Prompt verschwindet nach Ende der Shell wieder. Dies hat auch den Vorteil, dass wir einen Fehler rasch rückgängig machen können.
Deshalb funktioniert auch folgende Notfall-Info: Wir geben einfach exit auf einer neuen Zeile ein und schliessen das Terminal-Fenster. Beim Neustart der Shell kommt wieder der Standard-Prompt.
Später sehen wir, wie wir die Shell bleibend konfigurieren. Da sieht es dann schon anders aus.
(7.3.2) alias
Dieser Befehl ist ausserordentlich nützlich. Er erlaubt es uns neue Befehle zu definieren. Weiter oben erklärten wir, dass eine gewisse Sicherheitsfunktion uns vor versehentlichem Überschreiben schützen kann bei Befehl cp (kopieren). Wir können den Befehl cp nun auch so definieren, dass er automatisch immer diesen Parameter dazufügt.
$ alias cp=’cp -i’
Probiere mit dieser Funktion mal eine Datei zweimal an denselben Ort zu kopieren...
Mit folgendem Befehl können wir uns alle Definitionen ansehen:
$ alias
Auch diese Definitionen verfliegen wieder, sobald wir uns aus der Shell ausloggen. So wollen wir uns doch mal ansehen, dass wir ein paar Dinge definitiv konfigurieren können...
(7.3.3) bash - Konfiguration
bash sucht sich seine Informationen an verschiedenen Stellen zusammen. Es gibt
1) Systemweit geltende Informationen (vordefiniert oder allenfalls modifiziert durch den Admin)
/etc/profile
/etc/bashrc
/etc/bashrc
2) Benutzerspezifische Dateien
~/.bash_profile bzw. ~/.bash_login bzw. ~/.profile (nicht bash-spezifisch)
~/.bashrc
~/.bashrc
Konzept: Dabei unterscheidet bash, wie gestartet wurde. Kurz und vereinfacht:
- Wenn die Shell direkt von Terminal aufgerufen wird (Login-Modus), so werden /etc/profile (unspezifisch; welches jedoch von sich aus /etc/bashrc aufruft) und dann ~/.bash_profile bzw. ~/.bash_login bzw. ~/.profile aufgerufen (je nachdem, welches zuerst gefunden wird). Optimalerweise sind auch diese Scripts so gestaltet, dass sie die persönliche bashrc-Datei ~/.bashrc aufrufen, so dass die Konfiguration vollständig ist.
- Wenn bash direkt vom Benutzer aus einer Shell heraus gestartet wird (interaktiver Modus)
$ bash
so werden nur /etc/bashrc und ~/.bashrc ausgeführt.
Ganz einfach
Wir werden es mit folgenden Beispielen leichter verstehen. Auch fortgeschrittene User sollten nur die Dateien im persönlichen Verzeichnis zu ändern. Diese können im schlimmsten Fall ohne Probleme einfach wieder gelöscht werden. Bei Fehlern in den Systemdateien in /etc kann das System unter umständen in einen nicht mehr boot-fähigen Zustand geschossen werden...
Auch müssen wir uns so nicht als Admin anmelden (was wir ja gar noch nicht gelernt haben
). Aber wir können uns die systemweiten Konfigurationsdateien ja trotzdem mal ansehen:$ less /etc/profile
$ less /etc/bashrc
Wir sehen echte Shell-Scripts. Scripts sind kurz gesagt eine Abfolge von Befehlen. Auf die Syntax gehen wir im Moment nicht ein. Wir erkennen jedoch in /etc/profile, dass irgendwo /etc/bashrc aufgerufen wird. In /etc/bashrc erkennen wir, wie der Prompt definiert wird.
Bevor wir unsere eigenen Konfigurationsdateien definieren und so die ersten Shell-Scripts schreiben werden, muss ich noch etwas beichten
:Bisher haben wir einen wichtigen Punkt unterschlagen. Unsere Shell kann noch nicht korrekt mit Umlauten umgehen. Sie wird nicht automatisch mit der Installation des Mac OS internationalisiert. Aus didaktischen Gründen haben wir dies bisher weggelassen. Jetzt werden wir das korrigieren...
Beispiele:
So findet sich auf der Harddisk, sozusagen im Basisverzeichnis / ein Link mit dem Namen 'Benutzerhandbücher und Informationen'. Schauen wir doch nochmals
$ ls –la /
Anstelle des Umlauts stehen nur zwei Fragezeichen. Dies können wir zwar mit der Option –w bei ls korrigieren:
$ ls –law /
Jedoch besteht das Problem auch, wenn wir eine Datei mit Umlauten schreiben wollen:
$ touch ~/jöö.txt
$ touch ~/ähm.txt
$ ls –law ~
Die Umlaute werden nicht korrekt generiert. Wir können das auch im Finder in unserem Benutzerverzeichnis kontrollieren...
Dies werden wir nun unter anderem korrigieren. Die Beispiele sind dabei an Scripts angelehnt isnbesondere zur Internationalisierung, wie sie bereits früher in Apfeltalk beschrieben wurden (man muss ja nicht immer alles neu erfinden, Link (MacMark)).
Generieren wir mal unsere eigenen einfachen Scripts. Wir benutzen dazu simpel nano (oder Könner bereits vim, der sich ja sowieso zu lernen lohnt) und speichern das Ganze. Selbstverständlich können wir dazu auch copy & paste benutzen
$ nano ~/.bash_profile
Code:
. .bashrc
export PS1='\h:\w \u\$ '
alias ls='ls -w'
pman() { man -t "$@" | open -f -a Preview; }Zeilenweise Erklärung:
1) Das zusätzliche Shell-Script .bashrc wird gestartet. Dies erfolgt mit dem Punkt am Zeilenanfang (ein kurzer aber mächtiger Befehl
).2) Wir definieren unseren Prompt nach Wunsch.
3) Alias definieren unsere Zusatzfunktionen. Dabei benutzen wir auch schon die Option –w für ls. Weitere können nach belieben definiert werden.
4) Definition einer Shell-Function: pman kann aufgerufen werden wie man. Der neue Befehl generiert dann jedoch direkt ein PDF (man für Ästheten); von pepi
Wenn wir diese Datei gespeichert haben, editieren wir die nächste:
$ nano ~/.bashrc
Code:
export LC_ALL=de_DE.UTF-8
export LANG=de_DE.UTF-8Wir erinnern uns, dass wir das Terminalprogramm ebenso auf UTF-8 eingestellte haben.
Als nächstes benutzen wir noch eine weitere Definitionsdatei von bash, um auch noch die letzten Konfigurationen vorzunehmen:
$ nano ~/.inputrc
Code:
set meta-flag on
set convert-meta off
set output-meta on
set completion-ignore-case on
set show-all-if-ambiguous onDie Erklärungen zu diesen Schaltern finden sich hier. Dies zeigt auch, dass man noch viel konfigurieren könnte...
So, jetzt haben wir viel eingestellt. Insbesondere haben wir unser System auf deutsch internationalisiert. Eigentlich haben wir uns eine Pause verdient – und so auch der Computer. Schliessen wir die Shell
$ exit
und schliessen wir das Terminal-Fenster.
Schon zurück?
Nach der Pause können wir nun eine neue Shell öffnen. Dies müssen wir übrigens auch tun, wenn wir direkt ohne Pause durchgearbeitet haben.
Die oben gemachten Änderungen funktionieren erst ab dem neuen Start der Shell. Wir erinnern uns: Es sind Scripts, die zu bestimmten Zeitpunkten ausgeführt werden.So könnte man übrigens auch ein Script definieren, das beim Verlassen der Shell ausgeführt wird. Wir müssen es in ~/.bash_logout speichern. Doch das lassen wir für den Moment.
(7.3.4) bash - Scripts
Bereits im Rahmen der Konfiguration erwähnten wir oftmals Scripts. Scripts sind eine Abfolge von Befehlen, die zur einfacheren wiederkehrenden Anwendung derselben in einer Textdatei zusammengefasst werden. Dazu können mittels spezifischer Konstrukte bedingte Ausführung (if...fi), repetitive Anwendungen (Schleifen) und auch weitere Sprachelemente zur Ablaufsteuerung verwendet werden. Diese Befehlsabfolge kann dann wie ein einzelnes Programm aufgerufen werden.
Shell-Scripts sind wirklich das Salz in der UNIX-Suppe. Ohne sie läuft schlichtweg nichts. Mit etwas Erfahrung anderer Programmiersprachen lassen sich die verschiedenen Scriptsprachen zwar leicht aneignen. Dennoch sei zur Vorsicht gemahnt, da die Syntax oft in kleinen jedoch entscheidenden Details unterschiedlich ist.
Das Internet ist voll mit Beispielen zu Scripts (Suchfunktion). Auch gibt es einige sehr gute Informationen (hier und hier), welche den Umfang dieses Tutorials bei weitem sprengen würden. Ebenso empfehlen sich einige Bücher.
(7.4) tcsh
Bis Mac OS 10.2 war die tcsh (klassische BSD-Unix-Shell) die Standard-Shell. Der grösste Hauptunterschied zu einer sh-kompatiblen Shell wie bash ist die Script-Sprache. Diese ist sehr nahe an C angelehnt - und damit nicht mehr kompatibel zu beiden. Dies bringt jedoch Vorteile, wenn sich jemand sowieso gewohnt ist, C-Programme zu schreiben.
Daneben bietet die Shell einigen Benutzerkomfort. Sie hat einen command line editor, der mit dem gleichen Befehlssatz wie vi bedient werden kann. Auto-Vervollständigung von Programmen und Dateinamen (Tabulator) können Geschwindigkeitsvorteile bringen. Eine Rechtschreibprüfung (Korrektur zb. des Befehls lz nach ls) kann ebenso Vorteile bringen. Andererseits können solche Eingabehilfen auch rasch Probleme mit sich bringen, wenn (trotz Sicherheitsnachfrage nach automatischer Korrektur) ein Befehl oder eine Datei halt doch falsch durch das System substituiert wurde. Diese sehr mächtigen Zusatzfunktionen sind also eher etwas für fortgeschrittene Benutzer.
Ansonsten kann die Shell recht ähnlich wie bash in eigenen Konfigurationsskripten (andere Namen) konfiguriert werden. Ich verweise aufgrund des Umfangs in diesem Kontext auf das ausführliche Manual (man tcsh / oder wer oben für bash in .bash_profile bereits pman definiert hat (Danke pepi), kann in bash das ganze noch ästhetischer ansehen mittels pman tcsh).
Der Wechsel von tcsh auf bash erfolgte wahrscheinlich hauptsächlich wegen der ausserodentlich weiten Verbreitung von bash im Bereich der Linux-Welt.
(Anmerkung: Da Scripts in der ersten Zeile optimal direkt angeben, mit welcher Shell sie ausgeführt werden [she-bang], können ohne Probleme sh- bzw. csh-kompatible Scripts ausgeführt werden. Andererseits gibt es eher Probleme, wenn Scripts versionen-spezifische Features einer Shell verwenden. Diese werden nicht direkt durch die Shell abgefangen, sondern müssen durch den Programmierer abgefangen werden.)
(7.5) Perl / Python / andere Programmiersprachen
Scripts / Programme müssen nicht nicht unbedingt in einer Shell-spezifische Sprache geschrieben werden. Es können auch echte Programmiersprachen wie Perl und Python (benannt nach Monty Python) verwendet werden. Diese sind viel mächtiger an Funktionalität und bieten so mehr Möglichkeiten.
Systemprogramme werden dann jeweils an passender Stelle aus dem Programm heraus aufgerufen, so dass sich auch mit ihnen die gleiche Funktionalität wie in Shell-Sprachen erzielen lässt. Letztlich kommt es auf die Komplexität des Problems und die Kenntnisse des Entwicklers an, welche Sprache in welchem Ausmass verwendet wird.
Zu Perl habe ich von etinzi und Skeeve einen Link auf ein ausführliches Tutorial erhalten: Link. Auch hat sich Skeeve bereit erklärt, dass man sich bei Perl-spezifischen Fragen gern an ihn wenden kann. Vielen Dank!
(8) User / Admin / Superuser (meist = root)
Wie im ersten Teil dieses Tutorials gesehen (Kapitel 2.2), wird klar zwischen diesen Benutzerkategorien unterschieden. Die für normale User vergebenen Rechte genügen für das alltägliche Arbeiten, schützen jedoch andere Benutzer und insbesondere das System vor schädlichen Einflüssen. Einige Konfigurationen (Programme für alle Benutzer freigeben) müssen jedoch als Superuser ausgeführt werden. Der Superuser wird auf Macs immer root genannt. In anderen Systemen heisst er meist auch so (muss jedoch nicht).
Wir sind ja mittlerweile schon etwas geübt im Umgang mit unserer Shell. Nichtsdestoweniger muss nochmals ein Warnschild hier hin:
Dies gilt insbesondere, wenn wir als Admin oder gar Superuser unterwegs sind.Warnschild schrieb:
Kommentar: Mac OS ist so konfiguriert, dass man das Passwort für root selbst gar nicht benötigt. Standardmässig ist root auch deaktiviert (unmöglicher Passwort-Hash). Das Ganze funktioniert - wie wir sehen werden - wesentlich eleganter und besser geschützt. Dieses Vorenthalten des root Passworts ist eine hervorragende Idee für einen Computer, der doch hauptsächlich von Personen benutzt wird, welche v.a. die grafische Benutzeroberfläche benutzen und mit UNIX sonst nicht zwingend Kontakt hatten.
Die Sicherheit des Systems hängt stark von der Sicherheit dieses Passwortes ab. Wieso soll man vom Benutzer, welcher den Computer erst gerade auspackte, bereits so eine schwierige und - wie wir sehen werden - unnötige Frage stellen?
Mit zunehmender Kenntnis im Umgang mit UNIX wirst Du sehen, dass es für viele Fragen zahlreiche Lösungswege gibt. So gibt es gerade im Umgang mit den im folgenden beschriebenen Bereichen verschiedene Lösungsmöglichkeiten. Ich habe eine Form gewählt, die so sicher funktioniert und es mir gleichzeitig erlaubt, einige weitere Punkte zu beleuchten.
(8.1) sudo – Ein Entfesslungskünstler, von Houdinis Klasse
Dieses Programm ist die Antwort auf die Frage: Wie kann ich Programme mit den Rechten eines anderen Benutzers (v.a. Superusers) starten, wenn ich nicht mal deren Passwort kenne. Damit kann die Zeitdauer, während der effektiv der Superuser aktiv ist, auf ein Minimum reduziert werden. Ausserdem kann man so Personen das Rechte geben, gewisse administrative Aufgaben auszuführen ("rollenbasierte Administration"), ohne dass man ihnen gleich ein geheimes Passwort geben muss (das man bei Vertrauensbruch wieder bei allen anderen Administratoren ersetzen muss). Die Authentifikation erfolgt nämlich nicht über ein zentrales root Passwort, sondern über das benutzereigene Passwort (das selbstverständlich wie jedes Passwort auch sicher gewählt werden muss).
sudo ist ein Akronym für 'substitute user do' (führe einen Befehl als anderen Benutzer aus)
Probieren wir es mal aus mit einem gefahrlosen Befehl.
$ sudo ls
sudo fragt nach einem Passwort. Dies ist Dein persönliches Passwort und hat nichts mit dem Passwort von root zu tun. Dieses Passwort werden wir nie brauchen.
Es gibt nun zwei Möglichkeiten
- Wenn jetzt das aktuelle Verzeichnis ausgegeben wurde, dann geschah dies mit root Rechten. Dann ist auch klar, dass Du entweder (a) von einem Mac-Account aus die Shell eröffnet hast, der Admin-Rechte hat (dies ist standardmässig eigentlich nicht empfehlenswert; man sollte grundsätzlich immer vom gewöhnlichen Benutzer-Account aus arbeiten) oder dass Du (b) die entsprechenden Konfigurationsdateien von sudo bereits angepasst hast (also ein Pro, der die nächsten Abschnitte überspringen darf ).
- Eigentlich war zu erwarten, dass sudo das Passwort nicht akzeptiert, noch zweimal nachfragt und dann letztlich mit folgender Fehlermeldung den Dienst quittiert: User is not in the sudoers file. This incident will be reported.
sudo verfügt über einen ausgeklügelten Schutzmechanismus, mit dem präzise definiert werden kann, wer was mittels sudo machen kann. Es wäre ja noch zu schön, wenn jeder Benutzer (zB. gar ein Gast) mittels sudo Programme mit root Rechten ausführen könnte...
Standardmässig haben normale Benutzer also nicht das Recht, sudo zu benutzen. Andererseits haben alle mit Administrationsrechten ausgestatten Mac User das Recht, sudo ohne Einschränkung zu benutzen.
Wir werden diesen Schutzmechanismus im Verlauf genauer ansehen. Auch dieser Mechanismus kann präzise eingestellt werden. Jedoch benötigt man dazu root Rechte, die es erstmal zu erlangen gilt
Anmerkung: sudo kann nicht nur ein Programm als root ausführen. Man kann mittels der Option -u (siehe einmal mehr man sudo
) auch einen beliebigen anderen Benutzer wählen. Das einzugebende Passwort bleibt jedoch das eigene.Link: Fortsetzung Teil 4
Zuletzt bearbeitet von einem Moderator:
