Andreas Pakulat <[EMAIL PROTECTED]> writes: >On 11.Nov 2004 - 20:23:05, Helmut Waitzmann wrote: >> Andreas Pakulat <[EMAIL PROTECTED]> writes: >> >> >On 08.Nov 2004 - 23:30:26, Helmut Waitzmann wrote: >> >> Andreas Pakulat <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>, (Helmut Waitzmann) [EMAIL PROTECTED]
