Bashrc: Unterschied zwischen den Versionen

Aus wiki.archlinux.de
K („“ → code)
Zeile 1: Zeile 1:
{{titel|.bashrc}}
{{titel|.bashrc}}
{{righttoc}}
{{righttoc}}
Die [[bash]] ist unter Arch Linux die Standard-Shell. Mittels der Datei .bashrc“ kann man sich die bash konfigurieren und anpassen. Prinzipiell geht dies auch mit der .bash_profile“ und weiteren Dateien. In diesem Artikel wird allerdings nur auf die .bashrc“ eingegangen, was auch völlig ausreicht.
Die [[bash]] ist unter Arch Linux die Standard-Shell. Mittels der Datei <code>.bashrc</code> kann man sich die bash konfigurieren und anpassen. Prinzipiell geht dies auch mit der <code>.bash_profile</code> und weiteren Dateien. In diesem Artikel wird allerdings nur auf die <code>.bashrc</code> eingegangen, was auch völlig ausreicht.


== Voraussetzungen ==
== Voraussetzungen ==
Unter gewissen Voraussetzungen kann es vorkommen, dass die .bashrc“ nicht verarbeitet wird. Dies kann daran liegen, dass anstelle der .bashrc“ die .bash_profile“ automatisch ausgeführt wird. Nun hat man zwei Möglichkeiten: Entweder, man schreibt die Dinge in die .bash_profile“, oder man schreibt in die .bash_profile“, dass die .bashrc“ ausgeführt werden soll.
Unter gewissen Voraussetzungen kann es vorkommen, dass die <code>.bashrc</code> nicht verarbeitet wird. Dies kann daran liegen, dass anstelle der <code>.bashrc</code> die <code>.bash_profile</code> automatisch ausgeführt wird. Nun hat man zwei Möglichkeiten: Entweder, man schreibt die Dinge in die <code>.bash_profile</code>, oder man schreibt in die <code>.bash_profile</code>, dass die <code>.bashrc</code> ausgeführt werden soll.


  source .bashrc
  source .bashrc


Dies hat den Vorteil, dass man alles über die .bashrc“ machen kann. Diese Datei wird wesentlich häufiger erwähnt, und man muss sich beim Konfigurieren nicht erst Gedanken darüber machen, ob und wo man etwas reinschreiben muss, da .bash_profile“ auf einem so konfigurierten System ja nichts weiter macht, als .bashrc“ zu starten.
Dies hat den Vorteil, dass man alles über die <code>.bashrc</code> machen kann. Diese Datei wird wesentlich häufiger erwähnt, und man muss sich beim Konfigurieren nicht erst Gedanken darüber machen, ob und wo man etwas reinschreiben muss, da <code>.bash_profile</code> auf einem so konfigurierten System ja nichts weiter macht, als <code>.bashrc</code> zu starten.


Man kann auch einen Link anlegen, wovon aber abzuraten ist. Falls man doch irgendwann mal die .bashrc“ und die .bash_profile“ mit unterschiedlichen Inhalten füllen möchte, muss man nämlich erst wieder den Link entfernen und die Datei neu anlegen. Mit der Ausführungsanweisung erspart man sich im vorherein unnötige Arbeit.
Man kann auch einen Link anlegen, wovon aber abzuraten ist. Falls man doch irgendwann mal die <code>.bashrc</code> und die <code>.bash_profile</code> mit unterschiedlichen Inhalten füllen möchte, muss man nämlich erst wieder den Link entfernen und die Datei neu anlegen. Mit der Ausführungsanweisung erspart man sich im vorherein unnötige Arbeit.


== Vorüberlegungen ==
== Vorüberlegungen ==
Zeile 16: Zeile 16:
Man kann alles, was man anpassen will, direkt in die Datei schreiben. Dies hat allerdings den Nachteil, dass die Datei eventuell sehr umfangreich werden kann (siehe Beispiele weiter unten), und man schlicht irgendwann den Überblick verliert.
Man kann alles, was man anpassen will, direkt in die Datei schreiben. Dies hat allerdings den Nachteil, dass die Datei eventuell sehr umfangreich werden kann (siehe Beispiele weiter unten), und man schlicht irgendwann den Überblick verliert.


In der .bashrc“ können praktisch alle Befehle verwendet werden, die man auch in der bash selbst verwenden kann. So kann man natürlich auch Dateien ''sourcen'', sie also abarbeiten, ohne dafür einen eigenen Prozess (eine eigene Shell) zu starten.
In der <code>.bashrc</code> können praktisch alle Befehle verwendet werden, die man auch in der bash selbst verwenden kann. So kann man natürlich auch Dateien ''sourcen'', sie also abarbeiten, ohne dafür einen eigenen Prozess (eine eigene Shell) zu starten.


  source /datei/mit/viel/inhalt
  source /datei/mit/viel/inhalt
