Re: bash liest weder .profile noch .bash_profile ein
Andreas Pakulat <apaku@gmx.de> writes:
>On 21.Oct 2004 - 23:24:03, Helmut Waitzmann wrote:
>> Andreas Pakulat <apaku@gmx.de> writes:
>>
>> >Nein, es gibt keine Login-Shell wenn man sich grafisch einloggt.
>>
>> Verstehe ich Dich richtig, dass beim grafischen login ~/.xsession (oder
>> äquivalentes) gestartet wird, ohne dass jemals unter der Kennung des
>> angemeldeten Benutzers ein login shell gelaufen ist?
>>
>> Oder willst den zitierten Satz nur im Sinne von "die Shells in KDE's
>> konsole sind keine login shells" verstanden wissen?
>
>Da fragst du den falschen, so gut kenne ich mich da nicht aus. Aber
>die KDE-Prozesse sind alle Kinder von init und nicht (wie bei dem
>startx-Verfahren) des X11-Servers (IIRC). Die Shells in KDE (*term,
>konsole...) sind alle nicht-login-shells und kriegen offensichtlich
>auch keine Einstellungen aus irgendeiner Login-Shell vererbt... Ich
>denke mit obigem ist das eventuell erklaerbar (wer wessen Kind ist)...
>
>> Den ersten Fall fände ich ein bug report wert, der zweite Fall ist völlig
>> in Ordnung.
>Wieso?
Warum ich den ersten Fall für eines bug reports wert halte:
DIE traditionelle Methode, bei der ein Benutzer seinen Zugang
konfiguriert, sind die Startup-Dateien im HOME-Verzeichnis, die login
shells beim Start einlesen. Der Sicherheit am zuträglichsten ist es,
wenn des Benutzers sicherheitsrelevante Eintragungen, wie etwa umask,
Umgebungsvariablen, u.a., von jedem Zugang (egal, ob login am
Nur-Text-Terminal, kde, gnome, su, slogin, ...) zum System beachtet
werden. Sonst vergisst er garantiert irgendwann, verschiedene
Konfigurationsdateien synchron zu halten, mit der Folge, dass irgendein
Zugang, etwa xdm, gdm, kdm, su, login, slogin noch ein Sicherheitsloch
hat, das der Benutzer bei den übrigen Zugängen bereits gestopft hat.
Weil es nun aber den textorientierten Zugang "login am Nur-Text-Terminal"
immer noch gibt und dabei die einzigen Konfigurationsdateien die eines login
shells (etwa ~/.profile) sind, muss dort also eine ordentliche
Konfiguration vorgenommen werden. Aus den oben genannten Gründen sollten
kde, gnome, xdm, su, slogin, ... diese Konfigurationsdatei ebenfalls
verwenden, indem sie ein login shell starten.
Warum ich den zweiten Fall für in Ordnung halte:
Ein login shell ist traditionell eines, an dem eine interaktive Sitzung
hängt und mit dem sie steht und fällt. Daher würde ich in die
Konfigurationsdatei eines login shells (etwa ~/.profile, ~/.login,
~/.bash_profile) solche Kommandos stellen, die die Umgebung nicht nur für
dieses shell, sondern für alle daraus gestarteten Prozesse beeinflusst,
beispielsweise umask-, ulimits-, und solche Kommandos, die die
Umgebungsvariablen beeinflussen.
Diese Kommandos sollen aber nur ein einziges Mal innerhalb einer Sitzung
ausgeführt werden, nicht jedes Mal aufs Neue, wenn ich z.B. in kde ein
neues konsole-Fenster öffne. Daher ist der zweite Fall für mich in
Ordnung.
Ein Beispiel soll das verdeutlichen: Angenommen, ich möchte unterhalb
meines HOME-Verzeichnisses ein Verzeichnis anlegen, in das ich
selbstgeschriebene Programme stelle. Diese Programme sollen natürlich
vom shell gefunden werden. Also stelle ich das Verzeichnis in den PATH.
Für das bourne shell nehme ich die Datei ~/.profile und schreibe hinein:
export PATH
PATH="$HOME"/bin:"${PATH:-/usr/local/bin:/usr/bin:/bin}"
Wenn jetzt ein konsole ein login shell starten würde, käme bei jedem
shell, das in einem konsole läuft, an den PATH vorne "$HOME"/bin/: dran.
Wenn ich also aus einem konsole ein weiteres starte, indem ich darin
konsole &
eintippe, wäre "$HOME"/bin dann schon zweimal im PATH u.s.f., was keine
gute Idee ist.
Daher würde ich innerhalb einer interaktiven Sitzung nur EIN shell als
login shell laufen lassen. Und zwar müsste es das shell sein, von dem
alle meine Prozesse, die ich in der Sitzung starte, die Umgebung
erhalten.
--
Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please
Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with
meinen Vor- und Nachnamen, etwa so: | my full name, like
Helmut Waitzmann <xxx@example.net>, (Helmut Waitzmann) xxx@example.net
Reply to: