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


30

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 zu behalten? Soweit ich weiß, ist dies nicht die Standardmethode von * nix und ich habe verschiedene Systeme gesehen, bei denen dies nicht der Fall war. Daher gehe ich 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), von denen der Benutzer nicht erwartet hätte, dass sie ~/.bashrcstammen.

Der einzige Vorteil, den ich mir vorstellen kann, ist, dass der Benutzer nicht mit vielen Startdateien verwechselt wird und diese .bashrcunabhängig vom Shell-Typ alleine bearbeitet und gelesen werden können. 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 (oh mein Gott!).

Warum macht Ubuntu das? Was vermisse ich?


Warum -n "$BASH_VERSION"sollte es außerhalb von Bash wahr sein?
Elliott Frisch

@ElliottFrisch wird es nicht sein. Meine Frage ist, warum es .profileSource gibt .bashrc, das ist nicht in allen Linux-Versionen der Fall und ich frage mich, was die Gründe dafür sind.
Terdon

Scheint so in debian upstream implementiert zu sein .
Elliott Frisch

@ElliottFrisch ja, ich dachte es wäre nicht und schaute es nach und sah es war pünktlich um meinen Kommentar zu bearbeiten. Trotzdem ist es nicht der Fall auf einem SuSe-System, auf das ich Zugriff habe (obwohl es auf einem CentOS-System ist), und es war nicht der Fall auf verschiedenen Systemen (RHs, Fedoras, älterer Ubuntus), soweit ich mich erinnere. Also frage ich mich warum.
Terdon

Antworten:


15

Dies ist eine vorgelagerte Entscheidung von Debian. Die Gründe dafür werden in diesem sehr schönen Wiki-Beitrag erläutert , von dem der 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 jedoch "- / 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. Es gibt jedoch einen möglichen Nachteil bei diesem Ansatz: 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.


Ich denke immer noch, dass es keine gute Idee ist. Am besten stellen Sie sicher, dass der Anzeigemanager ein globales Profil (check) und die Benutzer-Shell .profile erzeugt. Jetzt weiß ich, warum ich Pfade in einigen Variablen dupliziert habe ...
Rmano

2

Dies ist Ubuntus Standardverhalten. Es handelt sich um eine ~/.bashrcStartdatei für jede interaktive Shell auf Benutzerebene. Wenn Sie ein Terminal öffnen, starten Sie im Grunde genommen eine nicht angemeldete, interaktive Shell, die liest ~/.bashrcund den Inhalt von ~/.bashrcbezieht und in Ihre aktuelle Shell-Umgebung exportiert. Es hilft einem, alle seine benutzerdefinierten Shell-Variablen und -Funktionen in der aktuellen Shell abzurufen. 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. Zum Beispiel einer Proxy - Berechtigungsnachweis in speichern könnte .bashrc, es sei denn , es keine von Terminal - Anwendungen stammt erhalten ( nämlich , ping, wget, curl, lynxetc.) richtig funktionieren. Oder Sie müssen die Proxy-Anmeldeinformationen jedes Mal angeben, wenn Sie ein Terminal öffnen.

Abgesehen davon, dass Ubuntus Standard .bashrcviele benutzerfreundliche Aliase (für lsund grepzum Drucken von farbigen Ausgaben) enthält, gibt es viele neue Definitionen für verschiedene Shell-Variablen, die die Benutzererfahrung verbessern.

Im Falle Ihres SSH-Logins oder eines Logins in der virtuellen Konsole erhalten Sie jedoch im Grunde genommen eine interaktive Login-Shell. Dort befindet sich die Shell-Initiierungsdatei ~/.profile. Wenn Sie also keine Quelle ~/.bashrcangeben, verpassen Sie all diese hilfreichen Einstellungen in Ihrer .bashrc. Deshalb Ubuntus ~/.profileStandardquelle~/.bashrc

Zu vermeidender Fall

  • Sie sollten nie beziehen ~/.profileForm innen ~/.bashrczur gleichen Zeit , als ~/.bashrcvon sourced wird ~/.profile. Es wird eine Endlosschleife der Situation erstellen und infolgedessen wird Ihre Terminal-Eingabeaufforderung angehalten, es sei denn, Sie drücken Ctrl+ C. In einer solchen Situation, wenn Sie eine Zeile in Ihre setzen~/.bashrc
setze -x

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


Danke, das sind alles wahre und nützliche Informationen. Es geht einfach nicht auf meine Frage ein. Ich kenne die Unterschiede zwischen Anmelde- und Nicht-Anmelde-Shells. Meine Frage ist, warum auf Ubuntu-Systemen .profileSourcing ist .bashrc? SuSe Enterprise 10 macht das nicht und auch keine der Fedora-Versionen, die ich verwendet habe, aber das war vor Jahren, ich kann mich irren. CentOS 5.8 funktioniert seltsamerweise. Wie auch immer, sehen Sie meinen Standpunkt? Dies ist eine Design-Wahl und ich frage mich, warum es gemacht wurde.
Terdon

Ich habe die anderen von Ihnen genannten Linux-Distributionen nicht rigoros verwendet. können Sie mir sagen , wie sie Situationen wie aliased Befehle in SSH - Sitzung behandeln , die in definiert sind .bashrcoder in .bash_aliases. Zum Beispiel habe ich einen Alias ​​für lswie ls --color=autoin meinem .bashrcund wurde von meinem .bashrcbezogen .profile. Hier kann ich den Alias ​​auch von ssh verwenden. Oder ich könnte Proxy in SSH-Sitzung verwenden. Wenn ich meine nicht mit der Quelle .bashrcaus .profileIch löse diese Funktionen. Ich denke, es geht um eine bessere Benutzererfahrung.
Souravc

Sie tun es nicht, diese Aliase werden nicht funktionieren. Und ja, Sourcing .bashrcbehebt das. Aber es verursacht auch Probleme. Ich erinnere mich, dass ich beim ersten Mal, als ich ein System mit diesem Verhalten verwendete, diese seltsamen Meldungen immer wieder erhielt ssh, weil ich xset b offin meinem .bashrcSystem die Terminalklingel deaktivierte, aber nur in einem X-System gab Fehlermeldungen. Ich brauchte eine Ewigkeit, um herauszufinden, was los war, da ich nicht dachte, dass .bashrcdies beim Ausführen einer Login-Shell gelesen werden würde. Ich frage mich nur, ob es eine "offizielle" Aussage dazu gibt.
Terdon

Ich stimme mit Ihnen ein. Ich hatte früher auch einige Probleme . Aber es ist meist hilfreich und benutzerfreundlich, wenn Sie einige Sonderfälle berücksichtigen und vermeiden. Ist es nicht :)
souravc

Ja, dafür gibt es triftige Gründe. Ich war nur neugierig, ob Canonical jemals begründet hat, diese vorgelagerte Entscheidung beizubehalten.
Terdon
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.