Zeile 22: Zeile 22:
So kann man Skripte – zum Beispiel Farbdefinitionen zum einfacheren Verwenden von Farben – auslagern. Vorteil ist natürlich, dass man die Datei selbst klein hält, aber dennoch viel Funktionalität integrieren kann. Zudem kann man die Dateien unabhängig voneinander bearbeiten.
So kann man Skripte – zum Beispiel Farbdefinitionen zum einfacheren Verwenden von Farben – auslagern. Vorteil ist natürlich, dass man die Datei selbst klein hält, aber dennoch viel Funktionalität integrieren kann. Zudem kann man die Dateien unabhängig voneinander bearbeiten.


Nachteil ist allerdings, dass man neben der .bashrc“ noch mehrere Dateien hat, die zur Anpassung der bash verwendet werden.
Nachteil ist allerdings, dass man neben der <code>.bashrc</code> noch mehrere Dateien hat, die zur Anpassung der bash verwendet werden.


=== Zentral definieren ===
=== Zentral definieren ===
Neben den User-Bezogenen Definitionsdateien gibt es unter /etc/profile“ noch eine Definitions-Datei die standardmäßig für alle bash-Instanzen aller Benutzer verwendet wird.
Neben den User-Bezogenen Definitionsdateien gibt es unter <code>/etc/profile</code> noch eine Definitions-Datei die standardmäßig für alle bash-Instanzen aller Benutzer verwendet wird.


In ihr werden grundlegende Dinge definiert. Man sollte hier nur etwas ändern, wenn man weiß, was es bewirkt. Man kann allerdings nach der letzten Zeile der Datei eigene Zeilen einfügen, diese werden dann ebenfalls bei jedem Start einer bash ausgeführt.
In ihr werden grundlegende Dinge definiert. Man sollte hier nur etwas ändern, wenn man weiß, was es bewirkt. Man kann allerdings nach der letzten Zeile der Datei eigene Zeilen einfügen, diese werden dann ebenfalls bei jedem Start einer bash ausgeführt.


Vorteil ist, dass man die Definitionen für verschiedene Nutzer nur ein mal erstellen muss, Nachteil ist allerdings, dass man diese Datei bei einem Backup dann auch berücksichtigen muss, oder sie bei einem Update eventuell überschrieben wird. User-Bezogene Definitionen „überschreiben“ zudem die Definitionen in den systemweiten Konfigurationsdateien.
Vorteil ist, dass man die Definitionen für verschiedene Nutzer nur ein mal erstellen muss, Nachteil ist allerdings, dass man diese Datei bei einem Backup dann auch berücksichtigen muss, oder sie bei einem Update eventuell überschrieben wird. User-Bezogene Definitionen <code>überschreiben</code> zudem die Definitionen in den systemweiten Konfigurationsdateien.


Wenn man den Rechner also alleine nutzt, oder nur wenige Nutzer hat, die das System mit eigenen Profilen nutzen, ist es sinnvoller, die nutzerbezogenen Konfigurationsdateien zu verwenden.
Wenn man den Rechner also alleine nutzt, oder nur wenige Nutzer hat, die das System mit eigenen Profilen nutzen, ist es sinnvoller, die nutzerbezogenen Konfigurationsdateien zu verwenden.


== Gefahren ==
== Gefahren ==
Es gibt drei Dinge, die man niemals und unter gar keinen Umständen in eine .bashrc“ (und nebenbei gesagt auch in keine andere Datei, die automatisch ausgeführt wird) schreiben sollte, wenn man nicht zu 100 Prozent weiß, was man tut, und sich über die Konsequenzen von auftretenden Fehlern – sowie deren Behebung – völlig im Klaren ist.
Es gibt drei Dinge, die man niemals und unter gar keinen Umständen in eine <code>.bashrc</code> (und nebenbei gesagt auch in keine andere Datei, die automatisch ausgeführt wird) schreiben sollte, wenn man nicht zu 100 Prozent weiß, was man tut, und sich über die Konsequenzen von auftretenden Fehlern – sowie deren Behebung – völlig im Klaren ist.


* exit
* exit
Zeile 42: Zeile 42:
Da die Datei bei jedem bash-Start automatisch ausgeführt wird, würden diese Befehle dafür sorgen, dass man umgehend wieder ausgeloggt wird, bzw. dass die bash in Rekursion immer und immer wieder gestartet wird.
Da die Datei bei jedem bash-Start automatisch ausgeführt wird, würden diese Befehle dafür sorgen, dass man umgehend wieder ausgeloggt wird, bzw. dass die bash in Rekursion immer und immer wieder gestartet wird.


Um den Startvorgang der bash kurz zu halten, sollte man darauf achten, rechen- und zeitintensive Prozess-Starts aus der .bashrc“ herauszuhalten. Es sollten nur einfache Befehle und Programmstarts verwendet werden. Dies spielt bei Hintergrundprozessen jedoch keine all zu große Rolle.
Um den Startvorgang der bash kurz zu halten, sollte man darauf achten, rechen- und zeitintensive Prozess-Starts aus der <code>.bashrc</code> herauszuhalten. Es sollten nur einfache Befehle und Programmstarts verwendet werden. Dies spielt bei Hintergrundprozessen jedoch keine all zu große Rolle.


== Beispiele ==
== Beispiele ==
Neben den im Artikel [[bash]] beschrieben Funktionalitäten kann man in der .bashrc“ noch weitere Dinge anpassen, eine Übersicht darüber bietet dieser Abschnitt.
Neben den im Artikel [[bash]] beschrieben Funktionalitäten kann man in der <code>.bashrc</code> noch weitere Dinge anpassen, eine Übersicht darüber bietet dieser Abschnitt.


=== Prompt anpassen ===
=== Prompt anpassen ===
Das Prompt gliedert sich in vier Teile, PS1 bis PS4. Jeder dieser Teile wird zu einem bestimmten Zeitpunkt verwendet. Der Standard-Teil ist PS1, er definiert das Eingabeprompt. Standardmäßig wird das Eingabepromt von Arch Linux als [user@host ~]$ dargestellt. und wie folgt definiert:
Das Prompt gliedert sich in vier Teile, PS1 bis PS4. Jeder dieser Teile wird zu einem bestimmten Zeitpunkt verwendet. Der Standard-Teil ist PS1, er definiert das Eingabeprompt. Standardmäßig wird das Eingabepromt von Arch Linux als <code>[user@host ~]$ </code> dargestellt. und wie folgt definiert:


  PS1='[\u@\h \W]\$ '
  PS1='[\u@\h \W]\$ '


Möchte man dieses Prompt jetzt anpassen, und zum Beispiel in ein extrem kurzes $verwandeln, schreibt man in die .bashrc“ einfach eine neue Definition. Die Original-Definition wird damit überschrieben.
Möchte man dieses Prompt jetzt anpassen, und zum Beispiel in ein extrem kurzes <code>$</code> verwandeln, schreibt man in die <code>.bashrc</code> einfach eine neue Definition. Die Original-Definition wird damit überschrieben.


  PS1='$'
  PS1='$'
Zeile 59: Zeile 59:


=== Programme starten ===
=== Programme starten ===
Man kann in der .bashrc“ auch Programmstarts definieren. Man sollte hier aber aufpassen, da das Abarbeiten der .bashrc so lange angehalten wird, wie sich das Programm im Vordergrund befindet. Man muss also die Programme so starten, dass sie in den Hintergrund gebracht werden.
Man kann in der <code>.bashrc</code> auch Programmstarts definieren. Man sollte hier aber aufpassen, da das Abarbeiten der .bashrc so lange angehalten wird, wie sich das Programm im Vordergrund befindet. Man muss also die Programme so starten, dass sie in den Hintergrund gebracht werden.


  # Startet bei jedem bash-Start Thunderbird
  # Startet bei jedem bash-Start Thunderbird
Zeile 66: Zeile 66:
  thunderbird &
  thunderbird &


Dies funktioniert allerdings nicht immer, zumal man mit dem Autostart von Programmen ja bewirken möchte, dass man das Programm sofort benutzen kann. Man sollte den Programmaufruf eines Vordergrundprogramms also immer ans Ende der .bashrc“ legen. Zwar wird die Abarbeitung der Datei nach Beendigung des Programms fortgesetzt, wenn man aber innerhalb des Programms auf Dinge zugreifen will, die erst nach dem Programmaufruf in der .bashrc“ definiert werden, schlägt dies fehl.
Dies funktioniert allerdings nicht immer, zumal man mit dem Autostart von Programmen ja bewirken möchte, dass man das Programm sofort benutzen kann. Man sollte den Programmaufruf eines Vordergrundprogramms also immer ans Ende der <code>.bashrc</code> legen. Zwar wird die Abarbeitung der Datei nach Beendigung des Programms fortgesetzt, wenn man aber innerhalb des Programms auf Dinge zugreifen will, die erst nach dem Programmaufruf in der <code>.bashrc</code> definiert werden, schlägt dies fehl.


