Re: bash liest weder .profile noch .bash_profile ein
Andreas Pakulat <apaku@gmx.de> writes:
>On 11.Nov 2004 - 20:23:05, Helmut Waitzmann wrote:
>> Andreas Pakulat <apaku@gmx.de> writes:
>>
>> >On 08.Nov 2004 - 23:30:26, Helmut Waitzmann wrote:
>> >> Andreas Pakulat <apaku@gmx.de> writes:
>>
>> Denn der Witz ist, wie ich mit den Ausschnitten aus Fedoras
>> /etc/X11/xdm/Xsession gezeigt habe, dass bei Fedora Core release 1 *auch
>> beim Zugang über X11* eine der Dateien "$HOME"/.bash_profile,
>> "$HOME"/.profile oder "$HOME"/.login (je nachdem, welches "$SHELL" man
>> verwendet) abgearbeitet wird, einfach, weil "$SHELL" als
>> nicht-interaktives Login-Shell gestartet wird.
>
>Na das ist ja nicht so wild, dann legt man alles in .profile ab.
Es sei denn, man nutzt Debian Sarge. Dann ergeht es einem wie Christine
Slotty (Zitat):
| Es handelt sich bei der Shell, die ich meine, vermutlich nicht um eine
| Login-Shell, denn ich spreche von der unter KDE (die "Konsole").
Aha. Sie nutzt also KDE als session manager.
| Bisher habe ich RedHat benutzt, und da waren zumindest die Änderungen
| in der .bash_profile immer auch auf der "Konsole" vorhanden.
Genau. Das sind sie deswegen, weil es vermutlich RedHat wie Fedora
richtig macht und ein nicht-interaktives Login-"$SHELL" startet:
exec -l "$SHELL" -c ...
| Mein bisheriger Stand war der, dass man Änderungen in der
| .bash_profile in KDE erst "aktiviert" indem man sich an KDE neu
| anmeldet, weil es eben nur eine ursprüngliche Login-Shell gibt, die
| ihre Umgebungs-Einstellungen dann aber an die Konsole weitergibt.
Genau. Das ist das einzig sinnvolle: Das ganze KDE bekommt meine
Umgebungs-Einstellungen von meinem nicht-interaktiven Login-"$SHELL"
vererbt und alles ist in Butter.
| Das scheint nun hier in Debian nicht der Fall zu sein, und das wäre
| dann das was ich übersehen habe.
Das wäre dann ein Manko an Debian Sarge: ein nicht-interaktives
Nicht-Login-Shell und beim Start von KDE vermutlich auch kein
"$HOME"/.xsession. Folge: Ich kann nichts konfigurieren...
An Christine: Versuche mal, den gdm als Login-Manager zu verwenden und
dann dort, wenn Du Deine Sitzung mit KDE betreiben willst, KDE
auszuwählen.
In meinem Debian Woody passiert da dann folgendes:
Es wird das bash-Shell-Script /etc/gdm/Sessions/KDE gestartet, das so
beginnt (sieh nach, ob das bei Sarge ebenso ist):
#!/bin/bash -login
Es ist also ein nicht-interaktives bash-Login-Shell-Script und sollte
daher Deine "$HOME"/.bash_profile oder "$HOME"/.profile lesen.
Prüfe mal nach, ob diese Dateien tatsächlich nicht gelesen werden. Das
wäre dann ein Problem von Sarge.
>> Damit hat man verloren, wenn man seine Account-Initialisierungskommandos
>> sowohl in einer dieser Login-Shell-Startup-Dateien (für den
>> Text-orientierten Zugang), als auch in "$HOME"/.xsession eingetragen hat:
>> Denn dann werden sie *zweimal* ausgeführt, wenn man beim Login-Chooser
>> das "Default System Session" (d.h. "$HOME"/.xsession) ausgewählt hat.
>
>Du meinst wenn man Default System Session waehlt wird sowohl .xsession
>ausgewertet als auch .profile?
So ist es: zuerst (je nach "$SHELL") "$HOME"/.bash_profile,
"$HOME"/.profile oder "$HOME"/.login, danach "$HOME"/.xsession.
>Naja auch da kann man sich mit einer in .profile zu definierenden
>Variable behelfen.
Das wäre wohl zu tun: In Login-"$SHELL"s Startup-Datei eine
Umgebungsvariable, die anzeigt, dass ein Login-Shell gelaufen ist, setzen
und in "$HOME"/.xsession dann keine Initialisierung mehr vornehmen, wenn
diese Variable gesetzt ist.
>> >Aber auch Fedora Core wird jawohl $HOME/.xsession einlesen
>>
>> Ja, wenn man beim Login-Chooser keines der Session-Managers, sondern
>> "Default System Session" auswählt.
>>
>> Insofern wäre das passende Vorgehen bei Fedora Core release 1, dass der
>> Benutzer seine Initialisierungs-Kommandos *nur* in die
>> Login-Shell-Startup-Dateien, nicht auch noch in "$HOME"/.xsession,
>> reinschreibt. Dann werden sie
(gemeint sind die Initialisierungs-Kommandos)
>> , egal ob der grafische oder der Text-Zugang genutzt wird, genau
>> einmal abgearbeitet, und der Nutzer muss seinen Zugang an nur *einer*
>> Stelle konfigurieren.
>
>Da bringst du jetzt was durcheinander.
Nein, nein, das verhält sich bei Fedora genau so, wie ich in dem
Abschnitt, den Du zitierst, geschrieben habe. Und das ist auch gut
so: Login-"$SHELL" immer, "$HOME"/.xsession nur bei grafischem "Default
System Session".
>Denn Text-Zugang wertet niemals .xsession aus, wenn doch machen die da
>ziemlichen Schweinkram.
Wer behauptet denn so etwas? Das wäre in der Tat Unsinn; aber ich kann
Dich beruhigen: Es ist nicht der Fall.
>Damit ich dich richtig verstehe bei jedem grafischen Login ausser
>"Default System Session" wird .profile (durch eine login-Shell)
>ausgewertet aber .xsession nicht.
Genau.
>Und bei dem "Default System Session" wird .xsession zusaetzlich zu
>.profile ausgewertet? Dann ist die Loesung doch einfach - nur in
>.profile definieren.
Genau. Und so hatte es auch Christine Slotty (von RedHat her), bis sie
bei Debian Sarge auf die Nase gefallen ist.
>In jedem Falle sind eh Unterschiede von Distri zu Distri vorhanden, da
>muss man sich immer drauf einstellen. Deswegen wuerde ich auch nie
>versuchen mein komplettes $HOME einfach mitzunehmen...
Wenn es NFS-montiert ist, kannst Du Dich nicht dagegen wehren...
Ich kenne eine Umgebung, da teilen sich beispielsweise Fedora Core
release 1 und HP-UX (mit CDE) das selbe "$HOME"-Verzeichnis. Und CDE
sorgt ebenfalls dafür, dass "$SHELL"s Login-Startup-Dateien eingelesen
werden (falls gewünscht).
Angenommen, es wäre jetzt Debian Woody statt Fedora. Dann gäbe es mit
dem nicht-interaktiven Nicht-Login-"$SHELL" und dem fehlenden Abarbeiten
von "$HOME"/.profile et al. Ärger.
Daher fände ich es gut, wenn Debian den grafischen Zugang immer mit einem
nicht-interaktiven Login-"$SHELL" versähe (im bash-Shell-Script):
exec -l $SHELL -c ...
>> >> Allerdings ist shell-unabhängiges Quoting ziemlich schwierig.
>> >
>> >Grade da ist aber wieder etwas was Debian gerne moechte, naemlich ein
>> >#!/bin/sh
>> >
>> >und demzufolge Shellunabhaengigkeit erreichen...
>>
>> Hier bin ich mir nicht sicher, was Du mit "Shellunabhängigkeit" meinst:
>
>Mit Shellunabhaengigkeit meinte ich, dass die Befehle in einem Skript
>das /bin/sh als auszufuehrende Shell definiert auch nur Funktionen
>benutzt werden die mit /bin/sh funktionieren.
Ah, meinst Du "Debian will sich nicht auf bash, sondern nur auf das
POSIX-shell stützen"? Dann kann man vermutlich
exec -l ...
nicht schreiben (ich habe keinen POSIX-Standard vorliegen). Aber
Debian nutzt doch bash sonst auch (z.B. in /etc/gdm/Sessions/KDE). Was
spricht dagegen, das auch hier zu tun?
Die andere Bedeutung von "Shellunabhängigkeit", nämlich, dass es egal
ist, welches "$SHELL" der Benutzer sich ausgesucht hat, wird mit Fedoras
Lösung in /etc/X11/xdm/Xsession
exec -l $SHELL -c "$SSHAGENT $HOME/.xsession"
einigermaßen erreicht: Diese Kommandozeile ist ein bash-Kommando, das
ein nicht-interaktives Login-"$SHELL" startet und ihm die Kommandozeile
$SSHAGENT $HOME/.xsession
mitgibt.
--
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: