Martin Steigerwald <Martin@lichtvoll.de> (Mo 07 Jan 2013 14:02:14 CET):
> Am Montag, 7. Januar 2013 schrieb Heiko Schlittermann:
> > Martin Steigerwald <Martin@lichtvoll.de> (Mo 07 Jan 2013 13:17:34 CET):
> > > Alternativ halt dann doch Shell-Spezifisch in:
> > > /etc/bash.bashrc
> >
> > In den rc-Files hat das eigentlich nichts zu suchen, meine ich.
> > Umgebungsvariablen werden vererbt, müssen also nur rechtzeitig gesetzt
> > werden. Die rc-Files werden bei jeder interaktiven Shell gelesen, wenn
> > sie keine Login-Shell ist.
>
> Hmmm, ja. Und selbst wenn sie eine ist:
>
> martin@merkaba:~> grep bashrc .bash_profile
> # include .bashrc if it exists
> #if [ -f ~/.bashrc ]; then
> # source ~/.bashrc
> if [ -e ~/.bashrc ]
> # execute .bashrc if it exists.
> . ~/.bashrc
> martin@merkaba:~> grep bashrc /etc/profile
> # The file bash.bashrc already sets the default PS1.
> if [ -f /etc/bash.bashrc ]; then
> . /etc/bash.bashrc
>
> Nun, PATH ist in /etc/profile definiert und nicht in der /etc/bash.bashrc,
> also scheint Upstream Deine Meinung zu teilen.
Schön. Und das Sourcen der rc-Files machen die Login-Shells über die
profile-Dateien, sonst würden die rc-Files nicht gelesen werden und
Funktionen (die normalerweise nicht vererbt werden, ebensowenig wie
Aliase) würden in der Login-Shell nicht zur Verfügug stehen. Wäre auch
wieder blöd.
> > Die Shell im Terminal zu einer Login-Shell zu machen, ist eine gute
> > Sache, der neue PATH gilt dann aber eben nur für Kinder von Prozessen im
> > Terminal (und natürlich die Shell im Terminal selbst.
>
> Warum? De facto ist sie doch keine. Ich habe mich nicht extra mit für die
> Shell anmelden müssen.
Ja, darum ist ja bei vielen Terminals die Shell keine Login-Shell. Das
mit der der Login-Shell im Terminal ist m.E. nur, um eben dieses Problem
mit Umgebungsvariablen zu „fixen“.
> > Wenn Du es in der gesamten X-Umgebung brauchst, solltest Du es in einem
> > der Scripte der XSession unterbringen.
>
> Ich hab Pfad-Anpassungen für mich persönlich einfach in der ~/.zshrc
>
> Ja, ist vielleicht auch nicht der optimale Ort, doch ich bin da irgendwann
> ausgestiegen bei der verschachtelten Logik, wer da was wann einbindet.
Bei der zsh weiß ich nicht, wie es geht. Bei der Bash ist es einfach:
Login-Shell: /etc/profile¹
~/.bash_profile|~/.bash_login|~/.profile ¹
von
…
~/.bash_logout
Interaktiv (keine Login-Shell):
/etc/bash.bashrc
~/.bashrc
andere: $BASH_ENV kann den Namen einer zu lesenden Datei enthalten
¹) In diesen Files sollte ausdrüclich /etc/bash.bashrc respektive
~/.bashrc gelesen werden.
Was gehört wohin?
In die profile-Files: Alles, was wir vererben können, i.d.R.
Umgebungsvariablen, umask
In die rc-Files: Der Rest, also Funktionen, Aliase
> > > Inwieweit allerdings /etc/profile shell-übergreifend funktioniert, ist
> > > mir nicht ganz klar. Denn man zshall erwähnt nur Z-Shell-spezifische
> > > Konfigurationsdateien. Könnte also sein, dass es so oder so
> > > shell-spezifisch ist, und dann würde ich die rc/env-Dateien
> > > bevorzugen, damit es auch für Nicht-Login-Shells passt.
Ich hatte gerade irgendwo gefunden, daß bei der Zsh das ausdrücklich
gemacht werden muß, wenn man an /etc/profile interessiert ist.
> > Nicht-Login-Shells sind eigentlich immer (mehr oder weniger direkte)
> > Kinder von Login-Shells und sollten die Umgebung geerbt haben.
>
> Demnach müsste der Pfad aber auch in X11 gesetzt sein. Zumindest eine KDE-
> Sitzung wird über ein Shell-Skript hochgefahren. Und auch mit anderen Setups
> dürften Shell-Skripte die Hauptrolle spielen. Bei Matthias hat aber
> irgendetwas diese Vererbungslogik unterbrochen.
Wenn ein Shell-Script die Sitzung hochfährt, ist diese Shell noch lange
keine Login-Shell oder interaktive Shell. Es ist einfach nur eine Shell
und interessiert sich für $BASH_ENV respl. $ENV (wenn sie /bin/sh hieß).
> > > Ich dachte eigentlich sei /etc/environment für sowas auch gedacht, aber
> > > binden die anderen Dateien gar nicht ein:
…
> Hehe, korrekt oder nicht :). Ich erinnere mich noch gut an den umask-Bug-
> Report, wo es darum ging, wie man diese am besten global setzt. Mein
> aktueller Stand und das funktioniert auf der Arbeit tatsächlich so, ist
> pam_umask.
…
> Jow, man pam_env:
…
> $HOME/.pam_environment
> User specific environment file
> Das kann Matthias ja dann mal ausprobieren.
Dem habe ich nichs mehr hinzu zusetzen :)
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: 7CBF764A -
gnupg fingerprint: 9288 F17D BBF9 9625 5ABC 285C 26A9 687E 7CBF 764A -
(gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2 7E92 EE4E AC98 48D0 359B)-
Attachment:
signature.asc
Description: Digital signature