Es ist zu beachten, dass die Programme, die gestartet werden sollen, entweder selbst überprüfen, ob es eine grafische Anzeige gibt, oder aber, dass die Programme keine grafische Anzeige benötigen, da es sonst eine Fehlermeldung gibt, wenn man den Programmstart nicht selbst durch if-Abfragen abfängt.
Es ist zu beachten, dass die Programme, die gestartet werden sollen, entweder selbst überprüfen, ob es eine grafische Anzeige gibt, oder aber, dass die Programme keine grafische Anzeige benötigen, da es sonst eine Fehlermeldung gibt, wenn man den Programmstart nicht selbst durch if-Abfragen abfängt.


=== Funktionen und Aliase ===
=== Funktionen und Aliase ===
Funktionen und Aliase erweitern das Repertoire der vom System bereitgestellten Befehle um eigene Befehle. Wenn man nicht weiß, ob es sich um ein Alias oder ein Programm handelt, verwendet man „type“.
Funktionen und Aliase erweitern das Repertoire der vom System bereitgestellten Befehle um eigene Befehle. Wenn man nicht weiß, ob es sich um ein Alias oder ein Programm handelt, verwendet man <code>type</code>.


Aliase sind nach einem „unalias“ so lange nicht mehr verfügbar, bis man sie neu definiert. Im Falle der .bashrc“ entweder durch das Sourcen dieser, oder durch ein erneutes Einloggen. Will man Aliase dauerhaft wieder entfernen, löscht man die Definition in der .bashrc“ wieder.
Aliase sind nach einem <code>unalias</code> so lange nicht mehr verfügbar, bis man sie neu definiert. Im Falle der <code>.bashrc</code> entweder durch das Sourcen dieser, oder durch ein erneutes Einloggen. Will man Aliase dauerhaft wieder entfernen, löscht man die Definition in der <code>.bashrc</code> wieder.


Funktionen verhalten sich diesbezüglich genau so. Sie überschreiben gleichlautende Befehle, und sind so lange gültig, bis man sie mittels „unset -f“ entfernt.
Funktionen verhalten sich diesbezüglich genau so. Sie überschreiben gleichlautende Befehle, und sind so lange gültig, bis man sie mittels <code>unset -f</code> entfernt.


Funktionen und Aliase überschreiben sich hingegen gegenseitig. Je nachdem, was zuletzt definiert wurde, ist entweder die Funktion, oder der Alias gültig. Was ein Befehl ist, kann mittels „type“ erfragt werden.
Funktionen und Aliase überschreiben sich hingegen gegenseitig. Je nachdem, was zuletzt definiert wurde, ist entweder die Funktion, oder der Alias gültig. Was ein Befehl ist, kann mittels <code>type</code> erfragt werden.


==== Aliase definieren ====
==== Aliase definieren ====
Zeile 86: Zeile 86:
  tar -pczf archiv.tar.gz /was/zu/packen/ist
  tar -pczf archiv.tar.gz /was/zu/packen/ist


Man muss also jedes mal „tar -pczf“ tippen. Auf Dauer wird dies einiges an Zeit kosten. Wenn man sich dafür zum Beispiel einen Alias „tgz“ anlegt, reicht es, statt „tar -pczf“ einfach „tgz“ zu verwenden.
Man muss also jedes mal <code>tar -pczf</code> tippen. Auf Dauer wird dies einiges an Zeit kosten. Wenn man sich dafür zum Beispiel einen Alias <code>tgz</code> anlegt, reicht es, statt <code>tar -pczf</code> einfach <code>tgz</code> zu verwenden.


  alias tgz='tar -pczf'
  alias tgz='tar -pczf'


Dieser Alias ist ab dem Speichern der .bashrc“ in allen ab diesem Zeitpunkt gestarteten standardmäßigen bash-Prozessen verfügbar. Will man mittels „ls“ zum Beispiel immer die Verzeichnisse zuerst angezeigt bekommen, definiert man sich einen entsprechenden Alias in der .bashrc“.
Dieser Alias ist ab dem Speichern der <code>.bashrc</code> in allen ab diesem Zeitpunkt gestarteten standardmäßigen bash-Prozessen verfügbar. Will man mittels <code>ls</code> zum Beispiel immer die Verzeichnisse zuerst angezeigt bekommen, definiert man sich einen entsprechenden Alias in der <code>.bashrc</code>.


  alias ls='ls --group-directories-first'
  alias ls='ls --group-directories-first'


Wenn man nun „ls“ eingibt, verwendet man automatisch den in der Datei definierten Alias für „ls“, der wiederum das Programm „ls“ mit einem Parameter startet.
Wenn man nun <code>ls</code> eingibt, verwendet man automatisch den in der Datei definierten Alias für <code>ls</code>, der wiederum das Programm <code>ls</code> mit einem Parameter startet.


