it-swarm.com.de

Warum gibt Ubuntu standardmäßig ~ / .profile ~ / .bashrc aus?

Dies sind die Inhalte des Bestands ~/.profile, der mit meinem 13.10 geliefert wurde (kommentierte Zeilen entfernt):

if [ -n "$BASH_VERSION" ]; then
    if [ -f "$HOME/.bashrc" ]; then
    . "$HOME/.bashrc"
    fi
fi

if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

Dies ist von Debian geerbt, aber warum hat Canonical beschlossen, es beizubehalten? Soweit ich weiß, ist dies nicht der Standard * nix-Weg, und ich habe verschiedene Systeme gesehen, bei denen dies nicht der Fall war. Ich gehe daher davon aus, dass sie einen guten Grund dafür hatten. Dies kann zu unerwartetem Verhalten führen, wenn Anmelde-Shells ausgeführt werden (z. B. beim Einlesen in den Computer), bei denen der Benutzer nicht erwartet hätte, dass ~/.bashrc bereitgestellt wird.

Der einzige Vorteil, den ich mir vorstellen kann, besteht darin, den Benutzer nicht mit vielen Startdateien zu verwechseln und ihnen zu erlauben, .bashrc allein zu bearbeiten und diese unabhängig vom Shell-Typ lesen zu lassen. Dies ist jedoch ein zweifelhafter Vorteil, da es oft nützlich ist, unterschiedliche Einstellungen für die Anmeldung und für interaktive Shells zu haben, was Sie daran hindert. Außerdem werden Anmelde-Shells häufig nicht in einer grafischen Umgebung ausgeführt. Dies kann je nach den Einstellungen in diesen Dateien zu Fehlern, Warnungen und Problemen führen.

Warum macht Ubuntu das? Was vermisse ich?

30
terdon

Dies ist eine vorgelagerte Entscheidung von Debian. Das Grundprinzip dafür wird in diesem sehr netten Wiki-Beitrag erklärt, von dem das Folgende ein Auszug ist. Die Zusammenfassung lautet "um sicherzustellen, dass GUI- und Nicht-GUI-Anmeldungen auf die gleiche Weise funktionieren":

Nehmen wir als Beispiel xdm. Pierre kommt eines Tages aus dem Urlaub zurück und stellt fest, dass sein Systemadministrator xdm auf dem Debian-System installiert hat. Er meldet sich gut an, und xdm liest seine .xsession-Datei und führt fluxbox aus. Alles scheint in Ordnung zu sein, bis er eine Fehlermeldung im falschen Gebietsschema erhält! Da er die LANG-Variable in seinem .bash_profile überschreibt und xdm niemals .bash_profile liest, wird seine LANG-Variable jetzt auf en_US anstelle von fr_CA gesetzt.

Die naive Lösung für dieses Problem besteht nun darin, dass er seinen Fenstermanager so konfigurieren kann, dass er "xterm -ls" startet, anstatt "xterm" zu starten. Dieses Flag teilt xterm mit, dass anstelle einer normalen Shell eine Login-Shell gestartet werden soll. Unter diesem Setup erzeugt xterm/bin/bash, fügt aber "-/bin/bash" (oder vielleicht "-bash") in den Argumentvektor ein, sodass bash wie eine Login-Shell funktioniert. Dies bedeutet, dass jedes Mal, wenn er ein neues xterm öffnet,/etc/profile und .bash_profile (integriertes Bash-Verhalten) und dann .bashrc (weil .bash_profile dies verlangt) gelesen werden. Dies scheint zunächst in Ordnung zu sein - seine Punktedateien sind nicht schwer, sodass er die Verzögerung nicht einmal bemerkt -, aber es gibt ein subtileres Problem. Er startet auch einen Webbrowser direkt aus seinem Fluxbox-Menü, und der Webbrowser erbt die LANG-Variable von Fluxbox, die jetzt auf das falsche Gebietsschema eingestellt ist. Obwohl seine xterms in Ordnung sind und alles, was von seinen xterms aus gestartet wird, in Ordnung ist, zeigt ihm sein Webbrowser immer noch Seiten in der falschen Ländereinstellung an.

Also, was ist die beste Lösung für dieses Problem? Es gibt wirklich keinen universellen. Ein besserer Ansatz ist, die .xsession-Datei so zu ändern, dass sie ungefähr so ​​aussieht:

[ -r /etc/profile ] && source /etc/profile
[ -r ~/.bash_profile ] && source ~/.bash_profile
xmodmap -e 'keysym Super_R = Multi_key'
xterm &
exec fluxbox

Dies bewirkt, dass die Shell, die das .xsession-Skript interpretiert,/etc/profile und .bash_profile einliest, sofern diese vorhanden und lesbar sind, bevor xmodmap oder xterm ausgeführt oder der Fenstermanager "ausgeführt" wird. Dieser Ansatz hat jedoch einen potenziellen Nachteil: Unter xdm wird die Shell, die .xsession liest, ohne ein steuerndes Terminal ausgeführt. Wenn entweder/etc/profile oder .bash_profile Befehle verwendet, die das Vorhandensein eines Terminals voraussetzen (z. B. "fortune" oder "stty"), schlagen diese Befehle möglicherweise fehl. Dies ist der Hauptgrund, warum xdm diese Dateien standardmäßig nicht liest. Wenn Sie diesen Ansatz verwenden möchten, müssen Sie sicherstellen, dass alle Befehle in Ihren "Punktedateien" sicher ausgeführt werden können, wenn kein Terminal vorhanden ist.

15
terdon

Dies ist Ubuntus Standardverhalten. ~/.bashrc ist eine Startdatei für die interaktive Shell auf Benutzerebene. Wenn Sie ein Terminal öffnen, starten Sie im Grunde genommen eine nicht angemeldete, interaktive Shell , die ~/.bashrc und den Inhalt von ~/.bashrc liest und in Ihre aktuelle Shell-Umgebung exportiert. Es hilft einem, alle seine benutzerdefinierten Shell-Variablen und Funktionen in zu erhalten die aktuelle Shell. Auch Sie könnten Linien wie diese finden

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

um benutzerdefinierte Aliase in der aktuellen Shell-Umgebung zu erhalten.

Dies ist wichtig, um auch eine gute Benutzererfahrung zu gewährleisten. Beispielsweise könnte man Proxy-Berechtigungsnachweise in .bashrc speichern, es sei denn, es werden keine Terminalanwendungen ( bezogen, nämlich , ping, wget, curl, lynx usw.) wird ordnungsgemäß funktionieren. Oder Sie müssen die Proxy-Anmeldeinformationen jedes Mal angeben, wenn Sie ein Terminal öffnen.

Neben Ubuntus Standard-.bashrc enthält es viele benutzerfreundliche Aliase (für ls und grep, um farbige Ausgaben zu drucken), viele neue Definitionen für verschiedene Shell-Variablen, die die Benutzererfahrung verbessern.

Aber im Falle Ihres SSH-Login oder Login in der virtuellen Konsole , Sie erhalten grundsätzlich eine interaktive Login-Shell. Dort ist die Shell-Initiierungsdatei ~/.profile. Wenn Sie also nicht ~/.bashrc als Quelle angeben, verpassen Sie all diese hilfreichen Einstellungen in Ihrem .bashrc. Das ist, warum Ubuntu standardmäßig ~/.profile Quelle ~/.bashrc

Zu vermeidender Fall

  • sie sollten das Formular ~/.profile niemals in ~/.bashrc zur selben Zeit eingeben, wenn ~/.bashrc aus ~/.profile bezogen wird. Es wird eine Endlosschleife der Situation erstellen und als Ergebnis wird Ihre Terminal-Eingabeaufforderung angehalten, es sei denn, Sie treffen Ctrl+C. In einer solchen Situation, wenn Sie in Ihrem ~/.bashrc eine Zeile einfügen
setze -x

Dann konnte man sehen, dass der Dateideskriptor stoppt, wenn Sie ein Terminal öffnen.

2
souravc