Re: bash liest weder .profile noch .bash_profile ein
Andreas Pakulat [EMAIL PROTECTED] writes:
On 12.Nov 2004 - 03:09:15, Helmut Waitzmann wrote:
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...
Dann legt man eine $HOME/.xsession an,
Da bringst Du mich auf eine Idee, s.u.
Login-$SHELL immer, $HOME/.xsession nur bei grafischem
Default System Session.
?? Wie funktionniert das denn mit KDE und Gnome Programmen? In
Sid/Sarge muss man wenn man KDE benutzt den gnome-settings-daemon
starten, sonst sehen saemtliche Gnome-Programme ziemlich mistig aus.
Keine Ahnung. Ich nutze KDE nicht.
Das kann ich wohl bei Fedora dann nicht mehr oder, da ja .xsession
nicht ausgewertet wird. Das ist IMHO ein Fehler bei Fedora,
Dreh den Spieß um: Leg einfach eine $HOME/.xsession an, wähl am login
chooser Default System Session und starte in Deiner $HOME/.xsession
alles weitere (z.B. KDE und gnome-settings-daemon) selbst.
Und um automatisches Starten eines Login-Shells zu erzwingen, falls zuvor
noch keines gelaufen ist, könnte man es so machen:
In der Startup-Datei des Login-$SHELLs die Umgebungsvariable
MY_HAVE_LOGINSHELL setzen und in $HOME/.xsession schreiben:
#!/bin/sh
if test -z ${MY_HAVE_LOGINSHELL+defined}
then
# Es ist noch kein Login-Shell gelaufen, starte eines und lasse es
# $HOME/.xsession starten:
#
# Voraussetzung: bash wird im PATH gefunden (muss nicht in /bin
# sein). bash ist hier noetig wegen exec -l.
exec bash -c 'exec -l ${1+$@}' bash $SHELL -c $HOME/.xsession
fi
# Hier folgt der Rest von $HOME/.xsession
Damit startet sich $HOME/.xsession notfalls rekursiv über ein
Login-$SHELL, und man kriegt eine ziemlich distributionsunabhängige
Konfiguration hin.
--
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]
Re: bash liest weder .profile noch .bash_profile ein
On 12.Nov 2004 - 03:09:15, Helmut Waitzmann wrote: 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. Ich auch und ich hab bisher keine Probleme :-) Allerdings setze ich meine Sprache auch in /etc/environment und meine $HOME/bin wird in .bashrc eingebunden falls es noch nicht im Pfad steht ;-) | 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: So und an welcher Stelle hast du jetzt nen Bugreport gegen kdm, gdm und die anderen Pakete mit *session Dateien geschrieben? | 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 Dann schreib nen Bugreport gegen die entsprechenden Pakete. | 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... Dann legt man eine $HOME/.xsession an, wo ist das Problem? $HOME/.profile muss ich ja auch veraendern wenn ich was anderes als die Default-Werte will. 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: Aber in Sarge nicht, da ist das keine loginshell mehr. Die andere Loesung ist .xsession anzulegen. , 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. ?? Wie funktionniert das denn mit KDE und Gnome Programmen? In Sid/Sarge muss man wenn man KDE benutzt den gnome-settings-daemon starten, sonst sehen saemtliche Gnome-Programme ziemlich mistig aus. Das kann ich wohl bei Fedora dann nicht mehr oder, da ja .xsession nicht ausgewertet wird. Das ist IMHO ein Fehler bei Fedora, AFAIK ist .xsession immer! auszuwerten wenn X11 startet. 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. Tja das ist nunmal so, wenn man die Distri wechselt, man muss sich die Aenderung erstmal in Ruhe zu Gemuete fuehren. 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... Das stimmt allerdings... 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 ... Zum 3. Male in dieser Mail: Schreib nen Bugreport und setze Severity auf important. 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 ... Ganz genau, das ist bei Debian so festgelegt, nach Moeglichkeit nur POSIX-konforme Shellskripte. nicht schreiben (ich habe keinen POSIX-Standard
Re: bash liest weder .profile noch .bash_profile ein
Andreas Pakulat [EMAIL PROTECTED] writes: On 08.Nov 2004 - 23:30:26, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: [Im folgenden Zitat bezog ich mich darauf, dass Du die Kommandos, die beim Sitzungsstart nur einmal ausgeführt werden sollen, in $HOME/.xsession und in $HOME/.profile schreiben kannst, weil sie so sowohl beim X11-Zugang als auch beim textorientierten Zugang genau einmal ausgeführt werden.] Das stimmt in diesem Fall natürlich. Was die Sache ärgerlich macht, ist, dass das z.B. für die Distribution Fedora Core release 1 bereits nicht mehr stimmt: Dort finden sich in '/etc/X11/gdm/Sessions' die Shellscripte 'GNOME' und 'KDE', die nichts tun, als ein exec /etc/X11/xdm/Xsession gnome bzw. exec /etc/X11/xdm/Xsession kde [... zu starten.] 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. 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. 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, egal ob der grafische oder der Text-Zugang genutzt wird, genau einmal abgearbeitet, und der Nutzer muss seinen Zugang an nur *einer* Stelle konfigurieren. 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: Meinst Du Der Benutzer kann sich sein Login-Shell auswählen und konfigurieren, und der grafische Zugang macht mit diesem vom Benutzer gewählten Shell eine ordentliche Initialisierung, egal, welches Shell der Benutzer sich ausgesucht hat. ? Oder meinst Du Der Benutzer soll sich daran gewöhnen, für die Konfiguration seines Accounts im Falle des grafischen Logins nur seine Datei $HOME/.profile zur Konfiguration zu verwenden. X11 hat mit keinem anderen Shell als /bin/sh etwas zu tun, denn es ignoriert die Umgebungsvariable SHELL und nimmt immer /bin/sh, ist also davon, was der Benutzer als Login-Shell gewählt hat, unabhängig, bürdet ihm aber damit auf, (falls er nicht /bin/sh oder bash als Login-Shell gewählt hat), zwei Login-Shells konfigurieren zu müssen. ? Ich ziehe hier Fedoras Vorgehensweise vor: Mein Account konfiguriere ich in der Startup-Datei meines Login-$SHELLs. Dann wird die Konfiguration immer verwendet, egal, ob ein Text-orientierter oder grafischer Zugang beim Login verwendet wird. -- 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]
Re: bash liest weder .profile noch .bash_profile ein
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. 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? Naja auch da kann man sich mit einer in .profile zu definierenden Variable behelfen. 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, 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. Denn Text-Zugang wertet niemals .xsession aus, wenn doch machen die da ziemlichen Schweinkram. Damit ich dich richtig verstehe bei jedem grafischen Login ausser Default System Session wird .profile (durch eine login-Shell) ausgewertet aber .xsession nicht. Und bei dem Default System Session wird .xsession zusaetzlich zu .profile ausgewertet? Dann ist die Loesung doch einfach - nur in .profile definieren. 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... 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. Also keine $SHELL spezifischen Dinge, wie z.B. . /zu/sourcende/Datei. Ich ziehe hier Fedoras Vorgehensweise vor: Mein Account konfiguriere ich in der Startup-Datei meines Login-$SHELLs. Dann wird die Konfiguration immer verwendet, egal, ob ein Text-orientierter oder grafischer Zugang beim Login verwendet wird. Jedem das sein, das ist ja nicht schwer fuer Debian zu adaptieren oder? Andreas -- The heaviest object in the world is the body of the woman you have ceased to love. -- Marquis de Lac de Clapiers Vauvenargues -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: bash liest weder .profile noch .bash_profile ein
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-$SHELLs 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
Re: bash liest weder .profile noch .bash_profile ein
Andreas Pakulat [EMAIL PROTECTED] writes: On 30.Oct 2004 - 22:44:23, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: On 26.Oct 2004 - 02:06:34, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: Die Auswahl KDE im Sessions-Men des GDM, /etc/gdm/Sessions/KDE, macht es richtig: Das shell script beginnt mit folgender Zeile: #!/bin/bash -login Das ist ein (nicht-interaktives) Login-bash-Skript, das beim Start zunchst /etc/profile und danach $HOME/.bash_profile oder $HOME/.profile liest. Also /etc/kde3/kdm/Xsession sourced /etc/X11/Xsession und hat #! /bin/sh Also in unstables gdm gibts keine KDE Session und da die eine bash benutzt wuerde ich ja mal behaupten wollen, die hast du selbst geschrieben oder? Bei mir war es in der Debian-Woody-Distribution so drin. Ich habe daran nichts verndert. Beim Login mittels eines Display-Managers haengt der X11-Server am Displaymanager: init kdmXFree86 kdmx-session-managgnome-settings- kwrapper ssh-agent kdm, wiederum wird von init ausgefuehrt, als letztes der Init-Skripte und benutzt wiederum soweit ich das sehe eine nicht-interaktive nicht-login-shell. Wenn da also kdm oder x-session-manag (ksmserver?) keine $HOME/.profile entsprechende Konfigurationsmglichkeit bietet, sieht es in der Tat nicht gut aus. x-session-manager == /etc/alternatives/x-session-manager und das zeigt aufs startkde Skript. Wie gesagt ich kann solche Sachen die nur einmal ausgefuehrt werden sollen mit in meine $HOME/.xsession schreiben, die wird beim Start der Session ausgefuehrt und sonst nicht, aehnlich .profile bei normalen login-Shells. Das stimmt in diesem Fall natrlich. Was die Sache rgerlich macht, ist, dass das z.B. fr die Distribution Fedora Core release 1 bereits nicht mehr stimmt: Dort finden sich in '/etc/X11/gdm/Sessions' die Shellscripte 'GNOME' und 'KDE', die nichts tun, als ein exec /etc/X11/xdm/Xsession gnome bzw. exec /etc/X11/xdm/Xsession kde zu starten. /etc/X11/xdm/Xsession aber ist ein bash-Shellscript, in dem (je nachdem, was fr ein Session man ausgewhlt hat) zum Schluss eines der folgenden Kommandos ausgefhrt wird: exec -l $SHELL -c $SSHAGENT /usr/share/apps/switchdesk/Xclients.$1; exec -l $SHELL -c xterm -geometry 80x24-0-0 exec -l $SHELL -c $SSHAGENT gnome-session exec -l $SHELL -c $SSHAGENT /usr/share/apps/switchdesk/Xclients.kde exec -l $SHELL -c $SSHAGENT /usr/share/apps/switchdesk/Xclients.twm exec -l $SHELL -c $SSHAGENT $1 exec -l $SHELL -c $SSHAGENT $HOME/.xsession exec -l $SHELL -c $SSHAGENT $HOME/.Xclients exec -l $SHELL -c $SSHAGENT /etc/X11/xinit/Xclients exec -l $SHELL -c xsm Das wird jedesmal des Benutzers $SHELL als nicht-interaktives login-shell gestartet (siehe Beschreibung des Parameters -l zum Kommando exec des bash) und ihm ein Kommando bergeben, das dann jeweils das gewnschte Session hochfhrt. Das halte ich fr (beinahe) vorbildlich: Egal, welches shell sich der Benutzer als $SHELL (via /etc/passwd o..) auch ausgesucht und via $HOME/.bash_profile, $HOME/.profile oder $HOME/.login konfiguriert hat: Es wird als nicht-interaktives login-shell gestartet. Damit ist eine ordentliche Konfiguration nach des Benutzers Wnschen sichergestellt. Knnte so etwas Debian nicht auch hinbekommen? Beinahe vorbildlich nenne ich es deshalb, weil beim Zusammensetzen der Kommandozeile (der Parameter zum $SHELL-option '-c') Variablen-Auswertungen ohne Quoting verwendet werden. Soweit aber die Variablen SSHAGENT, HOME und 1 fr das betreffende $SHELL unzerbrechliche Werte enthalten (was vermutlich der Fall sein drfte), ginge das nochmal gut. Das prft aber /etc/X11/Xsession zuvor nicht ab. Allerdings ist shell-unabhngiges Quoting ziemlich schwierig. Am ehesten knnte ich mir da noch folgende Vorgehensweise vorstellen: 1. Schreibe ein ' (ohne die Anfhrungszeichen) hin. 2. Nimm den Variablenwert, setze hinter jedes darin enthaltene Apostroph die Zeichenfolge \'' (ohne die Anfhrungszeichen). 3. Schreibe noch ein ' (ohne die Anfhrungszeichen) hin. So entsteht ein in Apostrophe eingeschlossener Text, dessen in ihm enthaltene Apostrophe ordentlich verpackt sind. Der Knigsweg, statt beispielsweise exec -l $SHELL -c $SSHAGENT $1 lieber exec -l $SHELL -c '$@' -`basename $SHELL` $SSHAGENT $1 hinzuschreiben, scheitert daran, dass erstens der Ausdruck $@ nicht in allen shells fr die positional parameters steht und zweitens manche -- aber nicht alle -- shells in diesem Fall als ersten Parameter nach der Kommandozeile den Namen des shells selbst, mit einem Minuszeichen vorne dran versehen, verlangen: Das bash und das bourne shell verlangen es, das csh und das tcsh verbieten es, das ksh verlangt oder verbietet es je nach Fassung oder OS. Es ist ein Graus. -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse
Re: bash liest weder .profile noch .bash_profile ein
On 08.Nov 2004 - 23:30:26, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: Also in unstables gdm gibts keine KDE Session und da die eine bash benutzt wuerde ich ja mal behaupten wollen, die hast du selbst geschrieben oder? Bei mir war es in der Debian-Woody-Distribution so drin. Ich habe daran nichts verändert. Warte mal ab bis sarge stable wird ;-) Das stimmt in diesem Fall natürlich. Was die Sache ärgerlich macht, ist, dass das z.B. für die Distribution Fedora Core release 1 bereits nicht mehr stimmt: Dort finden sich in '/etc/X11/gdm/Sessions' die Shellscripte 'GNOME' und 'KDE', die nichts tun, als ein exec /etc/X11/xdm/Xsession gnome bzw. exec /etc/X11/xdm/Xsession kde Aber auch Fedora Core wird jawohl $HOME/.xsession einlesen oder irre ich da? Das waere ansonsten IMHO ein ziemlicher Bloedsinn den die da verzapft haben. Könnte so etwas Debian nicht auch hinbekommen? Klaro, schreib ne entsprechende Anpassung fuer die relevanten Pakete und Bugreports mit den entsprechenden Patches. Allerdings ist shell-unabhängiges Quoting ziemlich schwierig. Am ehesten könnte ich mir da noch folgende Vorgehensweise vorstellen: Grade da ist aber wieder etwas was Debian gerne moechte, naemlich ein #!/bin/sh und demzufolge Shellunabhaengigkeit erreichen... Andreas -- The one good thing about repeating your mistakes is that you know when to cringe. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: bash liest weder .profile noch .bash_profile ein
On 30.Oct 2004 - 22:44:23, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: On 26.Oct 2004 - 02:06:34, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: Und? Die lesen auch keine .profile oder /etc/profile . Genau. Darum ist es Unsinn, zu sagen Nimm ~/.bashrc, das wird immer eingelesen. Denn das stimmt bei nicht-interaktiven shells nicht. Stimmt, mein Fehler. Die Auswahl KDE im Sessions-Men des GDM, /etc/gdm/Sessions/KDE, macht es richtig: Das shell script beginnt mit folgender Zeile: #!/bin/bash -login Das ist ein (nicht-interaktives) Login-bash-Skript, das beim Start zunchst /etc/profile und danach $HOME/.bash_profile oder $HOME/.profile liest. Also /etc/kde3/kdm/Xsession sourced /etc/X11/Xsession und hat #! /bin/sh Also in unstables gdm gibts keine KDE Session und da die eine bash benutzt wuerde ich ja mal behaupten wollen, die hast du selbst geschrieben oder? Schliesslich sind in Debian-Paketen meist /bin/sh die Shells. Oder ist das Gnome2.8 aus experimental Ja, aber die kannst du sowieso nicht weiter konfigurieren, weder mit *profile, nocht mit *bashrc. Genau. Du hast es ja doch verstanden. Darum halte ich beim startup nicht-interaktive nicht-login-shells eines Fehlerberichtes wert. Tja, dann musst du zu gdm, wdm, xdm und kdm mit einem neuen Fehlerbericht schreiben. (xdm und wdm hab ich jetzt nicht ueberprueft...) Beim Login mittels eines Display-Managers haengt der X11-Server am Displaymanager: init kdmXFree86 kdmx-session-managgnome-settings- kwrapper ssh-agent kdm, wiederum wird von init ausgefuehrt, als letztes der Init-Skripte und benutzt wiederum soweit ich das sehe eine nicht-interaktive nicht-login-shell. Wenn da also kdm oder x-session-manag (ksmserver?) keine $HOME/.profile entsprechende Konfigurationsmglichkeit bietet, sieht es in der Tat nicht gut aus. x-session-manager == /etc/alternatives/x-session-manager und das zeigt aufs startkde Skript. Wie gesagt ich kann solche Sachen die nur einmal ausgefuehrt werden sollen mit in meine $HOME/.xsession schreiben, die wird beim Start der Session ausgefuehrt und sonst nicht, aehnlich .profile bei normalen login-Shells. Andreas -- idleness, n.: Leisure gone to seed. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: bash liest weder .profile noch .bash_profile ein
Andreas Pakulat [EMAIL PROTECTED] writes: On 26.Oct 2004 - 02:06:34, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: Schreib sie in die $HOME/.bashrc, dann werden sie immer eingelesen... Nein. Dann werden sie von allen interaktiven nicht-login-shells eingelesen; nicht-interaktive nicht-login-shells lesen kein ~/.bashrc. Und? Die lesen auch keine .profile oder /etc/profile . Genau. Darum ist es Unsinn, zu sagen Nimm ~/.bashrc, das wird immer eingelesen. Denn das stimmt bei nicht-interaktiven shells nicht. Und weil das erste Shell-Skript, das bei einem grafischen login unter der Kennung des angemeldeten Benutzers gestartet wird, nun einmal von einem nicht-interaktiven shell gelesen wird (interaktive shells gibt es dann erst in Terminal-Emulatoren), kann man ihm nur auf die Weise eine ordentliche Konfiguration verpassen, dass man es zum login-shell macht. Die Auswahl KDE im Sessions-Men des GDM, /etc/gdm/Sessions/KDE, macht es richtig: Das shell script beginnt mit folgender Zeile: #!/bin/bash -login Das ist ein (nicht-interaktives) Login-bash-Skript, das beim Start zunchst /etc/profile und danach $HOME/.bash_profile oder $HOME/.profile liest. Nein, du kannst den ganzen Kram doch in eine ~/.bashrc tun und die noch in der .bash_profile sourcen. Dadurch kommst du bei jeder! Shell in den Genuss deiner Konfiguration. Nein. Nicht-interaktive nicht-login-shells bleiben da auen vor (siehe manual bash(1)). Ja, aber die kannst du sowieso nicht weiter konfigurieren, weder mit *profile, nocht mit *bashrc. Genau. Du hast es ja doch verstanden. Darum halte ich beim startup nicht-interaktive nicht-login-shells eines Fehlerberichtes wert. Nicht-interaktive nicht-login-shells sind im Normalfall Skripte, die saemtliche Umgebungsvariablen selbst setzen muessen... Eigentlich nicht. Eher sind es Skripte, die ihre Umgebungsvariablen bereits fertig in der Umgebung geliefert bekommen. Ich denke immernoch, das *dm keine Loginshell aufmachen, KDE aus der GDM-Auswahl ist ein Login-Shell, die anderen Auswahlmglichkeiten (Debian, Gnome, Xsession) allerdings nicht. da ja saemtliche Prozesse danach direkt an init haengen... Ich sehe zwischen keine Loginshell und smtliche Prozesse direkt an init hngen keinen Zusammenhang. Erklrst Du ihn mir? Klaro: Hab mich da etwas ungluecklich ausgedrueckt... Was ich meinte war: Der X11-Prozess haengt an init. Wenn man mittels startx den Xserver startet sieht das ganze so aus: init | |- bash -- startx -- xinit -- XFree86 .. | |- x-session-manager Und das bash ist ein login shell und baut eine ordentliche Umgebung fr startx usw. auf. Da ist also alles in Ordnung. Beim Login mittels eines Display-Managers haengt der X11-Server am Displaymanager: init kdmXFree86 kdmx-session-managgnome-settings- kwrapper ssh-agent kdm, wiederum wird von init ausgefuehrt, als letztes der Init-Skripte und benutzt wiederum soweit ich das sehe eine nicht-interaktive nicht-login-shell. Wenn da also kdm oder x-session-manag (ksmserver?) keine $HOME/.profile entsprechende Konfigurationsmglichkeit bietet, sieht es in der Tat nicht gut aus. -- 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]
Re: bash liest weder .profile noch .bash_profile ein
Andreas Pakulat [EMAIL PROTECTED] writes: On 24.Oct 2004 - 01:27:11, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: On 21.Oct 2004 - 23:24:03, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: 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. Schreib sie in die $HOME/.bashrc, dann werden sie immer eingelesen... Nein. Dann werden sie von allen interaktiven nicht-login-shells eingelesen; nicht-interaktive nicht-login-shells lesen kein ~/.bashrc. Aber selbst das ist keine gute Idee, wie das Beispiel mit dem PATH zeigt. 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. Nein, du kannst den ganzen Kram doch in eine ~/.bashrc tun und die noch in der .bash_profile sourcen. Dadurch kommst du bei jeder! Shell in den Genuss deiner Konfiguration. Nein. Nicht-interaktive nicht-login-shells bleiben da außen vor (siehe manual bash(1)). Klappt hier wunderbar. Meine .bash_profile enthaelt ausser ner Umask eigentlich nur noch das source.. Ich denke immernoch, das *dm keine Loginshell aufmachen, da ja saemtliche Prozesse danach direkt an init haengen... Ich sehe zwischen keine Loginshell und sämtliche Prozesse direkt an init hängen keinen Zusammenhang. Erklärst Du ihn mir? -- 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]
Re: bash liest weder .profile noch .bash_profile ein
On 26.Oct 2004 - 02:06:34, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: On 24.Oct 2004 - 01:27:11, Helmut Waitzmann wrote: Schreib sie in die $HOME/.bashrc, dann werden sie immer eingelesen... Nein. Dann werden sie von allen interaktiven nicht-login-shells eingelesen; nicht-interaktive nicht-login-shells lesen kein ~/.bashrc. Und? Die lesen auch keine .profile oder /etc/profile . Aber selbst das ist keine gute Idee, wie das Beispiel mit dem PATH zeigt. Hmm, sowas koennte man mit einem grep ueberpruefen (klappt hier wunderbar)... Nein, du kannst den ganzen Kram doch in eine ~/.bashrc tun und die noch in der .bash_profile sourcen. Dadurch kommst du bei jeder! Shell in den Genuss deiner Konfiguration. Nein. Nicht-interaktive nicht-login-shells bleiben da auen vor (siehe manual bash(1)). Ja, aber die kannst du sowieso nicht weiter konfigurieren, weder mit *profile, nocht mit *bashrc. Nicht-interaktive nicht-login-shells sind im Normalfall Skripte, die saemtliche Umgebungsvariablen selbst setzen muessen... Ich denke immernoch, das *dm keine Loginshell aufmachen, da ja saemtliche Prozesse danach direkt an init haengen... Ich sehe zwischen keine Loginshell und smtliche Prozesse direkt an init hngen keinen Zusammenhang. Erklrst Du ihn mir? Klaro: Hab mich da etwas ungluecklich ausgedrueckt... Was ich meinte war: Der X11-Prozess haengt an init. Wenn man mittels startx den Xserver startet sieht das ganze so aus: init | |- bash -- startx -- xinit -- XFree86 .. | |- x-session-manager Beim Login mittels eines Display-Managers haengt der X11-Server am Displaymanager: init kdmXFree86 kdmx-session-managgnome-settings- kwrapper ssh-agent kdm, wiederum wird von init ausgefuehrt, als letztes der Init-Skripte und benutzt wiederum soweit ich das sehe eine nicht-interaktive nicht-login-shell. Andreas -- Did you know that for the price of a 280-Z you can buy two Z-80's? -- P.J. Plauger -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: bash liest weder .profile noch .bash_profile ein
On 24.Oct 2004 - 01:27:11, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: On 21.Oct 2004 - 23:24:03, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] writes: 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. Schreib sie in die $HOME/.bashrc, dann werden sie immer eingelesen... 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. Nein, du kannst den ganzen Kram doch in eine ~/.bashrc tun und die noch in der .bash_profile sourcen. Dadurch kommst du bei jeder! Shell in den Genuss deiner Konfiguration. Klappt hier wunderbar. Meine .bash_profile enthaelt ausser ner Umask eigentlich nur noch das source.. Ich denke immernoch, das *dm keine Loginshell aufmachen, da ja saemtliche Prozesse danach direkt an init haengen... Ich teste gleich mal ob eine Aenderung meiner umask auch von KDE-Programmen aus sichtbar ist... Andreas -- Those lovable Brits department: They also have trouble pronouncing `vitamin'. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: bash liest weder .profile noch .bash_profile ein
kleiner Nachtrag: On 24.Oct 2004 - 10:34:28, Andreas Pakulat wrote: On 24.Oct 2004 - 01:27:11, Helmut Waitzmann wrote: DIE traditionelle Methode, bei der ein Benutzer seinen Zugang konfiguriert, sind die Startup-Dateien im HOME-Verzeichnis, die login shells beim Start einlesen. Richtig, zu den Startup-Dateien gehoert auch die $HOME/.xsession bzw. $HOME/.xinitrc. Ich denke immernoch, das *dm keine Loginshell aufmachen, da ja saemtliche Prozesse danach direkt an init haengen... Ich teste gleich mal ob eine Aenderung meiner umask auch von KDE-Programmen aus sichtbar ist... Ich sehe mich in diesem Verdacht bestaetigt. Aenderungen an $HOME/.bash_profile und /etc/profile werden beim grafischen Login nicht mit uebernommen. Es koennte allerdings sein, dass zumindestens /etc/profile bei einem Neustart des *dm eingelesen wird (das hab ich nicht getestet). Andreas -- A lack of leadership is no substitute for inaction. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: bash liest weder .profile noch .bash_profile ein
Am 2004-10-24 10:50:41, schrieb Andreas Pakulat:
kleiner Nachtrag:
On 24.Oct 2004 - 10:34:28, Andreas Pakulat wrote:
On 24.Oct 2004 - 01:27:11, Helmut Waitzmann wrote:
DIE traditionelle Methode, bei der ein Benutzer seinen Zugang
konfiguriert, sind die Startup-Dateien im HOME-Verzeichnis, die login
shells beim Start einlesen.
Richtig, zu den Startup-Dateien gehoert auch die $HOME/.xsession bzw.
$HOME/.xinitrc.
Ich denke immernoch, das *dm keine Loginshell aufmachen, da ja
saemtliche Prozesse danach direkt an init haengen... Ich teste gleich
mal ob eine Aenderung meiner umask auch von KDE-Programmen aus
sichtbar ist...
Ich sehe mich in diesem Verdacht bestaetigt. Aenderungen an
$HOME/.bash_profile und /etc/profile werden beim grafischen Login
nicht mit uebernommen. Es koennte allerdings sein, dass zumindestens
/etc/profile bei einem Neustart des *dm eingelesen wird (das hab ich
nicht getestet).
Schon mal die Manpages gelesen ?
Bei xdm und wdm wird die ~/.xsession genommen, welche bei einem
grafischen LOGIN die ~/.bashrc ersetzt. Du kanns allerdings auch
ein
( '/home/michelle/.xsession' )
/
| if [ -f ${HOME}/.bashrc ]; then
| source ${HOME}/.bashrc
| fi
| fvwm
\__
machen, womit sich das problem geregelt haben duerfte.
Fuer KDM und GDM gibt es etwas equivalentes, nur solltest Du bedenken,
das nicht alle optionen, die Du in der ~/.xsessin fuer xdm|wdm verwenden
kannst unter KDE und GNOME funktionieren, da dies ja Desktops sind, die
ihre eigene Resourcenverwaltung haben.
Die init-Datei fuer KDE und GNOME erfaehrst Du aus den Manualseiten
(Kann Dir nicht sagen, wie sie heist, da ich weder KDE noch GNOME habe)
Andreas
Greetings
Michelle
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com)
signature.pgp
Description: Digital signature
Re: bash liest weder .profile noch .bash_profile ein
On 24.Oct 2004 - 11:58:07, Michelle Konzack wrote: Am 2004-10-24 10:50:41, schrieb Andreas Pakulat: kleiner Nachtrag: On 24.Oct 2004 - 10:34:28, Andreas Pakulat wrote: On 24.Oct 2004 - 01:27:11, Helmut Waitzmann wrote: DIE traditionelle Methode, bei der ein Benutzer seinen Zugang konfiguriert, sind die Startup-Dateien im HOME-Verzeichnis, die login shells beim Start einlesen. Richtig, zu den Startup-Dateien gehoert auch die $HOME/.xsession bzw. $HOME/.xinitrc. Schon mal die Manpages gelesen ? Bei xdm und wdm wird die ~/.xsession genommen, welche bei einem grafischen LOGIN die ~/.bashrc ersetzt. Du kanns allerdings auch ein Du solltest naechstes Mal alles lesen, was ich geschrieben habe. Denn da steht ja das .xsession zu den Startupdateien gehoert... Andreas -- Youth of today! Join me in a mass rally for traditional mental attitudes! -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: bash liest weder .profile noch .bash_profile ein
Andreas Pakulat [EMAIL PROTECTED] writes:
On 21.Oct 2004 - 23:24:03, Helmut Waitzmann wrote:
Andreas Pakulat [EMAIL PROTECTED] 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 [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
Re: bash liest weder .profile noch .bash_profile ein
On 21.Oct 2004 - 23:24:03, Helmut Waitzmann wrote: Andreas Pakulat [EMAIL PROTECTED] 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? Andreas -- It was a virgin forest, a place where the Hand of Man had never set foot. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
bash liest weder .profile noch .bash_profile ein
Moin moin, meine bash scheint weder .profile noch .bash_profile einzulesen, obwohl das ja nun wirklich explizit in man bash drinsteht (ja, ich habe das Manual gelesen! ;-) ). Meine Debian-Version ist sarge - was könnte ich falsch machen? Um (wie üblich) nach der Installation eigene Pfade und Aliase zu setzen, auch einige der vorgeschlagenen, aber auskommentierten, habe ich zuerst nur .bash_profile, später aber auch .profile editiert, jedoch werden beide beim Systemstart nicht eingelesen. Auch habe ich z.B. den mc_wrapper eingefügt. Und noch eine Frage (wenn ich länger nachdenke fallen mir bestimmt noch 1000 weitere ein ;-) ): warum kommt man mit STRG-ALT-F1 eigentlich aus KDE nicht mehr auf eine Shell im ersten Terminal? Das hat doch bestimmt mit KDE oder dem XServer zu tun, war jedenfalls in RedHat auch schon der Fall. Bin für jede Hilfe dankbar, vielleicht stell ich mich auch blöd an oder habe irgendwas übersehen. Grüße, Christine -- Christine Slotty TUHH, IIW [EMAIL PROTECTED] -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: bash liest weder .profile noch .bash_profile ein
On 21.Oct 2004 - 12:31:55, Christine Slotty wrote: Moin moin, meine bash scheint weder .profile noch .bash_profile einzulesen, obwohl das ja nun wirklich explizit in man bash drinsteht (ja, ich habe das Manual gelesen! ;-) ). Sicher? Meine Debian-Version ist sarge - was könnte ich falsch machen? Um (wie üblich) nach der Installation eigene Pfade und Aliase zu setzen, auch einige der vorgeschlagenen, aber auskommentierten, habe ich zuerst nur .bash_profile, später aber auch .profile editiert, jedoch werden beide beim Systemstart nicht eingelesen. Auch habe ich z.B. den mc_wrapper eingefügt. Du loggst dich auf TTY1 ein und dann wird die Datei nicht gelesen? Dann ist das ein Bug in Bash. Wenn du dich mittels *dm anmeldest und dich wunderst, dass du in einem xterm (oder konsole ...) die Einstellungen nicht hast: Die Bash liste *profile nur ein, wenn sie ne Login-Shell ist, ansonsten ist *bashrc das was du willst. Und noch eine Frage (wenn ich länger nachdenke fallen mir bestimmt noch 1000 weitere ein ;-) ): warum kommt man mit STRG-ALT-F1 eigentlich aus KDE nicht mehr auf eine Shell im ersten Terminal? Das hat doch bestimmt mit KDE oder dem XServer zu tun, war jedenfalls in RedHat auch schon der Fall. Hatten wir letztens schonmal hier IIRC, aber ich weiss nicht ob das geloest wurde. Hier (sid) jedenfalls klappt das wunderbar... Andreas -- An INK-LING? Sure -- TAKE one!! Did you BUY any COMMUNIST UNIFORMS?? -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: bash liest weder .profile noch .bash_profile ein
meine bash scheint weder .profile noch .bash_profile einzulesen, obwohl das ja nun wirklich explizit in man bash drinsteht (ja, ich habe das Manual gelesen! ;-) ). Sicher? Okay... danke für den Hinweis. ;-) In `man bash` steht u.a. drin: When an _interactive_ shell that is _not a login shell_ is started, bash reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if these files exist. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of /etc/bash.bashrc and ~/.bashrc. Es handelt sich bei der Shell, die ich meine, vermutlich nicht um eine Login-Shell, denn ich spreche von der unter KDE (die Konsole). Bisher habe ich RedHat benutzt, und da waren zumindest die Änderungen in der .bash_profile immer auch auf der Konsole vorhanden. 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. Das scheint nun hier in Debian nicht der Fall zu sein, und das wäre dann das was ich übersehen habe. Du loggst dich auf TTY1 ein und dann wird die Datei nicht gelesen? Das weiß ich, ehrlich gesagt, nicht, da ich mich immer grafisch anmelde. Asche auf mein Haupt. ;-) Wie unten gesagt, an TTY1 kann ich mich nicht anmelden (was ich gerne würde), da STRG-ALT-F1 dunkel bleibt. Dann ist das ein Bug in Bash. Wenn du dich mittels *dm anmeldest und dich wunderst, dass du in einem xterm (oder konsole ...) die Einstellungen nicht hast: Die Bash liste *profile nur ein, wenn sie ne Login-Shell ist, ansonsten ist *bashrc das was du willst. Genau, das verstehe ich jetzt, danke. Und noch eine Frage (wenn ich länger nachdenke fallen mir bestimmt noch 1000 weitere ein ;-) ): warum kommt man mit STRG-ALT-F1 eigentlich aus KDE nicht mehr auf eine Shell im ersten Terminal? Das hat doch bestimmt mit KDE oder dem XServer zu tun, war jedenfalls in RedHat auch schon der Fall. Hatten wir letztens schonmal hier IIRC, aber ich weiss nicht ob das geloest wurde. Hier (sid) jedenfalls klappt das wunderbar... Okay... dann bleib ich einfach mal dran. -- Christine Slotty TUHH, IIW [EMAIL PROTECTED] -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: bash liest weder .profile noch .bash_profile ein
On 21.Oct 2004 - 14:11:37, Christine Slotty wrote: meine bash scheint weder .profile noch .bash_profile einzulesen, obwohl das ja nun wirklich explizit in man bash drinsteht (ja, ich habe das Manual gelesen! ;-) ). Sicher? Okay... danke für den Hinweis. ;-) Dafuer sin ma ja da. Es handelt sich bei der Shell, die ich meine, vermutlich nicht um eine Login-Shell, denn ich spreche von der unter KDE (die Konsole). Exakt. Dafuer ist die ~/.bashrc bzw. /etc/bash.bashrc (fuer Systemweite Dinge) da. Bisher habe ich RedHat benutzt, und da waren zumindest die Änderungen in der .bash_profile immer auch auf der Konsole vorhanden. Da wird in der /etc/bash.bashrc oder der ~/.bashrc die *profile Datei gesourced worden sein. Ich sehe da zwar keinen richtigen Sinn hinter, aber nunja... 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. Nein, es gibt keine Login-Shell wenn man sich grafisch einloggt. Die erhaelst du nur beim einloggen auf der Console. Die Shells in KDE's xterm (konsole genannt ;-) lesen nur /etc/bash.bashrc und ~/.bashrc ein, also hinterlege deine Sachen dort. Das scheint nun hier in Debian nicht der Fall zu sein, und das wäre dann das was ich übersehen habe. Jupp in Debian ist das ordentlich wie das die Manpage beschreibt. Andreas -- All other things being equal, a bald man cannot be elected President of the United States. -- Vic Gold -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: bash liest weder .profile noch .bash_profile ein
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. Nein, es gibt keine Login-Shell wenn man sich grafisch einloggt. Die erhaelst du nur beim einloggen auf der Console. Die Shells in KDE's xterm (konsole genannt ;-) lesen nur /etc/bash.bashrc und ~/.bashrc ein, also hinterlege deine Sachen dort. Jawohl! :-) Das scheint nun hier in Debian nicht der Fall zu sein, und das wäre dann das was ich übersehen habe. Jupp in Debian ist das ordentlich wie das die Manpage beschreibt. Ja... deswegen finde ich Debian ja auch so gut - auch wenn ich's noch nicht lange benutze ;-) Supi, danke. -- Christine Slotty TUHH, IIW [EMAIL PROTECTED] -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: bash liest weder .profile noch .bash_profile ein
Andreas Pakulat [EMAIL PROTECTED] writes: On 21.Oct 2004 - 14:11:37, Christine Slotty wrote: Bisher habe ich RedHat benutzt, und da waren zumindest die Änderungen in der .bash_profile immer auch auf der Konsole vorhanden. Da wird in der /etc/bash.bashrc oder der ~/.bashrc die *profile Datei gesourced worden sein. Ich sehe da zwar keinen richtigen Sinn hinter, aber nunja... Bei den meisten Terminal-Emulierungs-Programmen kann man einstellen, ob sie eine Login-Shell erzeugen. Das wird bei RedHat wohl standardmäßig anders gewesen sein. (Wäre zumindest auch eine Möglichkeit.) Gruß Malte -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: bash liest weder .profile noch .bash_profile ein
Am 2004-10-21 14:11:37, schrieb Christine Slotty: When an _interactive_ shell that is _not a login shell_ is started, bash reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if these files exist. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of /etc/bash.bashrc and ~/.bashrc. Es handelt sich bei der Shell, die ich meine, vermutlich nicht um eine Login-Shell, denn ich spreche von der unter KDE (die Konsole). Konsole ??? Das was Du von Dir gibst, hört sich aber nach einem kterm an. 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. So ware es auch bis zu meinem lezten Update... Jetzt habe ich kein funktionsfähiges 'xterm' mehr... Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: bash liest weder .profile noch .bash_profile ein
On 21.Oct 2004 - 16:56:01, Michelle Konzack wrote: Am 2004-10-21 14:11:37, schrieb Christine Slotty: Es handelt sich bei der Shell, die ich meine, vermutlich nicht um eine Login-Shell, denn ich spreche von der unter KDE (die Konsole). Konsole ??? Das was Du von Dir gibst, hört sich aber nach einem kterm an. kterm gibts nicht, das Programm heisst tatsaechlich konsole, deswegen gibts auch immer wieder Verwechslungen. Ich persoenlich habe mir angewoehnt fuer ttyX Console zu schreiben und fuer die Term-Emu von KDE (K|k)onsole. 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. So ware es auch bis zu meinem lezten Update... Jetzt habe ich kein funktionsfähiges 'xterm' mehr... Auch du aermste ;-) Nimm doch nen anderen Term-Emu Andreas -- Yow! Are you the self-frying president? -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: bash liest weder .profile noch .bash_profile ein
Am 2004-10-21 17:57:21, schrieb Andreas Pakulat: On 21.Oct 2004 - 16:56:01, Michelle Konzack wrote: So ware es auch bis zu meinem lezten Update... Jetzt habe ich kein funktionsfähiges 'xterm' mehr... Auch du aermste ;-) Nimm doch nen anderen Term-Emu Neee, ich will wissen was die geändert haben. 5 Jahre hats funktioniert, dann ein Update und nichts geht mehr. Andreas Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: bash liest weder .profile noch .bash_profile ein
Andreas Pakulat [EMAIL PROTECTED] 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? Den ersten Fall fände ich ein bug report wert, der zweite Fall ist völlig in Ordnung. Die erhaelst du nur beim einloggen auf der Console. Die Shells in KDE's xterm (konsole genannt ;-) lesen nur /etc/bash.bashrc und ~/.bashrc ein, also hinterlege deine Sachen dort. Dein weiterer Text legt den zweiten Fall nahe. Könntest Du das bitte nochmals deutlich machen? -- 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]