==== Funktionen ====
==== Funktionen ====
Anders als Aliase sind Funktionen nicht bloß einfache Textersetzungen, sondern können auch Parameter entgegennehmen und verarbeiten. Innerhalb einer Funktion können beliebige, von der bash verarbeitbaren Befehle verwendet werden.
Anders als Aliase sind Funktionen nicht bloß einfache Textersetzungen, sondern können auch Parameter entgegennehmen und verarbeiten. Innerhalb einer Funktion können beliebige, von der bash verarbeitbaren Befehle verwendet werden.


Mittels „cd“ wechselt man in Verzeichnisse, und mittels mkdir erstellt man sie. Wenn man nun häufig neue Verzeichnisse erstellt, könnte man das erstellen eines Verzeichnisses und das Wechseln in eben dieses mittels einer Funktionsdefinition in der .bashrc“ erledigen.
Mittels <code>cd</code> wechselt man in Verzeichnisse, und mittels mkdir erstellt man sie. Wenn man nun häufig neue Verzeichnisse erstellt, könnte man das erstellen eines Verzeichnisses und das Wechseln in eben dieses mittels einer Funktionsdefinition in der <code>.bashrc</code> erledigen.


  function mkcd () {
  function mkcd () {
Zeile 106: Zeile 106:
  }
  }


Wenn man nun „mkcd /verzeichnis/das/erzeugt/werden/soll“ eingibt, wird dieses Verzeichnis, inklusive Eltern-Verzeichnissen erzeugt, und in dieses dann auch gleich hineingewechselt.
Wenn man nun <code>mkcd /verzeichnis/das/erzeugt/werden/soll</code> eingibt, wird dieses Verzeichnis, inklusive Eltern-Verzeichnissen erzeugt, und in dieses dann auch gleich hineingewechselt.


=== Exports ===
=== Exports ===
Wenn man in der .bashrc“ eine Variable definiert, dann ist diese Variable in der aufgerufenen bash gültig. Programme, die man startet, können ohne weiteres nicht auf diese Variable zugreifen. Wenn man die Variable hingegen exportiert, ist sie auch den Programmen, die aufgerufen werden, zur Verwendung bereitgestellt.
Wenn man in der <code>.bashrc</code> eine Variable definiert, dann ist diese Variable in der aufgerufenen bash gültig. Programme, die man startet, können ohne weiteres nicht auf diese Variable zugreifen. Wenn man die Variable hingegen exportiert, ist sie auch den Programmen, die aufgerufen werden, zur Verwendung bereitgestellt.


  $ var="Variable 1"
  $ var="Variable 1"
Zeile 119: Zeile 119:
  $  
  $  


Zuerst wird die Variable $var“ definiert. Es wird die Variable dann in einer neuen Bash, die als Kindprozess läuft referenziert (Zur Syntax siehe [[bash|Wiki-Artikel zur bash]]). Da die Variable in dieser bash allerdings nicht gesetzt wurde, wird nur eine leere Zeile zurückgegeben, eben das „echo“. Dann wird die Variable exportiert, und der Vorgang nun wiederholt. Diesmal wird die Variable ausgegeben.
Zuerst wird die Variable <code>$var</code> definiert. Es wird die Variable dann in einer neuen Bash, die als Kindprozess läuft referenziert (Zur Syntax siehe [[bash|Wiki-Artikel zur bash]]). Da die Variable in dieser bash allerdings nicht gesetzt wurde, wird nur eine leere Zeile zurückgegeben, eben das <code>echo</code>. Dann wird die Variable exportiert, und der Vorgang nun wiederholt. Diesmal wird die Variable ausgegeben.


Alle Variablen, die anderen Programmen, als der bash, in der man sich gerade befindet, nach deren Start zur Verfügung stehen sollen, müssen exportiert werden.
Alle Variablen, die anderen Programmen, als der bash, in der man sich gerade befindet, nach deren Start zur Verfügung stehen sollen, müssen exportiert werden.

Version vom 4. Oktober 2012, 21:14 Uhr

Der richtige Titel für diesen Artikel lautet .bashrc. Dies ist aus technischen Gründen derzeit jedoch nicht möglich.


Die bash ist unter Arch Linux die Standard-Shell. Mittels der Datei .bashrc kann man sich die bash konfigurieren und anpassen. Prinzipiell geht dies auch mit der .bash_profile und weiteren Dateien. In diesem Artikel wird allerdings nur auf die .bashrc eingegangen, was auch völlig ausreicht.

Voraussetzungen

Unter gewissen Voraussetzungen kann es vorkommen, dass die .bashrc nicht verarbeitet wird. Dies kann daran liegen, dass anstelle der .bashrc die .bash_profile automatisch ausgeführt wird. Nun hat man zwei Möglichkeiten: Entweder, man schreibt die Dinge in die .bash_profile, oder man schreibt in die .bash_profile, dass die .bashrc ausgeführt werden soll.

source .bashrc

Dies hat den Vorteil, dass man alles über die .bashrc machen kann. Diese Datei wird wesentlich häufiger erwähnt, und man muss sich beim Konfigurieren nicht erst Gedanken darüber machen, ob und wo man etwas reinschreiben muss, da .bash_profile auf einem so konfigurierten System ja nichts weiter macht, als .bashrc zu starten.

Man kann auch einen Link anlegen, wovon aber abzuraten ist. Falls man doch irgendwann mal die .bashrc und die .bash_profile mit unterschiedlichen Inhalten füllen möchte, muss man nämlich erst wieder den Link entfernen und die Datei neu anlegen. Mit der Ausführungsanweisung erspart man sich im vorherein unnötige Arbeit.

Vorüberlegungen

Aufteilen

Man kann alles, was man anpassen will, direkt in die Datei schreiben. Dies hat allerdings den Nachteil, dass die Datei eventuell sehr umfangreich werden kann (siehe Beispiele weiter unten), und man schlicht irgendwann den Überblick verliert.

In der .bashrc können praktisch alle Befehle verwendet werden, die man auch in der bash selbst verwenden kann. So kann man natürlich auch Dateien sourcen, sie also abarbeiten, ohne dafür einen eigenen Prozess (eine eigene Shell) zu starten.

source /datei/mit/viel/inhalt

So kann man Skripte – zum Beispiel Farbdefinitionen zum einfacheren Verwenden von Farben – auslagern. Vorteil ist natürlich, dass man die Datei selbst klein hält, aber dennoch viel Funktionalität integrieren kann. Zudem kann man die Dateien unabhängig voneinander bearbeiten.

Nachteil ist allerdings, dass man neben der .bashrc noch mehrere Dateien hat, die zur Anpassung der bash verwendet werden.

Zentral definieren

Neben den User-Bezogenen Definitionsdateien gibt es unter /etc/profile noch eine Definitions-Datei die standardmäßig für alle bash-Instanzen aller Benutzer verwendet wird.

In ihr werden grundlegende Dinge definiert. Man sollte hier nur etwas ändern, wenn man weiß, was es bewirkt. Man kann allerdings nach der letzten Zeile der Datei eigene Zeilen einfügen, diese werden dann ebenfalls bei jedem Start einer bash ausgeführt.

Vorteil ist, dass man die Definitionen für verschiedene Nutzer nur ein mal erstellen muss, Nachteil ist allerdings, dass man diese Datei bei einem Backup dann auch berücksichtigen muss, oder sie bei einem Update eventuell überschrieben wird. User-Bezogene Definitionen überschreiben zudem die Definitionen in den systemweiten Konfigurationsdateien.

Wenn man den Rechner also alleine nutzt, oder nur wenige Nutzer hat, die das System mit eigenen Profilen nutzen, ist es sinnvoller, die nutzerbezogenen Konfigurationsdateien zu verwenden.

Gefahren

Es gibt drei Dinge, die man niemals und unter gar keinen Umständen in eine .bashrc (und nebenbei gesagt auch in keine andere Datei, die automatisch ausgeführt wird) schreiben sollte, wenn man nicht zu 100 Prozent weiß, was man tut, und sich über die Konsequenzen von auftretenden Fehlern – sowie deren Behebung – völlig im Klaren ist.

  • exit
  • logout
  • bash

Da die Datei bei jedem bash-Start automatisch ausgeführt wird, würden diese Befehle dafür sorgen, dass man umgehend wieder ausgeloggt wird, bzw. dass die bash in Rekursion immer und immer wieder gestartet wird.

Um den Startvorgang der bash kurz zu halten, sollte man darauf achten, rechen- und zeitintensive Prozess-Starts aus der .bashrc herauszuhalten. Es sollten nur einfache Befehle und Programmstarts verwendet werden. Dies spielt bei Hintergrundprozessen jedoch keine all zu große Rolle.

Beispiele

Neben den im Artikel bash beschrieben Funktionalitäten kann man in der .bashrc noch weitere Dinge anpassen, eine Übersicht darüber bietet dieser Abschnitt.

Prompt anpassen

Das Prompt gliedert sich in vier Teile, PS1 bis PS4. Jeder dieser Teile wird zu einem bestimmten Zeitpunkt verwendet. Der Standard-Teil ist PS1, er definiert das Eingabeprompt. Standardmäßig wird das Eingabepromt von Arch Linux als [user@host ~]$ dargestellt. und wie folgt definiert:

PS1='[\u@\h \W]\$ '

Möchte man dieses Prompt jetzt anpassen, und zum Beispiel in ein extrem kurzes $ verwandeln, schreibt man in die .bashrc einfach eine neue Definition. Die Original-Definition wird damit überschrieben.

PS1='$'

Natürlich ist dies nur ein vereinfachtes Beispiel. Weitere, sehr ausführliche Informationen, mit praxisnahen Beispielen bietet der Artikel Bash-Prompt anpassen hier im Wiki.

Programme starten

Man kann in der .bashrc auch Programmstarts definieren. Man sollte hier aber aufpassen, da das Abarbeiten der .bashrc so lange angehalten wird, wie sich das Programm im Vordergrund befindet. Man muss also die Programme so starten, dass sie in den Hintergrund gebracht werden.

# Startet bei jedem bash-Start Thunderbird
# als Hintergrundprozess …

thunderbird &

Dies funktioniert allerdings nicht immer, zumal man mit dem Autostart von Programmen ja bewirken möchte, dass man das Programm sofort benutzen kann. Man sollte den Programmaufruf eines Vordergrundprogramms also immer ans Ende der .bashrc legen. Zwar wird die Abarbeitung der Datei nach Beendigung des Programms fortgesetzt, wenn man aber innerhalb des Programms auf Dinge zugreifen will, die erst nach dem Programmaufruf in der .bashrc definiert werden, schlägt dies fehl.

Es ist zu beachten, dass die Programme, die gestartet werden sollen, entweder selbst überprüfen, ob es eine grafische Anzeige gibt, oder aber, dass die Programme keine grafische Anzeige benötigen, da es sonst eine Fehlermeldung gibt, wenn man den Programmstart nicht selbst durch if-Abfragen abfängt.

Funktionen und Aliase

Funktionen und Aliase erweitern das Repertoire der vom System bereitgestellten Befehle um eigene Befehle. Wenn man nicht weiß, ob es sich um ein Alias oder ein Programm handelt, verwendet man type.

Aliase sind nach einem unalias so lange nicht mehr verfügbar, bis man sie neu definiert. Im Falle der .bashrc entweder durch das Sourcen dieser, oder durch ein erneutes Einloggen. Will man Aliase dauerhaft wieder entfernen, löscht man die Definition in der .bashrc wieder.

Funktionen verhalten sich diesbezüglich genau so. Sie überschreiben gleichlautende Befehle, und sind so lange gültig, bis man sie mittels unset -f entfernt.

Funktionen und Aliase überschreiben sich hingegen gegenseitig. Je nachdem, was zuletzt definiert wurde, ist entweder die Funktion, oder der Alias gültig. Was ein Befehl ist, kann mittels type erfragt werden.

Aliase definieren

Wenn man häufig Programme mit immer gleichbleibenden Parametern ausführt, diese Programme aber keine Möglichkeit bieten, diesbezüglich schnell und einfach nutzerbezogen Einstellungen zu verwenden, kann man sich Aliase anlegen. Aliase sind nichts weiter als eine simple Ersetzung von Text, den man eingibt.

Wenn man beispielsweise häufig Dateien als tar.gz packt, wird man eventuell diesen Befehl verwenden:

tar -pczf archiv.tar.gz /was/zu/packen/ist

Man muss also jedes mal tar -pczf tippen. Auf Dauer wird dies einiges an Zeit kosten. Wenn man sich dafür zum Beispiel einen Alias tgz anlegt, reicht es, statt tar -pczf einfach tgz zu verwenden.

alias tgz='tar -pczf'

Dieser Alias ist ab dem Speichern der .bashrc in allen ab diesem Zeitpunkt gestarteten standardmäßigen bash-Prozessen verfügbar. Will man mittels ls zum Beispiel immer die Verzeichnisse zuerst angezeigt bekommen, definiert man sich einen entsprechenden Alias in der .bashrc.

alias ls='ls --group-directories-first'

Wenn man nun ls eingibt, verwendet man automatisch den in der Datei definierten Alias für ls, der wiederum das Programm ls mit einem Parameter startet.

Funktionen

Anders als Aliase sind Funktionen nicht bloß einfache Textersetzungen, sondern können auch Parameter entgegennehmen und verarbeiten. Innerhalb einer Funktion können beliebige, von der bash verarbeitbaren Befehle verwendet werden.

Mittels cd wechselt man in Verzeichnisse, und mittels mkdir erstellt man sie. Wenn man nun häufig neue Verzeichnisse erstellt, könnte man das erstellen eines Verzeichnisses und das Wechseln in eben dieses mittels einer Funktionsdefinition in der .bashrc erledigen.

function mkcd () {
  mkdir -p "$1"
  cd "$1"
}

Wenn man nun mkcd /verzeichnis/das/erzeugt/werden/soll eingibt, wird dieses Verzeichnis, inklusive Eltern-Verzeichnissen erzeugt, und in dieses dann auch gleich hineingewechselt.

Exports

Wenn man in der .bashrc eine Variable definiert, dann ist diese Variable in der aufgerufenen bash gültig. Programme, die man startet, können ohne weiteres nicht auf diese Variable zugreifen. Wenn man die Variable hingegen exportiert, ist sie auch den Programmen, die aufgerufen werden, zur Verwendung bereitgestellt.

$ var="Variable 1"
$ bash -c 'echo $var'

$ export var="Variable 1"
$ bash -c 'echo $var'
Variable 1
$ 

Zuerst wird die Variable $var definiert. Es wird die Variable dann in einer neuen Bash, die als Kindprozess läuft referenziert (Zur Syntax siehe Wiki-Artikel zur bash). Da die Variable in dieser bash allerdings nicht gesetzt wurde, wird nur eine leere Zeile zurückgegeben, eben das echo. Dann wird die Variable exportiert, und der Vorgang nun wiederholt. Diesmal wird die Variable ausgegeben.

Alle Variablen, die anderen Programmen, als der bash, in der man sich gerade befindet, nach deren Start zur Verfügung stehen sollen, müssen exportiert werden.

Beispiele

Nachfolgend zwei Beispiele. Ein Beispiel ist relativ einfach gehalten, das andere Beispiel baut vor allem darauf auf, andere Dateien zu integrieren und nimmt komplexere Änderungen vor.

Eine Datei

alias ls='ls --group-directories-first'
alias cp='cp -aiv'
alias grep='grep --color=always'
alias tgz='tar -pczf'

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

export OOO_FORCE_DESKTOP=gnome

function psgrep () {
  ps aux | grep "$1" | grep -v "grep"
}

function mkcd () {
  mkdir -p "$1"
  cd "$1"
}

Mehrere Dateien

.bashrc

if [ "$(tty)" = "/dev/tty1" ]; then
  startx -- -nolisten tcp
  logout
fi

source .bashrc_contents/aliases
source .bashrc_contents/functions
source .bashrc_contents/colors
source .bashrc_contents/lscolors
source .bashrc_contents/variables

.bashrc_contents/aliases

alias pdf='epdfview'
alias z='gqview'
alias myip="wget -q -O - http://www.example.com/meineip.php"

alias ls='ls -vph --color=auto --group-directories-first --time-style="+%F, %T  "'
alias cp='cp -aiv'
alias grep='grep --color=always'

alias tgz='tar -pczf'
alias wg='weatherget -m -s GMXX0049'

.bashrc_contents/functions

function psgrep () {
  ps aux | grep "$1" | grep -v "grep"
}

function mkcd () {
  mkdir -p "$1"
  cd "$1"
}

.bashrc_contents/colors

red='\[\e[0;31m\]'
RED='\[\e[1;31m\]'
blue='\[\e[0;34m\]'
BLUE='\[\e[1;34m\]'
cyan='\[\e[0;36m\]'
CYAN='\[\e[1;36m\]'
NC='\[\033[0m\]'      # no color
black='\[\e[0;30m\]'
BLACK='\[\e[1;30m\]'
green='\[\e[0;32m\]'
GREEN='\[\e[1;32m\]'
yellow='\[\e[0;33m\]'
YELLOW='\[\e[1;33m\]'
magenta='\[\e[0;35m\]'
MAGENTA='\[\e[1;35m\]'
white='\[\e[0;37m\]'
WHITE='\[\e[1;37m\]'

.bashrc_contents/lscolors

# ACHTUNG! Die Umbrüche hier sind nur aus designtechnischen Gründen
# für das Wiki eingefügt worden und müssen beim Übernehmen wieder
# Entfernt werden!

LS_COLORS='no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:
or=40;31;01:su=37;41:sg=30;43:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:
*.svgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:
*.dz=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:
*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:
*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:
*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01; 35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:
*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:
*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:
*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.aac=00;36:
*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:
*.ra=00;36:*.wav=00;36:'

export LS_COLORS

.bashrc_contents/variables

PS1="$GREEN\u@\h$NC:$BLUE\w$NC$ "

setterm -blength 0

export OOO_FORCE_DESKTOP=gnome soffice

Siehe auch

Weblinks